[Pce] Please publish draft-ietf-pce-disco-proto-isis-05.txt
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 09 May 2007 09:37 UTC
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlibt-0000F1-27; Wed, 09 May 2007 05:37:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlibr-0000Es-Gj; Wed, 09 May 2007 05:37:23 -0400
Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlibq-0004PB-NM; Wed, 09 May 2007 05:37:23 -0400
Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1Hlibp-0002r1-K1; Wed, 09 May 2007 09:37:21 +0000
Received: from your029b8cecfe ([217.158.132.37] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 May 2007 10:37:19 +0100
Message-ID: <0bc001c7921d$825824b0$61fadf0a@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Ross Callon <rcallon@juniper.net>
Date: Wed, 09 May 2007 10:30:19 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 09 May 2007 09:37:20.0139 (UTC) FILETIME=[A3B1BDB0:01C7921D]
X-Originating-Pythagoras-IP: [88.96.235.142]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c
Cc: pce@ietf.org, WG Milestone Tracker <iesg-secretary@ietf.org>, dward@cisco.com
Subject: [Pce] Please publish draft-ietf-pce-disco-proto-isis-05.txt
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Path Computation Element <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org
Please publish draft-ietf-pce-disco-proto-isis-05.txt as a Standards Track RFC. Please note that this document has a dependency on draft-ietf-pce-disco-proto-ospf-05.txt. The two documents may be progressed in parallel, or the OSPF document may be progressed ahead of this one. Here is the Document Shepherd write-up. >(1.a) Who is the Document Shepherd for this document? Adrian Farrel <adrian@olddog.co.uk> > Has the Document Shepherd personally reviewed this version > of the document and, in particular, does he or she believe > this version is ready for forwarding to the IESG for > publication? Yes >(1.b) Has the document had adequate review both from key WG > members and from key non-WG members? Yes. Cross-review to IS-IS WG held with significant input received. > Does the Document Shepherd have any concerns about the > depth or breadth of the reviews that have been performed? No concerns. >(1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar > with AAA, internationalization or XML? No concerns. >(1.d) Does the Document Shepherd have any specific concerns or > issues 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. No concerns. > Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion > on this issue. None has been filed. >(1.e) 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 agrees. >(1.f) 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 entered into the ID Tracker.) No. >(1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks > are not enough; this check needs to be thorough. Yes. > Has the document met all formal review criteria it needs > to, such as the MIB Doctor, media type and URI type > reviews? Yes. >(1.h) Has the document split its references into normative and > informative? Yes. > 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 strategy for their completion? There is a normative reference to draft-ietf-isis-caps that is in the RFC Editor Queue. As noted above, there is a normative reference to pce-disco-proto-ospf-05.txt. That document is advancing for publication at the same time. > Are there normative references that are downward > references, as described in [RFC3967]? If so, list these > downward references to support the Area Director in the > Last Call procedure for them [RFC3967]. There are downrefs as common for new IS-IS Standards Track documents. Those listed are: [ISO] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990. [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. It is believed that the first of these is commonly referenced as normative without any issue as it is a stable, external document. It is believed that ISIS WG action is under way to promote RFCs 3567 and 3784 to Standards Track. >(1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the > body of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? > If the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. IANA section is correct. IANA allocation is dependent on the registries created for draft-ietf-isis-caps that is in the RFC Editor Queue. Identification of the registries is, therefore, necessarily slightly ambiguous. Note that the IANA registries are, in part, common with pce-disco-proto-ospf-05.txt. That document is advancing for publication at the same time. > If the document describes an Expert Review process has > Shepherd conferred with the Responsible Area Director so > that the IESG can appoint the needed Expert during the IESG > Evaluation? None required. >(1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly > in an automated checker? Not applicable. >(1.k) 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 There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. > Working Group Summary The Working Group had consensus on this document. > Document Quality It is currently unclear whether these protocol extensions have been implemented. Note, however, that the protocol procedures are identical to those in draft-ietf-pce-disco-proto-ospf-05.txt that have been implemented. > Personnel > > Who is the Document Shepherd for this document? Adrian Farrel <adrian@olddog.co.uk> > Who is the Responsible Area Director(s)? Ross Callon, David Ward. > Is an IANA expert needed? No. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce
- [Pce] Please publish draft-ietf-pce-disco-proto-i… Adrian Farrel