Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-netconf-ssh-client-server-37 Reviewer: Elwyn Davies Review Date: 2024-02-14 IETF LC End Date: 2024-02-12 IESG Telechat date: 2024-02-29 Summary:Almost ready. The majority of points are editorial nits, however the proposed mechanism for generating YANG modules to provide automated access to certain sets of options defined in IANA registries is not explained at all in the introduction and needs to be. I also feel that the authors need to consider (and may have already done this) whether they should supply automation scripts that will assist IANA in creating and checking the updated YANG modules that they are to be asked to generate when the relevant registry entries are updated. I have not attempted to check that the IETF YANG modules are correct or complete as I do not have the SSH knowledge at my fingertips. I wonder if the mechanism needs a designated expert to deal with naming queries and help with any issues in creating the IANA YANG modules rather than passing this burden to the NETCONF WG chair - which rather assumes the NETCONF WG will be around for ever. Major issues: None Minor issues: General: The document contains a number of references to the NETCONF WG chairs and the NETCONF WG mailing list. Is this adequately future proof? General: Although this is not directly relevant to the draft, it occurs to me that since IANA is being requested to edit YANG modules in response to registry changes and the resulting modules would be expected to be read by protocol implementations, it would be desirable if IANA was supplied with scripts that could be used to automatically update the IANA modules and run the YANG checker script to ensure the syntactical correctness of the updates. The changes resulting from these updates should be automatically backwards compatible so updating the modules should not be problematic. S2.1.1: The last paragraph of this section reads: The diagram above uses syntax that is similar to but not defined in [RFC8340]. In that case had the syntax better be defined in this document? Nits/editorial comments: Abstract, para 2: I suggest s/enabling/supporting/ since the YANG modules provide a standardised framework rather than actually providing the only way of configuration of SSH entities. Abstract, para 3: Similarly, s/for an IANA-maintained/providing support for an IANA-maintained/. Introduction, s1: This section is very bald. In particular, the introduction is silent about the purpose of the IANA modules. It should, in the way of convention, contain similar words to paragraphs 2 and 3 of the abstract to explain the purpose of the document. The section should also contain a subsection similar to s1.1 to explain the purposes of the IANA modules and how they are created and maintained since the draft only defines the format and not the exact contents of the YANG modules. s1.1, para 1: s/more so than/rather than/, s/advance/extended/ s1.2, para 1: as with the Abstract s/enable/support/ Table 1: This table should have a RFC Editor note to clarify that the right hand column needs to be updated with the references to the RFCs that will hopefully result from the approval of the referenced I-Ds. For convenience of readers, I hope that the keys will be of the form RFCxxxx to reduce reader effort in working out what documents are reference. s1.4: The jargon <operational> should be replaced by 'operational state datastore' with a reference to Section 5.3 of RFC 8342. s2.3: OLD: rpc generate-asymmetric-key-pair { if-feature "asymmetric-key-pair-generation"; description "Requests the device to generate an public key using the specified key algorithm."; NEW: rpc generate-asymmetric-key-pair { if-feature "asymmetric-key-pair-generation"; description "Requests the device to generate a public key using the specified key algorithm."; END ss6.3-6.6: In the 5th para of the boilerplate text in each of these 4 sections: s/is a invalid for a YANG identity/is not a lexically valid name for a YANG identity/ Also 4 paragraphs from the end of each section: s/that points to the where the module was published./that points to the document defining the registry update that resulted in this change./ Appendix A: I think the intention of the instruction to remove Appendix A before publication only applies to the program in the header section rather than the whole Appendix which contains the initial creations of the IANA modules. I take it that the program will be rerun if necessary after the draft has been approved in case there have been registry updates since the last draft update. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
