Shepherd write-up for draft-ietf-pce-stateful-pce-lsp-scheduling-12
Document shepherd: Adrian Farrel <adrian@olddog.co.uk>
(1) What type of RFC is being requested
Publication is requested as a Proposed Standard.
This document includes the specification of protocol elements and
extensions to an existing standards track protocol. This makes Proposed
Standard appropriate.
The RFC type is indicated in the document header.
(2) Please provide such a Document Announcement Write-Up.
Technical Summary:
This document defines a set of extensions needed to the stateful Path
Computation Element (PCE) communication Protocol (PCEP), so as to
enable Labeled Switched Path (LSP) scheduling for path computation
and LSP setup/deletion based on the actual network resource usage and
the duration of a traffic service in a centralized network
environment as stated in RFC 8413.
Working Group Summary:
The working group process took 2.5 years and 12 revisions. This was
based on the previous 2 years and 5 revisions as an individual I-D.
The process has not contained anything noteworthy.
Document Quality:
This document contains an implementation status section per RFC 7942
and according to PCE WG policy. The section indicates suggested plans
for implementation by two vendors. The document shepherd is aware of
additional plans to implement in a private research implementation of
PCEP.
The document has not received any expert reviews.
Personnel:
Document shepherd: Adrian Farrel <adrian@olddog.co.uk>
Responsible Area Director: Deborah Brungard <db3546@att.com>
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
I have reviewed this document several times as a WG particpant, when I
was WG co-chair, and during WG last call. It was of particular interest
to me as co-editor of RFC 8413.
I also did a shepherd review after WG last call leading to a few fixes,
and an additional issue raised while composing this write-up led to
another revision.
The authors have addressed all of my comments, and I consider the
document ready for publication.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
I would, of course, have preferred to see a review from an implementer,
but as the author team and large contributor team include many people
familiar with PCEP and several of those who would be called upon to
implement, I think any concern is mitigated.
(5) Do portions of the document need review from a particular or from
broader perspective.
None 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?
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.
In addition to the declaration in the boilerplate of the document, each
author and contributor has made an explicit declaration at
https://mailarchive.ietf.org/arch/msg/pce/MW9cjP8T5DC1gNkQgsRfaJ14O5U
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
The datatrcker shows three IPR disclosures.
https://datatracker.ietf.org/ipr/3044/https://datatracker.ietf.org/ipr/3682/https://datatracker.ietf.org/ipr/3683/
The first of these was disclosed early in the process. The other two
were disclosed just before working group last call.
All were announced on the working group mailing list and attracted no
comments.
(9) How solid is the WG consensus behind this document?
The consensus is reasonable. It is a moderately small working group with
a total of 12 people involved in the document as authors or contributors
meaning that the number of additional reviewers available was not large.
Nevertheless, the working group last call attracted the following
comments from non-contributor/authors:
- I have read it and support it
- I'm an operator and consider this gives an operator flexiblity
- Support
- I have read this draft and consider it ready for publication
- I support publication
- Support publication
- Support publication
- I read the draft and strongly support its publication. I see such
requirement in real networks too
There were no negative comments or requests for further edits.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
None.
(11) Identify any ID nits the Document Shepherd has found in this
document.
idnits is clean except for the general progress of references that can
be cleaned up later.
(12) Describe how the document meets any required formal review
criteria.
No formal review is applicable.
(13) Have all references within this document been identified as either
normative or informative?
Yes, see sections 12.1 and 12.2
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
No.
(15) Are there downward normative references references (see RFC 3967)?
No downrefs in this document.
(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.
I have read and re-read the IANA section and cross-checked it against
the existing registries, RFC 8126, and the body of the document.
Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries.
Confirmed.
Confirm that any referenced IANA registries have been clearly
identified.
Confirmed
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
8126).
Confirmed.
(18) List any new IANA registries that require Expert Review for future
allocations.
None.
(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, YANG
modules, etc.
None appropriate.
(20) If the document contains a YANG module.
No YANG