Re-,
Thanks.
For the last EV2, we do currently have:
Be sure citations for all imported modules are present somewhere
in the document text (outside the YANG module).
Cheers,
Med
De : Eric Vyncke (evyncke) <[email protected]>
Envoyé : mardi 3 juin 2025 15:12
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; The IESG
<[email protected]>
Cc : [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Objet : Re: Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-25:
(with COMMENT)
Re-salut Med,
Thanks for the YIN reference, last comment below EV2> (can of course be ignored)
Regards
-éric
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Date: Tuesday, 3 June 2025 at 13:51
To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>, The
IESG <[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-25:
(with COMMENT)
Salut Éric,
Thanks for the follow-up. Made these new changes:
https://github.com/netmod-wg/rfc8407bis/pull/82/commits/bba5cd25b810d573157a05313ff0d7085ea474ee
Please see inline for some few points.
Cheers,
Med
PS: The same link below can be used to see the rendered diff.
De : Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>
Envoyé : mardi 3 juin 2025 11:20
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>; The IESG
<[email protected]<mailto:[email protected]>>
Cc :
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : Re: Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-25:
(with COMMENT)
Salut Med,
Thanks for the quick reply. Some comments of mine in-line prefixed with EV>
Regards
-éric
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Date: Monday, 2 June 2025 at 17:33
To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>, The
IESG <[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-25:
(with COMMENT)
Hi Éric,
Thank you for the review. The changes made ** so far ** to address your review
can be seen 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/boucadair-patch-2/draft-ietf-netmod-rfc8407bis.txt.
Please see inline.
Cheers,
Med (as editor)
> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <[email protected]<mailto:[email protected]>>
> Envoyé : lundi 2 juin 2025 14:24
> À : The IESG <[email protected]<mailto:[email protected]>>
> Cc :
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>
> Objet : Éric Vyncke's No Objection on draft-ietf-netmod-rfc8407bis-
> 25: (with COMMENT)
>
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netmod-rfc8407bis-25: 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:
> -------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-netmod-rfc8407bis-25
> CC @evyncke
>
> Thank you for the work put into this document, I share Gunter's
> comment on the
> usefulness and easy-to-read quality of this I-D.
[Med] Thanks.
>
> I have reviewed the whole draft rather than the diffs with RFC
> 8407.
>
> Please find below some non-blocking COMMENT points/nits (replies
> would be
> appreciated even if only for my own education).
>
> Special thanks to Qiufang Ma for the shepherd's detailed write-up
> including the
> WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS (non-blocking)
>
> ### Title vs. abstract
>
> The title is about data models while the abstract is about modules.
> Let's avoid
> spreading the confusion in a BCP. As the document is more about
> data model,
> let's use this term in title/abstract.
>
[Med] The current use is OK (and was inherited from 8407), but I see your point
especially that clarifying the use of Data model vs YANG module (Section 2.5).
I need to think about this further as we need to not break the mention of
IANA-maintained modules, for example.
> ### Section 1
>
> `Only constructs that all servers are required to support can be
> used in IETF
> YANG modules` , it is really unclear to me how this can be
> verified.
>
[Med] This is inherited from RFC 8407, which itself was inherited from RFC6087.
I always linked this sentence to the next one which motivates the need for
usage guidance in addition to the conformance per base YANG specs.
EV> I still do not see the link with the next paragraph (there is no next
sentence) ;-)
[Med] I meant the one right after in the para that follows:
==
compliant server is not required to support. Only constructs that
all servers are required to support can be used in IETF YANG modules.
This document defines usage guidelines related to the NETCONF
==
> ### Section 2
>
> s/and *which* is not maintained by IANA/and *that* is not
> maintained by IANA/ ?
[Med] OK
>
> ### Section 2.5
>
> I would go further than `Likewise, "YANG data module" should be
> avoided.`and
> use "Likewise, "YANG data module" is incorrect, has no meaning, and
> MUST be
> avoided."
>
[Med] OK, went with "Likewise, "YANG data module" has no meaning and must be
avoided."
> ### Section 3
>
> s/The following sections MUST be present in an I-D containing a
> YANG module/The
> following sections MUST be present in an I-D *or RFC* containing a
> YANG module/
[Med] OK
>
> ### Section 3.2
>
> Any chance to use a more recent date than 2016 ? Or is it to borrow
> as much as
> possible from RFC 8407 ?
[Med] This is inherited from 8407.
EV> looking strange but this is editorial and my comment can be ignored
[Med] Thanks.
>
> ### Section 3.4
>
> For large trees, I like to have a pruned version in the body part
> and not in
> the appendix, perhaps with subtrees.
[Med] Thanks for sharing your preference. I think that is covered by the spirit
of rfc8340#section-3.3 and the use of subtrees.
EV> our preferences differ and that's OK
[Med] Thanks.
>
> ### Section 3.5
>
> Is this section about the data models or modules ? Modules are
> mainly for
> syntax while the data models are for semantics, i.e., I think that
> relationships are between data models and not modules.
[Med] You are right that the first para can be about data models. However,
things such as:
If the module or modules defined by the specification imports
definitions from other modules (except for those defined in [RFC7950]
or [RFC6991])
are definitely about modules.
EV> correct
Made changes when I think is justified.
EV> thanks
>
> s/the Introduction section *should* mention this fact/the
> Introduction section
> *SHOULD* mention this fact/ if only to be consistent with the use
> of uppercase
> BCP14 terms in this section.
[Med] Works for me.
>
> The long line example seems to be for an instance of a module,
> should it rather
> be on the module itself ?
>
[Med] No. We do encourage against that for modules:
Built-in YANG features (e.g., breaking line, "+") SHOULD be used to
fit a module into the line limits. Exceptionally, RFC8792-folding of
YANG modules MAY be used if and only if built-in YANG features are
not sufficient. A similar approach (e.g., use "--tree-line-length
69" or split a tree into subtrees) SHOULD be followed for tree
diagrams.
EV> thanks for the clarification
> ### Section 3.6
>
> First time ever that I read about "YIN syntax", please provide a
> normative
> reference.
[Med] This inherited from 8407 and even rfc6087. This is used in base YANG spec
6020/7950.
EV> I learned something today, really suggest adding a reference to section 11
of RFC 6020 (if YIN was or is still used)
[Med] Added pointer to S13 of 7950
>
> ### Section 3.8
>
> I fail to imagine a non-normative YANG module in a RFC; therefore,
> is
> 'normative' required in `Each normative YANG module`.
[Med] Yes, as a document may include only example YANG modules.
EV> ack
>
> ### Section 3.9
>
> Suggest adding some template text to be used before the YANG module
> itself to
> add a normative reference (to avoid the 'unused reference' by id-
> nits).
>
[Med] Do you mean to make sure that references cited in the module are called
in the narrative part?
EV> correct
[Med] The template won't be helpful here as authors have to systematically
include a citation in the body text for every reference. What we actually need
is tooling to help detect those.
EV2> or a reminder to do so (perhaps already in the text though)
____________________________________________________________________________________________________________
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]
