Dear WG,
Please find a link below to project package for the TPR-P1 PDP (31 January 2023). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics.
Link: https://community.icann.org/x/MQDQCQ
1. Page 01 – Summary Dashboard, Project SitRep, and Activity Metrics
2. Page 02 – Meeting metrics, Roster, & Group Attendance
3. Page 03 – Project Plan, Gantt chart
4. Page 04 – Workplan
Key points:
* The WG Status is Behind Schedule and Health is At-Risk due to substantive review of the public comments for Phase 1A that in turn impacts restarting deliberations on Phase 1B. A PCR will be considered by the GNSO Council at its February meeting.
Please let staff know if you have questions.
Thank you.
B
Berry Cobb
Policy Development – Senior Program Manager
Internet Corporation for Assigned Names and Numbers (ICANN)
Mobile: +1 424 443 8960
Phone: +1 202 570 7240
Fax: +1 202 789 0104
Twitter: @berrycobb
www.icann.org<https://www.icann.org/>
All,
In the Tuesday (31 Jan) meeting, we had a discussion about Rec 13.
Two topics:
* Explicitly preventing a TAC having a lifetime longer than 14 days
* Allowing the Registry Operator the explicit freedom to have a policy that has the standard TAC lifetime for that Registry to be less than 14 days.
For context, here is a link to the Rec 13 doc
https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv…
First, explicitly preventing a TAC from having a lifetime longer than 14 days.
At present, the draft in
Sarah has made a suggestion (at the bottom of the googledoc) to insert “no more than” in the draft of 13.1.
13.1 The TAC MUST be valid for 14 calendar days from the time it is set at the Registry, enforced by the Registry
There was another suggestion made and subsequently rejected in the meeting. This was to add “must not exceed” (The TAC must not exceed…”) but that was rejected because it doesn’t require the TAC to be 14 days.
This edit solves the first point above, but (based on my reading) it prevents the Registry Operator from having a policy which has a standard TAC lifetime that is less than 14 days.
So… moving on to the second point:
As mentioned in the call 13.1 allows the Sponsoring Registrar to unilaterally set a TAC to null before 14 days “by agreement of the Registrar of Record and the RNH” (i.e. the RNH wants to cancel the transfer).
I am suggesting that the Registry Operator have the flexibility to have a policy that has its TACs be shorter than 14 days (for all TACs).
There was commentary on the call objecting to this flexibility because it would be “nonstandard”. Regarding this concern, I’ve inserted a minimum into the text below.
However, I think that most Ry operators will stick to the standard TTL because the Ry is incented to have most transfers proceed easily with the standard 14-day TTL. Like the gaining registrar, the registry has a revenue-generating transaction from a normal transfer.
But certain geos or high-security TLDs that may want to require transfers to occur more quickly, with a shorter window for TAC validity.
Using the existing text as a base… and making minimal changes:
13.1. The default standard duration of TAC validity is 14 calendar days. The Registry MAY have a policy that establishes a duration of TAC validity that is less than 14 days but must be greater than or equal to 5 calendar days. The TAC MUST be valid for the duration of TAC validity from the time it is set at the Registry, enforced by the Registry
Choosing to rewrite 13.1 to have the same effect, we would get:
13.1. The maximum and default standard duration of TAC validity is 14 calendar days. The Registry MAY have a policy that establishes a shorter duration that is no less than 5 calendar days. The duration of TAC validity is enforced by the Registry, beginning when the TAC is set at the registry
OR we could split this 13.1 into two parts… one of which talks about the Ry duration and the other which talks about enforcement. (This might be considered editorial.)
Regardless… any of these would require agreement that the Registry Operator has the flexibility to set a registry-wide policy about a TAC TTL for that TLD.
I think that this is both important for Registry flexibility and equitable because the Registry is responsible for enforcing the TTL (so it should have some ability to control it).
Thanks
Rick
Dear Working Group members,
As previewed in January and discussed on yesterday’s call, the GNSO Council will consider the TPR working group’s Project Change Request during the GNSO Council meeting on 16 February. The PCR will be submitted to Council prior to the Monday 6 February document deadline for the Council meeting.
Please respond on list with any questions or concerns.
Kind regards,
Caitlin, Berry, Julie, and Emily
Emily Barabas
Policy Development Support Senior Manager
Internet Corporation for Assigned Names and Numbers (ICANN)
Phone: +31 (0)6 84507976
www.icann.org<http://www.icann.org/>
