On 05/06/2025 11:47, [email protected] wrote:
Hi Gorry,
Thank you 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/Gorry-review/draft-ietf-netmod-rfc8407bis.txt.
Please see inline for more context.
Cheers,
Med (as editor)
Thanks, and note that these are "Comments". I will provide a little
follow-up below to help clarify.
-----Message d'origine-----
De : Gorry Fairhurst via Datatracker<[email protected]>
Envoyé : jeudi 5 juin 2025 11:43
À : The IESG<[email protected]>
Cc :[email protected];[email protected];
[email protected];[email protected];[email protected];
[email protected]
Objet : Gorry Fairhurst's No Objection on draft-ietf-netmod-
rfc8407bis-27: (with COMMENT)
Gorry Fairhurst has entered the following ballot position for
draft-ietf-netmod-rfc8407bis-27: No Objection
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.)
-------------------------------------------------------------------
COMMENT:
-------------------------------------------------------------------
I think Best Current Practice documents are particularly valuable
and are best
when they are accessible to a variety of readers. Hence my various
comments
below to improve the document and clarify what is actually required
by
contributors.
I am balloting 'no objection', but I do have comments that I expect
to be
considered by the editors and responsible AD. Please especially
note comment 3
===
1. Thank you to Joe Touch for the transport review provided by the
WIT ART.
I also share the comment that this draft normatively refers to the
use of QUIC
[Med] I disagree with "normatively refers". This is listed as an example, Gorry.
CURRENT:
(e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000])
as a transport, but does reference (informatively) the work to
develop that
support. Please do add a reference to draft-ietf-netconf-over-quic.
[Med] We don't actually cite the mapping specs for SSH, TLS, etc.
We used to cite the mapping themselves in 8407, but we changed that to the
current approach in the draft. Kent already shared the reasoning as part of the
tsvart review.
GF: Agree, if already considered - this indeed seems consistent.
Please also review the other text included in that review and
update as needed.
===
2. In section 4.5:
I could not understand this as a requirement, please consider
rewriting this in
different words: /From
that perspective, it is RECOMMENDED to avoid defining
constraints on
state data that would hinder the detection by a management
system of
abnormal behaviors of a managed entity./
- If this is an RFC 2119 recommendation, what SHOULD be done?
- If this a SHOULD/RECOMMENDED please state when this requirement can be safely
relaxed.
[Med] This is recommendation on the usage. As indicated in the sentence, if one
don't follow the reco, it should expect that the detection of abnormal
behaviors will be complicated.
So if such varients are OK with the WG, I'm suggesting that your add a
sentence (somewhat like this) to explain why people ought to conform.
(i.e. briefly explain the result of not complying).
===
3. In section 4.9 (Namespace Assignments):
/ It is RECOMMENDED that only valid YANG modules be included in
documents, whether or not the modules are published yet./
- I think the text needs to explain what is needed to satisfy the
RFC 2119
recommendation.
[Med] This reco is inherited from RFC6087 and RFC8407.
Does this apply to Internet draft revisions?
[Med] Yes. This is covered by "whether or not the modules are published yet"
FWIW, these are defined in Section 2 as follows:
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.
unpublished: An unstable release of a module or submodule. For
example the "Internet-Draft" described in Section 2.2 of [RFC2026]
is considered an unstable publication that is a work in progress,
subject to change at any time.
would seem
really a hard requirement, or submitted documents, or documents
ready for
review.)
[Med] This specific reco helped to get good yang modules and decreased
validation errors. Tooling is important here. YANG validation is integrated in
the Datatracker with errors/warning displayed. Before requesting publication,
the writeup has this check:
GF: I saw the use in RFC8407. I don't understand the action. I was
hoping to see something likeYANG models cited in other documents or in
documents that are to be published SHOULD be validated against XXX.That
for me would be actionable.
7. If the document contains a YANG module, has the final version of the module
been checked with any of the [recommended validation tools][4] for syntax
and
formatting validation? If there are any resulting errors or warnings, what
is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as
specified
in [RFC 8342][5]?
- The current recommendation does not make me feel like I
know what to
do if the recommendation is not followed and what this refers to.
[Med] You will need to fix the errors :-)
GF: In short, I think this BCP can only dictate what happens when it
does not conform.
===
4. In section 4.2.3:
/It is RECOMMENDED to augment only the "/foo" hierarchy of the base
model./
[Med] This is inherited from 8407.
- Why does this use the keyword /RECOMMEND/ rather than the word
/SHOULD/ here.
[Med] hmmm. RFC2119 says:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
GF:My comment was, that I think makes it harder to read, and harder
compare the different requirements.
To me this mix of terms obscures the actual requirement: In the
previous and
next text in the para uses SHOULD - and to me these have the same
requirement
level!
===
5. Sorry,I was not sure what was actually intended by "may be", is
this (or
something similar) clearer: /Exceptions may be example modules,
IANA-maintained
modules, or modules contained in AD-sponsored documents. /
Exceptions include:
example modules, IANA-maintained modules, or modules contained in
AD-sponsored
documents. /
[Med] Agree. Changed to:
"Exceptions include (but not limited):..."
GF: Thanks.
===
6.
I could not work out what to take away from the text below in
Section 4.30.1:
/Also, some YANG modules include parameters and values directly in
a
module that is not maintained by IANA while these are populated in
an
IANA registry. Such a design is suboptimal as it creates another
source of information that may deviate from the IANA registry as
new
values are assigned or some values are deprecated.
/
- I think this could be editorial: It would be useful to be clear
if this an
example of has happened, or what is needed, or it made some other
statement.
[Med] Changed to:
NEW:
A design, in which a YANG module includes parameters and values directly in
a
module that is not maintained by IANA while these are populated in an
IANA registry, is suboptimal. Such a design creates another
source of information that may deviate from the IANA registry as new
values are assigned or some values are deprecated.
GF - better, - I'd super-prefer better words than "is suboptimal",
perhaps - could you say "could lead to potential ambiguity" or something?
===
7.
What does "encourage" mean in the next para, this is also unclear
to me:
/For the sake of consistency and ability to support new values
while
maintaining IANA registries as the unique authoritative source of
information, this document encourages the use of IANA-maintained
modules as the single source of information./
... but then I see Sect 4.30.2 provides guidelines, is
/encourages/therefore
provides guidance/ ... or maybe I still misunderstood?
[Med] Changed to "recommends".
GF: OK:-)
===
8. In Sect 4.30:
/It is
RECOMMENDED that the reasoning for the design choice is
documented in
the companion specification that registers an IANA-maintained
module./
- I think this could simply be required (MUST)?
[Med] Works for me.
===
9.
/It is RECOMMENDED to include the URL from where to retrieve the
recent version of the module. /
- I suggest you do not use the keyword /RECOMMEND/ here and replace
the word by
/SHOULD/. To me this mix of terms obscures the actual requirement.
SHOULD is
used in other parts of the same section!
[Med] Idem as above.
===
10.
/Specifically, if the name begins with a number, it is
RECOMMENDED to spell out the number when used as an
identifier.
IANA should be provided with instructions to perform such
task./
- This confused me (sorry).
- Specifically please explain what /spell out/ means in this
context.
[Med] it literally means spelling it. Please see the example right after with
3des-cbc/etc. Amanda (IANA) clarified this in a separate message.
GF - Ah, maybe this might mean "written in full" rather than the
spelling?Or say not abbreviated, if that's better? IANA may have a good
suggestion if help is needed.
- I was very puzzled why this BCP does not require a document to
provide IANA
with the instructions to perform their task.
[Med] This is what this section about. I may miss your point.
GF - I was thrown by the above line of thinking, and if you fix the
above, then this then becomes clear.
... If there is
sometimes a need
for IANA to ask for this separately, could this be explained. AT
first sight,
it seems like a lot of extra flexibility for little benefit.
===
11.
/when creating a new "identity" statement name or a new "enum"
statement, it is RECOMMENDED to mirror the name (if
present) as
recorded in the IANA registry./
- Please explain in the text why? And I am a little unsure what
"mirror" means
in this context, please use a different word. - Why is this not a
RFC 2119
"SHOULD:, as used in other parts of the same section?
[Med] Hmm, but RECOMMENDED is a 2119 normative word and is equivalent to SHOULD.
GF: - Does "Mirror" mean reflect, or does it mean use the same name, or
does it mean something else?
GF: I am just noting that in the same sections the document sometimes
says "SHOULD" and sometimes says "RECOMMENDED" both for guidance and for
protocol actions. To me that reduces clarity, but this is only a comment.
===
12.
In section 4.30.3.1:
I read this text:
/ When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing revision statements. The "revision" statement MUST contain
both "description" and "reference" substatements as follows./
- Maybe I do not understand, but this seems to say you need (but
are not
required to provide a unique revision date in front of the existing
revision
statements, is that correct? (in this case I'd really like to see
/MUST? or
change to /needs/ ... - I also think this would be better as a
separate
paragraph to avoid confusion with the MUST that follows.
[Med] Changed to "needs"
GF: Thanks.
===
13.
I am not sure if there is intentional variation in the requirements
for t
"description" sub statement in the various template in 4.30.3.
Could the common
requirements, if any, use identical text?
[Med] I checked these two but are identical to me. Can you please indicate
which specific part are you referring to?
GF: My mistake, there were multiple lines of text about the description
and I managed to mis-match these. Sorry.
===
Finally, thank you for takin on the task of updating this Best
Current Practice!
[Med] Thank you for the careful review.
GF: I am no YANG expert, and do appreciate the work,
Gorry
____________________________________________________________________________________________________________
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]
To unsubscribe send an email to [email protected]
