[council] Jeff's Take on GAC-related issues for ICANN 78 (Long)
Mark Datysgeld
mark at governanceprimer.com
Mon Sep 25 16:44:05 UTC 2023
Thank you, Jeff. Please keep us up to date on the ".quebec" issue. :)
Best,
On 22 Sept 2023 17:01, jeff--- via council wrote:
> All,
>
> Full credit here to Paul McGrady who asked me a question on what I
> personally thought the issues for the GAC would be at the upcoming
> ICANN meeting and what if anything I believed may be subject to GAC
> advice. I thought I would share this with the full Council list so
> that you all could have discussions on these issues and be prepared.
>
> */Please note that my thoughts are based on discussions with the GAC
> Point of Contact and working on the agenda for ICANN 78. I am not
> speaking on behalf of the GAC PoC or the GAC as I cannot do that, nor
> do I have the ability to do so. This is being sent to you all with the
> huge caveat that everything is subject to change AND I have separated
> my _personal_ take on the topics in blue./*
>
> I am going to send out a more comprehensive version of this to the
> Council shortly before ICANN 78 which has the final agenda for the
> GAC/GNSO bilateral as well as some potential talking points. Some of
> these items below will likely be on the GAC/GNSO agenda, but likely
> not all of them due to time constraints.
>
> 1. _SubPro Topics:_
>
> a. Closed Generics - Status on the Facilitated Dialog and the
> future of Closed Generic discussions / implementation.
> /_
> _/
> /_Jeff's note_: If you recall the original draft letter proposed by
> the GNSO/GAC/ALAC chairs recommended that the Board be instructed to
> maintain the moratorium on Closed Generics from the last round, but
> the GNSO discussed removing that from the letter. The GAC has a very
> strong interest in the issue of Closed Generics and does not believe
> they should be allowed absent consensus policy on the topic (which of
> course is developed with GAC input). /
>
> b. IRT Progress on Next Round - _/Jeff's take/:_ /No known
> concerns here from GAC, just an update./
>
> c. Pending items still not addressed by the Board / Open Issues
> - PICs / RVCs:
> /_
> _/
> /_Jeff's Take_: As most GAC Advice on new gTLDs is implemented as a
> PIC, or may be implemented as an RVC if Registries respond to Early
> Warnings or comments, it is important to the GAC that these be
> incorporated as contractual commitments into the agreements (See ICANN
> 77 Communique Advice 2(a). GAC agrees that such commitments must be
> enforceable by ICANN through clear contractual obligations, and that
> consequences for the failure to meet those obligations should be
> specified in the relevant agreements with the contracted parties.
> However, they are looking to understand (as we are) the changes being
> proposed by the ICANN Board to the language. /
> - Private Auctions:
> /
> /
> /Jeff's take: The GAC has previously expressed on several occasions,
> including as Advice in its ICANN 77 Communique that, ICANN "ban or
> strongly disincentivize private monetary means of resolution of
> contention sets, including private auctions." (ICANN 77 Communique
> 4(a)(ii). They also do not want to see ICANN auctions of last resort
> in contention sets involving non-commercial applicants. /
>
> - Opening up small team to GAC participation
> (especially for items not accepted by the Board)
> /_
> _/
> /_Jeff's Take_: GAC members want to make sure that they are
> participating in the process to determine both the processes used, as
> well as the substance, of revisions to recommendations, new
> recommendations, not pursuing existing recommendations, etc. This is
> especially true for all of the issues that the GAC has already issued
> advice on as well as items that they previously deemed were of
> importance to the GAC./
>
> - Applicant Support (more than financial) -
> _
> _
> _Jeff's Take_: /Not surprisingly and also quite aligned with the GNSO,
> the GAC issued advice on Applicant Support (ICANN Communique 77,
> Advice #3). The Applicant Support program to be incredibly important
> to them and they want to make sure that applicants not only have
> access to financial assistance with the application, but also
> assistance in application preparation and ongoing registry management
> (including potentially a reduction in ICANN ongoing registry fees).
> They also want to make sure that the program is highly publicized to
> those that are the intended beneficiaries of the program./
> - GGP Initial Report -//
> /_
> _/
> /_Jeff's Take:_/ I would propose this/ gets combined with the topic
> above and may just be an update./
> - .quebec: Is this an issue for the GAC?
> /_
> _/
> /_Jeff's Take_: This issue of course is of interest to the GAC
> Canadian Reps, but as of today this issue has not gotten on the GAC
> agenda as a whole. That is not an indication of whether this issue is
> important or not, there just have not been any GAC-wide discussions on
> the topic. Because it was discussed within the GNSO Council this
> week, I raised it at the meeting today and the GAC Point of Contact is
> going to see if this is an issue for the GAC at this ICANN meeting./
> 2. _IGOs_
> a. Implementation of Curative Rights (what is the status of the
> IRT) -
> /_
> _/
> /_Jeff's Take_: I believe The GAC is supposed to get a briefing at
> ICANN78 from ICANN on the status of implementation of Curative Rights
> as well as the Watch Service (see below). They believe that these are
> must haves before ICANN should consider lifting the reservation of IGO
> Acronyms. This was in their GAC Communique as advice a couple of
> meetings ago. They want to discuss this with the GNSO. I do not
> expect further advice on this unless they affirm their previous advice
> or if it appears that ICANN is moving in a direction that is
> inconsistent with the previous GAC Advice./
> b. Question of Moratorium on IGO acronyms / watch service
> (which ICANN is supposed to develop) /- See Above./
> _
> _
> 3. _Future Policy Work on DNS Abuse_?
>
> Jeff's Take: /The GAC positions on this are well-known. They are
> supportive of the proposed contract amendments for the Contracted
> Parties but of course want to see more done on the policy front before
> the opening up of the next round. But I do not expect any advice
> here, just more of wanting an update on what is going on and making
> sure it is progressing. /
>
> 4. _WHOIS / Data Protection_
> a. Access to non-public information / "urgent requests" -
> /_Jeff's Take LONG):_ /
> /
> /
> /This relates to the pilot being lunched soon by ICANN with the
> Registrars. On August 23, 2023, the GAC Chair sent a letter to the
> ICANN Board
> (/https://www.icann.org/en/system/files/correspondence/caballero-to-sinha-23aug23-en.pdf),
> /to express its concerns over the time line to respond to requests in
> select emergency situations ("Urgent Requests"). They do not like the
> proposed three (3) business days currently in the EPDP Phase 1
> implementation report and want the ICANN Board to reconsider this. On
> September 8, 2023, the Registrars sent a letter to the ICANN Board
> (/https://www.icann.org/en/system/files/correspondence/heineman-to-sinha-08sep23-en.pdf)/ providing
> some context to the 3 business days stating that this language has
> been in the text since September 2021, but in August 2022 the language
> changed to requiring a response, "no longer than two (2) business days
> from receipt" which was put out for comment. This was a change from
> the Implementation Pilot Team without consultation of the full IRT.
> Once that was published, there were several meetings of the full IRT
> to come up with a compromise solution. The Compromise language
> published following the July 24, 2023 meeting, which the Registrars
> agree with, was:/
> /
> /
> /"10.6. For Urgent Requests for Lawful Disclosure, Registrar and
> Registry Operator MUST respond, as defined in Section 10.7, without
> undue delay, generally within 24 hours of receipt. /
> /
> /
> /10.6.1. If Registrar or Registry Operator cannot respond to an Urgent
> Request for Lawful Disclosure within 24 hours, it MUST notify the
> requestor within 24 hours of receipt of an Urgent Request for Lawful
> Disclosure of the need for an extension to respond. Registrar or
> Registry Operator’s extension notification to the requestor MUST
> include (a) confirmation that it has reviewed and considered the
> Urgent Request for Lawful Disclosure on its merits and determined
> additional time to respond is needed, (b) rationale for why additional
> time is needed, and (c) the time frame it will respond, as required by
> Section 10.7, which cannot exceed two (2) business days from the time
> of the initial receipt of the request. /
> /
> /
> /1//0.6.2. In addition to the extension provided for in Section
> 10.6.1, if responding to an Urgent Request for Lawful Disclosure is
> complex, or a large number of requests are received by Registrar or
> Registry Operator, it MAY extend the time for response up to an
> additional one (1) business day provided it notifies the requestor
> within (2) business days from the time of the initial receipt of the
> request of the updated time frame to respond explaining the need for
> an additional extension of time. "/
>
> /So according to the registrars, they are only requesting 3 business
> days if they have notified the requestor within 24 hours that it needs
> more time and if it needs 3 business days it needs to notify the
> requestor again within 2 business days from receipt of the original
> request. Registrars do not agree with the GAC's interpretation that
> this will always be 3 business days and believes that the GAC should
> have given the Board the full context. It is my impression that the
> GAC may believe that because it allows 3 business days that this will
> become the default./
> /
> /
> /This will be discussed by the GAC at ICANN 78./
> //
> b. Accuracy Issue and status of DPAs between the Contracted
> Parties and ICANN (Since this has been the reason for delaying policy
> work on accuracy).
>
> /_Jeff's Take:_ Accuracy of Registration data is of utmost importance
> to the GAC and "remains committed to working within the Accuracy
> Scoping Team to assess the current state of accuracy under ICANN's
> contracts." The GAC welcomes the completion of a Data Protection
> Impact Assessment on a contractual compliance audit that could shed
> light on the current state of accuracy. Although I believe they were
> ok with the initial 6-month delay of the Scoping Team work waiting for
> the DPAs, they are looking for more meaningful updates on where ICANN
> is with the DPAs . They would like to see policy work ASAP. I am not
> sure if there will be Advice on this, but it certainly is an issue of
> importance./
>
> 5. _SOI:_ Status of discussions on the representation of undisclosed
> clients.
>
> /_Jeff's Take:_ The GAC Is following this one closely and I believe
> they are aligned more with requiring disclosure of clients that are
> directly being represented in policy processes. Governments
> individually generally require full disclosure of clients when they
> engage in discussions with representatives of industry, the community,
> etc. Whether there will be advice on this at ICANN 78 or not, I don't
> think so. But it is an item of importance to them./
> /
> /
> /_Other GAC Activities / Issues (Jeff's Take)_/
> /
> /
> /1. /I discussed the proposed Charter for the Standing Committee on
> RDRS to help inform the next steps on the SSAD policy recommendations
> with the GAC PoC today. Specifically I discussed the composition
> which currently is made up of Councilors and members of the ePDP Phase
> 2 small team members. from the GAC, I believe Chris Lewis-Evans and
> Laureen Kapin had a "shared membership." Chris is no longer working
> with the Public safety working group and is in the private sector. So
> I am sure being able to appoint a replacement (not an alternate) will
> be important to them.
> /
> /
> /2. GAC is having two days of outreach sessions at ICANN 78 during
> the first weekend. The second day will focus on "emerging
> technologies" and getting briefings from ICANN Org on Blockchain in
> general and "alternative naming spaces" with an eye on trying to
> figure out what, if anything, is the GAC role./
> /
> /
> /3. GAC is also focused on the IANA Review, especially with respect
> to Articles 18 and 19 of the Bylaws.
> (https://www.icann.org/en/announcements/details/icann-board-convenes-second-iana-naming-function-review-ifr2-11-09-2023-en).
> This review is taking a broader look athat includes identifying
> whether the requirements identified in the IANA contract SOW are still
> relevant or whether they need changing. This is defined in Section
> 18.3 of the Bylaws. /
> /
> /
> /4. GAC will be looking at the Proposed Updates to Existing Rights
> Protection Mechanisms documentation
> (/https://www.icann.org/en/announcements/details/icanns-proposed-updates-to-existing-rights-protection-mechanisms-documentation-24-08-2023-en)
> /posted on August 24, 2023. /
> /
> /
> /5. There are a couple of ccTLD items the GAC will discuss including
> input on ccNSO PDP4 (initial Report on (de-) selection of IDN ccTLDs
> (/https://www.icann.org/en/announcements/details/icann-seeks-input-on-ccnso-pdp4-initial-report-on-de-selection-of-idncctlds-16-08-2023-en)
> and the proposed ccLD related Review mechanism Policy Proposal
> (https://www.icann.org/en/announcements/details/icann-seeks-input-on-a-specific-cctld-related-review-mechanism-policy-proposal-01-08-2023-en).
>
>
> /
> /
>
>
>
> _______________________________________________
> council mailing list
> council at gnso.icann.org
> https://mm.icann.org/mailman/listinfo/council
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
--
Mark W. Datysgeld [markwd.website <https://markwd.website>]
Director at Governance Primer [governanceprimer.com
<https://governanceprimer.com>]
ICANN GNSO Councilor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/council/attachments/20230925/ce52cf23/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lyl0mwzw.png
Type: image/png
Size: 11989 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/council/attachments/20230925/ce52cf23/lyl0mwzw-0001.png>
More information about the council
mailing list