Re-,
Please see inline.
Cheers,
Med
De : Kent Watsen <kent+i...@watsen.net>
Envoyé : mercredi 4 septembre 2024 15:29
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Amanda Baber
<amanda.ba...@iana.org>
Cc : netmod@ietf.org; Amanda Baber via RT <iana-issues-comm...@iana.org>
Objet : Re: [netmod] Regarding draft-ietf-netmod-rfc8407bis
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,
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> 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 <kent+i...@watsen.net<mailto:kent+i...@watsen.net>>
Envoyé : dimanche 11 août 2024 20:48
À : netmod@ietf.org<mailto:netmod@ietf.org>
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-\
class-rr-t...@2023-11-27.yang<mailto:class-rr-t...@2023-11-27.yang>"
}
#### END SNIPPET ####
OLD:
"https://www.iana.org/assignments/yang-parameters/iana-dns-\
class-rr-t...@2023-11-27.yang<mailto:class-rr-t...@2023-11-27.yang>”
NEW: (removing the whitespace on the 2nd line)
"https://www.iana.org/assignments/yang-parameters/iana-dns-\
class-rr-t...@2023-11-27.yang<mailto:class-rr-t...@2023-11-27.yang>"
There whitespace, added for formatting reasons
[Med] Aah, I see. The whitespaces were added by markdown as I’m using
“include-fold” in the .md file. Anyway, with the PR below, 8792 folding is not
used for these examples anymore.
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.
[Med] Thanks.
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.
[Med] Thanks for checking.
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?
[Med] IETF modules have already an RFC number to be listed there for each
published revision (which is the authoritative source to retrieve a module
version). I think that the current template is fine.
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.
[Med] ACK.
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 -- netmod@ietf.org<mailto:netmod@ietf.org>
To unsubscribe send an email to
netmod-le...@ietf.org<mailto:netmod-le...@ietf.org>
____________________________________________________________________________________________________________
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 -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
