YANG Module Tags
draft-ietf-netmod-module-tags-10

[Ballot discuss]
I think this document does introduce new security considerations,
specifically the ability for one user to remove ("mask") tags from being
visible to other users.  A malicious user could interfere with the
operations of other users/entities, especially in the case mentioned in
an example where multiple semi-independent clients use tags to indicate
modules to avoid that may be broken.

[Ballot comment]
Section 2

Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better
than "standard prefix".

Section 2.4

Similarly, "future registration" or "future use" seem to be better fits
for the intended sentiment.

Section 3.2

I may be misreading, but this seems to be encouraging implementations to
add new ietf:-prefixed tags that are not necessarily registered or
specified in IETF-consensus documents.

Section 7.2

  This registry allocates prefixes that have the standard prefix
  "ietf:".  [...]

The registry name just talks about "tags"; are we really allocating
*prefix*es?

[Ballot discuss]
This is generally a fine document, but after checking RFC 7950 syntax for strings I question why you think you need non ASCII tags. There are so many problems that can arise from that. For example, how would IANA be able to enforce uniqueness of Unicode tags written in different Unicode canonicalisation forms?

[Ballot comment]
(1) Along the same lines of Alissa's DISCUSS, which I support. 

§6.1: "For standardized modules new tags MUST be assigned in the IANA registry defined below, see Section 7.2."  What is a "standardized module"?  It sounds like a Standards Track document, but (as Alissa pointed out) the registration policy is only IETF Review. 

(2) §7.1: "All YANG module tags SHOULD begin with one of the prefixes in this registry."  That statement along with the text in §2.4:

  Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is
  reserved for future standardization.  These tag values are not
  invalid, but simply reserved in the context of standardization.

...seem to indicate that a tag with any format can be used.  Is that true?  Is that the intent?  If so, then it seems to me that vendor/user tags could simply forgo the standardized prefix.  I guess this is ok...it just makes me wonder about the need to even define those prefixes.

(3) I'm not sure what, but I think it may be wise to give the would-be DEs for the new registry in §7.1 some more guidance on the allocation of new prefixes.  The only current guidance is this: "Prefix entries in this registry should be short strings consisting of lowercase ASCII alpha-numeric characters and a final ":" character."

[Ballot comment]
(1) Along the same lines of Alissa's DISCUSS, which I support. 

§6.1: "For standardized modules new tags MUST be assigned in the IANA registry defined below, see Section 7.2."  What is a "standardized module"?  It sounds like a Standards Track document, but (as Alissa pointed out) the registration policy is only IETF Review. 

(2) §7.1: "All YANG module tags SHOULD begin with one of the prefixes in this registry."  That statement along with the text in §2.4:

  Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is
  reserved for future standardization.  These tag values are not
  invalid, but simply reserved in the context of standardization.

...seems to indicate that a tag with any format can be used.  Is that true?  Is that the intent?  If so, then it seems to me that vendor/user tags could simply forgo the standardized prefix.  I guess this is ok...it just makes me wonder about the need to even define those prefixes.

(3) I'm not sure what, but I think it may be wise to give the would-be DEs for the new registry in §7.1 some more guidance on the allocation of new prefixes.  The only current guidance is this: "Prefix entries in this registry should be short strings consisting of lowercase ASCII alpha-numeric characters and a final ":" character."

[Ballot discuss]
This is a minor thing, but people get really confused about it so I'd like to discuss it. This document allows for minting new "IETF Standard" tags by publishing documents that are not standards of any kind. That is, because the registry specified in 7.2 has its allocation policy as IETF Review, that means that informational documents can be used to register new "IETF Standard" tags. This seems ripe for creating further confusion about what is and is not an IETF "standard." Could these tags simply be called "IETF tags"?

[Ballot comment]
I strongly encourage you to follow the advice of the Gen-ART reviewer and include a contact or change controller field in the registry defined in 7.1. For a registry where you expect other SDOs to be making registrations, this field can be critical if the registry entries need to be updated years after they are created. See RFC 8126 Section 9.5.

