[netmod] Alvaro Retana's No Objection on draft-ietf-netmod-rfc6087bis-18: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-netmod-rfc6087bis-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) This sentence in the Introduction caught my attention: "This document
defines a set of usage guidelines for Standards Track documents containing
YANG...data models."    The Abstract extends to say that "Applicable portions
may be used as a basis for reviews of other YANG data model documents."

I don't remember a non-Standards Track document off the top of my head [*], but
I'm sure the guidelines apply to any IETF document containing a module.  Is
that true?

I see, for example, that in 4.1 (Module Naming Conventions) it is clear how
modules published by the IETF should be named...and a note is included about
what other SDOs might do.  Are there cases where the guidelines are only
applicable to Standards Track documents, but would not apply to other IETF
documents?

This may be a nit, but I think it is good to close this door before the
justification for non-compliance starts being the Status of a document.

[*] I do remember the IESG talking about whether a document with a module for
an Experimental protocol should be in the Standards Track or not.  IMHO, what
matters is for the module to be used (i.e. correct, implementable, implemented,
etc.) and not the status of the document it is in.

(2) The second paragraph in 2.1. (Requirements Notation) is not needed: "RFC
2119 language...as if it were describing best current practices."  This
document is now a BCP.