The PCE working group request publication of
draft-ietf-pce-stateful-pce-auto-bandwidth as an IETF Stream RFC.
> (1) What type of RFC is being requested?
Publication is requested as a Proposed Standard.
The document title page indicates "Standards Track" as is conventional for
Proposed Standard. This is the appropriate classification for this document
because it includes protocol extensions to a previous IETF Proposed Standard.
> (2) The IESG approval announcement includes a Document Announcement Write-Up.
>
> Technical Summary
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multi-Protocol
Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
LSPs) using PCEP.
The automatic bandwidth feature allows automatic and dynamic
adjustment of the TE LSP bandwidth reservation based on the volume of
traffic flowing through the LSP. This document describes PCEP
extensions for automatic bandwidth adjustment when employing an
Active Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs.
> Working Group Summary
There was nothing unusual in the working group processing of this document.
Before the document was adopted there were concerns regarding scaling and scope
of the work. The version of this I-D that was adopted handled these and had
broad support from the WG at the time of adoption and later during WGLC. There
is consensus in the WG to publish this work.
> Document Quality
The authors report "a few" implementations supporting this feature. Some, they
say, are more complete than others.
A few people in the working group performed substantial reviews, but most of
the working group was quiet. During working group last call a good number of
people reported that they had read the document and supported publication.
> Personnel
Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd.
Deborah Brungard 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.
I conducted a late review when I took over as document shepherd and the authors
fixed a number of nits for me. In my opinion, the document is ready for
pubication.
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
No.
> (5) Do portions of the document need review from a particular or from
> broader perspective?
No special reviews are needed, but the usual Directorate reviews will be
welcome if they come.
> (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 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.
All authors and contributors made an explicit declaration to the working grop
list.
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
There is an IPR disclosure at https://datatracker.ietf.org/ipr/2996/
This was announced to the working group on 2019-05-04
One WG participant raised a concern that the IPR was very old and had been
disclosed very late. The author who worked for the IPR-owning company answered
that he had disclosed as soon as he became aware of the IPR. The concerned
participant accepted this answer.
> (9) How solid is the WG consensus behind this document?
The document triggered various discussions and it has been carefully reviewed
by a few interested individuals. Overall it can be considered as a consensus of
the WG as a whole.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?
No.
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.
idnits runs clean.
> (12) Describe how the document meets any required formal review
> criteria.
No such criteria.
The document uses RBNF (RFC 5511) to describe a PCEP message, but it adopts
that unchanged from RFC 8281, so no special care is needed. A reference to RFC
5511 might usefully be added.
> (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?
None.
>(15) Are there downward normative references references (see RFC 3967)?
None.
> (16) Will publication of this document change the status of any
> existing RFCs?
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).
The IANA Considerations section is substantial, but well written and consistent
with the existing registries. All the necessary informaiton has been provided.
> (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.
Not Applicable.
> (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.
Not Applicable.