A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
draft-ietf-lime-yang-connectionless-oam-methods-13

Received changes through RFC Editor sync (created alias RFC 8533, changed title to 'A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications', changed abstract to 'This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols.  It provides technology-independent RPC operations for OAM protocols that use connectionless communication.  The retrieval methods model herein presented can be extended to include technology- specific details.  There are two key benefits of this approach: First, it leads to uniformity between OAM protocols.  Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface).', changed pages to 41, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-04-16, changed IESG state to RFC Published)

[Ballot comment]
After a useful conversation with Benoit, I better understand how the status-code and sub-status-code
are intended to be used.  While I do still have some concerns about the clarity and ease of using this,
I do not think it is Discuss-worthy, so I have moved these to be Comments.

a)  It would be helpful to clarify that and how additional OAM YANG modules
are expected to use the status-code identityref and sub-status-code identityref
so that there is a clear indication of how OAM modules are expected to interact
and be build to interact.

b) To handle the cases where OAM mechanisms might be triggered by the RPCs but that
OAM mechanism may not have an associated YANG module, it would be useful to be able
to send back the numeric codes (whether status-code or sub-status-code).  Maybe that's a
generic module of status codes - but this could help with dependencies.

These two points get to what I was concerned/confused by in (1) below.

1) on p. 19: "        leaf status-code {
          type identityref{
            base status-code;
          }
          mandatory true;
          description
          "Error code for continuity-check message, that is
            relevant to the protocol under use for CC.
            For example if ICMP is the protocol under use, the
            error codes are as defined in [RFC4443].";
        }"
I am quite unclear on how this could technically be used??  RFC4443 defines integer error codes or types and
sub-codes that are also integers.
Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs???
Clarification in at least the description is needed, since I don't see how it could be used as currently defined.

=======================================

1) On p.6 : "leaf protocol-id-meta-data {
            type uint64;
            description
              "An optional meta-data related to the protocol ID.
                For e.g., this could be the Internet Protocol number
                for standard Internet Protocols for help in protocol
                processing.";
          }"
Seems very useful - but how and where would a tool be able to learn the expected contents and parsing of the
protocol-id-meta-data?  I do not see any indication in the module on p.16 where the protocol-ids are defined -
not even in the descriptions much less programmatically.

2) The complete data hierarchy in Sec 3.2 is confusing in a couple ways.  First, it isn't clear what is going to be
defined in this document and what is from draft-ietf-lime-yang-connectionless-oam-14.  Second, the groupings
are all expanded - which makes it very hard to see the logical structure & requires sanity-checking that the same
information appears.

[Ballot discuss]
1) on p. 19: "        leaf status-code {
          type identityref{
            base status-code;
          }
          mandatory true;
          description
          "Error code for continuity-check message, that is
            relevant to the protocol under use for CC.
            For example if ICMP is the protocol under use, the
            error codes are as defined in [RFC4443].";
        }"
I am quite unclear on how this could technically be used??  RFC4443 defines integer error codes or types and
sub-codes that are also integers.
Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs???
Clarification in at least the description is needed, since I don't see how it could be used as currently defined.

[Ballot comment]
1) On p.6 : "leaf protocol-id-meta-data {
            type uint64;
            description
              "An optional meta-data related to the protocol ID.
                For e.g., this could be the Internet Protocol number
                for standard Internet Protocols for help in protocol
                processing.";
          }"
Seems very useful - but how and where would a tool be able to learn the expected contents and parsing of the
protocol-id-meta-data?  I do not see any indication in the module on p.16 where the protocol-ids are defined -
not even in the descriptions much less programmatically.

2) The complete data hierarchy in Sec 3.2 is confusing in a couple ways.  First, it isn't clear what is going to be
defined in this document and what is from draft-ietf-lime-yang-connectionless-oam-14.  Second, the groupings
are all expanded - which makes it very hard to see the logical structure & requires sanity-checking that the same
information appears.

[Ballot comment]
There is an outstanding issue stemming from the Gen-ART review concerning whether two-way delay is supported and whether it would be signaled by specifying TWAMP as the protocol-id. This should be resolved before the document gets published.

[Ballot comment]
id-nits reports:

  ** There are 5 instances of too long lines in the document, the longest one
    being 3 characters in excess of 72.

The document uses "id", "Id", and "ID" interchangeably for "identifier." I suggest changing these to "ID" everywhere.

The indenting and spacing in the YANG module appears to be inconsistent. You may want to consider a formatting pass to make it easier to read.

[Ballot comment]
I noted a few nits:

Line 729
    description
      "Propreitary protocol (eg.,IP SLA).";
  }
Typo: proprietary


