9 May 2007 11:30
Please publish draft-ietf-pce-disco-proto-isis-05.txt
Adrian Farrel <adrian <at> olddog.co.uk>
2007-05-09 09:30:19 GMT
2007-05-09 09:30:19 GMT
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 <at> 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 <at> olddog.co.uk> > Who is the Responsible Area Director(s)? Ross Callon, David Ward. > Is an IANA expert needed? No.