Adam noted that RFC 8199 is now a downref, based on changes made in the -07, after IETF last call. I think this is fine and does not require another last call.

[Ballot discuss]
This is a "discuss discuss" that I plan to clear once the IESG has considered
the topic during tomorrow's telechat.

This document has a normative reference to RFC 8199, which is informational.
This downref was not mentioned in the IETF Last Call announcement
, and RFC 8199 doesn't
yet appear in the downref registry .

Per RFC 8067, this doesn't require running another IETF last call; however, as
it wasn't part of the IETF last call discussion, the IESG is required to
evaluate whether the downref is appropriate.

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

The IANA Functions Operator has completed its review of draft-ietf-netmod-module-tags-05. If any part of this review is inaccurate, please let us know.

We have questions about the two actions requested in this document.

IANA Questions --> In sections 8.1 and 8.2 of the current draft references RFC 5226. RFC 5226 has been obsoleted by RFC 8126. Could those references be changed to reflect current guidance for IANA Considerations sections?

Section 8.1 assigns the Specification Required registration policy to a new registry. Would it be appropriate for this or another section to give experts guidance on how to evaluate new proposals for registration (see sections 4.6 and 5.3 of RFC 8126)?

Finally, where should these two new registries be located? Should they be added to an existing registry page? If not, do they belong in an existing category at http://www.iana.org/protocols?

IANA understand that upon creation of this document, there will be two actions to complete.

First, a new registry called YANG Module Tag Prefixes will be created. The location of the new registry needs to be specified by the authors of the current draft. The allocation policy for the new registry is Specification Required, as defined by RFC 8126. The initial values follow:

    prefix    description
    --------  ---------------------------------------------------
    ietf:    IETF Standard Tag allocated in the IANA YANG Module
              IETF Tag Registry.
    vendor:  Non-standardized tags allocated by the module implementer.
    user:    Non-standardized tags allocated by and for the user.

Second, a new registry called YANG Module IETF Tags will be created. The location of the new registry needs to be specified by the authors of the current draft. The allocation policy for the new registry is IETF Review, as defined by RFC 8126. The initial values follow:

  +----------------------------+--------------------------+-----------+
  |            Tag            |      Description        | Reference |
  +----------------------------+--------------------------+-----------+
  | ietf:network-element-class |  A module for a network  | [RFC8199] |
  |                            |        element.        |          |
  |                            |                          |          |
  | ietf:network-service-class |  A module for a network  | [RFC8199] |
  |                            |        service.        |          |
  |                            |                          |          |
  |  ietf:sdo-defined-class  |  A module defined by a  | [RFC8199] |
  |                            | standards organization.  |          |
  |                            |                          |          |
  | ietf:vendor-defined-class  |  A module defined by a  | [RFC8199] |
  |                            |        vendor.          |          |
  |                            |                          |          |
  |  ietf:user-defined-class  | A module defined by the  | [RFC8199] |
  |                            |          user.          |          |
  |                            |                          |          |
  |      ietf:hardware        |  A module relating to  |  [This  |
  |                            |    hardware (e.g.,      | document] |
  |                            |      inventory).        |          |
  |                            |                          |          |
  |      ietf:software        |  A module relating to  |  [This  |
  |                            |    software (e.g.,      | document] |
  |                            |      installed OS).      |          |
  |                            |                          |          |
  |          ietf:qos          |  A module for managing  |  [This  |
  |                            |  quality of service.    | document] |
  |                            |                          |          |
  |      ietf:protocol        | A module representing a  |  [This  |
  |                            |        protocol.        | document] |
  |                            |                          |          |
  |  ietf:system-management  |  A module relating to  |  [This  |
  |                            | system management (e.g., | document] |
  |                            |  a system management    |          |
  |                            | protocol such as syslog, |          |
  |                            |  TACAC+, SNMP, netconf,  |          |
  |                            |          ...).          |          |
  |                            |                          |          |
  |    ietf:network-service    |  A module relating to  |  [This  |
  |                            | network service (e.g., a | document] |
  |                            | network service protocol |          |
  |                            |  such as an NTP server,  |          |
  |                            | DNS server, DHCP server, |          |
  |                            |          etc).          |          |
  |                            |                          |          |
  |          ietf:oam          |  A module representing  |  [This  |
  |                            |      Operations,        | document] |
  |                            |  Administration, and    |          |
  |                            | Maintenance (e.g., BFD). |          |
  |                            |                          |          |
  |        ietf:routing        |  A module related to    |  [This  |
  |                            |        routing.        | document] |
  |                            |                          |          |
  |      ietf:signaling      |  A module representing  |  [This  |
  |                            | control plane signaling. | document] |
  |                            |                          |          |
  |          ietf:lmp          | A module representing a  |  [This  |
  |                            |    link management      | document] |
  |                            |        protocol.        |          |
  +----------------------------+--------------------------+-----------+


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 meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-03-03):

