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

Marc Blanchet <marc.blanchet@viagenie.ca> Tue, 17 February 2015 22:42 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 ED6301A8946 for <ietf@ietfa.amsl.com>; Tue, 17 Feb 2015 14:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 080WrppoprIh for <ietf@ietfa.amsl.com>; Tue, 17 Feb 2015 14:42:40 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF041A88D5 for <ietf@ietf.org>; Tue, 17 Feb 2015 14:42:40 -0800 (PST)
Received: from kuwa.viagenie.ca (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D1C3740391; Tue, 17 Feb 2015 17:42:41 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_79840C8A-2850-4D56-B3B7-8239D4B9B885"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: [IAB] Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <20140520204238.21772.64347.idtracker@ietfa.amsl.com>
Date: Tue, 17 Feb 2015 17:42:39 -0500
Message-Id: <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ZWJUaCh_wVI1jS8zlltv0bk1E2s>
Cc: IAB <iab@iab.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: Tue, 17 Feb 2015 22:42:44 -0000

Hello,
 Many LC comments were about the stale reference to RSSAC001. This RSSAC001 has been posted in december, which shall solve many issues raised.  Moreover, a new version of the draft (-02) http://datatracker.ietf.org/doc/draft-iab-2870bis/  has been posted based on the comments. Below is a summary of LC comments and actions taken.

Regards, Marc.

http://www.ietf.org/id/draft-iab-2870bis-02.txt <http://www.ietf.org/id/draft-iab-2870bis-02.txt>

Marc.

=====
Summary of IETF LC comments on draft-iab-2870bis

A) mainly 2 individuals do not agree with the document approach, such as:
- IETF should not specify what root servers do
- should not be a BCP
- should not be split into 2 documents
- should only put historic to 2870bis
However, 6 individuals responded to those comments with supporting the document and its approach.
We still believe that this document is the right approach and have achieve rough concensus.

B) Comment: RFC2119 language is not appropriate for a BCP.  We believe that, while not a protocol specification, it provides recommendations to an implementation of the root service therefore we think it is appropriate to use this language.

C) Comment: Add text on fragmentation and MTU. We believe that this is more of operational nature and therefore should not be part of this document.

D)  Some noted that some root servers are not supporting IPv6 at the moment. We note that we are not talking about specific root servers but the root service. Some followup comments have replied to that effect. Therefore, we think this is ok as it is.

E) Comment: .arpa is not really part of the root zone. Moreover, the MAY does not do anything. We agree and removed that requirement.

F) some (non-substantive) text fixes were suggested that we agreed and implemented in the new version of the document.

G) a suggestion to add that  "IANA has a responsibility to publish [ROOTZONE], update the root hints, and ensure the root zone trust anchor is published ». We agree on the idea, but believe this is more on IANA role than root service and therefore enlarge the intended scope of the document, therefore we did not change the document, unless the AD thinks we should.

H) a suggestion to state that a root service may not answer queries in the presence of operational events such as DDOS or else.  We agree on the idea, however, we believe this is an example of operational issues that should not be discussed in this document, since it would require all kind of operational qualifications and text..

I) Many comments were reflecting the absence of RSSAC001 publication at the time of the IETF LC. The RSSAC01 document has now been published by RSSAC and it has a stable reference. The reference has been updated accordingly in the document. This should solve those many comments.


> Le 2014-05-20 à 16:42, The IESG <iesg-secretary@ietf.org> a écrit :
> 
> 
> The IESG has received a request from the Internet Architecture Board 
> (iab) to consider the following document:
> 
> - 'DNS Root Name Service Protocol and Deployment Requirements'
>  <draft-iab-2870bis-01.txt> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>   The DNS Root Name service is a critical part of the Internet
>   architecture.  The protocol and deployment requirements expected to
>   be implemented for the DNS root name service are defined in this
>   document.  Operational requirements are out of scope.
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-iab-2870bis/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-iab-2870bis/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.