Skip to main content

A YANG Data Model for Wavelength Switched Optical Networks (WSONs)
draft-ietf-ccamp-wson-yang-28

Yes

(Deborah Brungard)

No Objection

Erik Kline
Warren Kumari
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Magnus Westerlund)
(Martin Vigoureux)

Note: This ballot was opened for revision 27 and is now closed.

Erik Kline
No Objection
Murray Kucherawy
No Objection
Comment (2020-12-02 for -27) Sent
The shepherd writeup says "This is the proper type of RFC" but the question being asked is "Why... ?"

12 versions and two years have passed, resulting in a sizeable diff, since the YANGDOCTORS review.  Should a more recent one have been done?
Roman Danyliw
No Objection
Comment (2020-12-02 for -27) Sent
** Section 4. Thank you for using the YANG Security Considerations template.  The text only notes the sensitivity of data nodes for write-operations.  Customarily, there is a statement about nodes considered sensitive for reading – are there none here?

** Section 1.2. Editorial.  s/used in chapter 2/used in Section 2/
Warren Kumari
No Objection
Éric Vyncke
No Objection
Comment (2020-11-27 for -27) Sent
Thank you for the work done in this document.

There are a couple of wrong/unused references identified by the ID-nits tool, you may want to check.

Regards

-éric
Deborah Brungard Former IESG member
Yes
Yes (for -27) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -27) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -27) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -27) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2020-12-01 for -27) Sent
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.

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?

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.

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.)

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.)
Magnus Westerlund Former IESG member
No Objection
No Objection (for -27) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -27) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2020-12-03 for -27) Not sent
Thank you for your work on this YANG model.