Shepherd writeup
rfc8934-27

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
Back