Line 766
  identity invalid-cc{
  base status-code;
Nit: " {"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-lime-yang-connectionless-oam-methods-10, and we have a question for Benoit.

QUESTION: should the new YANG module be posted in the registry? If so, instructions should be added to the IANA Considerations section.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single new registration is to be made as follows:

ID: yang:ietf-connectionless-oam
URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

The IESG-designated expert has reviewed and approved this request.

Second, in the YANG Module Names registry on the YANG Parameters page located at:

https://www.iana.org/assignments/yang-parameters/

a single new module name is to be registered as follows:

Name: ietf-connectionless-oam-methods
Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods
Prefix: cloam-methods
Module:
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

[Ballot comment]
Thanks for your work on this draft.  In the security considerations, could you please add a clause on network reconnaissance into the text since that could lead to other attack types (compromise, etc.).

OLD:

These are the
  operations and their sensitivity/vulnerability:

  o  continuity-check: Generates continuity check.

  o  path-discovery: Generates path discovery.

  which may lead to Denial-of-Service attack on both the local device
  and the network or unauthorized source access to some sensitive
  information.

NEW:
These are the
  operations and their sensitivity/vulnerability:

  o  continuity-check: Generates continuity check.

  o  path-discovery: Generates path discovery.

  which may be used for network reconnaissance or lead to Denial-of-Service attack on both the local device
  and the network or unauthorized source access to some sensitive
  information.

The following Last Call announcement was sent out (ends 2017-10-25):

From: The IESG
To: IETF-Announce
CC: Ron Bonica , cpignata@cisco.com, lime-chairs@ietf.org, Carlos Pignataro , draft-ietf-lime-yang-connectionless-oam-methods@ietf.org, bclaise@cisco.com, lime@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard


The IESG has received a request from the Layer Independent OAM Management in
the Multi-Layer Environment WG (lime) to consider the following document: -
'Retrieval Methods YANG Data Model for Connectionless Operations,
  Administration, and Maintenance(OAM) protocols'
  as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides technology-independent RPC
  operations for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details.  This is leading to uniformity between OAM protocols and
  support both nested OAM workflows (i.e., performing OAM functions at
  different levels through a unified interface) and interacting OAM
  workflows ( i.e., performing OAM functions at same levels through a
  unified interface).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides a technology-independent
  RPC commands for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (adjunct document)
  and the retrieval methods (this document).

Document Quality

  There are plans of and implementations of this protocol.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro is the Document Shepherd
  Benoit Claise is the Responsible Area  Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  This version of the document is ready to be sent to the responsible AD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns regarding both breath and depth of reviews.

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

  YANG, with review taken place by YANG Doctors (Carl Moberg)

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

  None.

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

  Yes, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  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? 

  WG Agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No threat of appeal.

  One working group participant has expressed discontent several
  times. In particular, this participant has expressed concern that
  his comments have not been addressed and also that he has
  not been given enough time to review. Part of that discussion can
  be seen at:
  https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4
  -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk
    -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI
      -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c
      -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I
  -> https://mailarchive.ietf.org/arch/msg/lime/l9Ym6lj7twTqqB0wz_EyHam_9P8

  The WG held 4 "Editathon" interims in which we went comment-by-comment
  hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime

  Further, both LIME WG Chairs believe there's been ample opportunity
  to share review and comments in multiple occasions, and that
  the document editors have responded timely and incorporated
  comments. In fact, multiple deadlines were given to this participant.
  Many of these deadlines were not respected, yet the WG and document
  editors waited and incorporated late comments just to get another
  deadline. This caused delay and broke the WG flow.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  YANG Doctor

(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? If such normative
references exist, what is the plan for their completion?

  Yes, to active I-Ds.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(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? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  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. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

  All looks good.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  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, etc.

  YANG Doctors Review.
  YANG Validator.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides a technology-independent
  RPC commands for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (adjunct document)
  and the retrieval methods (this document).

Document Quality

  There are plans of and implementations of this protocol.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro is the Document Shepherd
  Benoit Claise is the Responsible Area  Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  This version of the document is ready to be sent to the responsible AD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns regarding both breath and depth of reviews.

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

  YANG, with review taken place by YANG Doctors (Carl Moberg)

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

  None.

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

  Yes, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  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? 

  WG Agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No threat of appeal.

  One working group participant has expressed discontent several
  times. In particular, this participant has expressed concern that
  his comments have not been addressed and also that he has
  not been given enough time to review. Part of that discussion can
  be seen at:
  https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4
  -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk
    -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI
      -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c
      -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I
  -> https://mailarchive.ietf.org/arch/msg/lime/l9Ym6lj7twTqqB0wz_EyHam_9P8

  The WG held 4 "Editathon" interims in which we went comment-by-comment
  hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime

  Further, both LIME WG Chairs believe there's been ample opportunity
  to share review and comments in multiple occasions, and that
  the document editors have responded timely and incorporated
  comments.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  YANG Doctor

(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? If such normative
references exist, what is the plan for their completion?

  Yes, to active I-Ds.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(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? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  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. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

  All looks good.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  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, etc.

  YANG Doctors Review.
  YANG Validator.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides a technology-independent
  RPC commands for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (adjunct document)
  and the retrieval methods (this document).

Document Quality

  There are plans of and implementations of this protocol.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro is the Document Shepherd
  Benoit Claise is the Responsible Area  Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  This version of the document is ready to be sent to the responsible AD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns regarding both breath and depth of reviews.

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

  YANG, with review taken place by YANG Doctors (Carl Moberg)

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

  None.

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

  Yes, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  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? 

  WG Agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No threat of appeal.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  YANG Doctpr

(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? If such normative
references exist, what is the plan for their completion?

  Yes, to active I-Ds.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(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? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  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. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. 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 5226).

  All looks good.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  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, etc.

  YANG Doctors Review.
  YANG Validator.