YANG Groupings for SSH Clients and SSH Servers
draft-ietf-netconf-ssh-client-server-40

[Ballot comment]
From Orie Steele, incoming ART Area Director:

Regarding Section 6.3 (Considerations for the "iana-ssh-encryption-algs" Module):

Does IANA accept the python script and the manual revision statement process that is required?

[Ballot discuss]
BCP 81 says the registration contact has to be the IESG for things developed by the IETF.  Why do some of them list IANA as the contact?

[Ballot discuss]
Thanks for the document. I have a few DISCUSS items that hopefully are pretty minor to resolve.

1) client options?

The ssh client allows to set the source IP. Should that not be exposed here to support picking the right source IP on multihomed nodes?
Similarly, this does not seem to support ports != 22 ? And seeing people are starting to experiment with ssh over QUIC or
HTTP/3, perhaps a protocol should be added as well? Is compression an option that should be exposed here?

2) server options

I think the idle timeout might be a useful server option to expose here? It seems the best place for it instead of placing it in another ssh server module to include ?

3) algorithms, names and IANA entries


        2.2. Example Usage

This uses older ctr/cbc algorrithms, why not use more modern examples?
I'd recommend removing the cbc examples and including the well known AEAD
ones instead? (see also the catch below)

Note openssh uses names like  chacha20-poly1305@openssh.com, aes128-gcm@openssh.com,aes256-gcm@openssh.com while the IANA registry uses names like
AEAD_AES_128_GCM and AEAD_AES_256_GCM. How does this relates to names in
the document, which uses "aead-aes-256-gcm" which is not an IANA value,
but presumably points to AEAD_AES_256_GCM and aes256-gcm@openssh.com ?
I think some guidance or explanation about the valid value names here compared
to IANA and OpenSSH would be useful. I believe the "@" ones are non-IETF namespaces

I would also include at least one "@" encryption name to ensure people know
those are valid syntax as well. I do not know if AEAD_AES_256_GCM is the
same as aes256-gcm@openssh.com

What should the  field list for AEAD algorithms? Just be empty? Or
a special "none" value? Or should the field be entirely omitted? Is there
guidance needed here? (Sorry I am not a yang doctor)

The value diffie-hellman-group-exchange-sha256 is a valid IANA registry
name but points to a MAY entry. I would pick a MUST or SHOULD entry for
examples, in this case diffie-hellman-group14-sha256. Similar, the
example gss-group1-sha1-curve25519-sha256 is actually a SHOULD NOT
implement entry. Similar the mac aead-aes-256-gcm really has an IANA
entry of AEAD_AES_256_GCM.

[Ballot comment]
C1) hashed-password ?

The example "$0$secret" uses the most unsafe option as example. "secret"
is not a hash. It is cleartext baesd on RFC 7317 "crypt-hash". Maybe give
an example with an actual hashed password as well? Maybe change "secret"
to "cleartext-password" ?

Since RFC 7317 only defines crypt-hash 0,1,5 and 6 there is some
ambiguity here for hashed passwords based on other algorithms. My
crypt(5) man page also supports script, yescript, bcrypt, NT. But not
argon. But I guess this is an issue for RFC 7317, and not this document.

[Ballot comment]
Thank you for writing this document.

Also, I explicitly want to call out and thank Qin Wu for the excellent (and in-depth!) OpsDir review, and Kent for working though the comments.
Much thanks,
W

[Ballot comment]
Thank you for writing this document.

