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

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

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.png
    LAX-Galileo
    24:38
    Mark, maybe you see. Go ahead.
  • 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.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.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.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.