Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Shepherd writeup
draft-ietf-netconf-ssh-client-server

Shepherd review of draft-ietf-netconf-ssh-client-server-30.

Review done 2022-10-03

Thank you for your service as a document shepherd. Among the
responsibilities is answering the questions in this write-up to give
helpful context to Last Call and Internet Engineering Steering Group
(IESG [1]) reviewers, and your diligence in completing it is
appreciated. The full role of the shepherd is further described in
RFC 4858 [2]. You will need the cooperation of the authors and editors to
complete these checks.

Note that some numbered items contain multiple related questions; please
be sure to answer all of them.

Document History
----------------

1. Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

Shepherd:

The conception of the document was six years ago, which greatly exceeds
the document shepherds IETF involvement; making it difficult to analyze
and review the full picture.

Reviewing the discussions indicates that the most active NETCONF WG list
participants have discussed the document extensively. Furthermore, the
full set of related drafts have been discussed to the same extent by a
superset including this core group.

The last developments indicates that the WG consensus have been reached.

Note that the WGLC for this document was done in 2017 for revision -03.
Direct link to the NETCONF WGLC:
https://mailarchive.ietf.org/arch/msg/netconf/BS-lGFKDZybqEArfD3rnFnf6N2c/

Notable also is that subsequent WGLC for related documents did not gain
enough review to progress. See NETCONF WGLC for ietf-crypto-types,
ietf-keystore, and ietf-trust-anchors:
https://mailarchive.ietf.org/arch/msg/netconf/a2kByJuXp1tGRHAMsQEkKoQn5ak/

According to the minutes from NETCONF WG session during IETF 108, it
seems that the full set of documents went to WGLC without any
objections. Direct link to minutes from IETF 108:
https://datatracker.ietf.org/meeting/108/materials/minutes-108-netconf-02.html

2. Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

Shepherd:

There has been extensive discussion about key generation and modules for
the IANA registry of SSH Protocol parameters.

There seems to be WG consensus on the current state of the document.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Shepherd:

No one has threatened an appeal or indicated extreme discontent. Even
though the key generation and IANA modules issues were extensively
discussed, the ambition was to progress the document.

4. For protocol documents, are there existing implementations of the
contents of the document? Have a significant number of potential
implementers indicated plans to implement? Are any existing
implementations reported somewhere, either in the document itself (as
RFC 7942 [3] recommends) or elsewhere (where)?

Shepherd:

The following existing implementations are known

https://github.com/BroadbandForum/obbaa-polt-simulator

https://github.com/CESNET/netopeer2

Other implementations or implementation plans are unknown at this point.

Additional Reviews
------------------

5. Do the contents of this document closely interact with technologies
in other IETF working groups or external organizations, and would it
therefore benefit from their review? Have those reviews occurred? If
yes, describe which reviews took place.

Shepherd:

No such review is necessary and has not been performed.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

Shepherd:

The document went through SecDir review as part of the Last Call
process. The status is "Has Nits".

Direct links to the SecDir review and the response:
https://datatracker.ietf.org/doc/review-ietf-netconf-ssh-client-server-24-secdir-lc-leiba-2021-06-15
https://mailarchive.ietf.org/arch/msg/netconf/NsPkbDXiELfREG3yyaTWAP8JmCU/

The document went through two YANG Doctor reviews as part of the Last
Call process. The status of the last YANG Doctor review is "Ready".

Direct link to the YANG Doctor review of revision -24:
https://mailarchive.ietf.org/arch/msg/netconf/pzO_euLyLQLTqBTPu6DN32QdcQ8/

Direct link to the YANG Doctor review of revision -03:
https://mailarchive.ietf.org/arch/msg/netconf/cCYR6m57whoPqTxzdsLYPPQNkt8/

The document was last reviewed at revision -24, there are four new
models, and document changes, in need of review. The heavily discussed
key generation resulted in the RPC sshcmn:generate-public-key which has
also been introduced after the last round of reviews.

The document author also hints on the NETCONF WG list that a formal
expert review is needed for the updates. Direct link to mail:
https://mailarchive.ietf.org/arch/msg/netconf/rmDwfMrzH8pswr3UAUnetPsgxEU/

Suggest a new round of formal expert reviews.

7. If the document contains a YANG module, has the final version of the
module been checked with any of the recommended validation tools [4]
for syntax and formatting validation? If there are any resulting
errors or warnings, what is the justification for not fixing them at
this time? Does the YANG module comply with the Network Management
Datastore Architecture (NMDA) as specified in RFC 8342 [5]?

Shepherd:

The document contains seven YANG modules which are all well written and
follow good YANG style. All seven modules have passed validation with
pyang 2.5.3 and yanglint 2.0.112.

There are only whitespace and formatting lint issues with the models,
all of which are harmless.

The YANG modules comply with NMDA.

The content of the models iana-ssh-encryption-algs.yang,
iana-ssh-key-exchange-algs.yang, iana-ssh-mac-algs.yang, and
iana-ssh-public-key-algs.yang have been verified to be correct manually
against the IANA Protocol Registries for Secure Shell (SSH) Protocol
Parameters published at:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml

The curves in iana-ssh-key-exchange-algs.yang and
iana-ssh-public-key-algs.yang have been further verified against
RFC 5656, RFC 8732, and RFC 9142.

All the modules listing various SSH Protocol parameters from the IANA
registry have been verified against their respective normative
references. See question 14 for these references and suggestions to add
these to the document.

The identities for key exchange methods
diffie-hellman-group-exchange-sha1 and diffie-hellman-group1-sha1 should
be marked with "status deprecated;", as other identities for deprecated
algorithms (such as gss-gex-sha1-*) are marked as such per from e.g.
RFC 8732.

If the modules listing algorithms are going to be updated in the future,
and if the data format from the IANA Protocol Registries is stable, it
would be helpful to also include a method or script for generating
updated modules. This work probably exists somewhere already, and there
has been discussions on list including it in the document, but no method
is presented in the document. This is especially important if an
algorithm moves to the "MUST NOT" state in the "OK to Implement".

In the mail thread discussing creating IANA defined modules, a script is
attached for iana-tls-cipher-suite-algs.yang. Direct link:
https://mailarchive.ietf.org/arch/msg/netconf/TTMwp3veeBixD5k3NwHL2gyoCGs/

Similar work for the SSH IANA modules probably exist.

Further discussion about using XSLT template to create and update the
IANA modules:
https://mailarchive.ietf.org/arch/msg/netconf/cmudFQxPMQD67HIEjyT6BhapKFI/

The Internet Draft draft-boucadair-netmod-iana-registries [A] suggests
that pre-RFC, a document should include in an appendix XSLT templates or
scripts; which are to be removed by the RFC editor upon publication.

-> Suggest to publish the methods that generated the initial IANA
modules in a new revision.

Furthermore, [A] suggests adding to IANA maintained modules a motivation
for why identities or enumerations have been chosen for the module
contents. This is missing from the document.

-> Suggest introducing a section called "YANG Considerations" and
presenting why identities are chosen over enumerations. Possibly
add it as a sub section to the introduction, since it will
probably be rather short.

See Section 3 Guidelines for IANA-Maintained Modules in [A].

[A] https://datatracker.ietf.org/doc/html/draft-boucadair-netmod-iana-registries-04

export f=iana-ssh-encryption-algs@2022-06-16.yang
pyang --ietf $f
yanglint $f