The note below is a great example of the context lost by not including even an informational citation to the use of QUIC as a transport.
Not everyone reading this BCP in the future will scour the WG email archives to explain what’s in the doc. Joe > On May 16, 2025, at 7:24 AM, [email protected] wrote: > > 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] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > Envoyé : vendredi 16 mai 2025 16:11 > À : BOUCADAIR Mohamed INNOV/NET <[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]> > 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]
