[netmod] Re: Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-25: (with COMMENT)

[[e-mail]]

Hi Éric,

Thank you for the review. The changes made ** so far ** to address your review can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/boucadair-patch-2/draft-ietf-netmod-rfc8407bis.txt.

Please see inline.

Cheers,
Med (as editor) 

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <[e-mail]>
> Envoyé : lundi 2 juin 2025 14:24
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-
> 25: (with COMMENT)
> 
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netmod-rfc8407bis-25: 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.)
> 
> 
> -------------------------------------------------------------------
> COMMENT:
> -------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-netmod-rfc8407bis-25
> CC @evyncke
> 
> Thank you for the work put into this document, I share Gunter's
> comment on the
> usefulness and easy-to-read quality of this I-D.

[Med] Thanks.

> 
> I have reviewed the whole draft rather than the diffs with RFC
> 8407.
> 
> Please find below some non-blocking COMMENT points/nits (replies
> would be
> appreciated even if only for my own education).
> 
> Special thanks to Qiufang Ma for the shepherd's detailed write-up
> including the
> WG consensus and the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS (non-blocking)
> 
> ### Title vs. abstract
> 
> The title is about data models while the abstract is about modules.
> Let's avoid
> spreading the confusion in a BCP. As the document is more about
> data model,
> let's use this term in title/abstract.
> 

[Med] The current use is OK (and was inherited from 8407), but I see your point especially that clarifying the use of Data model vs YANG module (Section 2.5). I need to think about this further as we need to not break the mention of IANA-maintained modules, for example.


> ### Section 1
> 
> `Only constructs that all servers are required to support can be
> used in IETF
> YANG modules` , it is really unclear to me how this can be
> verified.
> 

[Med] This is inherited from RFC 8407, which itself was inherited from RFC6087. I always linked this sentence to the next one which motivates the need for usage guidance in addition to the conformance per base YANG specs. 

> ### Section 2
> 
> s/and *which* is not maintained by IANA/and *that* is not
> maintained by IANA/ ?

[Med] OK

> 
> ### Section 2.5
> 
> I would go further than `Likewise, "YANG data module" should be
> avoided.`and
> use "Likewise, "YANG data module" is incorrect, has no meaning, and
> MUST be
> avoided."
> 

[Med] OK, went with "Likewise, "YANG data module" has no meaning and must be avoided."

> ### Section 3
> 
> s/The following sections MUST be present in an I-D containing a
> YANG module/The
> following sections MUST be present in an I-D *or RFC* containing a
> YANG module/

[Med] OK

> 
> ### Section 3.2
> 
> Any chance to use a more recent date than 2016 ? Or is it to borrow
> as much as
> possible from RFC 8407 ?

[Med] This is inherited from 8407.

> 
> ### Section 3.4
> 
> For large trees, I like to have a pruned version in the body part
> and not in
> the appendix, perhaps with subtrees.

[Med] Thanks for sharing your preference. I think that is covered by the spirit of rfc8340#section-3.3 and the use of subtrees. 

> 
> ### Section 3.5
> 
> Is this section about the data models or modules ? Modules are
> mainly for
> syntax while the data models are for semantics, i.e., I think that
> relationships are between data models and not modules.

[Med] You are right that the first para can be about data models. However, things such as:

   If the module or modules defined by the specification imports
   definitions from other modules (except for those defined in [RFC7950]
   or [RFC6991])

are definitely about modules.

Made changes when I think is justified. 

> 
> s/the Introduction section *should* mention this fact/the
> Introduction section
> *SHOULD* mention this fact/ if only to be consistent with the use
> of uppercase
> BCP14 terms in this section.

[Med] Works for me.

> 
> The long line example seems to be for an instance of a module,
> should it rather
> be on the module itself ?
> 

