Skip to main content

Last Call Review of draft-ietf-netconf-ssh-client-server-24
review-ietf-netconf-ssh-client-server-24-yangdoctors-lc-bierman-2021-05-25-00

Request Review of draft-ietf-netconf-ssh-client-server-23
Requested revision 23 (document currently at 40)
Type Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2021-05-07
Requested 2021-04-20
Requested by Mahesh Jethanandani
Authors Kent Watsen
I-D last updated 2021-05-25
Completed reviews Genart Last Call review of -37 by Elwyn B. Davies (diff)
Intdir Telechat review of -38 by Sheng Jiang (diff)
Opsdir Last Call review of -36 by Qin Wu (diff)
Yangdoctors Last Call review of -03 by Andy Bierman (diff)
Yangdoctors Last Call review of -24 by Andy Bierman (diff)
Secdir Last Call review of -24 by Barry Leiba (diff)
Comments
This document was reviewed by a YANG doctor at revision -03. We are now at revision -23, and the document has changed substantially since then. Thus a request to review it again.
Assignment Reviewer Andy Bierman
State Completed
Request Last Call review on draft-ietf-netconf-ssh-client-server by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/6Rh265o_Dh6-A427NHKiZOSnS2Y
Reviewed revision 24 (document currently at 40)
Result Ready
Completed 2021-05-25
review-ietf-netconf-ssh-client-server-24-yangdoctors-lc-bierman-2021-05-25-00
Comments:

1) Measuring Interoperability for groupings and identities

[same comment for SSH and TLS drafts]

These modules are intentionally abstract.
There are no protocol-accessible objects defined at all.
Interoperability is usually measured in the context of a
specific protocol (e.g., NETCONF).

There is an assumption that interoperability will be achieved
by some other RFCs that will have "uses" statements to create
protocol-accessible or otherwise implementable objects.

There is also an assumption that the groupings will be used the
same everywhere, and the only difference will be the
path from root to the objects in these groupings.
In fact, the "refine" statement allows each usage to be
different.

Perhaps the drafts should mention these interoperability issues.

2) same feature names in 2 modules

  - feature userauth-hostbased
  - feature userauth-none
  - feature userauth-password
  - feature userauth-publickey

The ietf-ssh-client and ietf-ssh-server modules both use these
feature names. IMO users will not expect this, and this will cause
confusion.

Why can't these features be defined once in ietf-ssh-common.yang?
Seems like client and server will advertise the feature for
implementing their relevant values.