Hello Dave,
Thanks for the long reply.
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.
Well said.
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.
(...)
Dave:
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.)
I think that is a fair summary.
(...)
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.
Shall we, as a collective, try to start from common sense. I think that creating a check list or set of evaluation criteria is overkill.
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 little bit more certain that the DNS can scale just a bit more. Demonstrating the understanding of the principles by making the trade-off will certainly help the protocol designers and the folk that need to do the DNS reviewing.
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.
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.
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. Besides the underscored labels are used for subtyping the SRV RR. 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.
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.
So the difference in trade-off here is, I think, between sub-typing that is needed in the the application of SRV and sub-typing the TXT RR for use with different applications.
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.
I used a platitude :-) I seem to do that all the time :-)
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.
Thanks for the compliment. But I also hope that there is a bit more elaborate wording that refers to dns-choices and explains that TXT RRs are the least optimal choice.
I hope it is somewhat clear what I mean.
PS. I will be leaving for vacation soon but I wanted to reply before I leave; therefore I only replied on a few main points. I am not able to put more attention to this thread in the next 4 weeks.
PPS. oh by the way. DNSEXT has a last call on RFC2929bis [1] that document is relevant to this discussion, it explains how to obtain a new typecode.
PGP.sig