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
- [mif] Shepherd on draft-ietf-mif-dns-server-selec… Hui Deng
- Re: [mif] Shepherd on draft-ietf-mif-dns-server-s… Margaret Wasserman