I think it would help a lot of people in this thread if we knew what the
subject line meant by 'impending publication'.
I and others made numerous objections to draft-04 which were not responded to.
That draft expired April 26, 2007. I did not continue the conversation because
I believed that the paper had been withdrawn.
Why is this document now considered to be ready for publication when the
authors are aware that there are outstanding objections?
I think that the tone of the paper reflects very badly on the IAB: It is not
appropriate to second guess or assume the mental processes of designers. The
approach proposed in this paper is neither practical nor scalable for reasons
that have been stated in the past, both to you personally and on various
mailing lists. I made a counter proposal in the form of an ID which has been
discussed repeatedly on DNSEXT that addresses the limitation with wildcards and
prefix records. This proposal is not addressed in the draft despite the fact
that two IDs have been written proposing this approach:
I have the following objection to the proposal in the draft:
1) RRs are a finite resource, the mechanism does not scale.
Due to Web services we are likely to be adding several thousand new
protocols to the Internet each year. The well known ports approach is not
scalable in this respect. That was one of the reasons behind the introduction
of SRV and NAPTR.
2) Legacy infrastructure support is a real concern
Microsoft have demonstrated that their DNS server source code does not
provide production quality support for unknown RR types. Their servers have 50%
of the market. These are significant concerns for a protocol designer.
Yes, I know that you can inject extension RRs to a Windows DNS server
using a script and the DNS server will continue to relay them until it reboots.
That is a hack, it is not what any competent Windows sysadmin is going to
accept in a production environment. The manufacturer has stated that their
product is not capable of use in the stated manner.
3) Wildcard support is not a major concern
Wildcard support is not actually a concern for most DNS discovery or
policy distribution approaches. The only case where it is in fact an issue is
email policy statements where it is actually desirable to make a wildcard
statement of the form '*.example.com sends no email'. This requirement does not
arise in synchronous protocols where the two parties are simultaneously
4) Wildcard support in legacy DNS is no less unsatisfactory under the proposed
Introducing a new RR does not in fact address the principle concern that
people have with new RRs.
5) An alternate solution that has been proposed is not addressed in the draft
The 'choices' draft only examines the proposals that lead towards the
authors desired conclusion. the XPTR ID and Domain Centric Administration
drafts were both published while this ID was being edited. The approach
described provides a simple solution to the problem of constructing a midpoint
This solution can be effected without the need to introduce any new RRs by
defining semantics for the PTR RR in the forward DNS (it is currently undefined
in forward DNS). For tactical reasons of deployment incentives it is preferable
to introduce a new record for this purpose, XPTR.
The IAB should not publish this document in its current form. The proposal made
does not reflect a good architectural approach. It is unscalable, fails to
provide properly abstracted layer separation and fails to take account of the
legacy infrastructure. The authors have failed to make any effort to respond to
It is simply not appropriate for a controversial draft that has been expired
for almost a year to be pronounce ready for publication as an RFC with no
From: Patrik Fältström [mailto:patrik(_at_)frobbit(_dot_)se]
Sent: Tue 04/03/2008 10:35 AM
To: Hallam-Baker, Phillip
Cc: Stephane Bortzmeyer; Mark Andrews; ietf(_at_)ietf(_dot_)org;
Subject: Re: Impending publication: draft-iab-dns-choices-05
On 4 mar 2008, at 16.32, Hallam-Baker, Phillip wrote:
I also found the tone of the original paper insulting. I don't think
that 'send text' is an acceptable response to such objections.
For the specific issue, the lack of correct history of why people did
select TXT RR Types my conclusion was that some new added text was
needed that described it. For that specific issue, I felt "send text"
was the correct response.
IETF mailing list