I endorse and support Stuart Cheshire's remarks below. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com
On Tue, Dec 29, 2015 at 4:32 PM, Stuart Cheshire <chesh...@apple.com> wrote: > Hi Joe, Peter, Alain, > > I have some feedback on draft-adpkja-dnsop-special-names-problem-00. > > There seems to have been lots of recent discussion regarding confusion > surrounding RFC 6761. I’m a little surprised by this, since I didn’t think > RFC 6761 was unclear. But then as co-author, that’s my failing. I thought > it clearly stated our intention, and I thought the IETF Last Call scrutiny > should have identified any ambiguity, but apparently not. > > > In recent years, using the last label of a domain name (aka TLD) as > > switch to indicate how to treat name resolution has been experimented > > using the framework of [RFC6761]. > > Not only the last label. The last _n_ labels are also commonly used as the > algorithmic method for determining what names qualify as special. Some > examples: > > 10.in-addr.arpa. > 168.192.in-addr.arpa. > example.com. > example.net. > example.org. > > > This switch practice is not explicitly documented anywhere. > > That was the intention of the seven-question list: to have protocol > specifications explicitly document their “switch practice” -- i.e. how > their special names are to be unambiguously recognized, and what software > should do having recognized one of them. > > > Answers to these seven questions provide guidance to the > > corresponding seven audiences on how to handle a special-use domain > > name once it has been reserved by inclusion in the Registry. > > However, they are inadequate for making the determination whether a > > particular domain name qualifies as being special in the first place. > > You have it backwards. The seven questions were not “what to expect > *after* this special-use registration is done”; they were the > justifications *why* the special-use registration should be granted, > required in a document demonstrating that it (a) provides a result that the > community judges to be good, and (b) the aforementioned good result cannot > reasonably be achieved better another way. > > > The lack of a more elegant way to specify a name resolution protocol > > in (for example) a URI amounts to an architectural oversight. > > I’m not sure I agree that there *is* a more elegant way to achieve the > desired effect. Unless you intend to actually describe some hypothetical > “more elegant way” of doing this, I suggest simply removing this > unsupported implication from the document. > > > It should also be noted that there are other choice than using the > > most significant label for a protocol switch. In particular, a > > proposal to move those protocol switches under a specific top level > > domain has been discussed (.ALT). If that architecture choice is > > made, some of the questions listed in the sections bellow (sic) would > > become moot. > > RFC 6761 is not, and has never been, about TLDs. It is about special > behaviours, and how to trigger them. As such, whether the protocol switch > is a TLD, or SLD, or 3LD, or whatever, has no bearing at all on “the > questions listed in the sections below”. The same concerns would apply > equally, regardless of how the algorithmic determination of “specialness” > is to be performed. RFC 6761 states that the algorithmic determination is > *typically* done by looking for a certain suffix (i.e., one or more > labels). I deliberately did not want RFC 6761 to over-specify this, so as > to leave the door open for someone smarter than me who might come along in > the future and propose some new and valid algorithmic determinant that I > had not anticipated. Clearly a document stating that any name containing > any label starting with an “x” is now “special” ought to be thrown out by > the IESG as unreasonable, but there could be other valid ideas beyond my > current imagination. > > > Note: [RFC6761] mentions the reserved names could be any label in any > > random string, not just the rightmost one (or ones). > > Can you cite the actual text that says that? I couldn’t find what > particular text you’re paraphrasing there. > > > What does it mean to have a "non-DNS" entry in the registry > > described above? > > The answers to the seven questions, and other text in the associated > protocol specification, are supposed to tell you what it means. > > > Are applications supposed to check that registry to know what to do? > > No. > > > Can/Should applications do this check dynamically? > > No. > > > What if an application makes this dynamic check and realizes the > > name contains a switch it does not know how to treat? > > Not applicable. The closest equivalent to the run-time mechanism you’re > hinting at is something that already exists: The global DNS. Putting in > authoritative NXDOMAIN results for all appropriate special-use names is the > best way to achieve the result you want. > > > it is not clear who is responsible for carrying out an > > evaluation. A document which requests additions to the Registry > > might be performed by the IESG, by the IAB, by the DNSOP working > > group, by an ad-hoc working group, by expert review or any > > combination of those approaches. [RFC6761] provides no direction. > > RFC 6761 says: > > When IANA receives a request to record a new "Special-Use Domain > Name", it should verify, in consultation with the IESG, that the IETF > "Standards Action" or "IESG Approval" document [RFC5226] includes the > required "Domain Name Reservation Considerations" section stating how > the special meaning of this name affects the behavior of hardware, > software, and humans in the seven categories. If IANA and the IESG > determine that special handling of this "Special-Use Domain Name" is > appropriate, IANA should record the Special-Use Domain Name, and a > reference to the specification that documents it, in the registry. > > I confess I has assumed that IANA would designate some person with the > expertise and experience to evaluate whether “... special handling of this > "Special-Use Domain Name" is appropriate ...”, much as requests for TCP and > UDP ports are evaluated. That was my mistake. I should have been explicit > about the intended review process. > > > For example, is large scale prior deployment an acceptable criteria? > > Large scale prior deployment should *not* be required -- that would just > make squatting a necessary prerequisite for getting a special use name > assigned. RFC 6761 was intended to provide a legitimate path for proposals > to be evaluated on technical merit, rather than de facto squatting. > > > Going back to the previous point of prior usage of the protocol, in > > the case of LOCALHOST, LOCAL and ONION, those particular domain names > > were already in use by a substantial population of end-users at the > > time they were requested to be added to the Registry. Rightly or > > not, the practical cost of a transition was argued as a justification > > for their inclusion in the registry. > > No. The justification for having an entry in the registry was to > facilitate the desired special behaviour. The particular choice of what > name went in the registry was influenced by existing usage, but the > justification for having the entry itself was motivated by the desire for > special behaviour. If the IETF process went a bit more smoothly, the IETF > would have more participation in the choice of name *before* it becomes too > late to easily change that. > > As I read it, draft-adpkja-dnsop-special-names-problem seems to focus far > too intently on the issue names. (But then, that is what ICANN is in the > business of selling, so maybe it’s not surprising.) The substance of RFC > 6761 is about enabling special behaviours, and using special names to > trigger those special behaviours is merely a means to the end. What is > interesting and important, and worthwhile for the IETF to support, is the > special behaviours, not the names. > > Stuart Cheshire > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
