[IRT.RegDataPolicy] [Ext] RE: IRT Task 174 Review Drafting Error #10:DNSSECElement transfer from Registrar to Registry Operator 20211122

Wed Nov 17 13:54:14 UTC 2021

Indeed an interesting point & question.
I see multiple ways we can go about implementing this and would like to discuss it with IRT today.
I reordered the items on the agenda to ensure that happens.
https://community.icann.org/display/RDPIRT/2021-11-17+Registration+Data+Policy+Implementation+IRT+Meeting

I’ll see you in a few hours.

Thanks
Dennis Chang

From: Sarah Wyld <swyld at tucows.com>
Date: Wednesday, November 17, 2021 at 05:12
To: Gustavo Lozano <gustavo.lozano at icann.org>, Dennis Chang <dennis.chang at icann.org>, "irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
Subject: [Ext] RE: [IRT.RegDataPolicy] IRT Task 174 Review Drafting Error #10:DNSSECElement transfer from Registrar to Registry Operator 20211122

Hi Gustavo,

That is a really interesting point & question, hopefully we can discuss at today’s meeting!

Thanks,

--

Sarah Wyld, CIPP/E

Policy & Privacy Manager

Pronouns: she/they

swyld at tucows.com<mailto:swyld at tucows.com>

+1.416 535 0123 Ext. 1392

[cid:image001.png at 01D7DB77.3F183060]

From: Gustavo Lozano<mailto:gustavo.lozano at icann.org>
Sent: November 16, 2021 7:46 PM
To: Sarah Wyld<mailto:swyld at tucows.com>; Dennis Chang<mailto:dennis.chang at icann.org>; irt.regdatapolicy at icann.org<mailto:irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] IRT Task 174 Review Drafting Error #10:DNSSECElement transfer from Registrar to Registry Operator 20211122

Thank you, Sarah,

I raised the issue of the DNSSEC elements internally because section 8.2 contains Name Server(s) and Name Server IP Address(es). These data elements are technical parameters, and not having the DNSSEC elements there is inconsistent.

Like the DNSSEC elements, the RAA 2013 in sections 3.2.1.2 and 3.2.1.3 requires transferring the Name Server(s) and Name Server IP Address(es) to the Registry.

In my experience working for a Registrar, I remember scenarios in which the registrar staff may need to replace the Name Server(s) and Name Server IP Address(es) in the Registry with different values from the locally stored ones for legitimate reasons.

In other words, the Name Server(s) and Name Server IP Address(es) appear to present the same problem that you describe.

I wonder if a Registrar overriding values in the Name Server(s), Name Server IP Address(es), or DNSSEC Elements based on a legitimate reason could be considered an issue now because the RAA 2013 requires transferring those elements.

Just some food for thought.

Regards,
Gustavo

From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on behalf of "Sarah Wyld via IRT.RegDataPolicy" <irt.regdatapolicy at icann.org>
Reply-To: Sarah Wyld <swyld at tucows.com>
Date: Monday, November 15, 2021 at 11:04 AM
To: Dennis Chang <dennis.chang at icann.org>, "Roger D Carney via IRT.RegDataPolicy" <irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] IRT Task 174 Review Drafting Error #10: DNSSECElement transfer from Registrar to Registry Operator 20211122

Hi all,

Following up on the topic of the DNSSEC data element, whether it should be a MUST or MAY transfer from Registrar to Registry.

I see the note in the rationale doc, “Without this element being transferred, DNSSEC cannot be enabled on the domain name”; this is true, but I don’t think it means that this should be turned into a MUST requirement.

There are some cases where a Registrar needs the ability to NOT send the DNSSEC data that it holds over to the Registry. Making it mandatory to do so would cause problems for the domain owner.

  1.  When there is a problem with a domain's DNSSEC Key, which is unfortunately quite common, the best and standard way to fix it is to remove the DS Record from the Registry (called "unpublishing" it) even though this information is still held by the registrar. If the transfer from Registrar to Registry is a MUST, that unpublish becomes no longer permissible, so there's no way to fix the broken DNSSEC zone.

  1.  There's also a need to remove an old DNSSEC Key from the registry when updating to new DNSSEC keys, and so if ALL keys held by the Registrar MUST be transferred to the Registry, how would the Registrar ever remove the old key?

Registrars do already have an obligation in the RAA ("ADDITIONAL REGISTRAR OPERATION SPECIFICATION") to allow registrants to use DNSSEC by relaying the key info to the Registry, and I don’t think that having it be optional in the OneDoc/new Policy will override that. I'm not sure what the Phase1 team had intended, but I am no longer at all sure that making this a MUST to transfer is the right choice.

Thank you,

--

Sarah Wyld, CIPP/E

Policy & Privacy Manager

Pronouns: she/they

swyld at tucows.com<mailto:swyld at tucows.com>

+1.416 535 0123 Ext. 1392

[cid:image001.png at 01D7DB09.88476D50]

From: Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy at icann.org>
Sent: October 8, 2021 12:38 PM
To: Roger D Carney via IRT.RegDataPolicy<mailto:irt.regdatapolicy at icann.org>
Subject: [IRT.RegDataPolicy] IRT Task 174 Review Drafting Error #10: DNSSECElement transfer from Registrar to Registry Operator 20211122

Dear IRT,

Here is another drafting error we uncovered.
We’d appreciate IRT review to ensure we’ve got this correctly.
174

Review Drafting Error #10: DNSSEC Element transfer from Registrar to Registry Operator [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q9I2ZBTkiq8hFOZeWwdYAaiUge3JLFx7/edit__;!!PtGJab4!rFJLz11KxPuD1u7Yym_yO6N9Vy91pFrxxtjuozgyplls84SmTxSxay__FlInrLA1koqVXW8j$>

20211122

We’ll add it to next week’s agenda to explain the rationale but note that you have two weeks to complete the task.
This is to allow time for the IRT members to consult with their technical experts back at home.

One note on the drafting error document.
This document as you know will be used for Public Comment to be transparent and clear on our implementation that are not aligned with the recommendation.  When we publish the policy, this document will not be part of that.
However, we will maintain this work as a background material and it will be published on the IRT wiki for future reference.
We may also use some of the content for Educational Material where applicable.

We appreciate IRT support on careful examination of these drafting errors.
Without IRT, I think we’d have to go back to the Board and GNSO for every one of these items.
I feel fortunate to have the dedicated IRT supporting the IPT – the ICANN org implementation project team.

--
Gratefully Yours,
Dennis S. Chang
GDD Programs Director
Phone: +1 213 293 7889
Sykpe: dennisSchang
www.icann.org<http://www.icann.org> One World – One Internet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20211117/27293881/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14058 bytes
Desc: image001.png
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20211117/27293881/image001-0001.png>