[i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-network-topo-10: (with DISCUSS and COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

To make sure both draft-ietf-i2rs-yang-network-topo and
draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my
DISCUSS.
As background, email sent to I2RS/IESG on Jan 24th 2017

Let me repeat what I mentioned already on the I2RS mailing list:

    This document contains a YANG model, a generic YANG model that could
be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
    This document doesn't say (and that would be a mistake IMO if it
would) that this YANG model can only be accessed by the I2RS protocol.
    Hence I'm advocating that the security considerations diligently
follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and
that they don't go in the I2RS protocol specific details.

This comment was made for draft-ietf-i2rs-yang-network-topo, but is
equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a
data model usage to a particular protocol. These topology documents are
not I2RS YANG models, these are YANG models, which can be used in
different contexts. I'm very concerned if we start having per-WG or per
context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the
requirements.
We can't modify the current generic YANG security considerations for an
I2RS control plane and a new datastore that are not yet specified. If you
want to describe how I2RS will be using those topology YANG models (and
any YANG models btw), then it's suitable to include this part of the I2RS
protocol spec or part of an I2RS applicability statement. This is
typically where you would describe some protocol specific information
such as "write contention for two clients writing a node using I2RS
priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS
needs to use the IETF interface YANG model, does it mean that you will
require RFC 7223bis with an updated security considerations? This can't
be.

I still think the generic YANG security guidelines is suitable, as it
relates to IETF specified protocols NETCONF and RESTCONF. Addition of
some generic information about the data model (not I2RS protocol) might
be useful though. For example, text around "there is a risk that a write
to a topology may create a looping topology or overload a particular
node". Note that I don't think the the security considerations is the
best section for this though.

Regards, Benoit


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