[NCAP-Discuss] FW: [Ext] Questions from NCAP Discussion Group on IANA RZM procedures

[Thomas, Matthew]

NCAP DG – Please see some initial questions and reply from Kim Davies at IANA.  We hope to have Kim or an IANA person available for discussion next week at the workshop.

Matt

From: Kim Davies <kim.davies at iana.org>
Date: Wednesday, 27 September 2023 at 17:06
To: Suzanne Woolf <swoolf at pir.org>
Cc: Jennifer Bryce <jennifer.bryce at icann.org>, Matt Larson <matt.larson at icann.org>, "Thomas, Matthew" <mthomas at verisign.com>, James Mitchell <james.mitchell at iana.org>, Amy Creamer <amy.creamer at iana.org>
Subject: [EXTERNAL] Re: [Ext] Questions from NCAP Discussion Group on IANA RZM procedures


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Suzanne, Hi all,

My overall response on the scope of the questions is that I would not assume this concept needs to be strictly modelled into the existing delegation process, where an applicant (in this case TRT) contacts IANA, is evaluated, and then inserting a delegation in the root zone is a consequence of the successful completion of that evaluation. Rather, from what I gather of this TRT concept, it is part of the evaluation phase leading up to the production delegation of a string. Therefore I’d be looking to explore implementing a new phase of our existing evaluation workflow where IANA would implement a new sub-process to introduce NS/DS records in the root zone prior to the ultimate delegation to the actual applicant, rather than as two distinct delegations. I imagine we would distinguish this phase appropriately in all the appropriate records, but I don’t think it would manifest as an evaluation to delegate to the TRT entity itself.

In response to the questions:


  1.  There have been no substantial changes to the root zone update process described in the JAS study that are relevant to this discussion.
  2.  IANA has implemented API access for TLD managers, but that is only designed for existing TLDs, not for new delegations. With that said, I think per the above, we’d be looking to implement a brand new business procedure for this kind of concept rather than shoe-horn it into the existing concepts. We have internal API integrations between our systems and ICANN’s TLD application processing system that maybe we’d leverage for exchanging relevant information for such a process. Based on the role of the TRT, I’d imagine they’d have a portal into the TLD application system in order to see and evaluate incoming applications, and perhaps it is through that portal they’d be marking applications as “high risk”, “ready for pre-delegation” and the like which would trigger the associated workflows with IANA; rather than the TRT interacting with IANA directly itself.
  3.  I don’t have a confident answer, but if it is an implementation feature of the ultimate application process adopted by the ICANN Board for the next round of applications, I think that gives us the mandate to implement. In the last round, a number of implementation details were approved at the staff/management level, and this is probably similar in nature apart from the fact that it introduces a new, perhaps surprising, aspect to the operational community that would need to be clearly communicated and perhaps provide for the opportunity for community review prior to implementation.

Happy to make myself available for a discussion as timing permits.

kim


From: Suzanne Woolf <swoolf at pir.org>
Date: Monday, September 25, 2023 at 12:37 PM
To: Kim Davies <kim.davies at iana.org>
Cc: Jennifer Bryce <jennifer.bryce at icann.org>, Matt Larson <matt.larson at icann.org>, "Thomas, Matthew" <mthomas at verisign.com>
Subject: [Ext] Questions from NCAP Discussion Group on IANA RZM procedures

Hi Kim,


As you might recall, the NCAP Discussion Group has been discussing some changes to the 2012 New GTLD Round workflow for capturing and reviewing potential name collision issues for requested strings.

In order to finalize our thinking on the proposed changes, we need some help from IANA staff, in making sure we understand the processes for root zone updates and what additional burdens or risks the proposal could impose on the RZM system.

We’ve prepared a short description of the issue we’re attempting to resolve, and a couple of specific questions, which is available in Google Docs at: https://docs.google.com/document/d/1RqVYosWB1GNlzRjUwCCVuSEeEazqcncm2jolfDSTojs/edit?pli=1 [docs.google.com]<https://secure-web.cisco.com/1xQRrdG4qJfnoffeeTmOzynDgDAjd2xMCxXpLxVGIo7qgYcdNVX_DeUCyEsYXVlY7ULqF_RpDeoq5jpDRPIaRRdEEIk3iAgxp44inb6lV5ld9i1HLs21-_HGmRsKp0z6LzHwm9bq0MLag37Ec9QAfclZesTi-rZMYr5AfQfq41NXaELaIQYbtusvpKzIi1TdQA2oJy-0HTsEzPwutYXvR1EDMaG1SxH_b-5M-mQzcZTs-IEWeKjiM5EMueYNvLhUNaQid1fjevXVMmZHccJZIs6IN4HoBzvlKhIpSlhBjjaE/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdocs.google.com%2Fdocument%2Fd%2F1RqVYosWB1GNlzRjUwCCVuSEeEazqcncm2jolfDSTojs%2Fedit%3Fpli%3D1__%3B%21%21PtGJab4%219JqjlMlCLbxMHkzbKDB7DrgOJeAgUM5A_qQECqj2GYpCSZGFgPNQq9wxF-uaCfO3aVhyNWIwG_LTxwfCoUSz%24> (and also I’ve attached below, if that’s easier). We’d greatly appreciate responses (as brief or as expansive as you’d like) at your earliest convenience.

It would also be extremely helpful if you or one of your team could be available to talk with the DG about these questions, either at our regular discussion group meeting on Wednesday Sept. 27 at 20:00 UTC, or during our workshop in Washington DC on Tuesday next week.

My personal apologies for the short notice on this request, and we’ve tried to keep it brief and straightforward. Many thanks for your consideration.


Best,
Suzanne

For Suzanne Woolf & Matt Thomas
NCAP Discussion Group co-chairs
==============



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230929/b417a48c/attachment-0001.html>