IRT Task 251: Review draft advisory to Registry Operator for Escrowing Registrar Abuse Contacts. Due 20240410
Dear IRT, Thank you for supporting the IRT call yesterday;. I had considered working this topic via emails without a meeting but saw that it was helpful to avoid confusion with other Abuse Contact discussions happening elsewhere. Thank you, Marc, for your careful evaluation and double checking with your technical team to providing the explanation as a Registry Operator for whom this advisory is intended. Steve, I know you had to drop before the end, but Marc was very kind to provide an explanation for you so that you can pick it up from the recor4ding. Following the next steps per our plan, we have drafted an Advisory for your review. 251 Review Draft Advisory to Registry Operators for Escrowing Registrar Abuse Contacts<https://docs.google.com/document/d/1J_QbE-Gkuywn6OSOJkbjkBR-o86bRfV7kX7iuVJjhyI/edit> 20240410 Please review and comment directly on the document. As we discussed, this Advisory is an instruction to the Registry Operators to use the two data elements already available to meet the Registration Data Policy requirement in a consistent way. This is an implementation effort collaborating on how we meet the requirement; not making or changing requirements. An example of an implementation that the IRT asked me to bring to you for awareness instead of working directly with Registry Operators only. I am providing the slides we used at the meeting that contains that explanation for your convenience there. 249 Registry Escrow for Registrar Abuse Contacts <https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents?preview=/124847947/320012442/Registration%20Data%20Policy%20-%20Registry%20Escrow%20Of%20Registrar%E2%80%99s%20Abuse%20Contact%20Information%20.pdf> 20240326 Please share this with your technical implementation team and I think you’ll find them most receptive as a straight forward and clear implementation approach. When the Advisory is ready, it will be added to the list of Advisories here following our process. https://www.icann.org/resources/pages/advisories-2012-02-25-en Please feel free to reach out to me off-line too if you’d like further explanation or discussion. I’d be happy to support your call with your technical teams too if you’d like. One month in and five months to go till our Transition start date: 21 August 2024. Thanks you for your support to make this implementation a success for all. … Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet
Dennis, Thanks very much for noting the follow up after I left the call. I've reviewed the transcript and included a copy below of that portion of the call. The slide deck presenting the proposal includes the following - Registry Operators may be using the generic elements to escrow other Registrar’s contact information, but this should not be an issue: - ICANN org already publishes a public list with generic contact information of the Registrars: https://www.icann.org/en/accredited-registrars - Registry Operators and EBERO providers (in their role as RO) already have specialized points of contact within the Registrars. This would appear to suggest that other contact information, unrelated to Abuse, might be stored in those fields and hence might be mistakenly restored into the fields for the Abuse contact. The detail I was trying to pin down is whether there is a potential for confusion at time of restoration. I appreciate that Marc inquired of his technical people and got assurance everything is ok, but I think it's within our role as an implementation review team to understand this and not simply to hear that others think it's ok. Thanks, Steve On Thu, Mar 28, 2024 at 2:14 PM Dennis Chang via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Dear IRT,
Thank you for supporting the IRT call yesterday;.
I had considered working this topic via emails without a meeting but saw that it was helpful to avoid confusion with other Abuse Contact discussions happening elsewhere.
Thank you, Marc, for your careful evaluation and double checking with your technical team to providing the explanation as a Registry Operator for whom this advisory is intended.
Steve, I know you had to drop before the end, but Marc was very kind to provide an explanation for you so that you can pick it up from the recor4ding.
Following the next steps per our plan, we have drafted an Advisory for your review.
251
*Review Draft Advisory to Registry Operators for Escrowing Registrar Abuse Contacts <https://docs.google.com/document/d/1J_QbE-Gkuywn6OSOJkbjkBR-o86bRfV7kX7iuVJjhyI/edit>*
20240410
Please review and comment directly on the document.
As we discussed, this Advisory is an instruction to the Registry Operators to use the two data elements already available to meet the Registration Data Policy requirement in a consistent way. This is an implementation effort collaborating on how we meet the requirement; not making or changing requirements. An example of an implementation that the IRT asked me to bring to you for awareness instead of working directly with Registry Operators only.
I am providing the slides we used at the meeting that contains that explanation for your convenience there.
249
*Registry Escrow for Registrar Abuse Contacts <https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents?preview=/124847947/320012442/Registration%20Data%20Policy%20-%20Registry%20Escrow%20Of%20Registrar%E2%80%99s%20Abuse%20Contact%20Information%20.pdf>*
20240326
Please share this with your technical implementation team and I think you’ll find them most receptive as a straight forward and clear implementation approach.
When the Advisory is ready, it will be added to the list of Advisories here following our process.
https://www.icann.org/resources/pages/advisories-2012-02-25-en
Please feel free to reach out to me off-line too if you’d like further explanation or discussion.
I’d be happy to support your call with your technical teams too if you’d like.
One month in and five months to go till our Transition start date: 21 August 2024.
Thanks you for your support to make this implementation a success for all.
…
Kind Regards,
Dennis S. Chang
GDD Programs Director
Phone: +1 213 293 7889
Sykpe: dennisSchang
www.icann.org One World – One Internet
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
_______________________________________________ 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.
*From the transcript* - Gustavo Lozano Ibarra - ICANN Org 23:39 No, the idea is to - define the semantics of the generic information that we have right now in the deposit, so that the deposit right now contains 2, that elements, pre, generic - voice and email. - There is no definition of what - they mean. So it could mean, I use context. It could mean generic context. It could mean marketing context. - Who knows? Right? So the idea with advisory is to define the semantics of those generic elements - to be the abuse context. So there is no question - when someone is restoring this deposit. - That information contained within those generic elements - refers to the abuse context. - What do you have for yourself? - Laureen Kapin 24:19 So I guess my concern is that is there something less useful about identifying a generic contact as opposed to a more specific abuse contact which seems to be the intent of the specification. In the first place. - [image: image.png] LAX-Galileo 24:38 Mark, maybe you see. Go ahead. - [image: image.png] Marc Anderson 24:43 Spark. Anderson. I - I guess I'm I'm surprised by the the amount of discussion on on this one. I I I see this is pretty pretty straightforward. - so so from, you know. So again, this, this. - this is only only impactful. As as Gustavo said, this is - only impactful to - the registry operator, the escrow provider, and - the and whoever would be restoring for mass grow. As as Gustavo pointed out. Currently, there's only - there's 3 boroughs who are also registry operators. So so these, these are the the only entities that are that are impacted by this. There isn't - any operational impact. Otherwise it doesn't change anything external to the public. There's there's no change to our app. - There's no Epp change. There's no impact to registrars. There's no no change to Dns. So there's no, you know other otherwise impactful change to - you know, to to to the entire ecosystem. This is this is just an advisory that's - provides additional clarification to registry operators and escrow providers on how to escrow under the registration data policy. - I'm getting - getting to Steve's - question or or point he's trying to make. You know - these, you know, the the the fields that Gustavo has is proposing to to reuse are undefined currently. - and if if we were restoring - a restoring a registry based on an escrow deposit. And there were values in those fields today. We would drop them on the ground. - You know these would. These are these are, you know, these are fields that have no defined use today. - So in restoring a registry, if if there were values in those fields because they're undefined and they're unneeded. We would. We would drop them. They they wouldn't be used because there's no definition for what they are and what they're used for. - Staff is proposing to create an advisory that details how these fields must be used. And so this would. This would be a must, because esc under the new policy escrow of abuse, contact email and phone is is a must. - And so this advisory says you must use these fields to ask of this data in this way. - and so registries would escrow providers would validate. Ensure that data is, is is present and and valid, and Eboros or - anybody else restoring this would - no to restore that data in that way. So - from from from my perspective. I think it's I think it's it's very, very straightforward. There's there's there's limited impact. It's it's, you know, we have these - unused fields which line up rather nicely and - and and and you know, don't don't seem to present any any issues or conflicts from from my perspective. - [image: image.png] LAX-Galileo 28:17 So to Steve. Answer Steve's question from myself. The registry operator would know when they restore it, because they have the advisory as a registry operator, and there'd be plenty of communication to them when these advisory goes out, and the reminder that's how they were. Know - this is the instructions to the registry operator, saying, Hey, let registry operator, let's do it this way. And if the registry operator all agrees, then that's it. - And right now - there isn't clarity, but we're providing clarity anything else. - Let's see, we are at the top of the hour. 30 min seem really short. - and but we try this way. - [image: image.png] Marc Anderson 28:58 And I said, It's a new hand for me. - I know. - I know Steve. - I know. Steve dropped, but on the chance that he's listening to the recording later. You know he's concerned that - he has not heard how the necessary detail of how the restore process will know. You know. I'll just. - I'll just say, you know, Icann has issued advisories in the past. This is a a standard process that we are used to and comfortable with. And so - the advisory is the mechanism. As you know. As Gustav was saying, the advisory is the mechanism. This is something that's that's done before. And - yeah. And this is - I, you know I would dare to say, a standard practice for how to deal with something like this. - [image: image.png] LAX-Galileo 29:42 It is - most definitely - we're using the tools and the vehicles that - these are already available to us. And we use. We have used this - so many times. There's many advisory that's already been done. So this is not new. But for some people I understand this is a new Uk. So we? We need to take the time to explain these things, and that's part of our - purpose for the meeting anything else from anyone. - Thank you so much.
Dear Steve, Your inputs are always welcome, and you know I value them. I agree that I bring these items to the IRT for reviews as well as to build a consistent understanding. It’s important to me that IRT members gain the understanding so that they in turn can communicate to their respective implementation teams and stakeholders. Hence, I offer to support engagement with teams beyond the IRT and we have plans to do so throughout this implementation period. To explain a bit more here on our proposed implementation, the generic email and voice elements are optional in RFC9022. No policy or contract provision currently calls for using these generic elements in the gTLD space; therefore, defining their use should not negatively impact any current processes. The existing data sets already solve other potential use cases for the generic elements. In other words, there is no need for an extension to RFC9022 for our purposes and as you know standardizing an extension is a process that could take a long time to complete and therefore not practical for our use at this time. In the future, if a policy calls for escrowing additional specific-purpose contacts related to the registrar object, an escrow extension could be created and standardized. As to the point of potential confusion at time of restoration, the advisory we are proposing is designed to minimize that confusion. In the gTLD space, a limited set of parties use the data escrow deposits: RSPs, Data Escrow Agents, and EBERO providers. ICANN org will communicate the publishing of this advisory to all the parties, hence mitigating confusion when restoring from a deposit by EBERO providers. In addition to the formal notifications of the advisory to the parties for implementation, there are series of communications and instructions through multiple channels. ICANN org works with the implementers to ensure that they are aware, and their systems and processes are updated to perform to meet the requirement. The use of advisories (https://www.icann.org/resources/pages/advisories-2012-02-25-en) and redefining optional elements in standards as required is a common practice in the gTLD space. For example, the gTLD RDAP profile (https://www.icann.org/gtld-rdap-profile) redefines optional elements in RDAP as required in the gTLD space. Thanks again for your review and input and I’ll take this opportunity to remind those IRT members to please inform your implementation teams to see if we could improve the advisory language to make it clearer. Kind Regards, Dennis Chang From: "Steve com>" <steve@shinkuro.com> Date: Thursday, March 28, 2024 at 7:10 PM To: Dennis Chang <dennis.chang@icann.org> Cc: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org>, "Steve com>" <steve@shinkuro.com> Subject: [Ext] Re: [IRT.RegDataPolicy] IRT Task 251: Review draft advisory to Registry Operator for Escrowing Registrar Abuse Contacts. Due 20240410 Dennis, Thanks very much for noting the follow up after I left the call. I've reviewed the transcript and included a copy below of that portion of the call. The slide deck presenting the proposal includes the following o Registry Operators may be using the generic elements to escrow other Registrar’s contact information, but this should not be an issue: § ICANN org already publishes a public list with generic contact information of the Registrars: https://www.icann.org/en/accredited-registrars § Registry Operators and EBERO providers (in their role as RO) already have specialized points of contact within the Registrars. This would appear to suggest that other contact information, unrelated to Abuse, might be stored in those fields and hence might be mistakenly restored into the fields for the Abuse contact. The detail I was trying to pin down is whether there is a potential for confusion at time of restoration. I appreciate that Marc inquired of his technical people and got assurance everything is ok, but I think it's within our role as an implementation review team to understand this and not simply to hear that others think it's ok. Thanks, Steve On Thu, Mar 28, 2024 at 2:14 PM Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>> wrote: Dear IRT, Thank you for supporting the IRT call yesterday;. I had considered working this topic via emails without a meeting but saw that it was helpful to avoid confusion with other Abuse Contact discussions happening elsewhere. Thank you, Marc, for your careful evaluation and double checking with your technical team to providing the explanation as a Registry Operator for whom this advisory is intended. Steve, I know you had to drop before the end, but Marc was very kind to provide an explanation for you so that you can pick it up from the recor4ding. Following the next steps per our plan, we have drafted an Advisory for your review. 251 Review Draft Advisory to Registry Operators for Escrowing Registrar Abuse Contacts [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1J_QbE-Gkuywn6OSOJkbjkBR-o86bRfV7kX7iuVJjhyI/edit__;!!PtGJab4!4ihe_kBEjHcwsDeup0jkURyspQmJBTg8cGfxb05953zLy4AZqGXWi37gRi4KwqKABZR8xE_V9AXzF5nSjF7bhRk$> 20240410 Please review and comment directly on the document. As we discussed, this Advisory is an instruction to the Registry Operators to use the two data elements already available to meet the Registration Data Policy requirement in a consistent way. This is an implementation effort collaborating on how we meet the requirement; not making or changing requirements. An example of an implementation that the IRT asked me to bring to you for awareness instead of working directly with Registry Operators only. I am providing the slides we used at the meeting that contains that explanation for your convenience there. 249 Registry Escrow for Registrar Abuse Contacts <https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents?preview=/124847947/320012442/Registration%20Data%20Policy%20-%20Registry%20Escrow%20Of%20Registrar%E2%80%99s%20Abuse%20Contact%20Information%20.pdf> 20240326 Please share this with your technical implementation team and I think you’ll find them most receptive as a straight forward and clear implementation approach. When the Advisory is ready, it will be added to the list of Advisories here following our process. https://www.icann.org/resources/pages/advisories-2012-02-25-en Please feel free to reach out to me off-line too if you’d like further explanation or discussion. I’d be happy to support your call with your technical teams too if you’d like. One month in and five months to go till our Transition start date: 21 August 2024. Thanks you for your support to make this implementation a success for all. … Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet _______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org<mailto:IRT.RegDataPolicy@icann.org> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy _______________________________________________ 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. From the transcript · Gustavo Lozano Ibarra - ICANN Org 23:39 No, the idea is to · define the semantics of the generic information that we have right now in the deposit, so that the deposit right now contains 2, that elements, pre, generic · voice and email. · There is no definition of what · they mean. So it could mean, I use context. It could mean generic context. It could mean marketing context. · Who knows? Right? So the idea with advisory is to define the semantics of those generic elements · to be the abuse context. So there is no question · when someone is restoring this deposit. · That information contained within those generic elements · refers to the abuse context. · What do you have for yourself? · [Image removed by sender.] Laureen Kapin 24:19 So I guess my concern is that is there something less useful about identifying a generic contact as opposed to a more specific abuse contact which seems to be the intent of the specification. In the first place. · [cid:ii_luc0kcov0] LAX-Galileo 24:38 Mark, maybe you see. Go ahead. · [cid:ii_luc0kcoy1] Marc Anderson 24:43 Spark. Anderson. I · I guess I'm I'm surprised by the the amount of discussion on on this one. I I I see this is pretty pretty straightforward. · so so from, you know. So again, this, this. · this is only only impactful. As as Gustavo said, this is · only impactful to · the registry operator, the escrow provider, and · the and whoever would be restoring for mass grow. As as Gustavo pointed out. Currently, there's only · there's 3 boroughs who are also registry operators. So so these, these are the the only entities that are that are impacted by this. There isn't · any operational impact. Otherwise it doesn't change anything external to the public. There's there's no change to our app. · There's no Epp change. There's no impact to registrars. There's no no change to Dns. So there's no, you know other otherwise impactful change to · you know, to to to the entire ecosystem. This is this is just an advisory that's · provides additional clarification to registry operators and escrow providers on how to escrow under the registration data policy. · I'm getting · getting to Steve's · question or or point he's trying to make. You know · these, you know, the the the fields that Gustavo has is proposing to to reuse are undefined currently. · and if if we were restoring · a restoring a registry based on an escrow deposit. And there were values in those fields today. We would drop them on the ground. · You know these would. These are these are, you know, these are fields that have no defined use today. · So in restoring a registry, if if there were values in those fields because they're undefined and they're unneeded. We would. We would drop them. They they wouldn't be used because there's no definition for what they are and what they're used for. · Staff is proposing to create an advisory that details how these fields must be used. And so this would. This would be a must, because esc under the new policy escrow of abuse, contact email and phone is is a must. · And so this advisory says you must use these fields to ask of this data in this way. · and so registries would escrow providers would validate. Ensure that data is, is is present and and valid, and Eboros or · anybody else restoring this would · no to restore that data in that way. So · from from from my perspective. I think it's I think it's it's very, very straightforward. There's there's there's limited impact. It's it's, you know, we have these · unused fields which line up rather nicely and · and and and you know, don't don't seem to present any any issues or conflicts from from my perspective. · [cid:ii_luc0kcoz2] LAX-Galileo 28:17 So to Steve. Answer Steve's question from myself. The registry operator would know when they restore it, because they have the advisory as a registry operator, and there'd be plenty of communication to them when these advisory goes out, and the reminder that's how they were. Know · this is the instructions to the registry operator, saying, Hey, let registry operator, let's do it this way. And if the registry operator all agrees, then that's it. · And right now · there isn't clarity, but we're providing clarity anything else. · Let's see, we are at the top of the hour. 30 min seem really short. · and but we try this way. · [cid:ii_luc0kcp03] Marc Anderson 28:58 And I said, It's a new hand for me. · I know. · I know Steve. · I know. Steve dropped, but on the chance that he's listening to the recording later. You know he's concerned that · he has not heard how the necessary detail of how the restore process will know. You know. I'll just. · I'll just say, you know, Icann has issued advisories in the past. This is a a standard process that we are used to and comfortable with. And so · the advisory is the mechanism. As you know. As Gustav was saying, the advisory is the mechanism. This is something that's that's done before. And · yeah. And this is · I, you know I would dare to say, a standard practice for how to deal with something like this. · [cid:ii_luc0kcp14] LAX-Galileo 29:42 It is · most definitely · we're using the tools and the vehicles that · these are already available to us. And we use. We have used this · so many times. There's many advisory that's already been done. So this is not new. But for some people I understand this is a new Uk. So we? We need to take the time to explain these things, and that's part of our · purpose for the meeting anything else from anyone. · Thank you so much.
Dennis, Thanks. Please see questions and comments inline below. Steve On Fri, Apr 5, 2024 at 12:10 PM Dennis Chang <dennis.chang@icann.org> wrote:
Dear Steve,
Your inputs are always welcome, and you know I value them. I agree that I bring these items to the IRT for reviews as well as to build a consistent understanding. It’s important to me that IRT members gain the understanding so that they in turn can communicate to their respective implementation teams and stakeholders. Hence, I offer to support engagement with teams beyond the IRT and we have plans to do so throughout this implementation period.
To explain a bit more here on our proposed implementation, the generic email and voice elements are optional in RFC9022. No policy or contract provision currently calls for using these generic elements in the gTLD space; therefore, defining their use should not negatively impact any current processes.
The existing data sets already solve other potential use cases for the generic elements.
I don't understand this sentence. It seems to contradict the statement in the prior paragraph that these optional data elements are not used for anything else.
In other words, there is no need for an extension to RFC9022 for our purposes and as you know standardizing an extension is a process that could take a long time to complete and therefore not practical for our use at this time. In the future, if a policy calls for escrowing additional specific-purpose contacts related to the registrar object, an escrow extension could be created and standardized.
Yes, I think it's clear that everyone wants to avoid going through a formal change to RFC9022. (This suggests it would have been useful if RFC9022 had been written to include more flexibility, but that's a separate discussion.) As to the point of potential confusion at time of restoration, the advisory
we are proposing is designed to minimize that confusion. In the gTLD space, a limited set of parties use the data escrow deposits: RSPs, Data Escrow Agents, and EBERO providers. ICANN org will communicate the publishing of this advisory to all the parties, hence mitigating confusion when restoring from a deposit by EBERO providers.
Yes, the fact that only a limited set of parties will be restoring escrowed data seems helpful. On the other hand, restoration events will likely take place a long time after the escrow process is initiated, so the worry is there may be some miscommunication about the use of those fields.
In addition to the formal notifications of the advisory to the parties for implementation, there are series of communications and instructions through multiple channels. ICANN org works with the implementers to ensure that they are aware, and their systems and processes are updated to perform to meet the requirement.
This part is ok as long as there are no other possible uses of these fields. Inclusion of a flag indicating what the data means would be preferable. In essence, it would be a poor man's extension of RFC9022. It would make it possible for the restoration process to check that the data in those fields does in fact mean what it is supposed to mean, and it would make it possible to accommodate a further extension.
The use of advisories ( https://www.icann.org/resources/pages/advisories-2012-02-25-en) and redefining optional elements in standards as required is a common practice in the gTLD space. For example, the gTLD RDAP profile ( https://www.icann.org/gtld-rdap-profile) redefines optional elements in RDAP as required in the gTLD space.
Thanks again for your review and input and I’ll take this opportunity to remind those IRT members to please inform your implementation teams to see if we could improve the advisory language to make it clearer.
Kind Regards,
Dennis Chang
*From: *"Steve com>" <steve@shinkuro.com> *Date: *Thursday, March 28, 2024 at 7:10 PM *To: *Dennis Chang <dennis.chang@icann.org> *Cc: *"irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org>, "Steve com>" <steve@shinkuro.com> *Subject: *[Ext] Re: [IRT.RegDataPolicy] IRT Task 251: Review draft advisory to Registry Operator for Escrowing Registrar Abuse Contacts. Due 20240410
Dennis,
Thanks very much for noting the follow up after I left the call. I've reviewed the transcript and included a copy below of that portion of the call.
The slide deck presenting the proposal includes the following
o Registry Operators may be using the generic elements to escrow other Registrar’s contact information, but this should not be an issue:
§ ICANN org already publishes a public list with generic contact information of the Registrars: https://www.icann.org/en/accredited-registrars
§ Registry Operators and EBERO providers (in their role as RO) already have specialized points of contact within the Registrars.
This would appear to suggest that other contact information, unrelated to Abuse, might be stored in those fields and hence might be mistakenly restored into the fields for the Abuse contact.
The detail I was trying to pin down is whether there is a potential for confusion at time of restoration. I appreciate that Marc inquired of his technical people and got assurance everything is ok, but I think it's within our role as an implementation review team to understand this and not simply to hear that others think it's ok.
Thanks,
Steve
On Thu, Mar 28, 2024 at 2:14 PM Dennis Chang via IRT.RegDataPolicy < irt.regdatapolicy@icann.org> wrote:
Dear IRT,
Thank you for supporting the IRT call yesterday;.
I had considered working this topic via emails without a meeting but saw that it was helpful to avoid confusion with other Abuse Contact discussions happening elsewhere.
Thank you, Marc, for your careful evaluation and double checking with your technical team to providing the explanation as a Registry Operator for whom this advisory is intended.
Steve, I know you had to drop before the end, but Marc was very kind to provide an explanation for you so that you can pick it up from the recor4ding.
Following the next steps per our plan, we have drafted an Advisory for your review.
251
*Review Draft Advisory to Registry Operators for Escrowing Registrar Abuse Contacts [docs.google.com] <https://urldefense.com/v3/__https:/docs.google.com/document/d/1J_QbE-Gkuywn6OSOJkbjkBR-o86bRfV7kX7iuVJjhyI/edit__;!!PtGJab4!4ihe_kBEjHcwsDeup0jkURyspQmJBTg8cGfxb05953zLy4AZqGXWi37gRi4KwqKABZR8xE_V9AXzF5nSjF7bhRk$>*
20240410
Please review and comment directly on the document.
As we discussed, this Advisory is an instruction to the Registry Operators to use the two data elements already available to meet the Registration Data Policy requirement in a consistent way. This is an implementation effort collaborating on how we meet the requirement; not making or changing requirements. An example of an implementation that the IRT asked me to bring to you for awareness instead of working directly with Registry Operators only.
I am providing the slides we used at the meeting that contains that explanation for your convenience there.
249
*Registry Escrow for Registrar Abuse Contacts <https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents?preview=/124847947/320012442/Registration%20Data%20Policy%20-%20Registry%20Escrow%20Of%20Registrar%E2%80%99s%20Abuse%20Contact%20Information%20.pdf>*
20240326
Please share this with your technical implementation team and I think you’ll find them most receptive as a straight forward and clear implementation approach.
When the Advisory is ready, it will be added to the list of Advisories here following our process.
https://www.icann.org/resources/pages/advisories-2012-02-25-en
Please feel free to reach out to me off-line too if you’d like further explanation or discussion.
I’d be happy to support your call with your technical teams too if you’d like.
One month in and five months to go till our Transition start date: 21 August 2024.
Thanks you for your support to make this implementation a success for all.
…
Kind Regards,
Dennis S. Chang
GDD Programs Director
Phone: +1 213 293 7889
Sykpe: dennisSchang
www.icann.org One World – One Internet
_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
_______________________________________________ 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.
*From the transcript*
· * Gustavo Lozano Ibarra - ICANN Org*
23:39
No, the idea is to
· define the semantics of the generic information that we have right now in the deposit, so that the deposit right now contains 2, that elements, pre, generic
· voice and email.
· There is no definition of what
· they mean. So it could mean, I use context. It could mean generic context. It could mean marketing context.
· Who knows? Right? So the idea with advisory is to define the semantics of those generic elements
· to be the abuse context. So there is no question
· when someone is restoring this deposit.
· That information contained within those generic elements
· refers to the abuse context.
· What do you have for yourself?
· [image: Image removed by sender.]
*Laureen Kapin*
24:19
So I guess my concern is that is there something less useful about identifying a generic contact as opposed to a more specific abuse contact which seems to be the intent of the specification. In the first place.
·
*LAX-Galileo*
24:38
Mark, maybe you see. Go ahead.
·
*Marc Anderson*
24:43
Spark. Anderson. I
· I guess I'm I'm surprised by the the amount of discussion on on this one. I I I see this is pretty pretty straightforward.
· so so from, you know. So again, this, this.
· this is only only impactful. As as Gustavo said, this is
· only impactful to
· the registry operator, the escrow provider, and
· the and whoever would be restoring for mass grow. As as Gustavo pointed out. Currently, there's only
· there's 3 boroughs who are also registry operators. So so these, these are the the only entities that are that are impacted by this. There isn't
· any operational impact. Otherwise it doesn't change anything external to the public. There's there's no change to our app.
· There's no Epp change. There's no impact to registrars. There's no no change to Dns. So there's no, you know other otherwise impactful change to
· *you know, to to to the entire ecosystem. This is this is just an advisory that's*
· provides additional clarification to registry operators and escrow providers on how to escrow under the registration data policy.
· I'm getting
· getting to Steve's
· question or or point he's trying to make. You know
· these, you know, the the the fields that Gustavo has is proposing to to reuse are undefined currently.
· and if if we were restoring
· a restoring a registry based on an escrow deposit. And there were values in those fields today. We would drop them on the ground.
· You know these would. These are these are, you know, these are fields that have no defined use today.
· So in restoring a registry, if if there were values in those fields because they're undefined and they're unneeded. We would. We would drop them. They they wouldn't be used because there's no definition for what they are and what they're used for.
· Staff is proposing to create an advisory that details how these fields must be used. And so this would. This would be a must, because esc under the new policy escrow of abuse, contact email and phone is is a must.
· And so this advisory says you must use these fields to ask of this data in this way.
· and so registries would escrow providers would validate. Ensure that data is, is is present and and valid, and Eboros or
· anybody else restoring this would
· no to restore that data in that way. So
· from from from my perspective. I think it's I think it's it's very, very straightforward. There's there's there's limited impact. It's it's, you know, we have these
· unused fields which line up rather nicely and
· and and and you know, don't don't seem to present any any issues or conflicts from from my perspective.
·
*LAX-Galileo*
28:17
So to Steve. Answer Steve's question from myself. The registry operator would know when they restore it, because they have the advisory as a registry operator, and there'd be plenty of communication to them when these advisory goes out, and the reminder that's how they were. Know
· this is the instructions to the registry operator, saying, Hey, let registry operator, let's do it this way. And if the registry operator all agrees, then that's it.
· And right now
· there isn't clarity, but we're providing clarity anything else.
· Let's see, we are at the top of the hour. 30 min seem really short.
· and but we try this way.
·
*Marc Anderson*
28:58
And I said, It's a new hand for me.
· I know.
· I know Steve.
· I know. Steve dropped, but on the chance that he's listening to the recording later. You know he's concerned that
· he has not heard how the necessary detail of how the restore process will know. You know. I'll just.
· I'll just say, you know, Icann has issued advisories in the past. This is a a standard process that we are used to and comfortable with. And so
· the advisory is the mechanism. As you know. As Gustav was saying, the advisory is the mechanism. This is something that's that's done before. And
· yeah. And this is
· I, you know I would dare to say, a standard practice for how to deal with something like this.
·
*LAX-Galileo*
29:42
It is
· most definitely
· we're using the tools and the vehicles that
· these are already available to us. And we use. We have used this
· so many times. There's many advisory that's already been done. So this is not new. But for some people I understand this is a new Uk. So we? We need to take the time to explain these things, and that's part of our
· purpose for the meeting anything else from anyone.
· Thank you so much.
-- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
Thanks, Steve, for your questions and comments. Regarding your question about this sentence: “The existing data sets already solve other potential use cases for the generic elements.” What I meant was that there are no written rules or recommendations to registry operators on using these fields, and there are no rules or recommendations to DEAs on how to treat these fields, with or without data. Likewise, for EBEROs for restoring registry. Therefore, this allows us to use these generic fields to solve our needs this time for abuse contact. The “already solve” was meant to say that we were fortunate to find these elements we could use for our purpose. Thanks for your other comments. Dear IRT, With IRT review now being completed, we will proceed with the publication of the Advisory. I’ll notify you of the publication and ask that you inform your teams. Thanks you. More to come on this. Dennis Chang From: "Steve com>" <steve@shinkuro.com> Date: Monday, April 8, 2024 at 10:55 AM To: Dennis Chang <dennis.chang@icann.org> Cc: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [Ext] Re: [IRT.RegDataPolicy] IRT Task 251: Review draft advisory to Registry Operator for Escrowing Registrar Abuse Contacts. Due 20240410 Dennis, Thanks. Please see questions and comments inline below. Steve On Fri, Apr 5, 2024 at 12:10 PM Dennis Chang <dennis.chang@icann.org<mailto:dennis.chang@icann.org>> wrote: Dear Steve, Your inputs are always welcome, and you know I value them. I agree that I bring these items to the IRT for reviews as well as to build a consistent understanding. It’s important to me that IRT members gain the understanding so that they in turn can communicate to their respective implementation teams and stakeholders. Hence, I offer to support engagement with teams beyond the IRT and we have plans to do so throughout this implementation period. To explain a bit more here on our proposed implementation, the generic email and voice elements are optional in RFC9022. No policy or contract provision currently calls for using these generic elements in the gTLD space; therefore, defining their use should not negatively impact any current processes. The existing data sets already solve other potential use cases for the generic elements. I don't understand this sentence. It seems to contradict the statement in the prior paragraph that these optional data elements are not used for anything else. In other words, there is no need for an extension to RFC9022 for our purposes and as you know standardizing an extension is a process that could take a long time to complete and therefore not practical for our use at this time. In the future, if a policy calls for escrowing additional specific-purpose contacts related to the registrar object, an escrow extension could be created and standardized. Yes, I think it's clear that everyone wants to avoid going through a formal change to RFC9022. (This suggests it would have been useful if RFC9022 had been written to include more flexibility, but that's a separate discussion.) As to the point of potential confusion at time of restoration, the advisory we are proposing is designed to minimize that confusion. In the gTLD space, a limited set of parties use the data escrow deposits: RSPs, Data Escrow Agents, and EBERO providers. ICANN org will communicate the publishing of this advisory to all the parties, hence mitigating confusion when restoring from a deposit by EBERO providers. Yes, the fact that only a limited set of parties will be restoring escrowed data seems helpful. On the other hand, restoration events will likely take place a long time after the escrow process is initiated, so the worry is there may be some miscommunication about the use of those fields. In addition to the formal notifications of the advisory to the parties for implementation, there are series of communications and instructions through multiple channels. ICANN org works with the implementers to ensure that they are aware, and their systems and processes are updated to perform to meet the requirement. This part is ok as long as there are no other possible uses of these fields. Inclusion of a flag indicating what the data means would be preferable. In essence, it would be a poor man's extension of RFC9022. It would make it possible for the restoration process to check that the data in those fields does in fact mean what it is supposed to mean, and it would make it possible to accommodate a further extension. The use of advisories (https://www.icann.org/resources/pages/advisories-2012-02-25-en) and redefining optional elements in standards as required is a common practice in the gTLD space. For example, the gTLD RDAP profile (https://www.icann.org/gtld-rdap-profile) redefines optional elements in RDAP as required in the gTLD space. Thanks again for your review and input and I’ll take this opportunity to remind those IRT members to please inform your implementation teams to see if we could improve the advisory language to make it clearer. Kind Regards, Dennis Chang From: "Steve com>" <steve@shinkuro.com<mailto:steve@shinkuro.com>> Date: Thursday, March 28, 2024 at 7:10 PM To: Dennis Chang <dennis.chang@icann.org<mailto:dennis.chang@icann.org>> Cc: "irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>" <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>>, "Steve com>" <steve@shinkuro.com<mailto:steve@shinkuro.com>> Subject: [Ext] Re: [IRT.RegDataPolicy] IRT Task 251: Review draft advisory to Registry Operator for Escrowing Registrar Abuse Contacts. Due 20240410 Dennis, Thanks very much for noting the follow up after I left the call. I've reviewed the transcript and included a copy below of that portion of the call. The slide deck presenting the proposal includes the following o Registry Operators may be using the generic elements to escrow other Registrar’s contact information, but this should not be an issue: • ICANN org already publishes a public list with generic contact information of the Registrars: https://www.icann.org/en/accredited-registrars • Registry Operators and EBERO providers (in their role as RO) already have specialized points of contact within the Registrars. This would appear to suggest that other contact information, unrelated to Abuse, might be stored in those fields and hence might be mistakenly restored into the fields for the Abuse contact. The detail I was trying to pin down is whether there is a potential for confusion at time of restoration. I appreciate that Marc inquired of his technical people and got assurance everything is ok, but I think it's within our role as an implementation review team to understand this and not simply to hear that others think it's ok. Thanks, Steve On Thu, Mar 28, 2024 at 2:14 PM Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org<mailto:irt.regdatapolicy@icann.org>> wrote: Dear IRT, Thank you for supporting the IRT call yesterday;. I had considered working this topic via emails without a meeting but saw that it was helpful to avoid confusion with other Abuse Contact discussions happening elsewhere. Thank you, Marc, for your careful evaluation and double checking with your technical team to providing the explanation as a Registry Operator for whom this advisory is intended. Steve, I know you had to drop before the end, but Marc was very kind to provide an explanation for you so that you can pick it up from the recor4ding. Following the next steps per our plan, we have drafted an Advisory for your review. 251 Review Draft Advisory to Registry Operators for Escrowing Registrar Abuse Contacts [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1J_QbE-Gkuywn6OSOJkbjkBR-o86bRfV7kX7iuVJjhyI/edit__;!!PtGJab4!4ihe_kBEjHcwsDeup0jkURyspQmJBTg8cGfxb05953zLy4AZqGXWi37gRi4KwqKABZR8xE_V9AXzF5nSjF7bhRk$> 20240410 Please review and comment directly on the document. As we discussed, this Advisory is an instruction to the Registry Operators to use the two data elements already available to meet the Registration Data Policy requirement in a consistent way. This is an implementation effort collaborating on how we meet the requirement; not making or changing requirements. An example of an implementation that the IRT asked me to bring to you for awareness instead of working directly with Registry Operators only. I am providing the slides we used at the meeting that contains that explanation for your convenience there. 249 Registry Escrow for Registrar Abuse Contacts <https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents?preview=/124847947/320012442/Registration%20Data%20Policy%20-%20Registry%20Escrow%20Of%20Registrar%E2%80%99s%20Abuse%20Contact%20Information%20.pdf> 20240326 Please share this with your technical implementation team and I think you’ll find them most receptive as a straight forward and clear implementation approach. When the Advisory is ready, it will be added to the list of Advisories here following our process. https://www.icann.org/resources/pages/advisories-2012-02-25-en Please feel free to reach out to me off-line too if you’d like further explanation or discussion. I’d be happy to support your call with your technical teams too if you’d like. One month in and five months to go till our Transition start date: 21 August 2024. Thanks you for your support to make this implementation a success for all. … Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<http://www.icann.org> One World – One Internet _______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org<mailto:IRT.RegDataPolicy@icann.org> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy _______________________________________________ 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. From the transcript • Gustavo Lozano Ibarra - ICANN Org 23:39 No, the idea is to • define the semantics of the generic information that we have right now in the deposit, so that the deposit right now contains 2, that elements, pre, generic • voice and email. • There is no definition of what • they mean. So it could mean, I use context. It could mean generic context. It could mean marketing context. • Who knows? Right? So the idea with advisory is to define the semantics of those generic elements • to be the abuse context. So there is no question • when someone is restoring this deposit. • That information contained within those generic elements • refers to the abuse context. • What do you have for yourself? • Error! Filename not specified. Laureen Kapin 24:19 So I guess my concern is that is there something less useful about identifying a generic contact as opposed to a more specific abuse contact which seems to be the intent of the specification. In the first place. • Error! Filename not specified. LAX-Galileo 24:38 Mark, maybe you see. Go ahead. • Error! Filename not specified. Marc Anderson 24:43 Spark. Anderson. I • I guess I'm I'm surprised by the the amount of discussion on on this one. I I I see this is pretty pretty straightforward. • so so from, you know. So again, this, this. • this is only only impactful. As as Gustavo said, this is • only impactful to • the registry operator, the escrow provider, and • the and whoever would be restoring for mass grow. As as Gustavo pointed out. Currently, there's only • there's 3 boroughs who are also registry operators. So so these, these are the the only entities that are that are impacted by this. There isn't • any operational impact. Otherwise it doesn't change anything external to the public. There's there's no change to our app. • There's no Epp change. There's no impact to registrars. There's no no change to Dns. So there's no, you know other otherwise impactful change to • you know, to to to the entire ecosystem. This is this is just an advisory that's • provides additional clarification to registry operators and escrow providers on how to escrow under the registration data policy. • I'm getting • getting to Steve's • question or or point he's trying to make. You know • these, you know, the the the fields that Gustavo has is proposing to to reuse are undefined currently. • and if if we were restoring • a restoring a registry based on an escrow deposit. And there were values in those fields today. We would drop them on the ground. • You know these would. These are these are, you know, these are fields that have no defined use today. • So in restoring a registry, if if there were values in those fields because they're undefined and they're unneeded. We would. We would drop them. They they wouldn't be used because there's no definition for what they are and what they're used for. • Staff is proposing to create an advisory that details how these fields must be used. And so this would. This would be a must, because esc under the new policy escrow of abuse, contact email and phone is is a must. • And so this advisory says you must use these fields to ask of this data in this way. • and so registries would escrow providers would validate. Ensure that data is, is is present and and valid, and Eboros or • anybody else restoring this would • no to restore that data in that way. So • from from from my perspective. I think it's I think it's it's very, very straightforward. There's there's there's limited impact. It's it's, you know, we have these • unused fields which line up rather nicely and • and and and you know, don't don't seem to present any any issues or conflicts from from my perspective. • Error! Filename not specified. LAX-Galileo 28:17 So to Steve. Answer Steve's question from myself. The registry operator would know when they restore it, because they have the advisory as a registry operator, and there'd be plenty of communication to them when these advisory goes out, and the reminder that's how they were. Know • this is the instructions to the registry operator, saying, Hey, let registry operator, let's do it this way. And if the registry operator all agrees, then that's it. • And right now • there isn't clarity, but we're providing clarity anything else. • Let's see, we are at the top of the hour. 30 min seem really short. • and but we try this way. • Error! Filename not specified. Marc Anderson 28:58 And I said, It's a new hand for me. • I know. • I know Steve. • I know. Steve dropped, but on the chance that he's listening to the recording later. You know he's concerned that • he has not heard how the necessary detail of how the restore process will know. You know. I'll just. • I'll just say, you know, Icann has issued advisories in the past. This is a a standard process that we are used to and comfortable with. And so • the advisory is the mechanism. As you know. As Gustav was saying, the advisory is the mechanism. This is something that's that's done before. And • yeah. And this is • I, you know I would dare to say, a standard practice for how to deal with something like this. • Error! Filename not specified. LAX-Galileo 29:42 It is • most definitely • we're using the tools and the vehicles that • these are already available to us. And we use. We have used this • so many times. There's many advisory that's already been done. So this is not new. But for some people I understand this is a new Uk. So we? We need to take the time to explain these things, and that's part of our • purpose for the meeting anything else from anyone. • Thank you so much. -- Sent by a Verified [Image removed by sender. Sent by a Verified sender][wallet.unumid.co]<https://urldefense.com/v3/__https:/wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y__;!!PtGJab4!-GFRpQjrHDwH7SwYEIk8PoL4GoiLA8HkO28S7jYggrjYGPl834WpXXJ9iYO_RIZkcmWWvGE4KSMYXAPDvUWa7jU$> sender
participants (2)
-
Dennis Chang -
Steve Crocker