Subject: Re: Impending publication: draft-iab-dns-choices-05

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Mar 2008 10:31:40 +0100

On Fri, Feb 29, 2008 at 09:57:15AM -0800,
 Olaf Kolkman <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2008 00:52:05 +1100

> registered (the problem which is addressed by RFC 2929bis).

	It was historically difficult because:

	* there wasn't a standard mechanism to emit a unknown record
	  in master file format.
	* the description of when to use compression pointers was
	  wrong.
	* some nameserver only handled known type (through design or
	  as a result of implementation bugs).
	* there was no clear proceedure for gettting a new RR type
	  allocated.

	All of these issues have been addressed for years now.
 
> A second reason why many groups used TXT RR is because middleboxes

	If you worry too much about middle boxes you will never
	deploy anything new.  People will replace middle boxes that
	interfere with their need.

> and at least one Microsoft API do not allow unknown RR types. This has

	So you want to hold up everything because one company
	produced a API that was not RFC 1123 compliant?

> Resource Record Type is hard" in the conclusion.) 

	Because people keep putting up FUD whenever anyone suggests
	getting their own RR type.

	Having got a new RR type, it really was not that hard and
	that was a politically sensative RR.  Others have gone
	straight through once there was agreement about what to put
	in them.  You have that problem whether you use a TXT record
	or not.

	Also you don't have to use TXT to experiment.  There are
	enough types available to be able to experiment provided
	you actually go to the effort of getting a proper RR when
	you are done.  Been there, done that too.  About to do it
	again.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Mar 2008 15:13:46 +0100

On Wed, Mar 05, 2008 at 12:52:05AM +1100,
 Mark Andrews <[email-masked]> wrote 

> 	produced a API that was not RFC 1123 compliant?

Read my message before tearing me to pieces :-) I clearly said I fully
support the main conclusion of the draft ("TXT bad, new RR type
good"). But I regret that the choices of the TXT users are
misrepresented as pure stupidity.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 4 Mar 2008 15:30:08 +0100

On 4 mar 2008, at 15.13, Stephane Bortzmeyer wrote:

> But I regret that the choices of the TXT users are

As often said in the IETF: "Send text".

I.e. suggest text that you think one can get consensus on.

    Patrik

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Mar 2008 01:39:24 +1100

> misrepresented as pure stupidity.

	The IETF is supposed to make engineering decision which
	among other things should consider the entire life of of a
	protocol.

	Most of the cases where people have argued for TXT records,
	they really were not making good engineering decisions.
	Instead they were looking for short term expediancy.

	Middle boxes and API's arguements indicate short term
	thinking and should ring alarm bells with any engineer.

	I see a lot of short term thinking going on in the IETF.

	We should look at what is the best long term outcomes.
	Anything a current implementation that is doing wrong will
	be long gone before the protocol ceases to be used.

	Mark

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Mar 2008 07:32:24 -0800

The IAB tracker indicated this document was dead, now we are told that publication is imminent. Why?

Do we get to ask the author to address the other proposals that have been made to address this issue (XPTR) or does it just get published regardless of whether the claims made are true or not?

I also found the tone of the original paper insulting. I don't think that 'send text' is an acceptable response to such objections. If the author cannot respond to real operational objections that have been raised without condescension then someone else should write the paper or the paper should not be published at all.

I am happy to restate my objections, but not if they are going to be ignored yet again.

-----Original Message-----
From: [email-masked] on behalf of Patrik Fältström
Sent: Tue 04/03/2008 9:30 AM
To: Stephane Bortzmeyer
Cc: Mark Andrews; [email-masked]; [email-masked]
Subject: Re: Impending publication: draft-iab-dns-choices-05

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 4 Mar 2008 16:35:38 +0100

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.

    Patrik

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Mar 2008 08:27:54 -0800

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.

I think that the tone of the paper reflects very badly on the IAB and that 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:

http://quimby.gnus.org/internet-drafts/draft-hallambaker-xptr-00.txt

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 connected.

4) Wildcard support in legacy DNS is no less unsatisfactory under the proposed approach

     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 wildcard '_prefix.*.example.com'

     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 objections raised.

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 substantive changes.

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tue 04/03/2008 10:35 AM
To: Hallam-Baker, Phillip
Cc: Stephane Bortzmeyer; Mark Andrews; [email-masked]; [email-masked]
Subject: Re: Impending publication: draft-iab-dns-choices-05

    Patrik

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 4 Mar 2008 08:45:23 -0800

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:

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Tue 04/03/2008 10:35 AM
To: Hallam-Baker, Phillip
Cc: Stephane Bortzmeyer; Mark Andrews; [email-masked]; [email-masked]
Subject: Re: Impending publication: draft-iab-dns-choices-05

    Patrik