Hi Amanda,
Please find one comment for you below.
Hi Med,
Please see below for replies to other comments.
Kent
> On Sep 4, 2024, at 8:12 AM, [email protected] wrote:
>
> Hi Kent, all,
> (apologies for the delay to follow-up as I was out of office)
>
> Please see inline.
>
> Cheers,
> Med
>
> De : Kent Watsen <[email protected] <mailto:[email protected]>>
> Envoyé : dimanche 11 août 2024 20:48
> À : [email protected] <mailto:[email protected]>
> 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.
Amanda, please see [4] at bottom for context.
> 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.
Following is just one example, there are others instances elsewhere.
The following snippet appears in
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-14#section-4.30.3:
#### START SNIPPET ####
=============== NOTE: '\' line wrapping per RFC 8792 ================
revision 2023-11-27 {
description
"Registered RR Type RESINFO 261.";
reference
"https://www.iana.org/assignments/yang-parameters/iana-dns-\
[email protected]"
}
#### END SNIPPET ####
OLD:
"https://www.iana.org/assignments/yang-parameters/iana-dns-\
[email protected]”
NEW: (removing the whitespace on the 2nd line)
"https://www.iana.org/assignments/yang-parameters/iana-dns-\
[email protected]"
There whitespace, added for formatting reasons
> 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
Looks right.
> 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?
Strangely, I don’t see a diff now either - never mind.
> 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.
But how is it different for regular (not IANA-maintained) modules? Should
these module's “revision” statements point to their published locations as
well? Is this another thing to add to the template?
> 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.
Looks right - thanks.
Kent // contributor
> 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.
> _______________________________________________
> netmod mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
