Dear colleagues,
It will be helpful to the chairs in considering the future of this draft if folks could keep a few things in mind as we discuss it. 1. This draft as written takes no formal action to reserve anything for any particular purpose. It makes some observations about the administration of ISO 3166 and its use in the ICANN context, and suggests to operators and implementers that the ISO3166 user-assigned 2-letter strings could be suitable for local use in domain names. It does not include any IANA actions to update any registry or protocol element. So claims that this draft reserves names or attempts to override ICANN policy about “TLDs” seem premature. We’ve heard concerns that by encouraging people to use these strings in local DNS contexts, an RFC with no IANA actions could have the effect of constraining future ICANN policy. This brings us to: 2. If we want to know what ICANN-the-organization thinks of this proposal, there is a mechanism for asking that question. The IAB, on behalf of the IETF, maintains a liaison relationship with ICANN, in the form of a non-voting liaison to the ICANN Board of Directors, who can be asked to convey a question or statement about an issue of mutual interest. We’ve used this capability before, and intend to ask the IAB to make use of this liaison relationship again if the WG wants to proceed on this draft. As one of the draft authors already wrote to the list, the draft does not offer an official position or commitment by ICANN as an organization. (Under our process, affiliation of a draft author can’t be used to infer such statements, either.) That’s literally what liaisons are for: to allow the IETF to interact with a standards or policy body as an organization. 3. When several proposals came to the IETF more or less at once regarding “special use domain names”, which proponents were insisting had to be single-label names (“TLDs”), the DNSOP chairs — in consultation with the IAB and IESG — set those proposals aside in hopes of finding a less time-consuming, more scalable, and less dramatic way of considering changes to the special use names registry than having an open-ended IETF Last Call, since there’s almost no technical guidance in RFC 6761 to determine whether a specific request is useful or even valid. This did not happen. RFC 8244 was published in 2017, but several drafts attempting to solve parts of the problem it described met with very little interest from the WG. The chairs are reluctant to spend WG time in this area unless there’s reasonably clear benefit. If there is, we’re happy to work with the WG, the IAB, ICANN liaison, et. al. to manage any governance issues. Best, Suzanne, Tim, and Benno > On Jun 12, 2020, at 11:12 AM, Tim Wicinski <tjw.i...@gmail.com> wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular calls for adoptions over the next few months. We are looking for > *explicit* support for adoption. > > > This starts a Call for Adoption for draft-arends-private-use-tld > > The draft is available here: > https://datatracker.ietf.org/doc/draft-arends-private-use-tld/ > <https://datatracker.ietf.org/doc/draft-arends-private-use-tld/> > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 26 June 2020 > > Thanks, > tim wicinski > DNSOP co-chair
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