[Med] No. We do encourage against that for modules: 

   Built-in YANG features (e.g., breaking line, "+") SHOULD be used to
   fit a module into the line limits.  Exceptionally, RFC8792-folding of
   YANG modules MAY be used if and only if built-in YANG features are
   not sufficient.  A similar approach (e.g., use "--tree-line-length
   69" or split a tree into subtrees) SHOULD be followed for tree
   diagrams.


> ### Section 3.6
> 
> First time ever that I read about "YIN syntax", please provide a
> normative
> reference.

[Med] This inherited from 8407 and even rfc6087. This is used in base YANG spec 6020/7950.

> 
> ### Section 3.8
> 
> I fail to imagine a non-normative YANG module in a RFC; therefore,
> is
> 'normative' required in `Each normative YANG module`.

[Med] Yes, as a document may include only example YANG modules.

> 
> ### Section 3.9
> 
> Suggest adding some template text to be used before the YANG module
> itself to
> add a normative reference (to avoid the 'unused reference' by id-
> nits).
> 

[Med] Do you mean to make sure that references cited in the module are called in the narrative part?

> ### Section 3.10
> 
> It is disapointing not to see
> [yangcatalog.org](https://eur03.safelinks.protection.outlook.com/?u
> rl=https%3A%2F%2Fwww.yangcatalog.org%2Fyangvalidator&data=05%7C02%7
> Cmohamed.boucadair%40orange.com%7Ce1af181b233f423c62a108dda1d055ad%
> 7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638844638355444430%7CU
> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=J
> 4k1cVm9AMG%2Fu3QLjNAYkA6u56QDhwGrLvKrxlQ0qMA%3D&reserved=0) listed
> in the
> validation tools. Is it a hint by the authors that YCO use is not
> recommended ?

[Med] YC relies on other tools for validation. 

> 
> ### Section 3.12
> 
> Big thank you for forcing either IPv6 or dual-stack examples, we
> are indeed in
> 2025!
> 
> Please add RFC 9637 as a reference for documentation prefix (I was
> about to
> ballot a DISCUSS on this one as it MUST be addressed).

[Med] Argh. Fixed.

> 
> ### Section 4.2
> 
> s/moodules/modules/ ;-)

[Med] Ook :-)

> 
> ### Section 4.3
> 
> Should `character` be qualified as ASCII (I guess no UTF-8 encoding
> here).

[Med] As we provide the ABNF right after that text, I don't think a change is needed. This is inherited from 8407, btw.

> 
> ### Section 4.7
> 
> What are the events (RFC publication date ? IESG approval date ?)
> for `An
> object SHOULD be available for at least one year with a
> "deprecated" status
> before it is changed to "obsolete".`?
> 

[Med] This is about "published", which is defined as follows:

   published:  A stable release of a module or submodule.  For example,
      the "Request for Comments" described in Section 2.1 of [RFC2026]
      is considered a stable publication.

Note that this is inherited from 8407.

> ### Section 4.8
> 
> The "contact" statement is required but can it be empty ? Should
> there be
> guidance for other SDOs ?

[Med] This will depends on these SDOs. I'm afraid that it will be difficult to have guidance for them here. Do you have something specific in mind? Thanks.

> 
> ### Section 4.11.2
> 
> I was about to ballot a DISCUSS on this one :-( ... the `pattern
> '[0-9\.]*'` is
> clearly to lax for an IPv4 address even if RFC 6991 claims so.
> 

[Med] This is inherited from 8407. Do you prefer we use another example?

> ### Section 4.12
> 
> There are many "SHOULD" where I would have preferred "MUST", at
> least explain
> why an existing type cannot be re-used.
> 
> Also suggest adding how can an author find a re-usable data type.

[Med] These are typically defined in common type modules. Authors need to check these modules. Do you think that adding examples of such common type modules would be useful here? If so, I can add a list. Thanks. 

> 
> ### Section 4.25
> 
> To be honest, I fail to understand the content of this section,
> especially what
> an `open system` is...

[Med] I don't have the context why this was in 8407.

> 
> ### Section 4.30.3
> 
> Unsure whether a 2025 I-D should still contain reference to `3des-
> cbc` and for
> sure to `6to4`. These terms were probably current when RFC 8407 was
> published,
> but let's avoid them in the -bis.

[Med] These are examples from current registries maintained by IANA to insist on the importance on providing guidance on how to spell out when ids begin with a number

      -  If the name in the IANA registry does not comply with the
         naming conventions listed in Section 4.3.1, the procedure MUST
         detail how IANA can generate legal identifiers from such a
         name.  Specifically, if the name begins with a number, it is
         RECOMMENDED to spell out the number when used as an identifier.
         IANA should be provided with instructions to perform such task.

As we worked this part with IANA, I prefer to not touch it.

> 
> ### Ack section
> 
> I think you mean 'Rich' rather than `Thanks to Rach Salz` ;-)
> 
> 
[Med] Thanks, Éric.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.