Subject: [CCAMP] Benjamin Kaduk's No Objection on draft-ietf-ccamp-layer0-types-08: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 01 Dec 2020 15:33:44 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ccamp-layer0-types-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-layer0-types/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2

   YANG module ietf-layer0-types (defined in Section 3) references
   [RFC6163], [RFC7205], and [RFC7698].

RFC 7205 looks like a typo for 6205 -- I don't think that "Use Cases for
Telepresence Multistreams" is relevant for WSON.  That said, we
reference 6205 many times in the rest of the document, so (IIUC) we
don't need to mention it here in order to have a reference in the
document outside of the module itself?

Section 2

I'm not sure how appropriate RFC 6205 is as a reference for all of the
indicated terms; e.g., I don't see mention of "start", "end", "range",
or "hop" as applying to labels, there.

Section 3

     grouping l0-label-range-info {
       description
         "Information for layer 0 label range.";

nit(?): "information for" makes me expect that this will be describing
the range itself, but the contained type and priority seem to be more
metadata about the range than the range itself.  To me, writing
"Information about the layer 0 label range" would feel more natural.

     grouping flexi-grid-label-range-info {
       description
         "Info of Flexi-grid-specific label range";

nit: "Info of" seems rather colloquial; the same "Information about"
construction I suggested above seems like it would work well here, since
this is also a -label-range-info grouping.

It seems unusual to me (admittedly, not a YANG expert) that the
descriptions for min-slot-width-factor and max-slot-width-factor
separately refer to a "range" when each one only provides half of the
range.  I guess this is related to Erik's comment.

              Minimum slot width should be smaller than or equal to
              Maximum slot width. ";

Similarly, this restriction seems like one that can be expressed as a
YANG "must" directive, which it looks like Rob already noted.

Section 4

   modules.  It is critical consider how imported definitions will be
   utilized and accessible via RPC operations, as the resultant schema
   will have data nodes that can be writable, or readable, and will have

nit: "critical to consider"

Section 8.2

Don't RFCs 6163, 6205, 7698, and 8363 need to be normative since they
are used as references for YANG elements?

---

From: Zhenghaomian <[email-masked]>
Date: Wed, 16 Dec 2020 07:35:27 +0000

Hi Benjamin, 

Thank you very much for the comments, see inline for our response. We have also created a pull request on github to capture the module change: https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-layer0-types/pull/15, and also the diffs in the draft is attached in this email for your reference. Please let us know if any other problems. 

Best wishes,
Haomian (on behalf of all authors & contributors)

-----邮件原件-----
发件人: Benjamin Kaduk via Datatracker [mailto:[email-masked]] 
发送时间: 2020年12月2日 7:34
收件人: The IESG <[email-masked]>
抄送: [email-masked]; [email-masked]; [email-masked]; Daniele Ceccarelli <[email-masked]>; [email-masked]
主题: Benjamin Kaduk's No Objection on draft-ietf-ccamp-layer0-types-08: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Section 1.2

RFC 7205 looks like a typo for 6205 -- I don't think that "Use Cases for Telepresence Multistreams" is relevant for WSON.  That said, we reference 6205 many times in the rest of the document, so (IIUC) we don't need to mention it here in order to have a reference in the document outside of the module itself?

[Authors]: should be 6205, fixed in attached.  

Section 2

I'm not sure how appropriate RFC 6205 is as a reference for all of the indicated terms; e.g., I don't see mention of "start", "end", "range", or "hop" as applying to labels, there.

[Authors]: following changes are proposed to address this issue. 
OLD: 
A YANG grouping that defines the label-start or label-end to specify WSON label range as defined in <xref target="RFC6205" />.

NEW: 
WSON label range was defined in <xref target="RFC6205" />, and the generic topology model defines the label-start/label-end in  <xref target="RFC8795" />. This grouping shows the WSON-specific label-start and label-end information. 

Similar changes are made for other explanations, refer to the attached to see the changes before and after. 

Section 3

nit(?): "information for" makes me expect that this will be describing the range itself, but the contained type and priority seem to be more metadata about the range than the range itself.  To me, writing "Information about the layer 0 label range" would feel more natural.

nit: "Info of" seems rather colloquial; the same "Information about"
construction I suggested above seems like it would work well here, since this is also a -label-range-info grouping.

[Authors]: "Information about the layer 0 label range" and "Flexi-grid-specific label range related information" are used in the updated version, the latter is according to the suggestion from Rob in https://mailarchive.ietf.org/arch/msg/ccamp/EaueCtWSbdlW_-14SB-cc_oOYaQ/. Refer to https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-layer0-types/pull/15 for the update. 

It seems unusual to me (admittedly, not a YANG expert) that the descriptions for min-slot-width-factor and max-slot-width-factor separately refer to a "range" when each one only provides half of the range.  I guess this is related to Erik's comment.

Similarly, this restriction seems like one that can be expressed as a YANG "must" directive, which it looks like Rob already noted.

[Authors]: This will be discussed in Rob's thread, and resolved by introducing a 'must'. Refer to https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-layer0-types/pull/15 for the update. 

Section 4

nit: "critical to consider"
[Authors]: fixed in attached. 

Section 8.2

Don't RFCs 6163, 6205, 7698, and 8363 need to be normative since they are used as references for YANG elements?
[Authors]: fixed in attached.