Document Shepherd Write-Up for draft-wu-l3sm-rfc8049bis-03
> (1) What type of RFC is being requested
Publication is requested as a Proposed Standard
This is an implementable YANG model where interoperability is required.
The type of RFC is correctly indicated on the title page.
> (2) The IESG approval announcement includes a Document Announcement Write-Up.
>
> Technical Summary
This document defines a YANG data model that can be used for
communication between customers and network operators and to deliver
a Layer 3 provider-provisioned VPN service. This document is limited
to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This
model is intended to be instantiated at the management system to
deliver the overall service. It is not a configuration model to be
used directly on network elements. This model provides an abstracted
view of the Layer 3 IP VPN service configuration components. It will
be up to the management system to take this model as input and use
specific configuration models to configure the different network
elements to deliver the service. How the configuration of network
elements is done is out of scope for this document.
If approved, this document obsoletes RFC 8049. The changes are a
series of small fixes to the YANG module, and some clarifications to
the text.
> Working Group Summary
RFC 8049 was the product of the L3SM working group, but that WG has been
closed. No other WG covers this topic. However, the L3SM list remains open:
changes and revisions were publicised and discussed there. Although some of
the discussion involved firmly stated opinions, there was nothing approaching
controversy. Consensus should be checked through the normal IETF last call
process.
> Document Quality
Implementation work on RFC 8049 gave rise to this revision.
The shepherd knows of two independent efforts to implement.
Reviews by David Ball and Jan Lindblad have been particularly thorough.
A YANG Doctor review of the latest revision has NOT been performed at the
time of publication request,
but Jan Lindblad is a YANG Doctor and his review of RFC 8049 was
contributory to this work.
> Personnel
Adrian Farrel <adrian@olddog.co.uk> is the Document Shepherd
Benoit Claise <bclaise@cisco.com> is the Responsible Area Director
> (3) Briefly describe the review of this document that was performed by the
Document Shepherd.
I worked with the editor to prepare the -00 revision from the RFC.
I performed a thorough review as shepherd at revision -02 resulting in a
number of small points that have been fixed in -03. This revision is ready
for publication.
> (4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?
The team working on this draft is small, and there have only been three other
people who have performed reviews. That said, the document is substantially
built upon RFC 8049 that did receive wider review. A further YANG Doctor
review would be wise.
> (5) Do portions of the document need review from a particular or from broader
perspective?
A further YANG Doctor review would be wise.
> (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?
None.
> (7) Has each author confirmed that any and all appropriate IPR disclosures?
Yes, all authors have so confirmed.
> (8) Has an IPR disclosure been filed that references this document?
No.
No IPR was disclosed against RFC 8049.
> (9) How solid is the consensus of the interested community behind this
document?
The interested community is very small.
The consensus on the bulk of the document is good.
Some small points have rough consensus, but no hostle action is reported.
> (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.
idnits warns about the following things:
- section numbers that look like IPv4 addresses
- intentional spacing in YANG tree
- 132 lines too long
Only the last of these needs to be fixed and can be picked up in a late-stage
edit. The problems come from the difficulty of expressing the YANG tree and
YANG examples in 68 characters. The authors would like to work with the RFC
Editor to find a good way to address this problem.
> (12) Describe how the document meets any required formal review criteria.
None.
> (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?
No.
> (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?
> Are those RFCs listed on the title page header, listed in the abstract,
and discussed in the introduction?
Yes. This document obsoletes RFC 8049.
This is shown in the document header.
This is stated in the Abstract.
This is stated in the Introduction.
Section 1.4 summarises the changes from RFC 8049.
Section 1.4 is listed in the ToC.
> (17) Describe the Document Shepherd's review of the IANA considerations
section.
The IANA section is adequate and requests existing registry entries for 8049
to be update to point to this document when it becomes an RFC.
> (18) List any new IANA registries that require Expert Review for future
allocations.
None.
> (19) Describe reviews and automated checks performed by to validate sections
of the document written in a formal language.
YANG compilation checks have been performed.