Re: [CCAMP] FW: New Version Notification for draft-ietf-ccamp-flexigrid-yang-05.txt

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 10 January 2020 16:02 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5EF120905 for <ccamp@ietfa.amsl.com>; Fri, 10 Jan 2020 08:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkhV0CbCUvxb for <ccamp@ietfa.amsl.com>; Fri, 10 Jan 2020 08:02:45 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85D8120913 for <ccamp@ietf.org>; Fri, 10 Jan 2020 08:02:34 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00AG2Wxu007261; Fri, 10 Jan 2020 16:02:32 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 92C2F221D1; Fri, 10 Jan 2020 16:02:32 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 7D545221D0; Fri, 10 Jan 2020 16:02:32 +0000 (GMT)
Received: from LAPTOPK7AS653V (089144208052.atnat0017.highway.a1.net [89.144.208.52]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 00AG2VWW006872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jan 2020 16:02:32 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'King, Daniel'" <d.king@lancaster.ac.uk>, 'CCAMP' <ccamp@ietf.org>
References: <CWXP265MB03274E19D8BF3691B8AA98A4D6390@CWXP265MB0327.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP265MB03274E19D8BF3691B8AA98A4D6390@CWXP265MB0327.GBRP265.PROD.OUTLOOK.COM>
Date: Fri, 10 Jan 2020 16:02:30 -0000
Organization: Old Dog Consulting
Message-ID: <07ac01d5c7cf$5dbc8010$19358030$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI882HVxKwKgeo3gLQkq2ZK+cErracUkSlQ
Content-Language: en-gb
X-Originating-IP: 89.144.208.52
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25160.000
X-TM-AS-Result: No--11.371-10.0-31-10
X-imss-scan-details: No--11.371-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25160.000
X-TMASE-Result: 10--11.371200-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtFor4mPA3EMtnFPUrVDm6jtjHhXj1NLbjDI0aosJWf26jKm 6bJAvOKCeIkeOmkPpetjbpWJNJ4FnPKz418OhfUo9Ib/6w+1lWShp756/rM6UoNCethLwYzdKE7 RkZjddaHA/iUlUAcufN2zZGcigPKlX/y1f/UofMXjxJDUku2PNiILdc+InEErU6v/653LDVkcQu ggvr9e2KiHBcTU/mW6Kpg0Z12fTrZ7xjfhHTwa0a78ETDb69mD1yfU0PnELhoTLunq7JxcvSABS awZOxKYUoIWBxeBo6TOJ0IyxDDCgd7Jizf4VVgFyZHnIMmQ+Dj2X2nyY2WSCeM0/bFuUDgh/+9H Bw3oLFz1DzpmYbCmAb/5N19kwGfKXiUcOYY/P4S8coKUcaOOvaa/FCTmDGQyxWwvfxzKj7vKjxq 2fvLVJrprSyen4sz4YXSGYhBpvkDqjIQI8pAdJuLCI+zi1Z4HJX6plJdynNV1C1t2YInRXBnJJY TH2lb4q9SjLsJIel4DPA1DWlSwbWzrxUyZ4qgxgQB87+QSu6HxTZ6+JDIODT07m5a3Vf0jqzfws rnXnNJjhj8loEKiDbvvdPAEvtLtoENccSAv8N5usn2BWc6xnffjx7YIT/BiX15NJHwjp25/EVxw X5PdWWmdR6mzFj1UIhqUueTBqcutx33SUHR7hVPjo7D4SFg4DLYDOfwMCCYdBPwZA+Ryb4vcKin lzyX1bSwf5FhWV4d31PcFav1MzkRb1VL0LZbXN19PjPJahlKlAfiiC1VA/andDFFkPJPDm9OSsc aYt+wonAYNEz6eDzmlhfzyBJGfMKK3MQ624rWeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqt+RjzaoIlPjrxBNFWaBbALGEGeUy2rGVoUQFsTheSUpKOPQnuTulDKw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/UVY4lcLZuVAvLCBBEOk5Gud-S8U>
Subject: Re: [CCAMP] FW: New Version Notification for draft-ietf-ccamp-flexigrid-yang-05.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2020 16:02:51 -0000

That's timely Dan, thanks.

But I've just been reviewing the previous version so here are my comments on
that.

Apologies if you've already picked up any of these points.

Best,
Adrian

===

Update Young Lee's coordinates on the document and in the YANG module

---

Abstract should come first

---

Abstract

OLD
   This document defines a YANG model for managing flexi-grid optical
   Networks. The model described in this document defines a flexi-grid
   traffic engineering database. A complementary module is referenced
   to detail the flexi-grid media channels.

   This module is grounded on other defined YANG abstract models.
NEW
   This document defines a YANG module for managing flexi-grid optical
   networks. The model defined in this document specifies a flexi-grid
   traffic engineering database that is used to describe the topology of
   a flexi-grid network. It is based on and augments existing YANG 
   models that describe network and traffic engineering topologies. 

   A partner document defines a second YANG module for flexi-grid media
   channels, i.e., the paths from source to destination through a number
   of intermediate nodes.
END

---

Please capitalise all section headings

---

The table of contents appears to be missing most of the page numbers.

---

Section 1 reads a bit like a marketing statement for flexi-grid, rather
than introducing this document. How about:

OLD
   Internet-based traffic is dramatically increasing every year.
   Moreover, such traffic is also becoming more dynamic. Thus,
   transport networks need to evolve from current DWDM systems towards
   elastic optical networks, based on flexi-grid transmission and
   switching technologies [RFC7698]. This technology aims at increasing
   both transport network scalability and flexibility, allowing the
   optimization of bandwidth usage.

   This document presents a YANG [RFC7950] model for flexi-grid objects 
   in the dynamic optical network, including the nodes, transponders 
   and links between them, as well as how such links interconnect nodes 
   and transponders.

   The YANG model for flexi-grid networks allows the representation of
   the flexi-grid optical layer of a network, combined with the
   underlying physical layer.

   This document identifies the flexi-grid components, parameters and
   their values, characterizes the features and the performances of the
   flexi-grid elements. An application example is provided towards the
   end of the document to better understand their utility.
NEW
   The flexible grid (flexi-grid) optical network technology defined by
   the International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) and documented in Recommendation 
   G.694.1 and G.872 [G.694.1] [G.872] provides an enhanced Dense
   Wavelength Division Multiplexing (DWDM) grid by defining a set of
   nominal central frequencies, channel spacings, and the concept of the
   "frequency slot".  In such an environment, a data-plane connection is
   switched based on allocated, variable-sized frequency ranges within
   the optical spectrum, creating what is known as a flexible grid
   (flexi-grid).  This technology increases both transport network 
   scalability and flexibility, allowing the optimization of bandwidth
   usage.

   [RFC7698] provides a framework GMPLS-Based control of flexi-grid DWDM
   networks while [RFC7699] defines generalized labels for the use in
   flexi-grid in GMPLS networks.

   This document presents a YANG [RFC7950] model for flexi-grid objects 
   in the dynamic optical network, including the nodes, transponders 
   and links between them, as well as how such links interconnect nodes 
   and transponders.

   The YANG model for flexi-grid networks allows the representation of
   the flexi-grid optical layer of a network, combined with the
   underlying physical layer.

   This document identifies the flexi-grid components, parameters and
   their values, characterizes the features and the performances of the
   flexi-grid elements. An application example is provided towards the
   end of the document to better understand their utility.

   A partner document defines a second YANG module that described flexi-
   grid media channels, i.e., the paths from source to destination
   through a number of intermediate nodes
   [I-D.draft-ietf-ccamp-flexigrid-media-channel-yang].
END

---

Section 2 has a lot of stuff that can be dropped. I think:

OLD
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding the explicit compliance requirements of this RFC.
NEW
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
END

---

2.1

s/chapter 6/Section 6/

---

2.3

OLD
   Note: The RFC Editor will replace XXXX with the number assigned to
   the RFC once this draft becomes an RFC.
NEW
   RFC Editor Note: Please replace XXXX with the RFC number assigned to
   this document when it is published.  Please remove this note.
END

---

3.

s/proposed/defined/   (twice)
s/propose/define/
s/proposals/specifications/

---

4.
OLD
   This section details the defined YANG module. It is listed below in
   section 6.
NEW
   This section describes the YANG module. It is specified in Ssection
   6.
END

---

Section 4 uses notation that looks a bit like BNF. Can you add a note at
the top of this section to point to where the notation is defined, or to
define the notation if it is new.

Whoah! I found the answer in Section 4.1. Just kill that section and 
move the text to the top of Section 4. Although, are you sure you are
using ABNF from RFC 5234? That spec does not define "::=" for example.
What you actually have looks a lot more like RBNF per RFC 5511.

---

In Section 4, please pay attention to the need for additional blank 
lines between elements to provide clarity and make it easier to read.
Also consider the alignment of continuation lines.

For example (but there are many others)

OLD
           <config>: Contains the configuration of a node.
           <flexi-grid-node-attributes-config> ::= <list-interface>
           <connectivity_matrix>
NEW
           <config>: Contains the configuration of a node.

           <flexi-grid-node-attributes-config> ::= <list-interface>
                                                   <connectivity_matrix>
END

---

Section 4

s/A interface/An interface/

---

While Figure 1 is structurally correct for the example, it might help
the reader if you showed the traffic source and sink on the figure.

---

Section 5 is really helpful, but I think it needs to be enhanced to say 
which bits of which models/modules are used for the steps described.

---

Section 6.1 could also benefit from a lot more blank lines. I think, at
least, you could put one before each "augment".