From: The IESG
To: IETF-Announce
CC: ibagdona@gmail.com, netmod-chairs@ietf.org, draft-ietf-netmod-module-tags@ietf.org, netmod@ietf.org, joelja@gmail.com, Joel Jaeggli
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Module Tags) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG Module Tags'
  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 2019-03-03. 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 provides for the association of tags with YANG modules.
  The expectation is for such tags to be used to help classify and
  organize modules.  A method for defining, reading and writing a
  modules tags is provided.  Tags may be standardized and assigned
  during module definition; assigned by implementations; or dynamically
  defined and set by users.  This document provides guidance to future
  model writers and, as such, this document updates [RFC8407].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ballot/


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

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

The draft-ietf-netmod-module-tags-05 is requesting Standards Track status.

(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 provides for the association of tags with YANG modules.
  The expectation is for such tags to be used to help classify and
  organize modules.  A method for defining, reading and writing a
  modules tags is provided.  Tags may be standardized and assigned
  during module definition; assigned by implementations; or dynamically
  defined and set by users.  This document provides guidance to future
  model writers and, as such, this document updates RFC 8407.


Working Group Summary

The working group had significant questions on how module tags might be
used. Section 1.1 of draft 05 dwells on how and why tags are applied,
addressing significant points in this discussion from the vantage-point
of working-group participants.

Document Quality

The document has received signficant review, including vigorous working-
group debate that resulted in draft-03/04. Yang-doctors review of the WG
consensus draft-04 was completed.

Personnel

Joel Jaeggli is the document shepherd Ignas Bogdonas 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 has been reviewed by the document shepherd. As WG co-chair
I have been shepherding this document through the working group process
up to this point as well. I believe that it is ready for IETF last call IESG review
and publications.

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

No specific concerns are present at this time. The working-group last call
process for this draft was iterative, consensus has gradually become less
rough.

(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 module tags are a facility which is potentially employed by all
consumers of yang modules. While netmod is central to protocol
maintenance and more or less all yang implementors are represented
there consumers (operators) of the technology present at the IETF may
have limited exposure prior to IETF last call. IETF LC is therefore
important for the review process.

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

The document shepherd has not specific concerns with the document.

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


Chairs have requested positive confirmation of IPR status per NETMOD
operating procedure and have concluded that there are no acknowledged
IPR claims on the document.


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

No such IPR has been files.

(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 consensus was arrived at as a result of vigorous debate, was
revisited at 103 and subsequently confirmed on the mailing list.

https://mailarchive.ietf.org/arch/msg/netmod/UsuQJY9uscKGa35Bgy8LwvhRDyY

(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 appeals are anticipated.

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

Notable nits:

Appearance of the lack of security considerations

As with rfc 8047. there are no meaningful security implications to
imposing a structure on the documentation system for yang modules.

As with rfc 8407

  "This document defines documentation guidelines for NETCONF or
  RESTCONF content defined with the YANG data modeling language;
  therefore, it does not introduce any new or increased security risks
  into the management system."

Updates line needs to be changed from RFC8407 to 8407. This nit
accumulated since the draft referenced has exited the RFC editor queue.
the meaning  is unambiguous.

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

Draft-04 was been submitted for yang doctors review.

(13) Have all references within this document been identified as
either normative or informative?

All references are normatively or informatively referenced.

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

No references are in this state since the publication of RFC 8407.

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

RFC 8199 and 8407 are downward references to informational documents.
They describe variously consistent terminology for the classification of yang
modules and Guidelines for yang module authors. It is the belief of the shepherd
that these two downward references should be noted in the IETF last call but
are otherwise not exceptional.

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

This document proposes to update RFC 8407 as noted in section 7.1 by creating
a standard tag.

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

The document proposes in Section 8 to create:

A module tag prefix registry consisting of at present  three types of module
tags.

A IETF module tag registry with a pre-populated list of module tags.

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

Additions to the module tag prefix registry are specification required.

Additions to the IETF tag registry require IETF consensus.

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

No automated checks are required. Appendix A contains a fictional example result of a query from a module tag registry. It has been sanity checked and has been updated due to comments in the yang doctors review.

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

The draft-ietf-netmod-module-tags-04 is requesting Standards Track status.

(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 provides for the association of tags with YANG modules.
  The expectation is for such tags to be used to help classify and
  organize modules.  A method for defining, reading and writing a
  modules tags is provided.  Tags may be standardized and assigned
  during module definition; assigned by implementations; or dynamically
  defined and set by users.  This document provides guidance to future
  model writers and, as such, this document updates [RFC8407].


Working Group Summary

The working group had significant questions on how module tags might be
used. Section 1.1 of draft 04 dwells on how and why tags are applied,
addressing significant points in this discussion from the vantage-point
of working-group participants.

Document Quality

The document has received signficant review, including vigorous working-
group debate that resulted in draft-03/04. Yang-doctors review of the WG
consensus draft-04 is pending.

Personnel

Joel Jaeggli is the document shepherd Ignas Bogdonas 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 has been reviewed by the document shepherd. As WG co-chair
I have been shepherding this document through the working group process
up to this point as well. I believe that it is ready for IETF last call IESG review
and publications.

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

No specific concerns are present at this time. The working-group last call
process for this draft was iterative, consensus has gradually become less
rough.

(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 module tags are a facility which is potentially employed by all
consumers of yang modules. While netmod is central to protocol
maintenance and more or less all yang implementors are represented
there consumers (operators) of the technology present at the IETF may
have limited exposure prior to IETF last call. IETF LC is therefore
important for the review process.

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

The document shepherd has not specific concerns with the document.

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


Chairs have requested postive confirmation of IPR status per NETMOD
operating procedure and have concluded that there are no acknowledged
IPR claims on the document.


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

No such IPR has been files.

(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 consensus was arrived at as a result of vigorous debate, was
revisited at 103 and subsequently confirmed on the mailing list.

https://mailarchive.ietf.org/arch/msg/netmod/UsuQJY9uscKGa35Bgy8LwvhRDyY

(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 appeals are anticipated.

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

Notable nits:

Appearance of the lack of security considerations

As with rfc 8047. there are no meaningful security implications to
imposing a structure on the documentation system for yang modules.

As with rfc 8407

  "This document defines documentation guidelines for NETCONF or
  RESTCONF content defined with the YANG data modeling language;
  therefore, it does not introduce any new or increased security risks
  into the management system."

Updates line needs to be changed from RFC8407 to 8407. This nit
accumulated since the draft referenced has exited the RFC editor queue.
the meaning  is unambiguous.

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

Draft-04 has been submitted for yang doctors review.

(13) Have all references within this document been identified as
either normative or informative?

All references are normatively or informatively referenced.

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

No references are in this state since the publication of RFC 8407.

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

RFC 8199 and 8407 are downward references to informational documents.
They describe variously consistent terminology for the classification of yang
modules and Guidelines for yang module authors. It is the belief of the shepherd
that these two downward references should be noted in the IETF last call but
are otherwise not exceptional.

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

This document proposes to update RFC 8407 as noted in section 7.1 by creating
a standard tag.

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

The document proposes in Section 8 to create:

A module tag prefix registry consisting of at present  three types of module
tags.

A IETF module tag registry with a pre-populated list of module tags.

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

Additions to the module tag prefix registry are specification required.

Additions to the IETF tag registry require IETF consensus.

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

No automated checks are required. Appendix A contains a fictional example result of a query from a module tag registry. It has been sanity checked.

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

The draft-ietf-netmod-module-tags-04 is requesting Standards Track status.

(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 provides for the association of tags with YANG modules.
  The expectation is for such tags to be used to help classify and
  organize modules.  A method for defining, reading and writing a
  modules tags is provided.  Tags may be standardized and assigned
  during module definition; assigned by implementations; or dynamically
  defined and set by users.  This document provides guidance to future
  model writers and, as such, this document updates [RFC8407].


Working Group Summary

The working group had significant questions on how module tags might be
used. Section 1.1 of draft 04 dwells on how and why tags are applied,
addressing significant points in this discussion from the vantage-point
of working-group participants.

Document Quality

The document has received signficant review, including vigorous working-
group debate that resulted in draft-03/04. Yang-doctors review of the WG
consensus draft-04 is pending.

Personnel

Joel Jaeggli is the document shepherd Ignas Bogdonas 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 has been reviewed by the document shepherd. As WG co-chair
I have been shepherding this document through the working group process
up to this point as well. I believe that it is ready for IETF last call IESG review
and publications.

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

No specific concerns are present at this time. The working-group last call
process for this draft was iterative, consensus has gradually become less
rough.

(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 module tags are a facility which is potentially employed by all
consumers of yang modules. While netmod is central to protocol
maintenance and more or less all yang implementors are represented
there consumers (operators) of the technology present at the IETF may
have limited exposure prior to IETF last call. IETF LC is therefore
important for the review process.

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

The document shepherd has not specific concerns with the document.

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


Chairs have requested postive confirmation of IPR status per NETMOD
operating procedure and have concluded that there are no acknowledged
IPR claims on the document.


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

No such IPR has been files.

(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 consensus was arrived at as a result of vigorous debate, was
revisited at 103 and subsequently confirmed on the mailing list.

https://mailarchive.ietf.org/arch/msg/netmod/UsuQJY9uscKGa35Bgy8LwvhRDyY

(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 appeals are anticipated.

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

Notable nits:

Appearance of the lack of security considerations

As with rfc 8047. there are no meaningful security implications to
imposing a structure on the documentation system for yang modules.

As with rfc 8407

  "This document defines documentation guidelines for NETCONF or
  RESTCONF content defined with the YANG data modeling language;
  therefore, it does not introduce any new or increased security risks
  into the management system."

Updates line needs to be changed from RFC8407 to 8407. This nit
accumulated since the draft referenced has exited the RFC editor queue.
the meaning  is unambiguous.

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

Draft-04 has been submitted for yang doctors review.

(13) Have all references within this document been identified as
either normative or informative?

All references are normatively or informatively referenced.

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

No references are in this state since the publication of RFC 8407.

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

RFC 8199 and 8407 are downward references to informational documents.
They describe variously consistent terminology for the classification of yang
modules and Guidelines for yang module authors. It is the belief of the shepherd
that these two downward references should be noted in the IETF last call but
are otherwise not exceptional.

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

This document proposes to update RFC 8407 as noted in section 7.1 by creating
a standard tag.

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

The document proposes in Section 8 to create:

A module tag prefix registry consisting of at present  three types of module
tags.

A IETF module tag registry with a pre-populated list of module tags.

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

Additions to the module tag prefix registry are specification required.

Additions to the IETF tag registry require IETF consensus.

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

No automated checks are required. Appendix A contains a fictional example result of a query from a module tag registry. It has been sanity checked.