Skip to main content

Last Call Review of draft-ietf-netconf-ssh-client-server-37

Request Review of draft-ietf-netconf-ssh-client-server
Requested revision No specific revision (document currently at 40)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-02-12
Requested 2024-01-29
Authors Kent Watsen
I-D last updated 2024-02-14
Completed reviews Genart Last Call review of -37 by Elwyn B. Davies (diff)
Intdir Telechat review of -38 by Sheng Jiang (diff)
Opsdir Last Call review of -36 by Qin Wu (diff)
Yangdoctors Last Call review of -03 by Andy Bierman (diff)
Yangdoctors Last Call review of -24 by Andy Bierman (diff)
Secdir Last Call review of -24 by Barry Leiba (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-netconf-ssh-client-server by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 37 (document currently at 40)
Result Almost ready
Completed 2024-02-14
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-netconf-ssh-client-server-37
Reviewer: Elwyn Davies
Review Date: 2024-02-14
IETF LC End Date: 2024-02-12
IESG Telechat date: 2024-02-29

Summary:Almost ready.  The majority of points are editorial nits, however the
proposed mechanism for  generating YANG modules to provide automated access to
certain sets of options defined in IANA registries is not explained at all in
the introduction and needs to be. I also feel that the authors need to consider
(and may have already done this) whether they should supply automation scripts
that will assist IANA in creating and checking the updated YANG modules that
they are to be asked to generate when the relevant registry entries are
updated. I have not attempted to check that the IETF YANG modules are correct
or complete as I do not have the SSH knowledge at my fingertips.  I wonder if
the mechanism needs a designated expert to deal with naming queries and help
with any issues in creating the IANA YANG modules rather than passing this
burden to the NETCONF WG chair - which rather assumes the NETCONF WG will be
around for ever.

Major issues:

Minor issues:

General: The document contains a number of references to the NETCONF WG chairs
and the NETCONF WG mailing list. Is this adequately future proof?

General: Although this is not directly relevant to the draft, it occurs to me
that since IANA is being requested to edit YANG modules in response to registry
changes and the resulting modules would be expected to be read by protocol
implementations, it would be desirable if IANA was supplied with scripts that
could be used to automatically update the IANA modules and run the YANG checker
script to ensure the syntactical correctness of the updates.  The changes
resulting from these updates should be automatically backwards compatible so
updating the modules should not be problematic. S2.1.1:  The last paragraph of
this section reads:

 The diagram above uses syntax that is similar to but not defined in

In that case had the syntax better be defined in this document?

Nits/editorial comments:

Abstract, para 2:  I suggest s/enabling/supporting/ since the YANG modules
provide a standardised framework rather than actually providing the only way of
configuration of SSH entities.

Abstract, para 3:  Similarly, s/for an IANA-maintained/providing support for an

Introduction, s1:  This section is very bald.  In particular, the introduction
is silent about the purpose of the IANA modules.  It should, in the way of
convention, contain similar words to paragraphs 2 and 3 of the abstract to
explain the purpose of the document.

The section should also  contain a subsection similar to s1.1 to explain the
purposes of the IANA modules and how they are created and maintained since the
draft only defines the format and not the exact contents of the YANG modules.

s1.1, para 1: s/more so than/rather than/, s/advance/extended/

s1.2, para 1: as with the Abstract s/enable/support/

Table 1:  This table should have a RFC Editor note to clarify that the right
hand column needs to be updated with the references to the RFCs that will
hopefully result from the approval of the referenced I-Ds.  For convenience of
readers, I hope that the keys will be of the form RFCxxxx to reduce reader
effort in working out what documents are reference.

s1.4: The jargon <operational> should be replaced by 'operational state
datastore' with a reference to Section 5.3 of RFC 8342.

 rpc generate-asymmetric-key-pair {
       if-feature "asymmetric-key-pair-generation";
         "Requests the device to generate an public key using
          the specified key algorithm.";
 rpc generate-asymmetric-key-pair {
       if-feature "asymmetric-key-pair-generation";
         "Requests the device to generate a public key using
          the specified key algorithm.";

ss6.3-6.6:  In the 5th para of the boilerplate text in each of these 4 sections:
s/is a invalid for a YANG identity/is not a lexically valid name for a YANG

Also 4 paragraphs from the end of each section:
s/that points to the where the module was  published./that points to the
document defining the registry update that resulted in this change./

Appendix A:  I think the intention of the instruction to remove Appendix A
before publication only applies to the program in the header section rather
than the whole Appendix which contains the initial creations of the IANA
modules.  I take it that the program will be rerun if necessary after the draft
has been approved in case there have been registry updates since the last draft