Re: [netconf] logjam was re: YANG prefix Re: WG adoption poll for draft-wwlh-netconf-list-pagination

["Scharf, Michael" <[e-mail]>]

Tom, all,

Basically, draft-ietf-netconf-tcp-client-server serves two different purposes, apart from basic client/server addressing: It models TCP keep-alives (as a TCP feature that matters in particular for NETCONF), and it models proxy server configuration. Only the latter depends on crypto-types. 

Theoretically, it might be possible to separate these into two documents, and last call the former part - with simpler dependencies - first. If there really no progress, the WG could consider such a step to reduce the dependencies for a subset of documents, and finish the simpler parts.

Yet, I am not sure whether such a radical step is really required at this stage. I'd suggest trying to finish the set of documents with their current scope.

Michael



> -----Original Message-----
> From: Kent Watsen <[e-mail]>
> Sent: Thursday, April 28, 2022 3:50 PM
> To: tom petch <[e-mail]>
> Cc: [e-mail]; Scharf, Michael <[e-mail]>
> Subject: Re: [netconf] logjam was re: YANG prefix Re: WG adoption poll for
> draft-wwlh-netconf-list-pagination
> 
> Tom,
> 
> The set of drafts move forward together.   Every time another WG
> complains, the response is the same, can you help?  Crickets every time!
> 
> The current biggest blocker is ensuring the IANA-defined module sections in
> the ssh-client-server and tls-client-server drafts are ready, given draft-
> boucadair-netmod-iana-registries...not that we have to adhere to it, but it
> contains suggestions to reduce/avoid blowback from IANA.  Can you take a
> look?
> 
> BTW, did you look at the update made to the tls-client-server draft to
> address the 1.3 issue you raised?   It was a massive effort that so far has yet
> to even be acknowledged...
> 
> PS: regarding the Subject line, note the that the "list-pagination" draft
> adoption has not proceeded.  As author, I'm happy for the chairs to block-
> adoptions until this suite of drafts goes through.
> 
> Kent
> 
> 
> 
> > On Apr 28, 2022, at 6:49 AM, tom petch <[e-mail]> wrote:
> >
> > The resolution to a logjam, which is how I see the netconf I-D, is often just
> finding one log and taking it out and then the river runs freely.
> >
> > Looking at Normative dependencies, crypto-types is everywhere.  I had
> thought to propose working on tcp-client-server as something that could
> soon be in the RFC Editor's queue, but no, it too depends on crypto-types.
> >
> > crypto-types is everything cryptography plus YANG.  At the best times, you
> need a post-doc mathematician to review cryptography, here I doubt if
> anyone in the IETF, perhaps anyone in the world, has the technical skills to
> review this in its entirety.  I then see this taking a year or two or more to wind
> its way through the system so it may be the key log, but it may not the best
> place to start.
> >
> > Thinking laterally, the barrier to tcp-client-server is the use, from crypto-
> types, of
> > choice password type
> > case plaintext
> > case encrypted
> > which then requires augments into the encrypted option (which tcp-client-
> server does not do. so it looks as if it is fairly useless).  Whether it is or not,
> ditch it from tcp-client server, make the I-D do its own thing for password
> type and then there is an I-D which we could hope to move  forward; and
> having moved one, we might have the energy to move another.
> >
> > Tom Petch