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

[tom petch <[e-mail]>]

From: Scharf, Michael <[e-mail]>
Sent: 29 April 2022 10:01

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.

<tp>

Well, we have been doing that for a number of years and the logjam persists so radical action is called for, not two documents IMO but a revision of tcp.

The keystone(?) of the logjam is cryptotypes and I am pessimistic about that progressing any time soon but tcp could if it were not dependent on cryptotypes so my logic is to take the dependency out, have tcp provide its own plaintext/encrypted case (if they are really needed) and remove the dependency on algorithms.  Security used to be easy - 'the default ciphersuite is..' and it would sail through the IESG.  Now we have cryptotypes and I cannot see when it will reach the IESG so simplify tcp; having an endless and ever changing list of algorithms may be a nice-to-have but not when it halts progress.

In passing there is a lot wrong with tcp from the admin point of view so let me know if and when you plan a revision and I will provide comments.

Tom Petch
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