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

[Kent Watsen <[e-mail]>]

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