Document Shepherd Write-up
draft-ietf-pce-applicability-actn-10
The PCE working group requests that draft-ietf-pce-applicability-actn
be published as an Informational RFC in the IETF Stream.
> (1) What type of RFC is being requested?
The request is to publish this document as an Informational RFC.
This is appropriate because it describes how IETF components and
protocols can be used to achieve a specific function, but does not
define any new protocol elements.
The RFC type is clearly indicated on the title page.
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up.
> Technical Summary:
Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network (VN) operations needed to orchestrate, control and
manage large-scale multi-domain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and
end-to-end virtual service aware connectivity and network function
virtualization services.
The Path Computation Element (PCE) is a component, application, or
network node that is capable of computing a network path or route
based on a network graph and applying computational constraints. The
PCE serves requests from Path Computation Clients (PCCs) that
communicate with it over a local API or using the Path Computation
Element Communication Protocol (PCEP).
This document examines the applicability of PCE to the ACTN
framework.
> Working Group Summary:
The WG process has been smooth.
At one stage, this work caught up with (or got ahead of) the core ACTN
and it had to pause. But now RFCs 8453 and 8454 have been published, and
advancing this work is appropriate.
WG consensus was reasonable.
> Document Quality:
This is an Informational document, so implementation is moot. However,
there are known to be implementations (product and research) that use
the ACTN architecture and contain PCE as key component.
> Personnel:
Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (db3546@att.com) is the Responsible Area Director
> Briefly describe the review of this document that was performed by the
> Document Shepherd.
The document shepherd reviewed the work a number of times during its
development. Most recently, the shepherd conducted a review during WG
last call and found the document to be sound (barring a few small issues
that the uthors have since addressed).
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
No such concerns.
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
No broader review is needed. An OpsDir review would be interesting, and
it is expected that one will be commissioned during IETF last call as
normal.
> (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? For example, perhaps he or she
> is uncomfortable with certain parts of the document, or has concerns
> whether there really is a need for it. In any event, if the WG has
> discussed those issues and has indicated that it still wishes to
> advance the document, detail those concerns here.
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. If not, explain why?
This document carries the normal boilerplate concerning IPR and
copyright, and all authors are deemed to have agreed to the terms of
BCP 78 and BCP 79 by allowing their names to be used on the document.
In addition, each author has made a public declaration on the WG mailing
list.
> (8) Has an IPR disclosure been filed that references this document?
No.
> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it?
The concensus is good. In fact, by the standards of WG last calls, the
document is well and widely supported.
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?
No threats or indications.
> (11) Identify any ID nits the Document Shepherd has found in this
> document.
There is one idnits warning of an out-of-date reference. This will be
resolved when the XML is re-processed.
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
No such criteria apply.
> (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 such.
> (15) Are there downward normative references 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.
This document makes no requests for IANA action.
A suitable "null" IANA Considerations section is included.
> (18) List any new IANA registries that require Expert Review for
> future allocations
None such.
> (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.
None required.