Hi Warren! Thanks for the explanations to my feedback.
From: Warren Kumari <war...@kumari.net> Sent: Wednesday, April 26, 2023 11:49 AM To: Roman Danyliw <r...@cert.org> Cc: The IESG <i...@ietf.org>; draft-ietf-dnsop-alt-...@ietf.org; dnsop-cha...@ietf.org; dnsop@ietf.org; suzworldw...@gmail.com Subject: Re: Roman Danyliw's No Objection on draft-ietf-dnsop-alt-tld-23: (with COMMENT) On Tue, Apr 25, 2023 at 4:54 PM, Roman Danyliw <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-alt-tld-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Linda Dunbar for the SECDIR review. ** Section 2. Currently deployed projects and protocols that are using pseudo-TLDs are recommended to move under the .alt pseudo-TLD, but this is not a requirement. I don’t understand the basis of this recommendation. Projects and protocols using pseudo-TLDs (outside of https://www.iana.org/domains/reserved) are already not following published guidance. Why is there an expectation that this document can change behavior? It's not really an expectation, more of an invitation/suggestion. At one point this had text along the lines of "may choose to", but that was felt to be a bit weak. There was some discussion about making this "are RECOMMENDED to move", but that was felt to be too strong (and who the hell are we to tell 'em what to do anyway?!). This was the happy medium we settled on. Good enough? [Roman] Yes. I figured there long deliberation on a few set of words. Section 3.2. Item #3. Editorial. s/Writers of name resolution APIs/Creators of name resolution APIs/. Or “developers”, “implementers, or “designers” Thank you - I've updated this to be "Developers" in Pull Request #46. Backstory: This section "answers" the questions from RFC6761, and Q 3 was phrased as: "3. Name Resolution APIs and Libraries: Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?" We'd just sort of followed along from the language. ** Section 3.2. Item #7 7. DNS registries/registrars for the global DNS will never register names in the .alt pseudo-TLD because .alt will not exist in the global DNS root. Items #4 – 6 on this list use RFC2119 language to make the expected behavior clear. This text seems to be written in an aspiration form describing what registries/registrars will do, without explicitly prohibiting them with normative language. Is there a reason for that? Yup, actually 2 reasons: 1: .alt will not exist in the DNS, and so it's not possible for DNS registries and registrars to register DNS names. We don't tell pigs that they MUST NOT fly, and so telling registries and registrars that they MUST NOT do something that they are unable to seemed odd. But, Paul Wouters also pointed at this text in his ballot, and that it is unclear, so I've suggested (in PR 46) this instead: "7. It is not possible for DNS registries/registrars to register DNS names in the .alt pseudo-TLD as the .alt will not exist in the global DNS root." 2: there is some sensitivity here. ICANN regulates registries and registrars, and I was trying to be extra careful to not accidentally step on toes and imply that the IETF was telling 'em what to do… [Roman] Understood. Roman
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
