Hi Joe,
Thank you for the review.
Please see inline.
Cheers,
Med (as editor)
-----Message d'origine-----
De : Joseph Touch via Datatracker <noreply@xxxxxxxx>
Envoyé : vendredi 16 mai 2025 07:52
À : tsv-art@xxxxxxxx
Cc : draft-ietf-netmod-rfc8407bis.all@xxxxxxxx; last-call@xxxxxxxx;
netmod@xxxxxxxx
Objet : draft-ietf-netmod-rfc8407bis-25 ietf last call Tsvart
review
Document: draft-ietf-netmod-rfc8407bis
Title: Guidelines for Authors and Reviewers of Documents Containing
YANG Data Models Reviewer: Joseph Touch Review result: Ready with
Nits
This document has been reviewed as part of the transport area
review team's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors,
but are copied to the document's authors and WG to allow them to
address any issues raised and also to the IETF discussion list for
information.
When done at the time of IETF Last Call, the authors should
consider this review as part of the last-call comments they
receive. Please always CC tsv-art@xxxxxxxx if you reply to or
forward this review.
There is very little in this document of specific relation to
transport protocols, with the exception of the discussion of
security in terms of SSH, TLS, and QUIC. That list should be
augmented to include DTLS.
[Med] That list is about examples and does not intend to be exhaustive. Also, except a work in progress (e.g., draft-ietf-netconf-udp-notif), we don’t have the DTLS mapping "frozen" in an RFC. The good news is that this template can be updated outside of an RFC and DTLS can be added there if needed.
SSH is more of a security tunnel than a
secure transport layer.
[Med] We are adhering to RFC6242.
In that context, NETCONF is defined over SSH and TLS (RFC6241), but
not QUIC.
RESTCONF is exclusively defined over HTTP, TCP, and TLS (RFC8200),
but not QUIC
-- at least not yet. draft-ietf-netconf-over-quic-02 proposes it,
but it has not yet been published. Keeping QUIC here seems like it
would require a reference to that draft.
[Med] The WG discussed this and the conclusion is that only a reference to the base QUIC is needed. See for example: https://mailarchive.ietf.org/arch/msg/netmod/KJoBZCXsf-2YE2r2yw_WmcVrP6I/.
Some other observations, not transport related:
- This doc should help address the (IMO) oversight in RFC 7950 not
obsoleting RFC 6020. RFC 7960 clearly indicates (Sec 1.1) that it
addresses ambiguities and defects in 6020. There should not be a
reason to continue to encourage both
1.0 and 1.1 YANG specifications equally in this document to
perpetuate that confusion.
[Med] I know this may be confusing but this was not an oversight but a design choice. See for example the clarification provided recently by Rob at: https://mailarchive.ietf.org/arch/msg/netmod/MZS83OaCajdnydUJu5q5O1ZbgE0/
- This document should more clearly
state that it is addressing how to create RFCs describing YANG
models; much of the advice is not relevant if the resulting
document is not an RFC (or rfc-to-be as an I-D).
[Med] The guidance is also used outside the IETF. For example, a reason why we still include the security template in the doc and not in the wiki is that the IETF Trust asked for this as this was used by others; see draft-moriarty-yangsecuritytext.
- To the previous
point, I recommend this being clarified as” Guidelines for Authors
and Reviewers of RFCs Containing YANG Data Models”. All references
to I-Ds or the generic “document” throughput should be replaced
with “RFC”.
[Med] I don't think a change is needed here for the reason mentioned in the previous item, but also because we want this guidance to be used early in the process not only at the last stage in RFC production process.
- All instructions specific to writing RFCs or IDs
already contained elsewhere, such as including boilerplate,
following line length limits, etc., should be removed; those
already appear elsewhere. That includes the beginning of Sec 3 and
all of 3.1 and 3.3. 3.7 should focus on the way in which Security
considerations are written for YANG modules, not as much on the
fact that a security consideration section is needed (it is for all
RFCs, again, as established elsewhere). None of these sections
should restate the fact that the section is required by RFC rules.
[Med] This change was not part of the deal for the update this time. This can be considered for future bis work.
- Some of the more obscure rules here should have explanations –
e.g., limiting identifiers in published modules to 64 chars or less
per, e.g.,
RFC7950 Sec 6.2 establishing 64 as MUST be supported and longer as
optionally supported.
[Med] That specific one is not introduced by this bis and is inherited from 8407 and even RFC6087:
Identifiers for all YANG identifiers in published modules MUST be
between 1 and 64 characters in length. These include any construct
specified as an 'identifier-arg-str' token in the ABNF in Section 12
of [RFC6020].
This is compliant with the intended use of the guidance:
The guidelines in this
section are intended to supplement the YANG specification [RFC7950],
which is intended to define a minimum set of conformance
requirements.
On a final note, I’ll ask this but – to be clear – I’m not positive
I’ll get the terminology correct. I didn’t notice a discussion on
the importance of using leafrefs rather than copies of the same
leaf type, e.g., where instances of the former must refer to valid
values of the latter. That includes the importance of using
relative paths in leafrefs, to ensure a module instance can be
instantiated in another module at an arbitrary level of nesting.
[Med] Not sure to get the exact issue, but we do have already this reco:
mirror: create new objects in a new module or the original module,
except use a new naming scheme and data location. The naming can
be coupled in different ways. Tight coupling is achieved with a
"leafref" data type, with the "require-instance" substatement set
to "true". This method SHOULD be used.
And the bunch of xpath recos (+those already in the base specs).
____________________________________________________________________________________________________________
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.
