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) - 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 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
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
