RE: Impending publication: draft-iab-dns-choices-05

"Hallam-Baker, Phillip" <pbaker@verisign.com> Tue, 04 March 2008 16:51 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E0228C6CB; Tue, 4 Mar 2008 08:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.033
X-Spam-Level:
X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Lo44Qxy3Qsa; Tue, 4 Mar 2008 08:51:39 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEB128C5F1; Tue, 4 Mar 2008 08:46:17 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996F028C389; Tue, 4 Mar 2008 08:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSAm3r7ye1-b; Tue, 4 Mar 2008 08:46:10 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 3FA4128C6A8; Tue, 4 Mar 2008 08:45:50 -0800 (PST)
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id m24Ga0hv014505; Tue, 4 Mar 2008 08:36:00 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Mar 2008 08:45:26 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Impending publication: draft-iab-dns-choices-05
Date: Tue, 04 Mar 2008 08:45:23 -0800
Message-ID: <2788466ED3E31C418E9ACC5C3166155727C8F5@mou1wnexmb09.vcorp.ad.vrsn.com>
In-Reply-To: <BA55A872-D53B-4BA1-BAA3-2D4D48774E4C@frobbit.se>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Impending publication: draft-iab-dns-choices-05
Thread-Index: Ach+DWfOzTnHQvH0SWqsnwzH6xy5TgACX8FQ
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Patrik Fältström <patrik@frobbit.se>
X-OriginalArrivalTime: 04 Mar 2008 16:45:26.0647 (UTC) FILETIME=[25F8D070:01C87E17]
Cc: Mark Andrews <Mark_Andrews@isc.org>, ietf@ietf.org, iab@iab.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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:

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:patrik@frobbit.se]
Sent: Tue 04/03/2008 10:35 AM
To: Hallam-Baker, Phillip
Cc: Stephane Bortzmeyer; Mark Andrews; ietf@ietf.org; iab@iab.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.

    Patrik


_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf