Re: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

[tom petch <[e-mail]>]

From: CCAMP <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: 06 January 2022 20:35

Thanks, Adrian. We appreciate the review.

It’s good to have reviews, thanks WG!

We also captured a few LC comments from Tom, and we will address all current (and any new) issues after LC ends.

<tp>
I commented before that I struggle with the complexity of the 'when' statements in many CCAMP and TEAS I-D such as this one.

Is it 
      when "../../../../../../../../../../"
          + "nw:network-types/tet:te-topology/"
 or
      when "../../../../../../../../../"
          + "nw:network-types/tet:te-topology/"
 or
      when "../../../../../../../nw:network-types/tet:te-topology/"
    
? answer all of them depending!

I speculated that the absolute form of the path statement would be much simpler but it was pointed out to me by Martin that that would not work as 'nw:network is a list and so would return true if 'flexi-grid-topology' appeared anywhere in the list which in this case it is almost bound to; but there is the XPath 'ancestor' function which returns true only if the value appears in an immediate ancestor of the context node.  This is almost what I want the caveat being that it returns true if any of the predicates - e.g. primary-path, route-object-exclude-object, etc -  has the value  in question but I believe that that will never be the case.

In which case, 
 when "ancestor::node()/nw:network-types/tet:te-topology"
as proposed by Lada will do the job for almost all the 'when' statements (and I can understand it ).

The thread is on the netmod WG list from 29dec21 under the subject
YANG 'when' with absolute path

Tom Petch

BR, Dan.

From: Adrian Farrel <[e-mail]>
Sent: 06 January 2022 20:32
To: 'Daniele Ceccarelli' <[e-mail]>; [e-mail]
Cc: 'CCAMP' <[e-mail]>
Subject: RE: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

Hi Daniele and authors,

Here is my review of this draft in WG last call.

tl;dr This is ready for publication with some nits that need to be
sorted out.

Best,
Adrian

===

Throughout:

Please resolve "Flexi-Grid" or "flexi-grid"

---

As a general comment, I think it was only clear to me on reading sections
6 and 7 that this YANG module is entirely made up of individual
augmentations of leaf nodes defined in other modules. That's not a
problem, but it might helpful to highlight this in Section 1.

---

Section 1

   This document identifies the flexi-grid components, parameters and
   their values, characterizes the features and the performances of the
   flexi-grid elements.

I think this should be

   This document identifies the flexi-grid components, parameters, and
   their values.  It characterizes the features and the performances of
   the flexi-grid elements.

---

Section 3

   RFC Editor Note: Please replace XXXX with the RFC numbers assigned to
   [RFC9093].  Please replace YYYY with the RFC number assigned to this
   document.  Please remove this note.

I suspect that the number for XXXX is 9093 :-)

Note, however, that in Section 7 you use XXXX for this document. It may
help the RFC editor if you are consistent.

---

Section 4

OLD
      We also provide nodes A
      and B identifiers, addresses and interfaces.
NEW
      We also provide the identifiers, addresses and interfaces of nodes
      A and B.
END

s/Figure 1 shows a simple topology./Figure 2 shows a simple topology./

---

5.1

s/This document aims to describe/This document describes/
s/Traffic-engineering (TE)/traffic engineering (TE)/
s/Grid provide WDM/Grid provides WDM/
s/Traffic Engineered (TE)/TE/
s/identities and groupings/identities, and groupings/
s/The figure below/Figure 3/
s/describing an Flexi-Grid/describing a Flexi-Grid/
s/specifies with/specifies the/

---

5.1

   The Flexi-Grid specific attributes in [RFC7699], including the grid
   type, channel spacing, slot width granularity, n and m parameters,
   can be used to represent the label information.

Perhaps I am being pedantic, but isn't the label a representation of
those parameters, not the other way round?

---

5.2.  Attributes Augmentation

   There are a few characteristics augmenting to the generic TE
   topology.

I think, probably...

5.2.  Augmentations for Flexi-Grid Topology and Node

   There are a few augmentations to the generic TE topology as described
   in this section.

---

5.2

s/topology as follows./topology as shown in Figure 4./
s/is a Flexi-Grid node/is a Flexi-Grid node as shown in Figure 5./

---

5.3

/layer0/Layer 0/
s/to describe also/to also describe/

---

Section 5.3 contains a little surprise. "Here are the bandwidth
augmentations: there are n bandwidth augmentations."

Perhaps resolve this by adding a paragraph at the very top of the
section to say...

   No bandwidth augmentations are needed for this YANG module.

Then the rest of the section will appear as an explanation.

---

5.4

   The model augments all the occurrences of the label-restriction list
   with flexi-grid technology specific attributes using the flexi-grid-
   label-range-info grouping defined in [RFC9093].

Can you add a reference for where the label-restriction list is
defined. I think it is RFC 8795.

---

7.

   module ietf-flexi-grid-topology {
     description
       "This module provides a YANG data model for the routing and
        wavelength assignment (RWA) Traffic Engineering (TE)
        topology in flexi-grid optical networks. The YANG model
        described in this document is a flexi-grid technology-specific
        YANG model augmenting the generic TE topology module
        (ietf-te-topology, RFC 9795) based on the RFC 7698 and 7699.

s/based on the RFC 7698 and 7699./based on RFC 7698 and RFC 7699./

---

7.

Obviously, the copyright date is broken in the YANG

From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Daniele Ceccarelli
Sent: 17 December 2021 14:50
To: CCAMP <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-flexigrid-yang-11

CCAMP,

the IPR declaration collection has been successfully completed and we can move to the next step. Given the upcoming holiday period we’ll allow for a longer last call.

This starts a 4 weeks working group last call on draft-ietf-ccamp-flexigrid-yang-11
The last call ends on Friday January 14th. Please send you comments to the CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document (https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/history/)
If interested, please volunteer to be the shepherd of the draft (authors excluded).




Thanks

Daniele & Fatai