Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

manning <bmanning@karoshi.com> Wed, 28 May 2014 19:17 UTC

Return-Path: <bmanning@karoshi.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F801A01ED for <ietf@ietfa.amsl.com>; Wed, 28 May 2014 12:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtTovTbAJwHl for <ietf@ietfa.amsl.com>; Wed, 28 May 2014 12:17:46 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8406F1A0171 for <ietf@ietf.org>; Wed, 28 May 2014 12:17:46 -0700 (PDT)
Received: from [192.168.0.2] (cpe-23-241-118-60.socal.res.rr.com [23.241.118.60]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4SJHB01005797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 May 2014 12:17:15 -0700 (PDT)
Subject: Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Content-Type: text/plain; charset="windows-1252"
From: manning <bmanning@karoshi.com>
In-Reply-To: <FDC0E3E9-DD1B-4EF4-8C3C-54B902AEC92F@vigilsec.com>
Date: Wed, 28 May 2014 12:17:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BA5A979-97E6-4EA0-A657-DE4A8C02660A@karoshi.com>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140521194638.06eaf508@resistor.net> <1111FB79-012A-414B-B8CD-0BBDAE8BD6A8@hopcount.ca> <6.2.5.6.2.20140522095317.0c5fd648@elandnews.com> <5C02BCCA-79D7-40A5-BFB0-26284A667E78@vpnc.org> <DC9ED318-2352-4AF0-8A43-29D237C32B64@vigilsec.com> <924045CD-DC34-423B-8702-CD99CF687D46@vpnc.org> <FDC0E3E9-DD1B-4EF4-8C3C-54B902AEC92F@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.1878.2)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@karoshi.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/7nkcK1CXv45jyM7_d2txOMFEjFU
X-Mailman-Approved-At: Thu, 29 May 2014 08:10:58 -0700
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
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>
X-List-Received-Date: Wed, 28 May 2014 19:17:47 -0000

the odd thing is, since document is cobbled together as both a floor wax and a dessert topping it can do neither well, certainly NOT as a BCP.

It might be realistic of the IETF to talk about the protocol requirements for running a DNS server (the roots are not special in this regard).
It beggars the imagination to think the IETF can or should dictate operational considerations to any organization or organizations that use
its protocols.   First blush,  the pace of operational requirement changes can’t easily mesh with the pace of IETF document standardization.. Not even 
with a SyncroMesh(tm) Transmission.

Perhaps it might be better to move RFC 2870 to historic and admit the IETF does;t dictate operational requirements, instead choosing to focus on
it core competencies.

/bill

 
On 28May2014Wednesday, at 10:09, Russ Housley <housley@vigilsec.com> wrote:

> Paul:
> 
>>>> |      MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS
>>>> |      queries and responses.
>>>> 
>>>> This needs an addition: "Some servers in the root name service might not support IPv4, and some might not support IPv6." Without that, some people might think that each server must respond on both layer 3 technologies, but they do not.
>>> 
>>> I would like to see each and every root server support both IPv4 and IPv6.  
>> 
>> So would I. But is that a *requirement*, particularly given that the root service seems to run just fine today without it?
>> 
>> I propose that the addition is still needed, despite what you and I would like to see.
> 
> If a root server does not support both IPv4 and IPv6 then it does not comply with the proposed BCP.
> 
> Russ
>