[netmod] Re: Regarding draft-ietf-netmod-rfc8407bis

[[e-mail]]

Hi Kent, all,
(apologies for the delay to follow-up as I was out of office)

Please see inline.

Cheers,
Med

De : Kent Watsen <[e-mail]>
Envoyé : dimanche 11 août 2024 20:48
À : [e-mail]
Objet : [netmod] Regarding draft-ietf-netmod-rfc8407bis


The minutes for the NETMOD 120 session [0] captures this dialog:

             Tim Carey: What is the update for the best practices document and
             node-tags document

             Lou Berger: Best practices - I do not recall and will have to come back.


The update follows, in the form of the history/state of the current WGLC.


1) The chairs started the WGLC on the May 6 [1].  At this time, the document was at version -11.

2) Due to receiving no responses, the chairs extended the WGLC on June 3 [2] (still -11) and requested a YangDoctor review.  Two responses were received, both by the authors.

3) Xufeng provided a YangDoctors review on June 18 [3].  There was an exchange and then -12 was published on June 21.

4) Amanda Baber from IANA posted some concerns on June 26 [4], and -13 was published on July 3.  FWIW, I do not find a response from Amanda about if the update is okay, but I can see that her comment about "3des -> triple-res" was not addressed.
[Med] For "3des -> triple-des" comment, I clarified in my reply to Amanda that this is an example + instructions about how to spell out those are supposed to be supplied by authors of iana-maintained modules per the following:

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

For the specific example, triple is used instead of three to follow, for example, this part from RFC4253:

   The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
   encrypt), where the first 8 bytes of the key are used for the first
   encryption, the next 8 bytes for the decryption, and the following 8
    bytes for the final encryption.

Would be great to hear back from Amanda, though.

5) Xufeng and Med continue discussion, and -14 was published on July 5.

That's it.  No other comments are in the mail archive.  The WGLC never closed.  It is fair to say that few reviews were received after the extension on June 3.


As a contributor, looking at the current version I noticed the following issues, which I hope will be received as WGLC comments.  This is not a complete review, just some things I noticed jumping around diffs.

a) In Section 4.30.3, the examples are folded incorrectly (RFC 8792).  They use some (unsupported) mixed of the `\` or the `\\` strategies.

[Med] I fail to see these two mixed/used in the examples. Can you please help pointing to those? Thanks.

 More than that, YANG modules can avoid folding, in many cases, by converting a long line into a sequence of line-terminated string concatenations.  I suggest trying this to eliminate the folding altogether.

[Med] OK. Please see: https://github.com/netmod-wg/rfc8407bis/pull/63/files

b) In Section 4.30.3.1: the "reference" statement isn't described like it is in Section 4.30.3.2.  Should it be?

[Med] I don't see any difference out there. Can you please point to the text you identified?

c) In Section 4.30.3.2: I still don't understand why we'd want the "reference" statement pointing to IANA_FOO_URL_With_REV.  For example, a module-reader would have to be in possession of the module in order to see this statement's value, so value of pointing someone to the module when they already have it doesn't make sense to me.

[Med] Your reasoning is fair for the current version, not previous (or future) revisions. When new revisions are made on top of old ones, having specific URLs is useful to access previous revisions, for whatever reason.

d) In both Appendix B and C: replace "the format is (year-month-day)" with "the format is (YYYY-MM-DD)"...or otherwise specify what is meant by "year-month-day"elsewhere?

[Med] The format "(year-month-day)" was inherited from 8407. I'm neutral on this. FWIW, a PR of this is available at: https://github.com/netmod-wg/rfc8407bis/pull/64/files.

As chair again, the consensus is unclear.  It would great if Amanda could reply to Med's update, and if my comments above could be addressed.

Also, would anyone in the WG like to be the Document Shepherd for this draft?   Being a shepherd provides valuable insight to how the IETF process works.  It would be helpful to start the Shepherd Write-up process.


[0] https://datatracker.ietf.org/doc/minutes-120-netmod-202407222000/
[1] https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/
[2] https://mailarchive.ietf.org/arch/msg/netmod/G0ItnC5vaTXSAuh5XX-1p4mD7MA/
[3] https://mailarchive.ietf.org/arch/msg/netmod/Lto49pXDCpKdUdR-ISUrRFVWhBw/
[4] https://mailarchive.ietf.org/arch/msg/netmod/HC2ipQcCLN_QaGlDjhDvCz_P_OI/


Kent

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