[netmod] Re: Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis-25: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ketan,

Thanks for the review.

The changes made so far can be tracked 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/KTcomments/draft-ietf-netmod-rfc8407bis.txt.

See more context inline.

Cheers,
Med (as editro)

> -----Message d'origine-----
> De : Ketan Talaulikar via Datatracker <[e-mail]>
> Envoyé : mardi 3 juin 2025 08:04
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Ketan Talaulikar's Discuss on draft-ietf-netmod-rfc8407bis-
> 25: (with DISCUSS and COMMENT)
> 
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-netmod-rfc8407bis-25: Discuss
> 
> 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.)
> 
> 
> -------------------------------------------------------------------
> DISCUSS:
> -------------------------------------------------------------------
> 
> Thanks to the authors and the WG for your work on this important
> document.
> 
> I have one high-level point that I would like to discuss with the
> authors and
> the WG since is it not clear - this is regarding experimental and
> information
> track YANG module documents in IETF stream.
> 
> At a high-level, I would like to discuss and understand whether
> YANG model
> documents can be experimental or informational. I think the answer
> is YES?

[Med] YANG modules defined in the IETF so far are defined in PS documents, even when covering protocols that are in Info/Exp. An example is RFC9105. You may refer to https://mailarchive.ietf.org/arch/msg/opsawg/7E9g02ZwMt5z9PT1vgSai4kW42U/ or the discussion at the time in the IESG.

The key point is that a YANG module (independent of the underlying objects it manipulates) is about making two peers (client/server) interoperable.

The following usage in Section 3 (inherited from 8407):

CURRENT:
   There are three usage scenarios for YANG that can appear in an I-D or
   RFC:

   o  normative module or submodule

   o  example module or submodule

   o  example YANG fragment not part of any module or submodule


 But
> this is not clear. A follow-on question: what is the guidance for
> YANG models
> specified in standards track document being augmented by modules in
> experimental or informational track document? I think the answer is
> NO? But
> again, this is not clear.
> 
> Please also see in the comments sections for some concerns that are
> related to
> this topic - those are provided inline for better context.
> 
> 
> -------------------------------------------------------------------
> COMMENT:
> -------------------------------------------------------------------
> 
> Please find below some comments provided inline in the idnits
> output of v25 of
> this document.
> 
> 14      Abstract
> 
> 16         This memo provides guidelines for authors and reviewers
> of
> 
> <nit> s/memo/document

[Med] OK, even if this was inherited from 8407 ;-)

> 
> 232     1.1.  Changes Since RFC 8407
> 
> <minor> Since this is an exhaustive list of changes, can it be
> moved to the
> appendix section? First time (new) readers don't need to be
> bothered by this in
> the body of the RFC?

[Med] This is a matter of taste, but more importantly follow the practice used in rfc8407 vs 6087.

