On Fri, Feb 29, 2008 at 09:57:15AM -0800,
Olaf Kolkman <olaf@xxxxxxxxxxxx> wrote
a message of 48 lines which said:
> The IAB is ready to ask the RFC-Editor to publish
>
> Design Choices When Expanding DNS
> draft-iab-dns-choices-05
I fully agree with the overall message ("the use of a new DNS Resource
Record Type is the best solution") but not with the way that the other
choices are ridiculed:
> DNS extension discussions too often focus on reuse of the TXT
> Resource Record Type.
It is a bit strange that there is nowhere in the draft even a small
bit of auto-critique. If many people used TXT RR types, it is because
it has been historically quite difficult to get a new RR type
registered (the problem which is addressed by RFC 2929bis).
A second reason why many groups used TXT RR is because middleboxes and
at least one Microsoft API do not allow unknown RR types. This has
been reported several times.
Reading the current I-D, one may wonder why so many people stupidly
used TXT records... (See also the very questionable "it is worth
reexamining the oft-jumped-to conclusion that specifying a new
Resource Record Type is hard" in the conclusion.)
> example of new data is [...] data used for fighting spam
If this refers to RFC 4408 or 4871, then "fighting spam" is not a
correct summary (by itself, authentifying the sender does not fight
spam, spammers can be authentified too). "Email domain sender
authentication" may be a better term.
> Splitting an RRSet is a protocol violation
I have a doubt here. The protocol allows to send partial RRSets, you
just have to set the TC bit (RFC 2181, 5.1).
> The process for creating a new Resource Record Type is specified in
> [I-D.ietf-dnsext-2929bis].
It is just an informative reference. Do you plan to publish
draft-iab-dns-choices-05 before 2929bis? (It would be a bad idea,
IMHO, to tell people they must use a new RR type, before the new
procedure for doing so is ready.)
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf