Document shepherd write-up
The PCE Working Group requests the publication of draft-ietf-pce-stateful-hpce as an IETF Stream RFC.
> (1) What type of RFC is being requested? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Publication as an Informational RFC is requested.
This is appropriate because the document is an applicability statement that does not define any protocol elements. This status is indicated in the header on the title page.
> (2) Please provide a Document Announcement Write-Up.
> Technical Summary:
A Stateful Path Computation Element (PCE) maintains information on the current network state including existing Traffic Engineered (TE) Label Switched Path (LSPs). This information may be considered when computing path for new TE LSPs.
The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of inter-connected domains to be selected for a multi-domain TE LSP.
This document describes general considerations and use cases for the deployment of Stateful PCEs using the Hierarchical PCE architecture.
> Working Group Summary:
The working group process was "steady." The document was adopted two years ago and has progressed slowly with small updates and direction from the WG mainly off-list.
As an applicability statement, the WG supported the idea of the work (the adoption poll attracted support from ten non-authors), but didn't seem to put in much effort to advance the work, preferring to watch the authors write the text.
WG last call had several constructive comments of support that included reasoning, and also a couple of helpful reviews.
But there were no issues with consensus.
> Document Quality:
There are several research implementations of stateful hierarchical PCEs confessed to separately by two network operators, an equipment vendor, and a few universities. As such, this document provides a base reference for how to put the concepts together in a meaningful way.
No special reviewing was necessary.
Adrian Farrel (email@example.com) is the Document Shepherd
Deborah Brungard (firstname.lastname@example.org) is the Responsible Area Director
> (3) Briefly describe the review of this document that was performed by the Document Shepherd.
I reviewed this document at revision -06 coincident with WG last call. I had a large number of comments that were a mixture of editorial and clarification, and the authors have addressed these over the last three revisions.
The document could still be better-written, but I think energy to polish it has run out.
There are currently six author names on the front page, and I am working with the authors to agree that this number will be reduced to five or fewer during the IETF last call review period.
> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No. The relevant specialists in this topic are either authors or have reviewed the document.
> (5) Do portions of the document need review from a particular or from broader perspective.
> (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?
No such concerns.
> (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.
A specific poll was sent to all authors and contributors and answered on the working group mailing list.
This serves in addition to the boilerplate text.
> (8) Has an IPR disclosure been filed that references this document?
No IPR has been disclosed.
> (9) How solid is the WG consensus behind this document?
The consensus is reasonable. There is no dissent, and a small number (in addition to the authors) expressed strong support. It is a relatively small working group, and so this represents a passable level of support.
> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
No threats, no discontent.
> (11) Identify any ID nits the Document Shepherd has found in this document.
idnits runs clean
> (12) Describe how the document meets any required formal review criteria
No such criteria
> (13) Have all references within this document been identified as either normative or informative?
> (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?
All normative references are in-force published RFCs.
> (15) Are there downward normative references (see RFC 3967)?
> (16) Will publication of this document change the status of any existing RFCs?
> (17) Describe the Document Shepherd's review of the IANA considerations section.
No IANA action is requested.
A suitable null IANA Considerations section is present.
> (18) List any new IANA registries that require Expert Review for future allocations.
> (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language.
No such language, no such checks.