(Draft author hat here, not WG chair) > On Aug 10, 2019, at 11:36 AM, John Levine <jo...@taugh.com> wrote: > > In article > <CAHw9_i+dqqHKkzXdcMi1V1rGKBuM=OFGG-UJJ8nLO=dq17d...@mail.gmail.com> you > write: >> Thank you Paul. >> >> As an incentive to everyone else -- there is an Easter Egg hidden in >> this document: if you judiciously choose letters from the text (and >> reorder them) you can create a very rude word. > > I think that like everyone else I've read it, but I'm not sure what to say. >
Well, the document is intended as guidance to the IETF community and to the current/future IESG on what it’s reasonable for people to do with reservations for special use domain names, particularly in IETF protocols. This is only a piece of the larger space around the general idea of the special use names registry, but it seemed like a useful place to start. So it would be helpful to know if you think the recommendations are in fact reasonable. In particular, there’s a couple of distinctions the draft makes in order to carve out what looks (to me, anyway) like a manageable piece of the larger issue of administration of domain names as a superset of DNS names: between TLDs and names elsewhere in the namespace, and between IETF protocols and other possible uses for SUDNs. First, special use “TLDs” (single label domain names) present a hard case for the IETF because of the nexus with another body (ICANN) that has actual authority over what DNS names are delegated as TLDs in the public DNS. A failure to coordinate in such cases could result in poor outcomes for anyone who assumes that the reservation of a special use name under RFC 6761 comes with any assurances about the public DNS. IMO the IETF has three choices here: refuse to reserve single label names as special use; agree to reserve such names, at least as a possibility, and assume coordination is unnecessary; or ask ICANN, through the established liaison relationship, to discuss a process for coordination on reservation of special use single label names outside of the public DNS. No matter which course is chosen, however, a special use name under a TLD that’s already in existence and already under the policy control of the IETF presents a simpler path to approval with fewer risks, so the draft encourages IETF WGs to use such names in their protocols where possible, and the IESG to approve them. (This is the “home.arpa” case.) Second, the other line the draft tries to draw is between IETF protocols, and requests for special use name registrations for use in protocols or code bases not developed in the IETF. This isn’t about excluding anyone else from access to some magical potion, and in fact I’d be happy to propose a more detailed set of guidelines for non-IETF protocols that it might be reasonable to approve special use names for. (The draft suggests “stable specification required,” but I’m not attached to it.) The rationale here is that an IETF registry should have clear policy around its administration, and this one doesn’t: approval of the next .onion is likely to be just as ad hoc as the previous one, because “standards track” has a clear meaning inside the IETF, but there’s no equivalent set of guidelines for requests not based in IETF process. This doesn’t scale in, for example, the case that a sponsor of a closed, non-IETF protocol wants to reserve a set of names: is there any limit to how many names the IETF is willing to reserve? Should there be a stable reference to their use? Is there any presumption that if an existing codebase that uses a reserved name is forked, the new codebase should be able to get a new special use name? RFC 6761 is silent on these questions, which are implicitly resolved for a protocol that’s on the standards track in the IETF, but not for anything else. If a new organization of the contents would be less baffling, I’m definitely open to that, too. Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
