--On Tuesday, December 22, 2009 00:22 -0500 Olafur Gudmundsson <ogud@xxxxxxxx> wrote: > Correction the message should have been: > http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html > > Olafur > > > At 00:18 22/12/2009, Olafur Gudmundsson wrote: >> John, SM >> do the changes that Ted Hardie asked for address your >> concern(s)? see: >> http://www.ietf.org/mail-archive/web/ietf/current/msg59759.ht >> ml Olafur, It seems to me that Ted's message asks for more clarity about what is being specified, actual review by email-related groups of email-related records and their implications, and so on. Certainly I agree with those requests and concerns. Your response is fine, except I have no idea what is actually going to get done, and what those reviews will produce, until I see the results. And those issues are sweeping enough that I really wish the Last Call would be terminated and restarted only when those reviews, and a document that reflects them, is in place. >From that point of view, I'm objecting less to the content of this proposal (as far as it goes), but to the fact that the ducks don't seem to be lined up prior to its going out to IETF Last Call. The comments below are more substantive. >> All we want sink-arpa to do is to create a domain name with >> known characteristics and create a mechanism to define other >> such domain names that may have other characteristics for >> various applications. But that is, from my perspective, a large part of the problem. If SINK.ARPA (or its non-existence) is intended to support various functions, those function should be enumerated and be well-defined. By contrast, this document does some handwaving and includes two specific examples, at least one of which is a little problematic (and that has not been reviewed by the relevant community). I see two other issues that are basically corollaries: (1) In practice, there are many parts of the Internet today where various diversion strategies for failed DNS lookups result in a situation in which NXDOMAIN may not get back to the party issuing the query, at least absent some special case work. It is not clear whether that special case work is harmonious with the intent of this proposal; part of your response to Ted suggests that it is not. Perhaps DNSSEC will solve that problem. Perhaps the desire to commercially exploit those diversions will inhibit the deployment of DNSSEC. But it seems to me that the document should at least contain an analysis of those issues because they may constitute failure cases. (2) Whether names are allocated or permanently reserved, I think there are considerable advantages to keeping the logical second level of .ARPA as small as reasonably possible -- the minimum number of names that are operationally necessary and no more. >From that perspective, creating an IANA registry into which one can easily add names that are logically second-level domains in .ARPA (even if they are never allocated) would be a mistake. If you were confident that exactly one such name were going to be necessary, then maybe. But, if you anticipate more such names, as seems to be the case from the notion of setting up a registry, then it seems to me that all of the traditional arguments for hierarchy in the DNS apply and this should be set up with the expectation, not of sink.arpa. sunk.arpa. drowned.arpa. bitbucket.arpa. seriously-fubar.arpa. etc., but as sink.bogus.arpa. sunk.bogus.arpa. drowned.bogus.arpa. bitbucket.bogus.arpa. seriously-fubar.bogus.arpa. and so on. As with the proposal in the document, the specific names are not important; the structure is. john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf