Hi Med, Thanks for making the updates. One edit I would make is the link to the wiki page where the security considerations reside. It is:
https://wiki.ietf.org/en/group/ops/yang-security-guidelines Once it is finalized here, I will ask the secretariat to update the template at that link. Thanks. > On Sep 18, 2024, at 7:59 AM, [email protected] wrote: > > Hi Kent, > > Thanks for the follow-up. > > I went with many of your proposals. For “have to use/have mandatory/MUST > use”, I went for “have to use” for now. The use of normative language may be > questionable as this is more about use, less of an interop matter. > > A full diff to track changes can be seen here: > 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/sec-comment-from-Kent/draft-ietf-netmod-rfc8407bis.txt > > <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/sec-comment-from-Kent/draft-ietf-netmod-rfc8407bis.txt>. > > Let me know if there are other occurrences that I missed where we need to > follow “modeled after” approach. Thank you. > > Cheers, > Med > > De : Kent Watsen <[email protected]> > Envoyé : jeudi 12 septembre 2024 18:02 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : Mahesh Jethanandani <[email protected]>; [email protected] > Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 > <draft-ietf-netconf-ssh-client-server-40> for your review > > > Hi Med, > > Sorry this is taking so long, but we’re getting there! ;) > > > The reference of QUIC is to the protocol, RFC 9000, not NETCONF over QUIC, an > I-D as you note; just as the reference is to SSH protocol, RFC 4252, not > NETCONF over SSH, RFC 6242. > [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. > > RESTCONF already supports QUIC. > [Med] Yes, RESTCONF does not require a specific version of HTTP but still > TLS is what is indicated as MTI for RC per rfc8040#section-2.1. > > I was thinking about this nuance too. QUIC uses TLS, so I think > rfc8040#section-2.1 is still satisfied. That said, the NETCONF WG will be > working on a RESTCONF-next version, for which it would be easy to add some > clarifying text - agreed? I just added this > (https://github.com/netconf-wg/restconf-next/issues/19 > <https://github.com/netconf-wg/restconf-next/issues/19>) - good for now? > > No transport-binding document will be written to enable QUIC for RC. > [Med] Isn’t rfc9114 that is applicable for RC, rather than 9000? > > RFC 9112: HTTP/1.1 (i.e., TCP-or-TLS over TCP) > RFC 9113: HTTP/2 (i.e., TLS over TCP) > RFC 9114: HTTP/3 (i.e., QUIC, i.e., TLS over UDP) > > If we ref 9114, then we’d have to ref the others also, which isn’t what we > want. This is why 9000 is refed - makes sense? > > > > [mj] Why do you say that? The statement says the protocols have > mandatory-to-implement … > [Med] Having an MTI does not mean that MTI is actually used/enabled. > > Touché :) > > One could process “implement” to be at the runtime-level or code-level. I > meant the former, and see that you’re interpreting the later, which is fair. > > First, I wonder if there isn’t a formal definition for MTI that disambiguates > the two cases. Looking, I see MTI used in the context of algorithms, which > lends itself to the “code level” interpretation. Fine. > > [Med] Thanks > > Then either s/implement/use/ or s/-to-implement// ? > [Med] « have to use » would be better, IMO. > > Hmmm, so this? > > These protocols have to use a secure transport layer (e.g., SSH [RFC4252], > TLS [RFC8446], QUIC [RFC9000]) and have to use mutual authentication. > > vs > > These protocols have mandatory to use secure transport layers (e.g., SSH > [RFC4252], TLS [RFC8446], QUIC [RFC9000]) and mandatory to use mutual > authentication. > > Vs > > These protocols have mandatory secure transport layers (e.g., SSH [RFC4252], > TLS [RFC8446], QUIC [RFC9000]) and mandatory mutual authentication. > > > Of the three, I like the last one most, but like the first one (yours) next. > I like the last one since the statement seems stronger. One idea might be > this: > > > These protocols MUST use a secure transport layer (e.g., SSH [RFC4252], TLS > [RFC8446], QUIC [RFC9000]) and MUST use mutual authentication. > > > But I don’t think RFC2119 language should be in the Security Considerations > section. > > Thoughts? > > > > This section is modeled after the template described in Section 3.7 of > [RFCAAAA]. > > This first line wasn’t picked up. Note that the word “modeled” gives an > authors a little flexibility, as is needed sometimes. > > To point, the RFC Editor takes the words literally and raise issues when > things aren’t exactly same…until this word was changed. > > Honestly, the same should be done to all of the templates defined in the > document. > > [Med] This is fair. Please see: > https://github.com/netmod-wg/rfc8407bis/commit/972970ce16c050d8420f50f07637f4e00770cdd5 > > <https://github.com/netmod-wg/rfc8407bis/commit/972970ce16c050d8420f50f07637f4e00770cdd5> > > Thanks, both for accommodating and the link. > > Looking at the PR, it is only for this template. Do you not agree that > “modeled after” is good for all of the templates? > > > > > The "<module-name>" YANG module defines a data model that is designed to be > accessed via YANG- > > IIRC, you use different words than “data model”. I’m trying to use > sufficiently ambiguous language that includes also modules that only define > identities, or only enumerations, or only typedefs, etc. > > I was going to write “data model, or parts of data models,” but it seemed > unnecessarily wordy and obscures the main point of the sentence. > > I don’t deny that my text could be improved, but your take didn’t seem right > either. > > Can you reply to this? > > So we have: > > The "<module-name>" YANG module defines a data model that is designed to be > accessed via YANG-based management protocols, > > vs. > > The "<module-name>" YANG module defines a schema for data that is designed to > be accessed via YANG-based management protocols, > > > > > FWIW, I only know about your changes to my text because I received GitHub > notifications. Was a link for the PR sent? In any case, it would’ve been > nice if you’d stated that changes had been made, rather than me having to > discover them on my own. > > [Med] I didn’t share the PR because that wasn’t ready yet and I was waiting > for the discussion to converge to have something I’m more happy with it. Now > that you are on it, feel free to propose your edits directly there :-) Thanks. > > I’m unsure what you mean, but I don’t want to submit PRs and, honestly, I > don’t want to look at PRs. I want the full conversation to be on the list. > > > Kent // contributor > > > ____________________________________________________________________________________________________________ > 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]
