Olaf M. Kolkman wrote: > I only hope we both agree that the 'domainname' namespace will have two > registries once we create a registry for "underscored". The distributed > registry that roots in the IANA/ICANN domain name root and this new > registry for underscored labels.
Good point. That perspective had not occurred to me, but of course you are right. Alas, it is a natural outgrowth of having special meaning for underscore names. Value-add formal meaning requires value-add formal registration. >> 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.> > > As always this goes two ways. There have been many occasions where DNS > folk suggested that the definition of a new RR type is the best way > forward and the folk using "TXT" said "that won't work". Personally I > think it is important that protocol developers try to develop protocols > in a way that comes closest to what I, and many or my colleagues here, > have started to appreciate as architecturally sound. That way can be a Is it equally important for this group to wonder at the long-term poor track record, in getting new RRs to reach critical mass in a timely fashion? > little bit more certain that the DNS can scale just a bit If a particular proposal has real scaling problems, then their details can be stated clearly and compellingly. Not as a principle but as a specific, mechanical implication of the particular design. At that point, "it won't work" becomes a pretty obvious reality for the proposal... >> 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".> > > I think that in this space it is more about finding the balance between > "a hack that works" and an architecturally sound solution. Again a tradeoff. yup. > >> 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". > > That definition should IMHO include that it does not break something else. SRV "breaks" wildcard. Should we deprecate SRV? >>> 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 point that I am trying to make is that for the SRV record this makes > sense; roughly speaking for SRV RRs the underscored labels have always > had specified semantics. In terms of DNS history, SRV is quite recent, so I am not sure what you mean by "always". My reading of the SRV specification is that it is, in fact, ambiguous about the specific tables of names that it is citing. This prompts me to suspect that the SRV specification is really specification of a template, and that particular uses of that template need their own specification, citing the specific underscore names being covered. (It was only the process of writing the -attrleaf draft and reviewing the SRV spec closely that led me to that conclusion. I am hoping that someone will point out how that conclusion is incorrect, since the SRV has always struck me as being intended to enable its use for a broad class of services, without the overhead of specifying the lookup mechanism for each one in detail.) > For TXT RRs this has not been the case and even > when one uses a registry for the underscored labels there might be > different groups that use the TXT RR for the same owner name with > different semantics. In other words there is opportunity for collisions. You appear to be saying that two different groups have defined different semantics for the TXT record, under *the same* underscore name. I was not aware that this had happened. > One could have started using SRV techniques with TXT RRs with owner > names like _sip._udp._srv.example.com. That would have worked and would > have had more or less the same properties as the use of SRV RRs today. I think that's what the registry idea is intended to handle. >> 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.> > I used a platitude :-) I seem to do that all the time :-) Platitudes are nice. d/ ps. have a fun vacation. -- 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
