Med, As a BCP, the onus is on the doc to be complete, not to cite transports that are NOT yet standard but provide no pointer to their impending standardization.
As a BCP, the onus is on the doc to be clear to users about its focus. BCPs don’t differentiate in documentation guidance for I-Ds vs RFCs unless that content changes between the two. None of this is about “deals” or what the WG has previously decided - at this time, you’ve been given transport feedback. If you or the WG intends to be so dismissive of it, then please feel free to find a way to avoid wasting the time of transport (and perhaps other) area reviewers. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On May 16, 2025, at 1:26 AM, mohamed.boucad...@orange.com wrote: > > Hi Joe, > > Thank you for the review. > > Please see inline. > > Cheers, > Med (as editor) > >> -----Message d'origine----- >> De : Joseph Touch via Datatracker <nore...@ietf.org> >> Envoyé : vendredi 16 mai 2025 07:52 >> À : tsv-...@ietf.org >> Cc : draft-ietf-netmod-rfc8407bis....@ietf.org; last-c...@ietf.org; >> netmod@ietf.org >> 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-...@ietf.org 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.
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
