Re: SSH operations modelled in YANG

[tom petch <ietfc%btconnect.com@localhost>]

From: Sam Hartman <hartmans-ietf%mit.edu@localhost>
Sent: 25 January 2023 17:08

>>>>> "tom" == tom petch <ietfc%btconnect.com@localhost> writes:

    tom> I see this approach as fatally flawed since IANA-maintained
    tom> modules and regular ones have a different trajectory and

I'm skeptical for an entirely different reason.
Is anyone going to manage ssh using netconf anyway, and for example is
the way you think about managing ssh for a router or switch even vaguely
similar to how you would manage it for a cloud server?

Put another way, what's the danger that someone might try and implement
this?
If that's relatively low, the level of review required is low:-)

<tp>
Yes and no.
If published as an RFC, then it has a certain standing so that the list of algorithms, which includes their status, as deduced from the SSH IANA  registries, might be taken as an accurate and reliable source of information so I think that it matters that what is published is accurate.  This point of status came up in the Shepherd review, as to where the information came from, and there was a response from the author, but I am conscious that the status field in a YANG module does not use the same language as the (SSH) IANA registries which might be a source of mis-interpretation.  One aspect that I could not resolve relates to the GSSAPI entries for KEX where the SSH IANA registries end with an asterisk  which in the YANG Identity in most, but not all cases, have been expanded to 13 separate entries with an OID as  suffix.  I do not know where IANA are expected to get those OID from as and when a new KEX entry is created.

As to the level of implementation, who knows?  After so many years, I might infer that the demand is low but then the YANG modules co-author has the e-mail address of a major device manufacturer which suggests a potential implemenation.

Tom Petch