Folks, I am delighted to see thoughtful discussion exploring this topic. It was exactly my goal in writing dns-attrleaf. (And many thanks for alerting me to the thread.)
Preface: When documents specify the use of a special name, then the space from which that name is drawn needs a registry. This is a basic fact of computing life. So I will suggest that any argument against this needs to explain why collisions -- different uses for the same name -- are not a problem. In other words, the burden needs to be on anyone claiming no registry is needed. Similarly, the idea of having multiple registries for the same namespace needs to explain how collisions will be avoided. Bill Fenner wrote: > 1. Registration for any _foo that may appear, possibly just > the one closest to the root in a given domain name. > http://tools.ietf.org/html/draft-crocker-dns-attrleaf > Its introduction points out that the semantics of records > underneath the reserved node name may be restricted; > however, this wording may need a bit of work because, > e.g., dnssec may need to put records there no matter > what the semantics defined elsewhere. Right. On reviewing the comments, I now suspect that the language needs to be in terms of specifying restrictions only with respect to particular RRs that are explicitly listed. That is, the ones that are listed are under the control of the scope limitation, but all other RRs are unrestricted/unspecified. (This seems consonant with later postings in the thread.) > How to move forward? In a way, it's a question of one registry > or two. If draft-crocker-dns-attrleaf intends to have all > protocols and services used in SRV records as well as the other > contents, it could serve as both. However, given the history, I > think SRV records need a little bit different registration rules, In order to have something concrete to use for discussion, I think it is fine to use dns-attrleaf as an base of reference and try to understand what differences from -- or alternatives to -- it are needed. I included SRV in dns-attrleaf because my intent was to include ALL uses of underscore names. This then led to discovering what seem to me to be some basic problems with the details of the SRV specification. Although the form of the SRV documents listing of underscore names is indirect and, I believe, ambiguous I am not clear why it needs to be treated differently from any other. (Comments on your response to Olaf's query about this are below.) Olaf M. Kolkman wrote: > On Jul 18, 2006, at 1:46 AM, Edward Lewis wrote: >> This seems to be in conflict with the iab-dns-choices document. ... > > Well... my reading of dns-choices is a bit different. Choices is > intended to provide the arguments and considerations to make a > trade-off; ... > I think that whoever does the review of documents that 'extend' the DNS > should have a very critical look to see if trade-offs have been made and > if those trade offs have solid arguments. An extremely constructive view. It begs the next question, which is what criteria are supposed to be used, in creating and evaluating any discussion of trade-off considerations? We need to find ways to make this step both useful and predictable, lest it become merely another formal and unpredictable road-block. One example of a likely point of impasse is the tendency to confuse "it won't work" with "I don't like it". Hence the team doing the specification can go through it's considerations, document them, and produce a solution that will, in fact, work, but that reviewers disagree with. This difference between finding fatal flaws, versus points of differing preference, is a common difficulty in the IETF. My own experience with DNS discussions is that the tension between defining a new RR versus using an existing one is a particularly sensitive point that often confuses "it won't work" with "I don't like it". It occurs to me that we also have to ask how much extra burden to impose on the design team and working group, compared with typical IETF specification work. As a rule, the IETF does not require documenting trade-off discussions. Although being able to point to such discussions is sometimes called for, it is not a rule. The rule is that a solution must work, according to a variety of definitions of "work". > Focus on: "The underscore construct is used to define a semantic scope > for the name, within which the choice of valid RRs is limited to a > defined set." > > I think this is the wrong way around (hence including Dave in the CC). I > read the text above as: once one has a domain name with an underscored > label that name gets a semantic scope and only a limited number of RRs > are allowed to be used with that name. I think it is wrong to assign a > semantic scope to a label and then restrict the set of RRs and/or assume > that other RRs will comply to the same semantic scope. > > So I would rather see that turned around: Within the context of specific > resource records underscore labels can define a semantic scope. In other > words a domain name with an underscored label only has specific semantic > scope when used in combination with a RR type for which the semantics > are described/defined. This one gave me quite a bit of pause. (I seem to recall hearing it in Montreal, so I've been paused for about a week...) As nearly as I can tell, the problem with this alternative view is that it fails to solve the primary issues being addressed. The major reasons for using underscore names are to eliminate ambiguity and to eliminate scaling problems, such as multiple and different occurrences of SRV and TXT records. For example, the name says how to interpret any SRV or TXT records that occur under the name ensuring that no other interpretations are allowed, under that underscore name. That is, clear syntax/semantics, and no linear searching for a means of distinguishing one use from another in an undifferentiated set. > The use of underscore labels with a particular RR is just convention and > the chances of folk not sticking to the convention (and creating interop Standard protocols and format are "just convention", so I'm not sure what is being dismissed, here. Wherever there is supposed to be precise parsing and precise semantics, formal "conventions" are needed. In this case, "formal" means standardized. > If a registry as proposed by Dave were to be established I would also > register for which RRs the particular underscored label has semantic > scope. I like your wording here. I think it is simple, clear and correct. Bill Fenner wrote: >> Could you elaborate on that history and why you think you need >> different registration rules? > > RFC 2782 says that the service name is "from RFC1700" and doesn't > say which section. I've seen varying interpretations, from meaning > "any name registered anywhere in any IANA registry" to "the name > from the port-numbers registry". The latter is particularly > odd (you need to have a statically assigned port number in order > to get a name to be able to use the record that allows you to use > a dynamic port number), but seems fairly prevalent. Just to state the obvious: What you have just described is a pretty classic definition of a deficient specification. What is then required is fixing the spec, not creating a registry hack that tries to work around it. > I think that these names need different rules for two reasons: > a) I don't think there's a need to have globally unique > values for the "service" of a SRV record - it's OK if there's > an _spf._udp.example.com even if _spf is reserved as the "top > level" reserved label. This makes sufficiently little sense to me that I am not even sure what to ask or comment about it. Use of the "service" name for SRV is useless without a specification that defines it. If a specification defines it, then how can it possibly be acceptable to have two different specifications define different semantics for the same name? > b) It's too high a barrier to require people who have validly > been using values such as _http._tcp.example.com under the > RFC 2782 rules to write an RFC in order to register the usage. I do not know what is the minimum to require. I certainly believe that IETF standardization is far, far too high a bar. I tried for the lowest level that had long-term stability. This would seem to require an archival specification. RFC publication seems to require that. (We can grandfather all existing name uses in the document that defines the underscore registry.) I suspect that resolving the question of ambiguous usage -- and therefore, registered global uniqueness -- will resolve this question of how high the documentation bar should be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