> 
> 688        Unless the modules comply with [RFC8791] or define YANG
> extensions
> 689        (e.g., [RFC7952]), the security section MUST be modeled
> after the
> 690        latest approved template (available at
> 691 
> <major> I am not sure if a wiki pointer is appropriate here.

[Med] This practice is implemented and followed since many years now (including RFC editor, etc.). We need a stable reference to maintain the template out of the RFC itself. A reason why the template is maintained here and not completely offloaded is that we received a request from the IETF trust that we addressed (this text is used outside the IETF). 

 If it
> is a BCP
> level thing (beyond what is in 3.7.1 below) then please cover
> inline and
> remove the URL.
> 
> 847     3.8.  IANA Considerations Section
> 
> 849        In order to comply with IESG policy as set forth in
> 850
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.ietf.org%2Fid-
> info%2Fchecklist.html&data=05%7C02%7Cmohamed.boucadair%40orange.com
> %7C9b04b9803c344846ae4908dda2646796%7C90c7a20af34b40bfbc48b9253b6f5
> d20%7C0%7C0%7C638845274308491793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qLf%2Fz4Eu%2BzB2Lm7ZIQrn3DcE7ldb
> eA5dZGnMvCj65RI%3D&reserved=0>, every I-D that is
> 851        submitted to the IESG for publication MUST contain an
> IANA
> 852        Considerations section.  The requirements for this
> section vary
> 
> <major> The text gives an impression of referencing an IETF webpage
> (that is
> not updated via IETF consensus process) for a  normative (MUST)
> directive. More
> problematic is that it is not scoped to YANG documents alone. Given
> that the
> URL is already present in the template, would there be an issue if
> the text
> were to simply say "Every I-D specifying a YANG module that is
> submitted to the
> IESG for publication MUST contain an IANA Considerations section."
> ?

[Med] Even if this was in 8407/6087, removed that text.

> 
> 884     3.8.2.  Documents That Extend an Existing Namespace
> 
> 886        It is possible to extend an existing namespace using a
> YANG submodule
> 887        that belongs to an existing module already administered
> by IANA.  In
> 888        this case, the document containing the main module MUST
> be updated to
> 889        use the latest revision of the submodule.
> 
> <major> What is exactly meant by "the document containing the main
> module MUST
> be updated"? That "document" has already been published as an RFC
> and that
> module is now being maintained by IANA on its website. Is this
> something that
> IANA needs to take care of by itself (I guess this is the case)? Or
> is it
> something that each new document doing such updates need to ask
> IANA to do
> this? Please clarify.

[Med] This section is under "3.8. IANA Considerations Section" which covers considerations in a document that extends the existing namespace.

> 
> 954     3.10.  Validation Tools
> 
> 956        All modules need to be validated before submission in an
> I-D.  The
> 957        'pyang' YANG compiler is freely available from GitHub:
> 
> 959
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> github.com%2Fmbj4668%2Fpyang&data=05%7C02%7Cmohamed.boucadair%40ora
> nge.com%7C9b04b9803c344846ae4908dda2646796%7C90c7a20af34b40bfbc48b9
> 253b6f5d20%7C0%7C0%7C638845274308504790%7CUnknown%7CTWFpbGZsb3d8eyJ
> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IM3BY3o8Q2%2BUVR0WGUo0HXt
> JhqWmnRYzrQQn1v0HCEs%3D&reserved=0>
> 
> <minor> Should these GitHub links not be moved into the informative
> reference
> section?

[Med] Preserved the use from 8407.

> 
> 1053    4.1.  Module Naming Conventions
> 
> 1055       Normative modules contained in Standards Track documents
> MUST be
> 1056       named according to the guidelines in the IANA
> Considerations section
> 1057       of [RFC6020].
> 
> <major> The referenced RFC talks about "IETF stream documents" and
> not
> Standards Track documents alone. Could you please review all
> occurrences of
> reference to standards track document to review for correctness?
> They should
> also cover experimental and informational?

[Med] This part is untouched from 8407. The key part of the text you quoted is "normative modules". Other types (e.g., example modules) are not concerned to follow the full guidance. 

> 
> 1605    4.7.  YANG Definition Lifecycle Management
> 
> 1607       The YANG status statement MUST be present within a
> definition if its
> 1608       value is "deprecated" or "obsolete".  The status SHOULD
> NOT be
> 1609       changed from "current" directly to "obsolete".  An
> object SHOULD be
> 1610       available for at least one year with a "deprecated"
> status before it
> 1611       is changed to "obsolete".
> 
> <major> This at least one year limit - does it include time as an
> I-D or it is
> so that it can be changed by another RFC that gets published one
> year after
> the publication of the previous one. Can you please clarify?

[Med] Idem as previous one, this is inherited from 8407. As clarified in that same section, the reasoning is vs. published module, which is defined as follows:

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

> 
> 1656       The "organization" statement MUST be present.  If the
> module is
> 1657       contained in a document intended for IETF Standards
> Track status,
> 1658       then the organization SHOULD be the IETF working group
> (WG) chartered
> 1659       to write the document.  For other standards
> organizations, a similar
> 1660       approach is also suggested.
> 
> <major> This is another instance which talks only about standards
> track - what
> about the others? Also, not all standards track need to come via WG
> - some may
> be AD sponsored? Why not allow "IETF" alone for AD sponsored?

[Med] This is not excluded. This is covered as exception to the SHOULD. Added "Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents."

> 
> 1824       Note that a different URN prefix string SHOULD be used
> for modules
> 1825       that are not Standards Track.  The string SHOULD be
> selected
> 1826       according to the guidelines in [RFC7950].
> 
> <major> Which specific section of RFC7950 is being referenced here?
> And what
> is the guideline for experimental and informational track documents
> with YANG
> modules?

[Med] Updated to reference Section 5.3, where we have: 

   XML namespaces for private modules are assigned by the organization
   owning the module without a central registry.  Namespace URIs MUST be
   chosen so they cannot collide with standard or other enterprise
   namespaces -- for example, by using the enterprise or organization
   name in the namespace.

> 
> 3154          The initial version of this YANG module is part of
> RFC IIII; see
> 3155          the RFC itself for full legal notices.
> 
> <minor> This RFC IIII is used here and other places in the context
> of the IANA
> related aspects. The use is described in the following paragraph
> but can you
> also please cover in Section 2?

[Med] Happily. Done.

> 
> 3196    4.30.3.  Guidance for Writing the IANA Considerations for
> RFCs Defining
> 3197             IANA-Maintained Modules
> 
> <major> What is missing is guidance for future documents (i.e. not
> RFC IIII)

[Med] There won't be any ;-) This is the beauty of IANA-maintained modules.

> that allocate code points from a registry that is associated with
> an
> IANA-maintained YANG module. I guess the instruction for such a
> document is to
> not give any specific instruction related to such a module (e.g.,
> don't try to
> repeat the updated module in appendix or such?) - all of this
> should be taken
> care of by IANA automatically based on instructions provided in RFC
> IIII ?
> 
> 3257       *  A note that unassigned or reserved values must not be
> present in
> 3258          the IANA-maintained module.
> 
> <major> Is that a MUST NOT? There is a mix of lower and upper case
> normative
> language. Some consistency would be good.

[Med] The note will be included in IANA consideration section. The current wording is consistent with the guidance fro that section at: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/#inappropriate-uses-of-key-words

> 
> 3623    7.1.  Normative References
> 
> 3625       [ID-Guidelines]
> 3626                  IETF, "Guidelines to Authors of Internet-
> Drafts", n.d.,
> 3627
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> authors.ietf.org%2Fen%2Fcontent-guidelines-
> overview&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9b04b9803c
> 344846ae4908dda2646796%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> C638845274308518244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C0%7C%7C%7C&sdata=FQf7Fjalpe9gC57J1hzJvUkDGELGP9Mk2g4tioa%2BkPM
> %3D&reserved=0>.
> 
> <major> Is it normal for this to be a normative reference to an
> IETF webpage
> that is not updated via IETF consensus? Why not move it to
> informative
> references?

[Med] This is inherited from 8407. I think that we can move it around as we softened now the generic I-D guidance.

> 
> <EoRv25>
> 
> 

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