Subject: [CCAMP] Last Call: <draft-ietf-ccamp-wson-yang-25.txt> (A YANG Data Model for WSON (Wavelength Switched Optical Networks)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 16 Sep 2020 13:45:20 -0700

The IESG has received a request from the Common Control and Measurement Plane
WG (ccamp) to consider the following document: - 'A YANG Data Model for WSON
(Wavelength Switched Optical Networks)'
  <draft-ietf-ccamp-wson-yang-25.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-09-30. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document provides a YANG data model for the routing and
   wavelength assignment (RWA) TE topology in wavelength switched
   optical networks (WSONs).  The YANG data model defined in this
   document conforms to the Network Management Datastore Architecture
   (NMDA).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-yang/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-ietf-ccamp-optical-impairment-topology-yang: A Yang Data Model for Optical Impairment-aware Topology (None - IETF stream)
    draft-ietf-ccamp-flexigrid-yang: YANG data model for Flexi-Grid Optical Networks (None - IETF stream)

---

From: tom petch <[email-masked]>
Date: Thu, 17 Sep 2020 11:25:54 +0100

> of the Subject line to allow automated sorting.

Two glitches and some trivia:

Introduction
/impairement/impairment/

The only key word I see is a 'should' in IANA which is going to go so 
whether or not Requirements Language should be included is a moot point.

YANG import for layer0-types references the wrong I-D

YANG module description talks of two encoding documents but omits RFC7581

grouping wson-node-attributes has the same 'e.g.' for both true and 
false which looks odd; and I wonder if 'i.e.' is intended

the e-mail address for Aihua Guo is different for the YANG module and 
for Authors' Addresses

Tom Petch

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: tom petch <[email-masked]>
Date: Wed, 23 Sep 2020 11:05:42 +0100

A new verson of this I-D has been posted with substantial changes.  In 
particular, the sequence of definitions in the YANG module has been 
changed while the YANG tree diagram has not been updated to match.  Look 
for example at augments 4, 5, 6 and 7.  In the tree diagram, as in -25, 
they are to label-start, label-end, label-step, label-hop; in the module 
they are to 'from', 'to' and then switch from node attributes to 
information source.

It is technically possible for me to review -26 against -25 but it would 
take so long that I am not going to do it.  My review is to compare, 
side by side, old and new, so resequencing destroys that and with a 62 
page I-D I will not contemplate any other approach.

A new tree diagram, to match the YANG module, again would not make it 
feasible.  The module sequence needs to be the same as in -25 for me.

Tom Petch

On 17/09/2020 11:25, tom petch wrote:
>>      draft-ietf-ccamp-optical-impairment-topology-yang: A Yang Data
>> Model for Optical Impairment-aware Topology (None - IETF stream)

---

From: tom petch <[email-masked]>
Date: Wed, 30 Sep 2020 17:44:53 +0100

One final thought on this I-D.  As most of you will have seen,
I have queried the placement of the network type wson-topology
under te-topology instead of under network-types not seeing
an explanation of the rationale of the tree structure in the RFC that 
set up the namespace for this scenario.  I struggle to see the benefit 
of one over the other when it comes to using the YANG modules in a 
network, creating the data and accessing it, and have a vague concern 
that this hierarchy may turn out to be limiting in future.
However, noone else agrees with me so I will leave it at that; I post
this here for completeness, the discussion having spanned three WG.
I note that the other CCAMP modules use the same placement.

Tom Petch