[Gen-art] Genart last call review of draft-ietf-netconf-ssh-client-server-37

[Elwyn Davies via Datatracker]

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

.

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 RFC to reduce reader
effort in working out what documents are reference.

s1.4: The jargon  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 

Re: [Gen-art] [CCAMP] Genart last call review of draft-ietf-ccamp-layer1-types-16

[Italo Busi]

Dear Dale, 

Thank you for the review, the authors have updated the document to address your 
comments and posted the updated document as draft-ietf-ccamp-layer1-types-17

For clarity we have included the proposed resolution for each issue identified 
in the text below [Haomian & Italo]. 

Last month we received a YANG Doctors Review the latest version of the module 
(in v16), and have address several comments/suggestions made by Rob.  

Again, thanks for the support and review. 

Authors, Haomian and Italo.

> -Original Message-
> From: Dale Worley via Datatracker 
> Sent: giovedì 16 novembre 2023 22:16
> To: gen-art@ietf.org
> Cc: cc...@ietf.org; draft-ietf-ccamp-layer1-types@ietf.org; last-
> c...@ietf.org
> Subject: [CCAMP] Genart last call review of draft-ietf-ccamp-layer1-types-16
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:  draft-ietf-ccamp-layer1-types-16
> Reviewer:  Dale R. Worley
> Review Date:  2023-11-16
> IETF LC End Date:  2023-11-21
> IESG Telechat date:  [not known]
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
> 
> I recommend the Yang Doctors check the Yang module again.  The last Yang
> Doctor check was done on the -04 version, this is the -16 version, and the
> Yang has changed considerably since then.
> 
> Nits/editorial comments:
> 
> Different parts of the text disagree on whether (1) this module is applicable
> to all layer 1 networks, but is primarily expected to be used for OTN layer 1
> networks, or (2) is applicable to OTN layer networks.  E.g. the two sentences
> of the Abstract seem to take opposite approaches, sec. 4.1 seems to be OTN-
> specific.  Presumably the intention is agreed upon; the text needs to be
> made consistent with the intention.
> 

[Haomian & Italo] Ok, we see the need to be clearer in the Abstract, and 
Section 4.1.

>3.  Prefix in Data Node Names
> 
>   +-+---+--+
>   | Prefix  | YANG module   | Reference|
>   +-+---+--+
>   | l1-types| ietf-layer1-types | This Document|
>   +-+---+--+
>  Table 1: Prefixes and Corresponding YANG Modules
> 
> 
>RFC Editor Note: Please replace  with the number assigned to the
>RFC once this draft becomes an RFC.
> 
> Should "This Document" be replaced by "RFC "?
> 

[Haomian & Italo] Yes, updated.

>6.  YANG Code for Layer1 Types
> 
>  identity ODU0 {
>base odu-type;
>description
>  "ODU0 type (1.24Gb/s).";
> 
> For "description" values that are not full sentences, there is inconsistency
> whether the value ends with a period or not.  There is also inconsistency in
> values that are full sentences.  (Perhaps this is a matter for the Editor.)
> 

[Haomian & Italo] Ok, thanks. We have reviewed and used the current convention, 
and updated as needed.

>Appendix A.  Examples of OTN Label Ranges
> 
> There are several instances of
> 
>  "//not-present tsg": "",
> 
> I suspect they are intended to be
> 
>  "// not-present tsg": "",
> 

[Haomian & Italo] Thanks, good catch as well.

> [END]
> 
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-lamps-pkcs12-pbmac1-07

[Roni Even via Datatracker]

Reviewer: Roni Even
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-lamps-pkcs12-pbmac1-??
Reviewer: Roni Even
Review Date: 2024-02-13
IETF LC End Date: 2024-02-22
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is ready for publication as an informational RFC with nits

Major issues:

Minor issues:

Nits/editorial comments:
1. Section 3 if needed should include the reference to RC8174 as in the
following text: “The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown
here.”

2. In appendix B you should have a note to the RFC editor to relocate the TBD
value with the value assigned by IANA



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art