Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-yang-network-topo-10: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 05 Jan 2017 03:50:29 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: 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-i2rs-yang-network-topo/

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

Reading this document one more time, some more editorial comment
-

OLD:
   At the same time, where data specific to a network type does comes
   into play

NEW:
   At the same time, where data specific to a network type does come
   into play

- The figure shows two Service Functions - X1 and X2 - mapping onto a
   single L3 network element; this could happen, for example, if two
   service functions reside in the same VM (or server) and share the
   same set of network interfaces.

You meant X1 and X3, mapping to the same Y2 L3 network element, right?

- please expand ROADM

- There are multiple slightly different definitions of the datastore in
the different RFCs.
Let's not add to the confusion.
Pick one (RFC6241 should be the latest one) and mention the reference.

- YANG definition "YANG: A data definition language for NETCONF"
I would use:
   YANG is a data modeling language used to model configuration data,
   state data, Remote Procedure Calls, and notifications for network
   management protocols [RFC7950]

- OLD:
  The abstract (base) network model is defined in the network.yang
   module.  Its structure is shown in the following figure.  Brackets
   enclose list keys, "rw" means configuration data, "ro" means
   operational state data, and "?" designates optional nodes.  A "+"
   indicates a line break.

NEW (cut/paste from RFC8022 and
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09]

   o  Brackets "[" and "]" enclose list keys.

   o  Curly braces "{" and "}" contain names of optional features that
      make the corresponding node conditional.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write), "ro" state data (read-only), "-x" RPC operations or
      actions, and "-n" notifications.

   o  Symbols after data node names: "?" means an optional node, "!" a
      container with presence, and "*" denotes a "list" or "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are
also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

Note that you have two instances of this.

- Final comment: the security considerations should be better aligned
with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as
replied to Kathleen's DISCUSS.