Re: [netmod] [Editorial Errata Reported] RFC8407 (7791)

[mohamed . boucadair]

Hi all, 

Here is an update on the initial comments from Dale:

> > 1) It would be helpful if the beginning of the template contained a
> > reference to RFC 8407 to provide a pointer back to where the
> templated
> > section of Yang module definitions was instantiated from.  Perhaps
> > starting the template with "[Instantiated from the template of
> > [RFC8407] section 3.7.1.]"
> >

After discussion with Dale, this PR is created: 
https://github.com/boucadair/rfc8407bis/pull/36/files. This will be merged into 
the next iteration of i-d.rfc8407bis. 

> > 2) While the URL given in RFC 8407 works, the URL given in the
> online
> > template only goes to a generic page, "Welcome to the IETF Community
> > Wiki".  Presumably the URL in the online template should be the URL
> of
> > that page itself.

The secretariat helped fixing the broken link. 

With these actions, I think that the erratum can be safely rejected.

Cheers,
Med

> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : mardi 30 janvier 2024 18:53
> À : 'RFC Errata System' ;
> wor...@alum.mit.edu
> Cc : netmod@ietf.org
> Objet : RE: [netmod] [Editorial Errata Reported] RFC8407 (7791)
> 
> Hi Dale, all,
> 
> I don't think filling an erratum is appropriate here given that the
> original text is not broken (including the URL). I suggest to reject
> it.
> 
> However, text enhancements can be considered as part of
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/. Let's
> have that discussion. Thanks.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : netmod  De la part de RFC Errata
> System
> > Envoyé : mardi 30 janvier 2024 18:01 À : rfc-edi...@rfc-editor.org
> Cc
> > : wor...@alum.mit.edu; netmod@ietf.org Objet : [netmod] [Editorial
> > Errata Reported] RFC8407 (7791)
> >
> > The following errata report has been submitted for RFC8407,
> > "Guidelines for Authors and Reviewers of Documents Containing YANG
> > Data Models".
> >
> > --
> > You may review the report below and at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > rfc-
> >
> editor.org%2Ferrata%2Feid7791=05%7C02%7Cmohamed.boucadair%40orang
> >
> e.com%7C2cb3e186d23d4eac917208dc21b511f8%7C90c7a20af34b40bfbc48b9253b6
> >
> f5d20%7C0%7C0%7C638422308774178382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> > data=6Qi9sKVPa44FCI8dW984szRS1EZso%2FpPr%2BRDnsGkobE%3D=0
> >
> > --
> > Type: Editorial
> > Reported by: Dale R. Worley 
> >
> > Section: GLOBAL
> >
> > Original Text
> > -
> > There are two related items.
> >
> > 1) Section 3.7.1 "Security Considerations Section Template" begins
> >
> >X.  Security Considerations
> >
> >The YANG module specified in this document defines a schema for
> > data
> >that is designed to be accessed via network management protocols
> > such
> >as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF
> > layer
> >is the secure transport layer, and the mandatory-to-implement
> > secure
> >transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF
> > layer
> >is HTTPS, and the mandatory-to-implement secure transport is TLS
> >[RFC8446].
> >
> > 2) RFC 8470 says "the latest approved template (available at
> )".  But
> the template at that URL says "the latest approved template (available
> at http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-
> guidelines).">
> >
> > Corrected Text
> > --
> > 1) It would be helpful if the beginning of the template contained a
> > reference to RFC 8407 to provide a pointer back to where the
> templated
> > section of Yang module definitions was instantiated from.  Perhaps
> > starting the template with "[Instantiated from the template of
> > [RFC8407] section 3.7.1.]"
> >
> > 2) While the URL given in RFC 8407 works, the URL given in the
> online
> > template only goes to a generic page, "Welcome to the IETF Community
> > Wiki".  Presumably the URL in the online template should be the URL
> of
> > that page itself.
> >
> >
> >
> > Notes
> > -
> > Item (2) is a straightforward correction.  Item (1) is in service to
> > having better pointers/references in our documents.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please use
> > "Reply All" to discuss whether it should be verified or rejected.
> When
> > a decision is reached, the verifying party will log in to change the
> > status and edit the report, if necessary.
> >
> > --
> > RFC8407 (draft-ietf-netmod-rfc6087bis-20)
> > --
> > Title   : Guidelines for Authors and Reviewers of
> > Documents Containing YANG Data 

[netmod] rfc8407bis IANA guidance (enums vs identities)

[Kent Watsen]

Authors, WG,

Following is a comment on Section 4.30.2.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-06#section-4.30.2

The text says:

START
An IANA-maintained module may use identities (e.g., [RFC8675]) or enumerations 
(e.g., [RFC9108]). The decision about which type to use is left to the module 
designers and should be made based upon specifics related to the intended use 
of the IANA-maintained module. For example, identities are useful if the 
registry entries are organized hierarchically, possibly including multiple 
inheritances. It is RECOMMENDED that the reasoning for the design choice is 
documented in the companion specification that registers an IANA-maintained 
module. For example, [RFC9244] defines an IANA-maintained module that uses 
enumerations for the following reason:

 "The DOTS telemetry module (Section 10.1) uses "enumerations" rather
 than "identities" to define units, samples, and intervals because
 otherwise the namespace identifier "ietf-dots-telemetry" must be
 included when a telemetry attribute is included (e.g., in a
 mitigation efficacy update).  The use of "identities" is thus
 suboptimal from a message compactness standpoint; one of the key
 requirements for DOTS messages."
STOP

I’m wondering if the guidance here cannot be stronger but, first, let me 
explain how I got here…

The "ssh-client-server" and the "tls-client-server” drafts both register 
IANA-maintained modules for IANA-registries (for crypto algorithms).  All of 
these IANA-modules use *identities* (not enums).

As I’m in the process of updating the two drafts to follow this template, I’m 
struggling with the above quoted text.  The reason for the struggle is because 
I’m having a hard time justifying these draft’s current use of identities 
(yikes!)
  
The impetus for using identities in the first place was to enable new 
identities to be added by future modules (and nothing to do with multiple 
inheritances).   But when moving to the modules being IANA-maintained, it seems 
that we’re simultaneously saying that new values should NOT be definable any 
other way.  That is, IETF would NOT publish new algorithms via new RFCs, when 
IANA is already publishing said algorithms via revisions of the base-module).

Perhaps it is theoretically possible that "proprietary” algorithms could be 
used in private deployments, but such would not foster the interoperability 
that IETF seeks.

Thus I am wondering if the guidance in this section should be stronger.  Should 
it actually say something like “Enumerations SHOULD be used unless the 
multiple-inheritance property of identities is needed.”?

Thoughts?

Kent // contributor





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

[mohamed . boucadair]

Hi Mahesh, all,

FWIW, we submitted an updated version of the draft to address the pending 
points from your reviews. A diff to track the changes vs. -04 can be seen at: 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-acl-extensions-04=draft-ietf-netmod-acl-extensions-06=--html.

Cheers,
Med

De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 16:57
À : 'Mahesh Jethanandani' 
Cc : Lou Berger ; NETMOD Group ; NetMod WG 
Chairs 
Objet : RE: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi Mahesh,

Thanks for the follow-up. Made some changes as you can see at 
https://boucadair.github.io/enhanced-acl-netmod/#go.draft-ietf-netmod-acl-extensions.diff.

Please see inline for more context.

Cheers,
Med



Orange Restricted
De : Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Envoyé : mercredi 20 décembre 2023 18:20
À : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Cc : Lou Berger mailto:lber...@labn.net>>; NETMOD Group 
mailto:netmod@ietf.org>>; NetMod WG Chairs 
mailto:netmod-cha...@ietf.org>>
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi Med,

Thanks for addressing some of my comments. Please see inline.

On Dec 19, 2023, at 12:09 AM, 
mohamed.boucad...@orange.com wrote:

Hi Mahesh, all,

Thank you for the review and comments. We just posed 
draft-ietf-netmod-acl-extensions-04.

Please see more context inline.

Cheers,
Med

De : netmod mailto:netmod-boun...@ietf.org>> De la 
part de Mahesh Jethanandani
Envoyé : mardi 5 décembre 2023 23:09
À : Lou Berger mailto:lber...@labn.net>>
Cc : NETMOD Group mailto:netmod@ietf.org>>; NetMod WG Chairs 
mailto:netmod-cha...@ietf.org>>
Objet : Re: [netmod] WG Last Call: draft-ietf-netmod-acl-extensions-03

Hi,

I do support this work, as it is much needed, and would like to see it 
progress. However, I do believe that the document needs to undergo a revision 
to qualify for LC. Some of the comments are editorial or minor, and can be 
addressed easily, but others are not. They should all be addressed for the WG 
to call the document ready.

- The Security Considerations section has both the read/write nodes and the 
read-only nodes as empty (or marked as TBC, which I imagine stands for To Be 
Completed). This needs to be filled out, or if no nodes are worth any security 
considerations, it should be stated so, and why.

[Med] ACK. We don’t repeat what is already in 8519 but focus on key additions 
in the spec: https://github.com/boucadair/enhanced-acl-netmod/pull/65/files

[mj] Thanks for updating the section.

s/setf/set/
s/Simialr/Similar/

and in other place
s/modelled/modeled/

[Med] Thanks. Fixed.


- Isn’t the YANG model normative portion of the document? Isn’t what this 
document all about? Why is it then in the Appendix?

[Med] We are using a script to generate the IANA modules + we are actually 
following this part from the 8407bis:

   It is RECOMMENDED to include the URL from where to retrieve the
   recent version of the module.  When a script is used, the Internet-
   Draft that defines an IANA-maintained module SHOULD include an
   appendix with the initial full version of the module.  Including such
   an appendix in pre-RFC versions is meant to assess the correctness of
   the outcome of the supplied script.  The authors MUST include a note
   to the RFC Editor requesting that the appendix be removed before
   publication as RFC and that RFC  is replaced with the RFC number
   that is assigned to the document.  Initial versions of IANA-
   maintained modules that are published in RFCs may be misused despite
   the appropriate language to refer to the IANA registry to retrieve
   the up-to-date module.

[mj] I am not clear on what happens to the IANA module once the draft is 
published as an RFC based on what you cite from 8407bis.
[Med] It will be removed as per the note:

(2) The modules are provided in {{iana-icmp}}, {{iana-icmpv6}}, and 
{{iana-ipv6-ext}} for the users convenience before publication as RFC. Please 
remove these appendices from the final RFC.

The document states that the reference to “RFC ” is replaced with the 
actual RFC number, but  it also says that the Appendix be removed. What happens 
to the initial version of the module itself? Is it removed if the Appendix is 
removed?
[Med] It will be removed as per the note above. Please note that this practice 
is already followed in rfc9108, for example.

Or does it remain in the Appendix as an initial version, with language that 
indicates that the IANA registry should be used to retrieve the most up-to-date 
model? The language in Section 1.1 item (2) does not help.

The above text from 8407bis needs to be explicit on what happens to the initial 
version of the module as part of the RFC publication.
[Med] Please feel free to propose changes to this part of the bis for better 
clarity:

   The authors MUST include a note
   to the RFC Editor requesting