Re: [netconf] logjam was re: YANG prefix

[tom petch <[e-mail]>]

From: Kent Watsen <[e-mail]>
Sent: 28 April 2022 14:50

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

<tp>
Thank you for the effort but I got sidetracked.  My take is the crypto-types is the problem and so that is the only I-D worth working on.  That said, I see it as complex and not progressing any time soon so  I then looked at tcp, which used to be independent of cryptotypes but is no more, joining the ranks of cryptotypes dependent.  My logic then says that this could progress if the dependency were removed which I think it can and so should be.  Yes the resulting logjam would not be quite as perfect but the benefits of even a little progress outweigh that IMO.

Moving everything forward together is logical and has benefits but the consequences I see are a lack of progress which leads me to the conclusion that cryptotypes is (almost) the only I-D worth reviewing, adding in tcp where I see the prospect of progress.

Tom Petch

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