Skip to main content

Shepherd writeup
draft-ietf-pce-stateful-hpce

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.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (db3546@att.com) 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.

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.

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?

They have

> (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)?

No downrefs.

> (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.

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.

None

> (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.
Back