Re: [mif] Shepherd on draft-ietf-mif-dns-server-selection-08

Margaret Wasserman <mrw@lilacglade.org> Fri, 20 April 2012 13:29 UTC

Return-Path: <mrw@lilacglade.org>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF9621F86DD for <mif@ietfa.amsl.com>; Fri, 20 Apr 2012 06:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.965
X-Spam-Level:
X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7hW2ZFhqcrc for <mif@ietfa.amsl.com>; Fri, 20 Apr 2012 06:29:15 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13021F86DB for <mif@ietf.org>; Fri, 20 Apr 2012 06:29:15 -0700 (PDT)
Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 2578A20244; Fri, 20 Apr 2012 09:24:53 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-114-139067973
From: Margaret Wasserman <mrw@lilacglade.org>
In-Reply-To: <CANF0JMDzAnAvY4Ozdc6pNJZy7ApD3PDmo0YvQQo3vyV041SMVQ@mail.gmail.com>
Date: Fri, 20 Apr 2012 09:29:13 -0400
Message-Id: <31B088F1-9F92-4602-B8EE-EBA91FF3F0CF@lilacglade.org>
References: <CANF0JMDzAnAvY4Ozdc6pNJZy7ApD3PDmo0YvQQo3vyV041SMVQ@mail.gmail.com>
To: Hui Deng <denghui02@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: MIF Mailing List <mif@ietf.org>
Subject: Re: [mif] Shepherd on draft-ietf-mif-dns-server-selection-08
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 13:29:17 -0000

Your write-up looks good to me, Hui.  Thank you for doing it!

Margaret

On Apr 20, 2012, at 9:21 AM, Hui Deng wrote:

> Hello all
> 
> Belo are document writeup for draft-ietf-mif-dns-server-selection-08
> Chair will submit if there is no any issue on this.
>  
> thanks
>  
> -co-chairs
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?  Why
> is this the proper type of RFC?  Is this type of RFC indicated in the
> title page header?
> 
> ==> Proposed Standard, this document is a normaltive work and request IANA 
> to assign two new option codes, in the title page header states "Standards Track"
> 
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
> 
> Technical Summary
> 
> ==>A multi-interfaced node is connected to multiple networks, some of
>    which may be utilizing private DNS namespaces.  A node commonly
>    receives DNS server configuration information from all connected
>    networks.  Some of the DNS servers may have information about
>    namespaces other servers do not have.  When a multi-interfaced node
>    needs to utilize DNS, the node has to choose which of the servers to
>    contact to.  This document describes DHCPv4 and DHCPv6 options that
>    can be used to configure nodes with information required to perform
>    informed DNS server selection decisions.
> 
> Working Group Summary
> 
>   Was there anything in WG process that is worth noting? For 
>   example, was there controversy about particular points or 
>   were there decisions where the consensus was particularly 
>   rough?
> 
> ==> There is no controversy about this document, but There were fears
>     that this document is actually “promoting use of split-brain 
>     DNS”. After discussions the concern was tackled in Section 7 
>     “Considerations for network administrators” with text:
>     ”Private namespaces MUST be globally unique in order to keep DNS
>     unambiguous and henceforth avoiding caching related issues and 
>     destination selection problems (see Section 2.3).”
> 
>     Another major area that caused lots of discussion was security 
>     implications caused by risks related to attacker redirecting some
>     DNS queries to bad places. This is addressed in Section 4.4. 
>     “Limitations on use” and in Section 4.1, especially with help 
>     of DNSSEC.
> 
> Document Quality
> 
>   Are there existing implementations of the protocol? Have a 
>   significant number of vendors indicated their plan to 
>   implement the specification? Are there any reviewers that 
>   merit special mention as having done a thorough review, 
>   e.g., one that resulted in important changes or a 
>   conclusion that the document had no substantive issues? If 
>   there was a MIB Doctor, Media Type or other expert review, 
>   what was its course (briefly)? In the case of a Media Type 
>   review, on what date was the request posted?
> 
> ==> There are two implementations of the protocol, one from
> Nokia, the other from NTT. Microsoft also has Name Resolution
> Policy Table implementation. There are thorough review, but not
> lead to important changes, there is no substntive issues.
> There are no MID and Media type definition which need expert review.
> 
> Personnel
> 
>   
>   Hui Deng is the Document Shepherd, Ralph Drom is the Responsible Area
>   Director
> 
> 
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
> ==》 The document has been discussed in the working group which has won
> the concenuss to move forward this document.
> 
> 
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?  
>  ==> The document has had extensive reviews within the IETF, not just 
>    MIF working group, but also DNSOP, DNSEXT and DHCWG. I do not have
>    any concerns about the depth or breadth of reviews received.
> 
> 
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
>  ==> The document has already got review from DNSEXT,DNSOP and DHCWG, 
>   others are not needed.
> 
> 
> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.
>  ==> There is no concern or issue on this document.
> 
> 
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.
>  ==> There are 3 authors in this document, 
>  Teemu has conformed Nokia's IPR claimed.
>  Ted has conformed he is not aware of any IPR.
>  J. Kato from NTT didn't reply anything on this. Need IESG's advice 
>  on how to handle this.
>  
> 
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
>  ==> Yes, it has an IPR disclosure before it has been adopted as the 
>  working group document, but there isn't one filed in the datatracker.
>  working group feel that the terms in that IPR filing is acceptable.
> https://datatracker.ietf.org/ipr/1103/
> 
> 
> (9) How solid is the WG consensus behind this document? Does it 
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?   
>  ==> WG as a whole understand and agree with it.
>  
> (10) Has anyone threatened an appeal or otherwise indicated extreme 
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.) 
>  ==> No.
>  
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
>  ==> the document has passed the ID nits check, no error and warning.
>  
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>  ==> This document meets the required criteria, and it doesn't define
>  a new MIF, media type, and URL type.
>  
> (13) Have all references within this document been identified as
> either normative or informative?
>  ==> Yes.
>  
> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?
>  ==> No.
>  
> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in the
> Last Call procedure. 
>  ==> No.
>  
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.
>  ==> No.
>  
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
>  ==> Shepherd confirms that the document does request no new registries
>   and pointers to existing registries 
>  
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
>  ==> the document doesn't request new registeries to existing registries
>  
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.
>  ==> Shepherd think the document is well written in the formal language