Hi Joe, thanks for your thoughtful comments. > On 6 May 2020, at 02:18, Joe Abley <[email protected]> wrote: > > Hi Roy, > > I have read this document and I like it. > > There have been other proposals to make recommendations like this in the past > that I have not been very enthusiastic about. The reason I like this > draft-arends proposal more is that it neatly avoids the problem of who gets > to make policy about this stuff by pointing out that suitable policies > already exist and that hence the problem is already solved. > > I also like the happy accident that the names on the user-assigned list are > all pretty much equally arbitrary in every language in which US-ASCII labels > have the potential to have semantic meaning. This seems better than choosing > a label that is a recognisable word in some languages but not others. > > I have two suggestions for the document. I have some doubt about the second > suggestion, but the first one seems definitely great. :-) > > 1. While this document currently includes instructions to the IANA that could > be viewed as specifying TLD naming policy, it might be possible to avoid that > particular hidden foot-operated explosive device with some re-wording. > > This document could simply make the observation that since existing ccTLD > label policy is to defer completely to ISO-3166 alpha-2 (citation needed) and > since ISO-3166 alpha-2 includes user-assigned codes that will never be > assigned to a territory (citation needed) then it is consistent with existing > policies that those user-assigned codes will never be delegated from the root > zone in the DNS and, for that reason, will never give rise to collisions with > any future new TLD. > > That would leave this document simply as a clarifying description of existing > policy, instead of appearing to have ambitions to change or specify policy in > the root zone (which is the kind of thing that ICANN is also plausibly > responsible for). The consequence of that small change might be (is, I think) > to make this document completely uncontroversial whilst preserving the core > advice. No worm containment failure required.
That is good advice. I’ll take it. This will be reflected in version -02, which will drop shortly. > 2. The document stops short of making a clear recommendation in section 5. > While the decision to anchor a private namespace in something that looks like > a TLD is not necessarily the only plausible answer (I could anchor such a > namespace at a domain that I reserve through normal domain registration, for > example) the document *could* say "for applications that require a private > namespace anchored at something that looks like a TLD, our recommendation is > to do this". > > It is possible, of course, that a clear recommendation might have an XKCD-927 > effect (which would be unfortunate but perhaps tolerable) or no effect > whatsoever (which at least seems benign, but which is also a bit useless). > However, if the document is not going to make any clear recommendation, I'm > not sure what the point of publishing it is. Good point, I’ll take this into consideration. I will have new and improved wording in version -02. Roy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
