Re: [CCAMP] Benjamin Kaduk's No Objection on draft-ietf-ccamp-wson-yang-27: (with COMMENT)

[Zhenghaomian <[e-mail]>]

Hi Benjamin, 

Thank you for the review and comments, please find our revision attached and some responses inline. Let us know if you have any other comments. 

Best wishes,
Haomian (on behalf of all authors)

-----邮件原件-----
发件人: Benjamin Kaduk via Datatracker [mailto:[e-mail]] 
发送时间: 2020年12月2日 11:02
收件人: The IESG <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; Daniele Ceccarelli <[e-mail]>; [e-mail]
主题: Benjamin Kaduk's No Objection on draft-ietf-ccamp-wson-yang-27: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ccamp-wson-yang-27: 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-wson-yang/



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

These changes would have been much easier to review if we could just issue a new version of te-types that included the WSON label and type information!  But I recognize that such a thing is not done lightly and so the current structure came to be.  That said, I assume that some kind of automated tooling has been used in order to verify that the set of augmented nodes is complete.  If not, that should probably be done before publication.
[Authors] Yes, there is an automated script used for augmentation generic model and has been used in multiple documents. 


Section 3

I greatly appreciate the attention to detail that went into this YANG module.  It is sadly all too common for (e.g.) the description to not be updated when using copy/paste to repeat a stanza for a similar sibling node (such as a range's start/end), but these all look to have the description match the node name.  Thank you!

     augment "/nw:networks/tet:te/tet:templates/"
           + "tet:link-template/tet:te-link-attributes/"
           + "tet:underlay/tet:primary-path/tet:path-element/tet:type/"
           + "tet:label/tet:label-hop/tet:te-label/tet:technology" {
       description
         "Augment TE label hop for the underlay primary path
          of the TE link template.";

Why do we not need to limit this/these to when the te-topology is of WSON type?  Is it because this is only a link template and not an actual link?
[Authors] Yes you are right, this is only a link template and not an actual link, so there is no network-type associated. 

Section 4

   There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

I think we need another sentence or two more here, to expand on the nature of the "negative effect on network operations".  (My understanding is that, basically, if these values are set improperly, no data will pass at all, but please confirm that.)

We should probably also incorporate (by reference) the security considerations of the underlying WSON technologies.

   /nw:networks/nw:network/.../tet:te-bandwidth/tet:technology

I couldn't find where tet:te-bandwidth is used/referenced.

[Authors] This results in a comprehensive change. The current text was following some old versions of RFC8795, and we are revising to align with the latest text in RFC8795 (by skipping detailed path description). It is worth noting that a new paragraph about 'readable data' is also added. 

Section 7.1

I'm having trouble coming up with criteria that make [ITU-Tg6982] a normative reference of this document but not of the layer0-types companion document.  Should it be classified the same way in both documents?  (My preference would be to reclassify it to normative in layer0-types, I think.)

[Authors] Ok, this results in moving the ITU-T G.698.2 to normative in layer0-type document. There is no changes for this document. 

Section 7.2

We refer to RFCs 7446 and 7581 for enough things that they seems more properly categorized as normative.  (Not least, for terminology.)
[Authors] done and refer to the attached.