[netmod] Re: AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review

[Kent Watsen <[e-mail]>]

Hi Med,

On Sep 12, 2024, at 3:14 AM, [e-mail] wrote:



Hi Mahesh,

 

Please see inline.

 

Cheers,

Med

 

De : Mahesh Jethanandani <[e-mail]>
Envoyé : jeudi 12 septembre 2024 00:49
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Kent Watsen <[e-mail]>; [e-mail]
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review

 

Hi Med,

 

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. 

No transport-binding document will be written to enable QUIC for RC. 

On Sep 11, 2024, at 2:57 AM, [e-mail] wrote:

 

Hi Kent,

 

I like the NEWER better compared to the initial NEW you shared, however I think some more tweaking is needed.

 

I understand why you cited QUIC as well, but we don’t have formally a spec for mapping with QUIC (I know there is an individual I-D). We actually don’t need to be exhaustive here and cite every transport option.

 

The proposed NEWER changes a little bit the approach from the **recommending the use of MTI** to simply listing available MTI.  

 

[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. 

Then either s/implement/use/  or  s/-to-implement// ? 

Separately, I see your update is different in a couple ways.  Please see below for details…

 

Cheers,

Med

 

De : Kent Watsen <[e-mail]> 
Envoyé : mercredi 11 septembre 2024 00:10
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]
Objet : Re: [netmod] AD - Re: AUTH48: RFC-to-be 9644 <draft-ietf-netconf-ssh-client-server-40> for your review

 

Hi Med,

 

NEWER (this is what I’m asking RFC Editor to do for the suite of client-server drafts)

 

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.  

 

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 unnecessary 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. 

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. 

Kent // contributor