Shepherd writeup
rfc8299-11

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