Re-, This is not about dismissing your comments on DTLS/QUIC, but to provide you some background that may not be visible in the text itself.
For example, if you follow the link I provided below, you can see that as, an individual, I was initially with your opinion to not cite QUIC: == > [Med] I understand the intent is to cite the transport themselves, but the > text refers to MTI of these “YANG-based management protocols”. I don’t think > we can make any claim about QUIC here as we don’t have an authoritative spec > for that. If we want to cite QUIC, some further tweaking to the text is > needed, IMO. = I changed my mind after discussion with Kent that RESTCONF does not require a specific http version. I hoped you check that link to see if the arguments made there are convincing for you or not. Thank you. Cheers, Med (as editor) De : [email protected] <[email protected]> Envoyé : vendredi 16 mai 2025 16:11 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: draft-ietf-netmod-rfc8407bis-25 ietf last call Tsvart review 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<http://www.strayalpha.com> On May 16, 2025, at 1:26 AM, [email protected]<mailto:[email protected]> wrote: Hi Joe, Thank you for the review. Please see inline. Cheers, Med (as editor) -----Message d'origine----- De : Joseph Touch via Datatracker <[email protected]<mailto:[email protected]>> Envoyé : vendredi 16 mai 2025 07:52 À : [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> 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. ____________________________________________________________________________________________________________ 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]