Also, I explicitly want to call out and thank Qin Wu for the excellent (and in-depth!( OpsDir review, and Kent for working though the comments.
Much thanks,
W

[Ballot discuss]
I struggle to understand when it is assumed that the security considerations of the imported modules apply, and when they will be surfaced as issues in the module that is using them.  With that confusion in mind:

** Section 5.7.  The ietf-ssh-server module is described as having no readable data nodes that are sensitive.  Consider the example in Section 4.2.  Wouldn’t enumerating the list of users for which there is a client-authentication configuration be sensitive?

[Ballot comment]
** Section 5.1, 5.2, 5.3 and 5.4?
  The protocol-accessible read-only node for the algorithms supported
  by a server is mildly sensitive, but not to the extent that special
  NACM annotations are needed to prevent read-access to regular
  authenticated administrators.

What is meant by “mildly sensitive” to call it out?

** Section 5.5.  Does this section need a disclaimer that there are groupings that importing modules need to fully consider in their own Security Considerations?  Same as in draft-ietf-netconf-tcp-client-server?

** Appendix A.  Please provide an informative reference to Python for this non-normative (?) section.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netconf-ssh-client-server-36. If any part of this review is inaccurate, please let us know.

IANA has a question about the third through sixth actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are six actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

seven new namespaces will be registered as follows:

ID: yang:iana-ssh-key-exchange-algs
URI: urn:ietf:params:xml:ns:yang:iana-ssh-key-exchange-algs
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:iana-ssh-encryption-algs
URI: urn:ietf:params:xml:ns:yang:iana-ssh-encryption-algs
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:iana-ssh-mac-algs
URI: urn:ietf:params:xml:ns:yang:iana-ssh-mac-algs
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:iana-ssh-public-key-algs
URI: urn:ietf:params:xml:ns:yang:iana-ssh-public-key-algs
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ssh-common
URI: urn:ietf:params:xml:ns:yang:ietf-ssh-common
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ssh-client
URI: urn:ietf:params:xml:ns:yang:ietf-ssh-client
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ssh-server
URI: urn:ietf:params:xml:ns:yang:ietf-ssh-server
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

seven new YANG modules will be registered as follows:

Name: iana-ssh-key-exchange-algs
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-ssh-key-exchange-algs
Prefix: sshkea
Module:
Reference: [ RFC-to-be ]

Name: iana-ssh-encryption-algs
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-ssh-encryption-algs
Prefix: sshea
Module:
Reference: [ RFC-to-be ]

Name: iana-ssh-mac-algs
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-ssh-mac-algs
Prefix: sshma
Module:
Reference: [ RFC-to-be ]

Name: iana-ssh-public-key-algs
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-ssh-public-key-algs
Prefix: sshpka
Module:
Reference: [ RFC-to-be ]

Name: ietf-ssh-common
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-common
Prefix: sshcmn
Module:
Reference: [ RFC-to-be ]

Name: ietf-ssh-client
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-client
Prefix: sshc
Module:
Reference: [ RFC-to-be ]

Name: ietf-ssh-server
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ssh-server
Prefix: sshs
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

Third, a new YANG Module is to be added to the YANG Modules available at:

https://www.iana.org/protocols

The new module will be named: iana-ssh-encryption-algs YANG Module. The contents of the module will be copied from Appendix A.1 of the current draft.

IANA Question --> Is the intent of the authors to have IANA publish the IANA Module based on Appendix A.1 and then update it to reflect any recent additions to the "Encryption Algorithm Names" sub-registry of the "Secure Shell (SSH) Protocol Parameters" registry?

Fourth, a new YANG Module is to be added to the YANG Modules available at:

https://www.iana.org/protocols

The new module will be named: iana-ssh-mac-algs YANG Module. The contents of the module will be copied from Appendix A.2 of the current draft.

IANA Question --> Is the intent of the authors to have IANA publish the IANA Module based on Appendix A.2 and then update it to reflect any recent additions to the "MAC Algorithm Names" sub-registry of the "Secure Shell (SSH) Protocol Parameters" registry?

Fifth, a new YANG Module is to be added to the YANG Modules available at:

https://www.iana.org/protocols

The new module will be named: iana-ssh-public-key-algs YANG Module. The contents of the module will be copied from Appendix A.3 of the current draft.

IANA Question --> Is the intent of the authors to have IANA publish the IANA Module based on Appendix A.3 and then update it to reflect any recent additions to the "Public Key Algorithm Names" sub-registry of the "Secure Shell (SSH) Protocol Parameters" registry?

Sixth, a new YANG Module is to be added to the YANG Modules available at:

https://www.iana.org/protocols

The new module will be named: iana-ssh-key-exchange-algs YANG Module. The contents of the module will be copied from Appendix A.4 of the current draft.

IANA Question --> Is the intent of the authors to have IANA publish the IANA Module based on Appendix A.4 and then update it to reflect any recent additions to the ""Key Exchange Method Names" sub-registry of the "Secure Shell (SSH) Protocol Parameters" registry?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-02-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netconf-ssh-client-server@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, perander@cisco.com, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Groupings for SSH Clients and SSH Servers) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'YANG Groupings for SSH Clients and SSH
Servers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines three YANG 1.1 modules: the first defines
  features and groupings common to both SSH clients and SSH servers,
  the second defines a grouping for a generic SSH client, and the third
  defines a grouping for a generic SSH server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5647: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol (Informational - Internet Engineering Task Force (IETF))

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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "encryption-alg-base";
---
>      base encryption-alg-base;
62d58
<
395d390
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "key-exchange-alg-base";
---
>      base key-exchange-alg-base;
62d58
<
1532c1528
<      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1672c1668
<      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1812c1808
<      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2093c2089
<      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2223d2218
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "mac-alg-base";
---
>      base mac-alg-base;
62d58
<
169d164
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "public-key-alg-base";
---
>      base public-key-alg-base;
62d58
<
443d438
<


export f=ietf-ssh-client@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
39d34
<
45d39
<
142d135
<
249d241
<
270,271c262,263
<          refine
<            "local-or-truststore/local/local-definition/public-key" {
---
>          refine "local-or-truststore/local/local-definition"
>                + "/public-key" {
275,276c267,268
<          refine
<            "local-or-truststore/truststore/truststore-reference" {
---
>          refine "local-or-truststore/truststore"
>                + "/truststore-reference" {
314d305
<
322d312
<
326,328c316,317
<      presence
<        "Indicates that the SSH client proactively tests the
<          aliveness of the remote SSH server.";
---
>      presence "Indicates that the SSH client proactively tests the
>                aliveness of the remote SSH server.";
332c321
<          server is dropped after approximately max-wait *
---
>          server is dropped after approximately max-wait *


export f=ietf-ssh-common@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
44d38
<
50d43
<
216c209
<        default cleartext;
---
>        default "cleartext";
231,232c224,225
<                "Indicates that the key is to be encrypted using
<                the specified symmetric or asymmetric key.";
---
>              "Indicates that the key is to be encrypted using
>                the specified symmetric or asymmetric key.";


export f=ietf-ssh-server@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
45d39
<
51d44
<
160d152
<
197d188
<
215c206
<            ks:local-or-keystore-end-entity-cert-with-key-grouping {
---
>              ks:local-or-keystore-end-entity-cert-with-key-grouping {
220,221c211,213
<              refine "local-or-keystore/keystore/keystore-reference"
<                    + "/asymmetric-key" {
---
>              refine
>                "local-or-keystore/keystore/keystore-reference"
>              + "/asymmetric-key" {
224c216
<                  + 'format, "ct:subject-public-key-info-format")';
---
>                + 'format, "ct:subject-public-key-info-format")';
231d222
<
251c242
<              must authenticate to all configured methods.
---
>              must authenticate to all configured methods.
368d358
<
376d365
<
380,382c369,370
<      presence
<        "Indicates that the SSH server proactively tests the
<          aliveness of the remote SSH client.";
---
>      presence "Indicates that the SSH server proactively tests the
>                aliveness of the remote SSH client.";


8.  Describe reviews and automated checks performed to validate sections
    of the final version of the document written in a formal language,
    such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:

The document's XML snippets have been validated with yanglint 2.0.112.

All but the following examples validated correctly. The examples below
did not validate correctly with yanglint, even though they seem to be
well formed and fulfill the must requirements. Perhaps it is an operator
error during review?

Note that the generated ietf-ssh-*@*.yang modules from the refs are
used, wherein they create a container which uses the grouping, used in
respective example.


refs/ex-ssh-client-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-client-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-keystore.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ex-ssh-server-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml \
    ex-ssh-server-keystore.xml
Segmentation fault


Document Shepherd Checks
------------------------

9.  Based on the shepherd's review of the document, is it their opinion
    that this document is needed, clearly written, complete, correctly
    designed, and ready to be handed off to the responsible Area
    Director?

Shepherd:

The document is needed, clearly written, complete, and correctly
designed.

However, since there are new nontrivial contributions to the document
since the last round of reviews from formal experts, new reviews from
SecDir and YANG Doctors are suggested. This is also hinted by the
author. See question 6 above.

There are also various issues found during document shepherd review, see
questions 7, 8, and 14 for these.

Otherwise the document is ready for handoff to the responsible Area
Director.


10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter [6]. For which areas have such issues been
    identified and addressed? For which does this still need to happen
    in subsequent reviews?

Shepherd:

No common issues have been identified, thus no further detailed review
is needed.


11. What type of RFC publication is being requested on the IETF stream
    (Best Current Practice [7], Proposed Standard, Internet Standard [8],
    Informational, Experimental or Historic [9])? Why is this the proper
    type of RFC? Do all Datatracker state attributes correctly reflect
    this intent?

Shepherd:

The RFC status requested is Proposed Standard.

This is the correct RFC status because it is a standardization of the
configuration of, configuration parameters, and methods, to configure
and setup SSH clients and servers.

The Datatracker correctly reflects the requested RFC status:
https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/


12. Have reasonable efforts been made to remind all authors of the
    intellectual property rights (IPR) disclosure obligations described
    in BCP 79 [10]? To the best of your knowledge, have all required
    disclosures been filed? If not, explain why. If yes, summarize any
    relevant discussion, including links to publicly-available messages
    when applicable.

Shepherd:

No IPR disclosure have been raised in reference to this document.

The WG chair requested an IPR poll. The author confirmed that they are
not aware of any IPR related to this document. No IPR disclosures were
made.

Direct link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/rS4SV38blMOgX0Ez7mw9E9B9sx0/


13. Has each author, editor, and contributor shown their willingness to
    be listed as such? If the total number of authors and editors on the
    front page is greater than five, please provide a justification.

Shepherd:

There is one author and one contributor for this document, no editors
are listed.

The author has not explicitly confirmed willingness to be listed as an
author but has driven the adoption, discussions, work, and updates of
the document. Thus, the author is assumed to willingly be listed as
such.

Regarding the contributor, they were previously listed as a draft
co-author but were silently removed in document revision -22. However,
the contributor is listed as author since revision -01 for the
ietf-ssh-* YANG models, of which they are especially attributed to have
contributed to ietf-ssh-common.yang. Thus, it is assumed that they are
willingly listed as contributors.


14. Document any remaining I-D nits in this document. Simply running the
    idnits tool [11] is not enough; please review the "Content
    Guidelines" [12] on authors.ietf.org. (Also note that the current
    idnits tool generates some incorrect warnings; a rewrite is
    underway.)

Shepherd:

I-D nits was tested against revision -30 of the draft.

Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

Two warnings target whitespace formatting.

One of them being for YANG tree diagamrs following the format from RFC
8340. This warning is harmless.

The second whitespace warning targets a double space in the YANG model
ietf-ssh-client@2022-08-30.yang, grouping ssh-client-grouping for the
description of the ca-certs container. This is harmless but gives a
sloppy impression and should be addressed.

The two remaining warnings target old draft versions. All these
documents are assumed to be fixed as part of the standardization
process.


A minor editorial change is that the iana-*.yang set of modules
could squash the current two revisions to only one revision, i.e.
"Inital version", since they will be officially released when the
document is published.

Should the iana-*.yang modules be regenerated before the document is
published and then replace "June 16th, 2022" with the new date; and the
same for the YANG module revision date? Or should it be kept as is with
2022-06-16 as the date?

When reviewing iana-ssh-key-exchange-algs.yang it was found that the
identities for key exchange methods diffie-hellman-group-exchange-sha1
and diffie-hellman-group1-sha1 should be marked with "status
deprecated;", see question 7 for details.

The YANG modules for the IANA algorithm listings should contain a
section with information corresponding to the first paragraph of
Section 2.3, listing the normative references in the following YANG
module. All such references should also be listed in
Section 7.1 Normative References.

For iana-ssh-encryption-algs.yang include normative references:
* FIPS-46-3
* RFC 4253
* RFC 4344
* RFC 5647
* RFC 8758

For iana-ssh-key-exchange-algs.yang include normative references:
* RFC 4419
* RFC 4432
* RFC 8268
* RFC 8308
* RFC 8731
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For iana-ssh-mac-algs.yang include normative references:
* RFC 4253
* RFC 5647
* RFC 6668

For iana-ssh-public-key-algs.yang include normative references:
* RFC 4253
* RFC 4462
* RFC 5656
* RFC 6187
* RFC 8332
* RFC 8709

For ietf-ssh-common.yang include normative references:
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For ietf-ssh-client.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types

For ietf-ssh-server.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types


Regarding the ietf-ssh-common grouping transport-params-grouping
referencing Section 5 Security Considerations later in the document, for
host-key algorithm compatibility with the private key; there is no such
presentation of compatible combinations in the current revision, -30, of
the document. This compatibility matrix was added in revision -08 and
subsequently removed in revision -19. This compatibility matrix might
however be out of scope for this document, but another reference to
relevant RFCs is suitable. Whatever path is taken, the reference needs
to be updated.


The ietf-ssh-client container keepalives should reference unresponsive
SSH servers in the description, not TLS servers.

the aliveness of the SSH server.  An unresponsive TLS
server is dropped after approximatively max-wait *

    -> the aliveness of the SSH server.  An unresponsive SSH
      server is dropped after approximatively max-wait *

Likewise the ietf-ssh-client leaf max-wait in the keepalives container
should reference SSH not TLS.

  no data has been received from the SSH server, a
  TLS-level message will be sent to test the
  aliveness of the SSH server.";

    -> no data has been received from the SSH server, an
      SSH-level message will be sent to test the
      aliveness of the SSH server.";

The user "mary" in ex-ssh-server-local.xml has two public keys listed,
they are listed as "User A" and "User B". Suggest naming them
differently to indicate that they are used by the same user "mary" on
different devices, e.g. "Key #1" and "Key #2".


The ietf-ssh-server container keepalives should reference unresponsive
SSH clients in the description, not SSL clients.

  the aliveness of the SSL client. an unresponsive SSL
  client is dropped after approximately max-wait *

    -> the aliveness of the SSH client. an unresponsive SSH
      client is dropped after approximately max-wait *

Likewise the ietf-ssh-server leafs seconds and max-attempts in the
keepalives container should reference SSH not SSL.

keepalives/seconds description:

  if no data has been received from the SSL client,
  a SSL-level message will be sent to test the
  aliveness of the SSL client.";

    -> if no data has been received from the SSH client,
      an SSH-level message will be sent to test the
      aliveness of the SSH client.";

keepalives/max-attempts description:

  the SSL client before assuming the SSL client is

    -> the SSH client before assuming the SSH client is


Section 6.6

Also mention the "status" statement "obsolete", since it is present in
the YANG module identities listing.

Furthermore, the column to track algorithm status seems to be present
alreday in the IANA Protocol registry for the SSH Protocol.


15. Should any informative references be normative or vice-versa? See the
    IESG Statement on Normative and Informative References [13].

Shepherd:

The informative reference RFC 7317 (iana-crypt-hash.yang) should be
normative, since it is imported in ietf-ssh-server.yang.

Otherwise the listed normative and informative references are correctly
listed.


16. List any normative references that are not freely available to
    anyone. Did the community have sufficient access to review any such
    normative references?

Shepherd:

All normative references are freely available to the public.


17. Are there any normative downward references (see RFC 3967 [14] and
    BCP 97 [15]) that are not already listed in the DOWNREF
    registry [16]? If so, list them.

Shepherd:

There are no normative downward references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear
    state? If so, what is the plan for their completion?

Shepherd:

The normative references to the internet drafts ietf-crypto-types,
ietf-keystore, and ietf-trust-anchors, will all be submitted
simultaneously to the IESG for review.


19. Will publication of this document change the status of any existing
    RFCs? If so, does the Datatracker metadata correctly reflect this and
    are those RFCs listed on the title page, in the abstract, and
    discussed in the introduction? If not, explain why and point to the
    part of the document where the relationship of this document to these
    other RFCs is discussed.

Shepherd:

The publication of this document will not change the status of any
existing RFCs.


20. Describe the document shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all aspects of the document requiring IANA
    assignments are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that each newly created IANA registry
    specifies its initial contents, allocations procedures, and a
    reasonable name (see RFC 8126 [17]).

Shepherd:

The IANA Considerations section has been reviewed. The document
registers seven URIs and seven YANG models.

All aspects of the document requiring IANA Considerations are associated
with appropriate reservations in the IANA registries.

Any referenced IANA registries are cleary identified.

Each newly created IANA registry specifies its initial contents,
allocation procedures, and reasonable names.


21. List any new IANA registries that require Designated Expert Review
    for future allocations. Are the instructions to the Designated Expert
    clear? Please include suggestions of designated experts, if
    appropriate.

Shepherd:

The new IANA registries will not require Designated Expert review for
future allocations.


[1] https://www.ietf.org/about/groups/iesg/
[2] https://datatracker.ietf.org/doc/rfc4858/
[3] https://datatracker.ietf.org/doc/rfc7942/
[4] https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5] https://datatracker.ietf.org/doc/rfc8342/
[6] https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7] https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[8] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[9] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[10] https://datatracker.ietf.org/doc/bcp79/
[11] https://www.ietf.org/tools/idnits/
[12] https://authors.ietf.org/en/content-guidelines-overview
[13] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[14] https://datatracker.ietf.org/doc/rfc3967/
[15] https://www.rfc-editor.org/info/bcp97
[16] https://datatracker.ietf.org/doc/downref/
[17] https://datatracker.ietf.org/doc/rfc8126/

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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "encryption-alg-base";
---
>      base encryption-alg-base;
62d58
<
395d390
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "key-exchange-alg-base";
---
>      base key-exchange-alg-base;
62d58
<
1532c1528
<      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1672c1668
<      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1812c1808
<      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2093c2089
<      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2223d2218
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "mac-alg-base";
---
>      base mac-alg-base;
62d58
<
169d164
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "public-key-alg-base";
---
>      base public-key-alg-base;
62d58
<
443d438
<


export f=ietf-ssh-client@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
39d34
<
45d39
<
142d135
<
249d241
<
270,271c262,263
<          refine
<            "local-or-truststore/local/local-definition/public-key" {
---
>          refine "local-or-truststore/local/local-definition"
>                + "/public-key" {
275,276c267,268
<          refine
<            "local-or-truststore/truststore/truststore-reference" {
---
>          refine "local-or-truststore/truststore"
>                + "/truststore-reference" {
314d305
<
322d312
<
326,328c316,317
<      presence
<        "Indicates that the SSH client proactively tests the
<          aliveness of the remote SSH server.";
---
>      presence "Indicates that the SSH client proactively tests the
>                aliveness of the remote SSH server.";
332c321
<          server is dropped after approximately max-wait *
---
>          server is dropped after approximately max-wait *


export f=ietf-ssh-common@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
44d38
<
50d43
<
216c209
<        default cleartext;
---
>        default "cleartext";
231,232c224,225
<                "Indicates that the key is to be encrypted using
<                the specified symmetric or asymmetric key.";
---
>              "Indicates that the key is to be encrypted using
>                the specified symmetric or asymmetric key.";


export f=ietf-ssh-server@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
45d39
<
51d44
<
160d152
<
197d188
<
215c206
<            ks:local-or-keystore-end-entity-cert-with-key-grouping {
---
>              ks:local-or-keystore-end-entity-cert-with-key-grouping {
220,221c211,213
<              refine "local-or-keystore/keystore/keystore-reference"
<                    + "/asymmetric-key" {
---
>              refine
>                "local-or-keystore/keystore/keystore-reference"
>              + "/asymmetric-key" {
224c216
<                  + 'format, "ct:subject-public-key-info-format")';
---
>                + 'format, "ct:subject-public-key-info-format")';
231d222
<
251c242
<              must authenticate to all configured methods.
---
>              must authenticate to all configured methods.
368d358
<
376d365
<
380,382c369,370
<      presence
<        "Indicates that the SSH server proactively tests the
<          aliveness of the remote SSH client.";
---
>      presence "Indicates that the SSH server proactively tests the
>                aliveness of the remote SSH client.";


8.  Describe reviews and automated checks performed to validate sections
    of the final version of the document written in a formal language,
    such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:

The document's XML snippets have been validated with yanglint 2.0.112.

All but the following examples validated correctly. The examples below
did not validate correctly with yanglint, even though they seem to be
well formed and fulfill the must requirements. Perhaps it is an operator
error during review?

Note that the generated ietf-ssh-*@*.yang modules from the refs are
used, wherein they create a container which uses the grouping, used in
respective example.


refs/ex-ssh-client-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-client-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-keystore.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ex-ssh-server-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml \
    ex-ssh-server-keystore.xml
Segmentation fault


Document Shepherd Checks
------------------------

9.  Based on the shepherd's review of the document, is it their opinion
    that this document is needed, clearly written, complete, correctly
    designed, and ready to be handed off to the responsible Area
    Director?

Shepherd:

The document is needed, clearly written, complete, and correctly
designed.

However, since there are new nontrivial contributions to the document
since the last round of reviews from formal experts, new reviews from
SecDir and YANG Doctors are suggested. This is also hinted by the
author. See question 6 above.

There are also various issues found during document shepherd review, see
questions 7, 8, and 14 for these.

Otherwise the document is ready for handoff to the responsible Area
Director.


10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter [6]. For which areas have such issues been
    identified and addressed? For which does this still need to happen
    in subsequent reviews?

Shepherd:

No common issues have been identified, thus no further detailed review
is needed.


11. What type of RFC publication is being requested on the IETF stream
    (Best Current Practice [7], Proposed Standard, Internet Standard [8],
    Informational, Experimental or Historic [9])? Why is this the proper
    type of RFC? Do all Datatracker state attributes correctly reflect
    this intent?

Shepherd:

The RFC status requested is Proposed Standard.

This is the correct RFC status because it is a standardization of the
configuration of, configuration parameters, and methods, to configure
and setup SSH clients and servers.

The Datatracker correctly reflects the requested RFC status:
https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/


12. Have reasonable efforts been made to remind all authors of the
    intellectual property rights (IPR) disclosure obligations described
    in BCP 79 [10]? To the best of your knowledge, have all required
    disclosures been filed? If not, explain why. If yes, summarize any
    relevant discussion, including links to publicly-available messages
    when applicable.

Shepherd:

No IPR disclosure have been raised in reference to this document.

The WG chair requested an IPR poll. The author confirmed that they are
not aware of any IPR related to this document. No IPR disclosures were
made.

Direct link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/rS4SV38blMOgX0Ez7mw9E9B9sx0/


13. Has each author, editor, and contributor shown their willingness to
    be listed as such? If the total number of authors and editors on the
    front page is greater than five, please provide a justification.

Shepherd:

There is one author and one contributor for this document, no editors
are listed.

The author has not explicitly confirmed willingness to be listed as an
author but has driven the adoption, discussions, work, and updates of
the document. Thus, the author is assumed to willingly be listed as
such.

Regarding the contributor, they were previously listed as a draft
co-author but were silently removed in document revision -22. However,
the contributor is listed as author since revision -01 for the
ietf-ssh-* YANG models, of which they are especially attributed to have
contributed to ietf-ssh-common.yang. Thus, it is assumed that they are
willingly listed as contributors.


14. Document any remaining I-D nits in this document. Simply running the
    idnits tool [11] is not enough; please review the "Content
    Guidelines" [12] on authors.ietf.org. (Also note that the current
    idnits tool generates some incorrect warnings; a rewrite is
    underway.)

Shepherd:

I-D nits was tested against revision -30 of the draft.

Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

Two warnings target whitespace formatting.

One of them being for YANG tree diagamrs following the format from RFC
8340. This warning is harmless.

The second whitespace warning targets a double space in the YANG model
ietf-ssh-client@2022-08-30.yang, grouping ssh-client-grouping for the
description of the ca-certs container. This is harmless but gives a
sloppy impression and should be addressed.

The two remaining warnings target old draft versions. All these
documents are assumed to be fixed as part of the standardization
process.


A minor editorial change is that the iana-*.yang set of modules
could squash the current two revisions to only one revision, i.e.
"Inital version", since they will be officially released when the
document is published.

Should the iana-*.yang modules be regenerated before the document is
published and then replace "June 16th, 2022" with the new date; and the
same for the YANG module revision date? Or should it be kept as is with
2022-06-16 as the date?

When reviewing iana-ssh-key-exchange-algs.yang it was found that the
identities for key exchange methods diffie-hellman-group-exchange-sha1
and diffie-hellman-group1-sha1 should be marked with "status
deprecated;", see question 7 for details.

The YANG modules for the IANA algorithm listings should contain a
section with information corresponding to the first paragraph of
Section 2.3, listing the normative references in the following YANG
module. All such references should also be listed in
Section 7.1 Normative References.

For iana-ssh-encryption-algs.yang include normative references:
* FIPS-46-3
* RFC 4253
* RFC 4344
* RFC 5647
* RFC 8758

For iana-ssh-key-exchange-algs.yang include normative references:
* RFC 4419
* RFC 4432
* RFC 8268
* RFC 8308
* RFC 8731
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For iana-ssh-mac-algs.yang include normative references:
* RFC 4253
* RFC 5647
* RFC 6668

For iana-ssh-public-key-algs.yang include normative references:
* RFC 4253
* RFC 4462
* RFC 5656
* RFC 6187
* RFC 8332
* RFC 8709

For ietf-ssh-common.yang include normative references:
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For ietf-ssh-client.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types

For ietf-ssh-server.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types


Regarding the ietf-ssh-common grouping transport-params-grouping
referencing Section 5 Security Considerations later in the document, for
host-key algorithm compatibility with the private key; there is no such
presentation of compatible combinations in the current revision, -30, of
the document. This compatibility matrix was added in revision -08 and
subsequently removed in revision -19. This compatibility matrix might
however be out of scope for this document, but another reference to
relevant RFCs is suitable. Whatever path is taken, the reference needs
to be updated.


The ietf-ssh-client container keepalives should reference unresponsive
SSH servers in the description, not TLS servers.

the aliveness of the SSH server.  An unresponsive TLS
server is dropped after approximatively max-wait *

    -> the aliveness of the SSH server.  An unresponsive SSH
      server is dropped after approximatively max-wait *

Likewise the ietf-ssh-client leaf max-wait in the keepalives container
should reference SSH not TLS.

  no data has been received from the SSH server, a
  TLS-level message will be sent to test the
  aliveness of the SSH server.";

    -> no data has been received from the SSH server, an
      SSH-level message will be sent to test the
      aliveness of the SSH server.";

The user "mary" in ex-ssh-server-local.xml has two public keys listed,
they are listed as "User A" and "User B". Suggest naming them
differently to indicate that they are used by the same user "mary" on
different devices, e.g. "Key #1" and "Key #2".


The ietf-ssh-server container keepalives should reference unresponsive
SSH clients in the description, not SSL clients.

  the aliveness of the SSL client. an unresponsive SSL
  client is dropped after approximately max-wait *

    -> the aliveness of the SSH client. an unresponsive SSH
      client is dropped after approximately max-wait *

Likewise the ietf-ssh-server leafs seconds and max-attempts in the
keepalives container should reference SSH not SSL.

keepalives/seconds description:

  if no data has been received from the SSL client,
  a SSL-level message will be sent to test the
  aliveness of the SSL client.";

    -> if no data has been received from the SSH client,
      an SSH-level message will be sent to test the
      aliveness of the SSH client.";

keepalives/max-attempts description:

  the SSL client before assuming the SSL client is

    -> the SSH client before assuming the SSH client is


Section 6.6

Also mention the "status" statement "obsolete", since it is present in
the YANG module identities listing.

Furthermore, the column to track algorithm status seems to be present
alreday in the IANA Protocol registry for the SSH Protocol.


15. Should any informative references be normative or vice-versa? See the
    IESG Statement on Normative and Informative References [13].

Shepherd:

The informative reference RFC 7317 (iana-crypt-hash.yang) should be
normative, since it is imported in ietf-ssh-server.yang.

Otherwise the listed normative and informative references are correctly
listed.


16. List any normative references that are not freely available to
    anyone. Did the community have sufficient access to review any such
    normative references?

Shepherd:

All normative references are freely available to the public.


17. Are there any normative downward references (see RFC 3967 [14] and
    BCP 97 [15]) that are not already listed in the DOWNREF
    registry [16]? If so, list them.

Shepherd:

There are no normative downward references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear
    state? If so, what is the plan for their completion?

Shepherd:

The normative references to the internet drafts ietf-crypto-types,
ietf-keystore, and ietf-trust-anchors, will all be submitted
simultaneously to the IESG for review.


19. Will publication of this document change the status of any existing
    RFCs? If so, does the Datatracker metadata correctly reflect this and
    are those RFCs listed on the title page, in the abstract, and
    discussed in the introduction? If not, explain why and point to the
    part of the document where the relationship of this document to these
    other RFCs is discussed.

Shepherd:

The publication of this document will not change the status of any
existing RFCs.


20. Describe the document shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all aspects of the document requiring IANA
    assignments are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that each newly created IANA registry
    specifies its initial contents, allocations procedures, and a
    reasonable name (see RFC 8126 [17]).

Shepherd:

The IANA Considerations section has been reviewed. The document
registers seven URIs and seven YANG models.

All aspects of the document requiring IANA Considerations are associated
with appropriate reservations in the IANA registries.

Any referenced IANA registries are cleary identified.

Each newly created IANA registry specifies its initial contents,
allocation procedures, and reasonable names.


21. List any new IANA registries that require Designated Expert Review
    for future allocations. Are the instructions to the Designated Expert
    clear? Please include suggestions of designated experts, if
    appropriate.

Shepherd:

The new IANA registries will not require Designated Expert review for
future allocations.


[1] https://www.ietf.org/about/groups/iesg/
[2] https://datatracker.ietf.org/doc/rfc4858/
[3] https://datatracker.ietf.org/doc/rfc7942/
[4] https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5] https://datatracker.ietf.org/doc/rfc8342/
[6] https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7] https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[8] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[9] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[10] https://datatracker.ietf.org/doc/bcp79/
[11] https://www.ietf.org/tools/idnits/
[12] https://authors.ietf.org/en/content-guidelines-overview
[13] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[14] https://datatracker.ietf.org/doc/rfc3967/
[15] https://www.rfc-editor.org/info/bcp97
[16] https://datatracker.ietf.org/doc/downref/
[17] https://datatracker.ietf.org/doc/rfc8126/

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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "encryption-alg-base";
---
>      base encryption-alg-base;
62d58
<
395d390
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "key-exchange-alg-base";
---
>      base key-exchange-alg-base;
62d58
<
1532c1528
<      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1672c1668
<      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1812c1808
<      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2093c2089
<      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2223d2218
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "mac-alg-base";
---
>      base mac-alg-base;
62d58
<
169d164
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "public-key-alg-base";
---
>      base public-key-alg-base;
62d58
<
443d438
<


export f=ietf-ssh-client@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
39d34
<
45d39
<
142d135
<
249d241
<
270,271c262,263
<          refine
<            "local-or-truststore/local/local-definition/public-key" {
---
>          refine "local-or-truststore/local/local-definition"
>                + "/public-key" {
275,276c267,268
<          refine
<            "local-or-truststore/truststore/truststore-reference" {
---
>          refine "local-or-truststore/truststore"
>                + "/truststore-reference" {
314d305
<
322d312
<
326,328c316,317
<      presence
<        "Indicates that the SSH client proactively tests the
<          aliveness of the remote SSH server.";
---
>      presence "Indicates that the SSH client proactively tests the
>                aliveness of the remote SSH server.";
332c321
<          server is dropped after approximately max-wait *
---
>          server is dropped after approximately max-wait *


export f=ietf-ssh-common@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
44d38
<
50d43
<
216c209
<        default cleartext;
---
>        default "cleartext";
231,232c224,225
<                "Indicates that the key is to be encrypted using
<                the specified symmetric or asymmetric key.";
---
>              "Indicates that the key is to be encrypted using
>                the specified symmetric or asymmetric key.";


export f=ietf-ssh-server@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
45d39
<
51d44
<
160d152
<
197d188
<
215c206
<            ks:local-or-keystore-end-entity-cert-with-key-grouping {
---
>              ks:local-or-keystore-end-entity-cert-with-key-grouping {
220,221c211,213
<              refine "local-or-keystore/keystore/keystore-reference"
<                    + "/asymmetric-key" {
---
>              refine
>                "local-or-keystore/keystore/keystore-reference"
>              + "/asymmetric-key" {
224c216
<                  + 'format, "ct:subject-public-key-info-format")';
---
>                + 'format, "ct:subject-public-key-info-format")';
231d222
<
251c242
<              must authenticate to all configured methods.
---
>              must authenticate to all configured methods.
368d358
<
376d365
<
380,382c369,370
<      presence
<        "Indicates that the SSH server proactively tests the
<          aliveness of the remote SSH client.";
---
>      presence "Indicates that the SSH server proactively tests the
>                aliveness of the remote SSH client.";


8.  Describe reviews and automated checks performed to validate sections
    of the final version of the document written in a formal language,
    such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:

The document's XML snippets have been validated with yanglint 2.0.112.

All but the following examples validated correctly. The examples below
did not validate correctly with yanglint, even though they seem to be
well formed and fulfill the must requirements. Perhaps it is an operator
error during review?

Note that the generated ietf-ssh-*@*.yang modules from the refs are
used, wherein they create a container which uses the grouping, used in
respective example.


refs/ex-ssh-client-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-client-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-keystore.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ex-ssh-server-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml \
    ex-ssh-server-keystore.xml
Segmentation fault


Document Shepherd Checks
------------------------

9.  Based on the shepherd's review of the document, is it their opinion
    that this document is needed, clearly written, complete, correctly
    designed, and ready to be handed off to the responsible Area
    Director?

Shepherd:

The document is needed, clearly written, complete, and correctly
designed.

However, since there are new nontrivial contributions to the document
since the last round of reviews from formal experts, new reviews from
SecDir and YANG Doctors are suggested. This is also hinted by the
author. See question 6 above.

There are also various issues found during document shepherd review, see
questions 7, 8, and 14 for these.

Otherwise the document is ready for handoff to the responsible Area
Director.


10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter [6]. For which areas have such issues been
    identified and addressed? For which does this still need to happen
    in subsequent reviews?

Shepherd:

No common issues have been identified, thus no further detailed review
is needed.


11. What type of RFC publication is being requested on the IETF stream
    (Best Current Practice [7], Proposed Standard, Internet Standard [8],
    Informational, Experimental or Historic [9])? Why is this the proper
    type of RFC? Do all Datatracker state attributes correctly reflect
    this intent?

Shepherd:

The RFC status requested is Proposed Standard.

This is the correct RFC status because it is a standardization of the
configuration of, configuration parameters, and methods, to configure
and setup SSH clients and servers.

The Datatracker correctly reflects the requested RFC status:
https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/


12. Have reasonable efforts been made to remind all authors of the
    intellectual property rights (IPR) disclosure obligations described
    in BCP 79 [10]? To the best of your knowledge, have all required
    disclosures been filed? If not, explain why. If yes, summarize any
    relevant discussion, including links to publicly-available messages
    when applicable.

Shepherd:

No IPR disclosure have been raised in reference to this document.

The WG chair requested an IPR poll. The author confirmed that they are
not aware of any IPR related to this document. No IPR disclosures were
made.

Direct link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/rS4SV38blMOgX0Ez7mw9E9B9sx0/


13. Has each author, editor, and contributor shown their willingness to
    be listed as such? If the total number of authors and editors on the
    front page is greater than five, please provide a justification.

Shepherd:

There is one author and one contributor for this document, no editors
are listed.

The author has not explicitly confirmed willingness to be listed as an
author but has driven the adoption, discussions, work, and updates of
the document. Thus, the author is assumed to willingly be listed as
such.

Regarding the contributor, they were previously listed as a draft
co-author but were silently removed in document revision -22. However,
the contributor is listed as author since revision -01 for the
ietf-ssh-* YANG models, of which they are especially attributed to have
contributed to ietf-ssh-common.yang. Thus, it is assumed that they are
willingly listed as contributors.


14. Document any remaining I-D nits in this document. Simply running the
    idnits tool [11] is not enough; please review the "Content
    Guidelines" [12] on authors.ietf.org. (Also note that the current
    idnits tool generates some incorrect warnings; a rewrite is
    underway.)

Shepherd:

I-D nits was tested against revision -30 of the draft.

Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

Two warnings target whitespace formatting.

One of them being for YANG tree diagamrs following the format from RFC
8340. This warning is harmless.

The second whitespace warning targets a double space in the YANG model
ietf-ssh-client@2022-08-30.yang, grouping ssh-client-grouping for the
description of the ca-certs container. This is harmless but gives a
sloppy impression and should be addressed.

The two remaining warnings target old draft versions. All these
documents are assumed to be fixed as part of the standardization
process.


A minor editorial change is that the iana-*.yang set of modules
could squash the current two revisions to only one revision, i.e.
"Inital version", since they will be officially released when the
document is published.

Should the iana-*.yang modules be regenerated before the document is
published and then replace "June 16th, 2022" with the new date; and the
same for the YANG module revision date? Or should it be kept as is with
2022-06-16 as the date?

When reviewing iana-ssh-key-exchange-algs.yang it was found that the
identities for key exchange methods diffie-hellman-group-exchange-sha1
and diffie-hellman-group1-sha1 should be marked with "status
deprecated;", see question 7 for details.

The YANG modules for the IANA algorithm listings should contain a
section with information corresponding to the first paragraph of
Section 2.3, listing the normative references in the following YANG
module. All such references should also be listed in
Section 7.1 Normative References.

For iana-ssh-encryption-algs.yang include normative references:
* FIPS-46-3
* RFC 4253
* RFC 4344
* RFC 5647
* RFC 8758

For iana-ssh-key-exchange-algs.yang include normative references:
* RFC 4419
* RFC 4432
* RFC 8268
* RFC 8308
* RFC 8731
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For iana-ssh-mac-algs.yang include normative references:
* RFC 4253
* RFC 5647
* RFC 6668

For iana-ssh-public-key-algs.yang include normative references:
* RFC 4253
* RFC 4462
* RFC 5656
* RFC 6187
* RFC 8332
* RFC 8709

For ietf-ssh-common.yang include normative references:
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For ietf-ssh-client.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types

For ietf-ssh-server.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types


Regarding the ietf-ssh-common grouping transport-params-grouping
referencing Section 5 Security Considerations later in the document, for
host-key algorithm compatibility with the private key; there is no such
presentation of compatible combinations in the current revision, -30, of
the document. This compatibility matrix was added in revision -08 and
subsequently removed in revision -19. This compatibility matrix might
however be out of scope for this document, but another reference to
relevant RFCs is suitable. Whatever path is taken, the reference needs
to be updated.


The ietf-ssh-client container keepalives should reference unresponsive
SSH servers in the description, not TLS servers.

the aliveness of the SSH server.  An unresponsive TLS
server is dropped after approximatively max-wait *

    -> the aliveness of the SSH server.  An unresponsive SSH
      server is dropped after approximatively max-wait *

Likewise the ietf-ssh-client leaf max-wait in the keepalives container
should reference SSH not TLS.

  no data has been received from the SSH server, a
  TLS-level message will be sent to test the
  aliveness of the SSH server.";

    -> no data has been received from the SSH server, an
      SSH-level message will be sent to test the
      aliveness of the SSH server.";

The user "mary" in ex-ssh-server-local.xml has two public keys listed,
they are listed as "User A" and "User B". Suggest naming them
differently to indicate that they are used by the same user "mary" on
different devices, e.g. "Key #1" and "Key #2".


The ietf-ssh-server container keepalives should reference unresponsive
SSH clients in the description, not SSL clients.

  the aliveness of the SSL client. an unresponsive SSL
  client is dropped after approximately max-wait *

    -> the aliveness of the SSH client. an unresponsive SSH
      client is dropped after approximately max-wait *

Likewise the ietf-ssh-server leafs seconds and max-attempts in the
keepalives container should reference SSH not SSL.

keepalives/seconds description:

  if no data has been received from the SSL client,
  a SSL-level message will be sent to test the
  aliveness of the SSL client.";

    -> if no data has been received from the SSH client,
      an SSH-level message will be sent to test the
      aliveness of the SSH client.";

keepalives/max-attempts description:

  the SSL client before assuming the SSL client is

    -> the SSH client before assuming the SSH client is


An observation is that not all uint types specify a range,
e.g. keepalives/max-wait is a uint16 which specifies the range "1..max"
but keepalives/max-attempts is a uint8 without range specification.

This is also inconsistent in other models in the draft set and it can
also be inconsistent in the same model. Is this intended?


Section 6.6

Also mention the "status" statement "obsolete", since it is present in
the YANG module identities listing.

Furthermore, the column to track algorithm status seems to be present
alreday in the IANA Protocol registry for the SSH Protocol.


15. Should any informative references be normative or vice-versa? See the
    IESG Statement on Normative and Informative References [13].

Shepherd:

The informative reference RFC 7317 (iana-crypt-hash.yang) should be
normative, since it is imported in ietf-ssh-server.yang.

Otherwise the listed normative and informative references are correctly
listed.


16. List any normative references that are not freely available to
    anyone. Did the community have sufficient access to review any such
    normative references?

Shepherd:

All normative references are freely available to the public.


17. Are there any normative downward references (see RFC 3967 [14] and
    BCP 97 [15]) that are not already listed in the DOWNREF
    registry [16]? If so, list them.

Shepherd:

There are no normative downward references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear
    state? If so, what is the plan for their completion?

Shepherd:

The normative references to the internet drafts ietf-crypto-types,
ietf-keystore, and ietf-trust-anchors, will all be submitted
simultaneously to the IESG for review.


19. Will publication of this document change the status of any existing
    RFCs? If so, does the Datatracker metadata correctly reflect this and
    are those RFCs listed on the title page, in the abstract, and
    discussed in the introduction? If not, explain why and point to the
    part of the document where the relationship of this document to these
    other RFCs is discussed.

Shepherd:

The publication of this document will not change the status of any
existing RFCs.


20. Describe the document shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all aspects of the document requiring IANA
    assignments are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that each newly created IANA registry
    specifies its initial contents, allocations procedures, and a
    reasonable name (see RFC 8126 [17]).

Shepherd:

The IANA Considerations section has been reviewed. The document
registers seven URIs and seven YANG models.

All aspects of the document requiring IANA Considerations are associated
with appropriate reservations in the IANA registries.

Any referenced IANA registries are cleary identified.

Each newly created IANA registry specifies its initial contents,
allocation procedures, and reasonable names.


21. List any new IANA registries that require Designated Expert Review
    for future allocations. Are the instructions to the Designated Expert
    clear? Please include suggestions of designated experts, if
    appropriate.

Shepherd:

The new IANA registries will not require Designated Expert review for
future allocations.


[1] https://www.ietf.org/about/groups/iesg/
[2] https://datatracker.ietf.org/doc/rfc4858/
[3] https://datatracker.ietf.org/doc/rfc7942/
[4] https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5] https://datatracker.ietf.org/doc/rfc8342/
[6] https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7] https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[8] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[9] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[10] https://datatracker.ietf.org/doc/bcp79/
[11] https://www.ietf.org/tools/idnits/
[12] https://authors.ietf.org/en/content-guidelines-overview
[13] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[14] https://datatracker.ietf.org/doc/rfc3967/
[15] https://www.rfc-editor.org/info/bcp97
[16] https://datatracker.ietf.org/doc/downref/
[17] https://datatracker.ietf.org/doc/rfc8126/

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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "encryption-alg-base";
---
>      base encryption-alg-base;
62d58
<
395d390
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "key-exchange-alg-base";
---
>      base key-exchange-alg-base;
62d58
<
1532c1528
<      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP256-SHA256-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1672c1668
<      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP384-SHA384-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
1812c1808
<      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-NISTP521-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2093c2089
<      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
---
>      "GSS-CURVE448-SHA512-1.2.840.10045.3.1.1 (nistp192, secp192r1)";
2223d2218
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "mac-alg-base";
---
>      base mac-alg-base;
62d58
<
169d164
<


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

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

8d7
<
16d14
<
44d41
<
56c53
<      base "public-key-alg-base";
---
>      base public-key-alg-base;
62d58
<
443d438
<


export f=ietf-ssh-client@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
39d34
<
45d39
<
142d135
<
249d241
<
270,271c262,263
<          refine
<            "local-or-truststore/local/local-definition/public-key" {
---
>          refine "local-or-truststore/local/local-definition"
>                + "/public-key" {
275,276c267,268
<          refine
<            "local-or-truststore/truststore/truststore-reference" {
---
>          refine "local-or-truststore/truststore"
>                + "/truststore-reference" {
314d305
<
322d312
<
326,328c316,317
<      presence
<        "Indicates that the SSH client proactively tests the
<          aliveness of the remote SSH server.";
---
>      presence "Indicates that the SSH client proactively tests the
>                aliveness of the remote SSH server.";
332c321
<          server is dropped after approximately max-wait *
---
>          server is dropped after approximately max-wait *


export f=ietf-ssh-common@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
44d38
<
50d43
<
216c209
<        default cleartext;
---
>        default "cleartext";
231,232c224,225
<                "Indicates that the key is to be encrypted using
<                the specified symmetric or asymmetric key.";
---
>              "Indicates that the key is to be encrypted using
>                the specified symmetric or asymmetric key.";


export f=ietf-ssh-server@2022-09-16.yang
pyang --ietf $f
yanglint $f

pyang -f yang --keep-comments --yang-line-length 69 $f > new.yang \
&& diff $f new.yang

11d10
<
17d15
<
23d20
<
29d25
<
35d30
<
45d39
<
51d44
<
160d152
<
197d188
<
215c206
<            ks:local-or-keystore-end-entity-cert-with-key-grouping {
---
>              ks:local-or-keystore-end-entity-cert-with-key-grouping {
220,221c211,213
<              refine "local-or-keystore/keystore/keystore-reference"
<                    + "/asymmetric-key" {
---
>              refine
>                "local-or-keystore/keystore/keystore-reference"
>              + "/asymmetric-key" {
224c216
<                  + 'format, "ct:subject-public-key-info-format")';
---
>                + 'format, "ct:subject-public-key-info-format")';
231d222
<
251c242
<              must authenticate to all configured methods.
---
>              must authenticate to all configured methods.
368d358
<
376d365
<
380,382c369,370
<      presence
<        "Indicates that the SSH server proactively tests the
<          aliveness of the remote SSH client.";
---
>      presence "Indicates that the SSH server proactively tests the
>                aliveness of the remote SSH client.";


8.  Describe reviews and automated checks performed to validate sections
    of the final version of the document written in a formal language,
    such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Shepherd:

The document's XML snippets have been validated with yanglint 2.0.112.

All but the following examples validated correctly. The modules below did
not validate correctly with yanglint, even though they seem to be well
formed and fulfill the must requirements. Perhaps it is an operator
error during review?


refs/ex-ssh-client-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-client-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-client@2022-09-16.yang \
    ex-ssh-client-keystore.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-local.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ex-ssh-server-local.xml \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml
Segmentation fault


refs/ex-ssh-server-keystore.xml:

$ yanglint -m ../ietf-crypto-types\@*.yang ../ietf-truststore\@*.yang \
    ../ietf-keystore\@*.yang ../ietf-ssh-common\@*.yang ./ietf-origin.yang \
    ietf-ssh-server@2022-09-16.yang \
    ../../trust-anchors/refs/ex-truststore.xml \
    ../../keystore/refs/ex-keystore.xml \
    ex-ssh-server-keystore.xml
Segmentation fault


Document Shepherd Checks
------------------------

9.  Based on the shepherd's review of the document, is it their opinion
    that this document is needed, clearly written, complete, correctly
    designed, and ready to be handed off to the responsible Area
    Director?

Shepherd:

The document is needed, clearly written, complete, and correctly
designed.

However, since there are new nontrivial contributions to the document
since the last round of reviews from formal experts, new reviews from
SecDir and YANG Doctors are suggested. This is also hinted by the
author. See question 6 above.

There are also various issues found during document shepherd review, see
questions 7, 8, and 14 for these.

Otherwise the document is ready for handoff to the responsible Area
Director.


10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter [6]. For which areas have such issues been
    identified and addressed? For which does this still need to happen
    in subsequent reviews?

Shepherd:

No common issues have been identified, thus no further detailed review
is needed.


11. What type of RFC publication is being requested on the IETF stream
    (Best Current Practice [7], Proposed Standard, Internet Standard [8],
    Informational, Experimental or Historic [9])? Why is this the proper
    type of RFC? Do all Datatracker state attributes correctly reflect
    this intent?

Shepherd:

The RFC status requested is Proposed Standard.

This is the correct RFC status because it is a standardization of the
configuration of, configuration parameters, and methods, to configure
and setup SSH clients and servers.

The Datatracker correctly reflects the requested RFC status:
https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/


12. Have reasonable efforts been made to remind all authors of the
    intellectual property rights (IPR) disclosure obligations described
    in BCP 79 [10]? To the best of your knowledge, have all required
    disclosures been filed? If not, explain why. If yes, summarize any
    relevant discussion, including links to publicly-available messages
    when applicable.

Shepherd:

No IPR disclosure have been raised in reference to this document.

The WG chair requested an IPR poll. The author confirmed that they are
not aware of any IPR related to this document. No IPR disclosures were
made.

Direct link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netconf/rS4SV38blMOgX0Ez7mw9E9B9sx0/


13. Has each author, editor, and contributor shown their willingness to
    be listed as such? If the total number of authors and editors on the
    front page is greater than five, please provide a justification.

Shepherd:

There is one author and one contributor for this document, no editors
are listed.

The author has not explicitly confirmed willingness to be listed as an
author but has driven the adoption, discussions, work, and updates of
the document. Thus, the author is assumed to willingly be listed as
such.

Regarding the contributor, they were previously listed as a draft
co-author but were silently removed in document revision -22. However,
the contributor is listed as author since revision -01 for the
ietf-ssh-* YANG models, of which they are especially attributed to have
contributed to ietf-ssh-common.yang. Thus, it is assumed that they are
willingly listed as contributors.


14. Document any remaining I-D nits in this document. Simply running the
    idnits tool [11] is not enough; please review the "Content
    Guidelines" [12] on authors.ietf.org. (Also note that the current
    idnits tool generates some incorrect warnings; a rewrite is
    underway.)

Shepherd:

I-D nits was tested against revision -30 of the draft.

Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

Two warnings target whitespace formatting.

One of them being for YANG tree diagamrs following the format from RFC
8340. This warning is harmless.

The second whitespace warning targets a double space in the YANG model
ietf-ssh-client@2022-08-30.yang, grouping ssh-client-grouping for the
description of the ca-certs container. This is harmless but gives a
sloppy impression and should be addressed.

The two remaining warnings target old draft versions. All these
documents are assumed to be fixed as part of the standardization
process.


A minor editorial change is that the iana-*.yang set of modules
could squash the current two revisions to only one revision, i.e.
"Inital version", since they will be officially released when the
document is published.

Should the iana-*.yang modules be regenerated before the document is
published and then replace "June 16th, 2022" with the new date; and the
same for the YANG module revision date? Or should it be kept as is with
2022-06-16 as the date?

When reviewing iana-ssh-key-exchange-algs.yang it was found that the
identities for key exchange methods diffie-hellman-group-exchange-sha1
and diffie-hellman-group1-sha1 should be marked with "status
deprecated;", see question 7 for details.

The YANG modules for the IANA algorithm listings should contain a
section with information corresponding to the first paragraph of
Section 2.3, listing the normative references in the following YANG
module. All such references should also be listed in
Section 7.1 Normative References.

For iana-ssh-encryption-algs.yang include normative references:
* FIPS-46-3
* RFC 4253
* RFC 4344
* RFC 5647
* RFC 8758

For iana-ssh-key-exchange-algs.yang include normative references:
* RFC 4419
* RFC 4432
* RFC 8268
* RFC 8308
* RFC 8731
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For iana-ssh-mac-algs.yang include normative references:
* RFC 4253
* RFC 5647
* RFC 6668

For iana-ssh-public-key-algs.yang include normative references:
* RFC 4253
* RFC 4462
* RFC 5656
* RFC 6187
* RFC 8332
* RFC 8709

For ietf-ssh-common.yang include normative references:
* RFC 8732, since RFC 5656 is listed
* RFC 9142, since RFC 5656 is listed

For ietf-ssh-client.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types

For ietf-ssh-server.yang include normative references:
* RFC 4252
* RFC 4254
* RFC 8341
* I-D.ietf-crypto-types


Regarding the ietf-ssh-common grouping transport-params-grouping
referencing Section 5 Security Considerations later in the document, for
host-key algorithm compatibility with the private key; there is no such
presentation of compatible combinations in the current revision, -30, of
the document. This compatibility matrix was added in revision -08 and
subsequently removed in revision -19. This compatibility matrix might
however be out of scope for this document, but another reference to
relevant RFCs is suitable. Whatever path is taken, the reference needs
to be updated.


The ietf-ssh-client container keepalives should reference unresponsive
SSH servers in the description, not TLS servers.

the aliveness of the SSH server.  An unresponsive TLS
server is dropped after approximatively max-wait *

    -> the aliveness of the SSH server.  An unresponsive SSH
      server is dropped after approximatively max-wait *

Likewise the ietf-ssh-client leaf max-wait in the keepalives container
should reference SSH not TLS.

  no data has been received from the SSH server, a
  TLS-level message will be sent to test the
  aliveness of the SSH server.";

    -> no data has been received from the SSH server, an
      SSH-level message will be sent to test the
      aliveness of the SSH server.";

The user "mary" in ex-ssh-server-local.xml has two public keys listed,
they are listed as "User A" and "User B". Suggest naming them
differently to indicate that they are used by the same user "mary" on
different devices, e.g. "Key #1" and "Key #2".


The ietf-ssh-server container keepalives should reference unresponsive
SSH clients in the description, not SSL clients.

  the aliveness of the SSL client. an unresponsive SSL
  client is dropped after approximately max-wait *

    -> the aliveness of the SSH client. an unresponsive SSH
      client is dropped after approximately max-wait *

Likewise the ietf-ssh-server leafs seconds and max-attempts in the
keepalives container should reference SSH not SSL.

keepalives/seconds description:

  if no data has been received from the SSL client,
  a SSL-level message will be sent to test the
  aliveness of the SSL client.";

    -> if no data has been received from the SSH client,
      an SSH-level message will be sent to test the
      aliveness of the SSH client.";

keepalives/max-attempts description:

  the SSL client before assuming the SSL client is

    -> the SSH client before assuming the SSH client is


Section 6.6

Also mention the "status" statement "obsolete", since it is present in
the YANG module identities listing.

Furthermore, the column to track algorithm status seems to be present
alreday in the IANA Protocol registry for the SSH Protocol.


15. Should any informative references be normative or vice-versa? See the
    IESG Statement on Normative and Informative References [13].

Shepherd:

The informative reference RFC 7317 (iana-crypt-hash.yang) should be
normative, since it is imported in ietf-ssh-server.yang.

Otherwise the listed normative and informative references are correctly
listed.


16. List any normative references that are not freely available to
    anyone. Did the community have sufficient access to review any such
    normative references?

Shepherd:

All normative references are freely available to the public.


17. Are there any normative downward references (see RFC 3967 [14] and
    BCP 97 [15]) that are not already listed in the DOWNREF
    registry [16]? If so, list them.

Shepherd:

There are no normative downward references.


18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear
    state? If so, what is the plan for their completion?

Shepherd:

The normative references to the internet drafts ietf-crypto-types,
ietf-keystore, and ietf-trust-anchors, will all be submitted
simultaneously to the IESG for review.


19. Will publication of this document change the status of any existing
    RFCs? If so, does the Datatracker metadata correctly reflect this and
    are those RFCs listed on the title page, in the abstract, and
    discussed in the introduction? If not, explain why and point to the
    part of the document where the relationship of this document to these
    other RFCs is discussed.

Shepherd:

The publication of this document will not change the status of any
existing RFCs.


20. Describe the document shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document. Confirm that all aspects of the document requiring IANA
    assignments are associated with the appropriate reservations in IANA
    registries. Confirm that any referenced IANA registries have been
    clearly identified. Confirm that each newly created IANA registry
    specifies its initial contents, allocations procedures, and a
    reasonable name (see RFC 8126 [17]).

Shepherd:

The IANA Considerations section has been reviewed. The document
registers seven URIs and seven YANG models.

All aspects of the document requiring IANA Considerations are associated
with appropriate reservations in the IANA registries.

Any referenced IANA registries are cleary identified.

Each newly created IANA registry specifies its initial contents,
allocation procedures, and reasonable names.


21. List any new IANA registries that require Designated Expert Review
    for future allocations. Are the instructions to the Designated Expert
    clear? Please include suggestions of designated experts, if
    appropriate.

Shepherd:

The new IANA registries will not require Designated Expert review for
future allocations.


[1] https://www.ietf.org/about/groups/iesg/
[2] https://datatracker.ietf.org/doc/rfc4858/
[3] https://datatracker.ietf.org/doc/rfc7942/
[4] https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5] https://datatracker.ietf.org/doc/rfc8342/
[6] https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7] https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[8] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[9] https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[10] https://datatracker.ietf.org/doc/bcp79/
[11] https://www.ietf.org/tools/idnits/
[12] https://authors.ietf.org/en/content-guidelines-overview
[13] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[14] https://datatracker.ietf.org/doc/rfc3967/
[15] https://www.rfc-editor.org/info/bcp97
[16] https://datatracker.ietf.org/doc/downref/
[17] https://datatracker.ietf.org/doc/rfc8126/