---

6.2
Maybe put <CODE BEGINS> on its own line

---

Section 6.2

Please clean up the instructions to the RFC Editor about inserting RFC
numbers as follows:

- Start the section (before the YANG model) with the following text

  RFC Editor Note: Please replace the string "ZZZZ" in the YANG model
  definition below with the RFC number assigned to
  draft-ietf-ccamp-wson-yang when it is published as an RFC. Please
  replace the string "YYYY" in the YANG model definition below with the
  RFC number assigned to draft-ietf-teas-yang-te-topo when it is
  published as an RFC. Please remove this note.

- Replace your use of XXXX in this section with ZZZZ (Note you have
  already used XXXX to mean something else in Section 2.3.

-- Remove the two notes embedded in comments in the YANG model

---

6.2
You have commented out some YANG in a number of places. For example:

  /* Augment maximum LSP bandwidth of TE link template */
  augment "/nw:networks/tet:te/tet:templates/"
        + "tet:link-template/tet:te-link-attributes/"
        + "tet:interface-switching-capability/"
        + "tet:max-lsp-bandwidth/"
        + "tet:te-bandwidth/tet:technology" {
/*
    when "../../../../../../nw:network-types/tet:te-topology/"
       + "flexi-grid:flexi-grid-topology" {
      description "flexi-grid TE bandwidth.";
    }
*/
    description "flexi-grid bandwidth.";
    case flexi-grid {
      uses layer0-types:flexi-grid-path-bandwidth;
    }
  }

What's that all about?

---

6.2
Some of the comment-wraps need to be correctly indented

---

6.3 Why is this section present? I think it is wrong.

---

Section 8 looks wrong to me. Maybe:

OLD
   The namespace used in the defined model has to register a URI in
   the IETF XML registry [RFC3688], as well as in the YANG Module
   Names registry [RFC6020].
NEW
   IANA is requested to assigned a new URI from the "IETF XML Registry"
   [RFC3688] as follows:

      URI: urn:ietf:params:xml:ns:yang:ietf-flexi-grid-topology
      Registrant Contact: The IESG
      XML: N/A; the requested URI is an XML namespace.

   IANA is requested to assign a new YANG module name in the "YANG
   Module Names" registry [RFC6020] as follows:

      Name: ietf-l3vpn-svc
      Namespace: urn:ietf:params:xml:ns:yang:ietf-flexi-grid-topology
      Prefix: flexi-grid-topology
      Reference: [This.I-D]
END

---

9.2

draft-ietf-ccamp-wson-yang should be a normative reference for how it
is used in import ietf-layer0-types.

draft-ietf-teas-yang-te-topo should be a normative reference for how 
it is used in import ietf-te-topology

-----Original Message-----
From: CCAMP <ccamp-bounces@ietf.org> On Behalf Of King, Daniel
Sent: 09 January 2020 21:45
To: CCAMP (ccamp@ietf.org) <ccamp@ietf.org>
Subject: [CCAMP] FW: New Version Notification for
draft-ietf-ccamp-flexigrid-yang-05.txt

Dear CCAMP'rs, 

Please note that the new version of draft-ietf-ccamp-flexigrid-yang (version
5). The new I-D has minimal updates (affiliation changes). 

Several YANG errors exist which will be fixed shortly. In the meantime, WG
participants are most welcome to review and comment on the I-D. 

BR, Dan. 

-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
Sent: 09 January 2020 21:32
To: Haomian Zheng <zhenghaomian@huawei.com>; Jorge E. Lopez de Vergara
<jorge.lopez_vergara@uam.es>; Universidad de Madrid
<jorge.lopez_vergara@uam.es>; King, Daniel <d.king@lancaster.ac.uk>; Young
Lee <younglee.tx@gmail.com>; Daniel Perdices <daniel.perdices@naudit.es>;
Victor Lopezalvarez <victor.lopezalvarez@telefonica.com>; Victor Lopez
<victor.lopezalvarez@telefonica.com>
Subject: [External] New Version Notification for
draft-ietf-ccamp-flexigrid-yang-05.txt

This email originated outside the University. Check before clicking links or
attachments.

A new version of I-D, draft-ietf-ccamp-flexigrid-yang-05.txt
has been successfully submitted by Daniel King and posted to the
IETF repository.

Name:           draft-ietf-ccamp-flexigrid-yang
Revision:       05
Title:          YANG data model for Flexi-Grid Optical Networks
Document date:  2020-01-08
Group:          ccamp
Pages:          75

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ccamp-flexigrid-yang-05
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-flexigrid-yang-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Abstract:
   This document defines a YANG model for managing flexi-grid optical
   Networks. The model described in this document defines a flexi-grid
   traffic engineering database. A complementary module is referenced
   to detail the flexi-grid media channels.

   This module is grounded on other defined YANG abstract models.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp