On Tue, Nov 26, 2019 at 9:40 AM Matthew Pounsett <m...@conundrum.com> wrote:
> > > On Tue, 26 Nov 2019 at 12:35, Paul Hoffman <paul.hoff...@icann.org> wrote: > >> On Nov 26, 2019, at 9:16 AM, Matthew Pounsett <m...@conundrum.com> wrote: >> > I'm also persuaded by Bill's argument that the IETF has already stated >> that ISO 3166 has control over that bit of the namespace, and trying to >> take back part of it is confusing, bad form, and risky. >> >> For those who read the draft, ypu'll see that "trying to take back part >> of it" is not there. The same was made clear in the presentation to the WG. >> "If you want a private name, here's one to consider; ones like it are >> already being used as private names in dozens of other contexts" is far >> from "taking" anything. >> > > It's still the IETF stating that it's safe to use for that purpose, which > is no longer the purview of the IETF having delegated that responsibility > to ISO3166. That is taking back authority over that name. > No, this is an example how, in some contexts, a double negative is not necessarily the same as a positive. What the proposal is saying is, that the IETF is saying you can't ever use these 42 labels for global use, that they are only ever possible to use in strictly local context. And it is saying, that because ISO 3166 has effectively marked them in a method similar to RFC 6761, there is no reason to expect that to ever change, and that if you need to have a pseudo-TLD for private use (strictly local scope), these would be advisable choices. And, just the way RFC 1918 works, using these for any purpose other than local scope is just a bad idea. However, it is possible for local scope functionality in protocols, to actually require standardization for interoperation, with the caveat of "local scope" made very clear, this proposal is actually really important. I expect to refer to this proposed item in my own proposed work for doing things related to DNS resolver discovery, where the interoperability inside RFC 1918 addressed networks (i.e. explicitly local scope) needs a corresponding local scope namespace. So, it's a particular corner case, where currently the IETF has no previously non-delegated namespace it can work with, and where things under '.arpa' would be poor candidates (because .arpa is a real TLD, etc.). IMHO, of course. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
