Stewart Bryant
2016-12-14 10:41:07 UTC
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-i2rs-yang-network-topo-09
Reviewer: Stewart Bryant
Review Date: 12 Dec 2016
IETF LC End Date: 19 Dec 2016
IESG Telechat date: 5 Jan 2017
Summary: Ready with issues
This is a well written document and is basically ready for publication
and the issues
are minor.
There are a number of minor issues that the responsible AD needs to
look into,
and a systematic English problem (missing pronouns) that the authors
ought fix
to avoid the RFC Editor having to ask.
There are six authors which I assume is acceptable.
I am not a YANG expert and have therefore not checked the YANG syntax or
logic.
Detail:
=========
1. Introduction
This document introduces an abstract (base) YANG [RFC7950] [RFC6991]
data model to represent networks and topologies. The data model is
divided into two parts.
The first part of the model defines a
network model that allows to define network hierarchies (i.e. network
SB> minor English problem : "allows to define" perhaps "allows the
SB> definition of" or "allows an operator to define".
stacks) and to maintain an inventory of nodes contained in a network.
SB> same problem as above.
SB> Also I am a little worried that the term "network stack" is going to
SB> to confuse a lot of people. Many will confuse network stack with
SB> protocol stack. There probably needs to be some text explaining
SB> the difference.
========
While it would be possible to combine both parts into a single model,
the separation facilitates integration of network topology and
network inventory models, by allowing to augment network inventory
information separately and without concern for topology into the
network model.
SB> same English problem - "by allowing to augment"
The model can be augmented to describe specifics of particular types
SB> describe THE specifics
of networks and topologies. For example, an augmenting model can
SB> Not sure is that should be augmenting or augmented (same further
SB> down the para).
=============
The basic data models introduced in this document are generic in
nature and can be applied to many network and service topologies and
inventories. The models allow applications to operate on an
inventory or topology of any network at a generic level, where
specifics of particular inventory/topology types are not required.
At the same time, where data specific to a network type does comes
into play and the model is augmented, the instantiated data still
adheres to the same structure and is represented in consistent
SB> nit: in a consistent
fashion. This also facilitates the representation of network
hierarchies and dependencies between different network components and
network types.
The abstract (base) network YANG module introduced in this document,
entitled "network.yang", contains a list of abstract network nodes
and defines the concept of network hierarchy (network stack). The
abstract network node can be augmented in inventory and topology
SB> nit possibly "augmented in both the inventory"
SB> either way I think at least a "the" is missing
models with inventory and topology specific attributes. Network
==========================
A network can contain
multiple topologies, for example topologies at different layers and
overlay topologies. The model therefore allows to capture
SB> English: "allows to capture" - who does it allow to make a capture?
relationships between topologies, as well as dependencies between
nodes and termination points across topologies. An example of a
topology stack is shown in the following figure.
===========================
3. Definitions and Acronyms
HTTP: Hyper-Text Transfer Protocol
SB> HTTP is stared in the "well known" list and so does not need expanding
SB> also it is only used once in the text
===========================
When a network is of a certain type, it will contain a corresponding
data node. Network types SHOULD always be represented using presence
containers, not leafs of empty type. This allows to represent
SB> missing word "This allows who or what to represent"
===========================
This (physical) network,
respectively the (entities) nodes in that network, can then be
referred to as underlay network and nodes from the other (logical)
networks and nodes, respectively. Note that the model allows to
SB> allows who to define?
define more than one underlay network (and node), allowing for
simultaneous representation of layered network- and service
SB> Spurious "-"
topologies and physical instantiation.
Similar to a network, a node can be supported by other nodes, and map
onto one or more other nodes in an underlay network. This is
captured in the list "supporting-node". The resulting hierarchy of
nodes allows also to represent device stacks, where a node at one
SB> Allows who to also?
level is supported by a set of nodes at an underlying level. For
example, a "router" node might be supported by a node representing a
route processor and separate nodes for various line cards and service
modules, a virtual router might be supported or hosted on a physical
device represented by a separate node, and so on.
Finally, there is an object "server-provided". This object is state
that indicates how the network came into being. Network data can
come into being in one of two ways. In one way, network data is
configured by client applications, for example in case of overlay
networks that are configured by an SDN Controller application. In
annother way, it is populated by the server, in case of networks that
SB> s/annother/another/
can be discovered.
SB> I don't understand the end of the previous para. I think you are
SB> covering the case of SDN and classic self-learning networks where
SB> information is discovered from neighbours. If that is the case
SB> it is not clear from the text above.
If server-provided is set to false, the network was configured by a
client application, for example in the case of an overlay network
that is configured by a controller application. If server-provided
is set to true, the network was populated by the server itself,
respectively an application on the server that is able to discover
the network. Client applications SHOULD NOT modify configurations of
networks for which "server-provided" is true. When they do, they
need to be aware that any modifications they make are subject to be
SB> s/be/being/
reverted by the server. For servers that support NACM (Netconf
Access Control Model), data node rules should ideally prevent write
access by other clients to network instances for which server-
provided is set to true.
==========================
A node has a list of termination points that are used to terminate
links. An example of a termination point might be a physical or
logical port or, more generally, an interface.
SB> When I read this I immediately wondered about multi-point links
SB> You clear up later that your model does not support them. It
SB> would be kind to the reader to pre-empt the question here.
===========================
4.4.4. Use of groupings
The model makes use of groupings, instead of simply defining data
nodes "in-line". This allows to more easily include the
SB> this allows who?
=============================
4.4.7. Mapping redundancy
In a hierarchy of networks, there are nodes mapping to nodes, links
mapping to links, and termination points mapping to termination
points. Some of this information is redundant. Specifically, if the
link-to-links mapping known, and the termination points of each link
SB> link-to-links mapping IS known
============================
In the case of a physical network, nodes represent physical devices
and termination points physical ports. It should be noted that it is
also conceivable to augment the model for a physical network-type,
SB> do you mean conceivable or possible?
====================
That said,
it is conceivable that certain types of topology need to also be
SB> again I think you mean "it is possible"
configurable by an application. The model needs to support both
cases.
=====================
Another alternative would make use of a YANG extension to tag
specific network instances as "server-provided" instead of defining a
leaf object, or rely on the concept of YANG metadata [RFC7952] for
SB> perhaps "or relying on"
the same effect. The tag would be automatically applied to any
topology data that comes into being (respectively is configured) by
an embedded application on the network, as opposed to e.g. a
controller application.
========================
4.4.11. Identifiers of string or URI type
The current model defines identifiers of nodes, networks, links, and
termination points as URIs. An alternative would define them as
string.
SB> given "them" (plural) I think that should be "strings"
The case for strings is that they will be easier to implement. The
reason for choosing URIs is that the topology/node/tp exists in a
larger context, hence it is useful to be able to correlate
identifiers across systems. While strings, being the universal data
type, are easier for human beings (a string is a string is a string),
SB> Well maybe, it could be an ASCII string or an EBCDIC string etc
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-i2rs-yang-network-topo-09
Reviewer: Stewart Bryant
Review Date: 12 Dec 2016
IETF LC End Date: 19 Dec 2016
IESG Telechat date: 5 Jan 2017
Summary: Ready with issues
This is a well written document and is basically ready for publication
and the issues
are minor.
There are a number of minor issues that the responsible AD needs to
look into,
and a systematic English problem (missing pronouns) that the authors
ought fix
to avoid the RFC Editor having to ask.
There are six authors which I assume is acceptable.
I am not a YANG expert and have therefore not checked the YANG syntax or
logic.
Detail:
=========
1. Introduction
This document introduces an abstract (base) YANG [RFC7950] [RFC6991]
data model to represent networks and topologies. The data model is
divided into two parts.
The first part of the model defines a
network model that allows to define network hierarchies (i.e. network
SB> minor English problem : "allows to define" perhaps "allows the
SB> definition of" or "allows an operator to define".
stacks) and to maintain an inventory of nodes contained in a network.
SB> same problem as above.
SB> Also I am a little worried that the term "network stack" is going to
SB> to confuse a lot of people. Many will confuse network stack with
SB> protocol stack. There probably needs to be some text explaining
SB> the difference.
========
While it would be possible to combine both parts into a single model,
the separation facilitates integration of network topology and
network inventory models, by allowing to augment network inventory
information separately and without concern for topology into the
network model.
SB> same English problem - "by allowing to augment"
The model can be augmented to describe specifics of particular types
SB> describe THE specifics
of networks and topologies. For example, an augmenting model can
SB> Not sure is that should be augmenting or augmented (same further
SB> down the para).
=============
The basic data models introduced in this document are generic in
nature and can be applied to many network and service topologies and
inventories. The models allow applications to operate on an
inventory or topology of any network at a generic level, where
specifics of particular inventory/topology types are not required.
At the same time, where data specific to a network type does comes
into play and the model is augmented, the instantiated data still
adheres to the same structure and is represented in consistent
SB> nit: in a consistent
fashion. This also facilitates the representation of network
hierarchies and dependencies between different network components and
network types.
The abstract (base) network YANG module introduced in this document,
entitled "network.yang", contains a list of abstract network nodes
and defines the concept of network hierarchy (network stack). The
abstract network node can be augmented in inventory and topology
SB> nit possibly "augmented in both the inventory"
SB> either way I think at least a "the" is missing
models with inventory and topology specific attributes. Network
==========================
A network can contain
multiple topologies, for example topologies at different layers and
overlay topologies. The model therefore allows to capture
SB> English: "allows to capture" - who does it allow to make a capture?
relationships between topologies, as well as dependencies between
nodes and termination points across topologies. An example of a
topology stack is shown in the following figure.
===========================
3. Definitions and Acronyms
HTTP: Hyper-Text Transfer Protocol
SB> HTTP is stared in the "well known" list and so does not need expanding
SB> also it is only used once in the text
===========================
When a network is of a certain type, it will contain a corresponding
data node. Network types SHOULD always be represented using presence
containers, not leafs of empty type. This allows to represent
SB> missing word "This allows who or what to represent"
===========================
This (physical) network,
respectively the (entities) nodes in that network, can then be
referred to as underlay network and nodes from the other (logical)
networks and nodes, respectively. Note that the model allows to
SB> allows who to define?
define more than one underlay network (and node), allowing for
simultaneous representation of layered network- and service
SB> Spurious "-"
topologies and physical instantiation.
Similar to a network, a node can be supported by other nodes, and map
onto one or more other nodes in an underlay network. This is
captured in the list "supporting-node". The resulting hierarchy of
nodes allows also to represent device stacks, where a node at one
SB> Allows who to also?
level is supported by a set of nodes at an underlying level. For
example, a "router" node might be supported by a node representing a
route processor and separate nodes for various line cards and service
modules, a virtual router might be supported or hosted on a physical
device represented by a separate node, and so on.
Finally, there is an object "server-provided". This object is state
that indicates how the network came into being. Network data can
come into being in one of two ways. In one way, network data is
configured by client applications, for example in case of overlay
networks that are configured by an SDN Controller application. In
annother way, it is populated by the server, in case of networks that
SB> s/annother/another/
can be discovered.
SB> I don't understand the end of the previous para. I think you are
SB> covering the case of SDN and classic self-learning networks where
SB> information is discovered from neighbours. If that is the case
SB> it is not clear from the text above.
If server-provided is set to false, the network was configured by a
client application, for example in the case of an overlay network
that is configured by a controller application. If server-provided
is set to true, the network was populated by the server itself,
respectively an application on the server that is able to discover
the network. Client applications SHOULD NOT modify configurations of
networks for which "server-provided" is true. When they do, they
need to be aware that any modifications they make are subject to be
SB> s/be/being/
reverted by the server. For servers that support NACM (Netconf
Access Control Model), data node rules should ideally prevent write
access by other clients to network instances for which server-
provided is set to true.
==========================
A node has a list of termination points that are used to terminate
links. An example of a termination point might be a physical or
logical port or, more generally, an interface.
SB> When I read this I immediately wondered about multi-point links
SB> You clear up later that your model does not support them. It
SB> would be kind to the reader to pre-empt the question here.
===========================
4.4.4. Use of groupings
The model makes use of groupings, instead of simply defining data
nodes "in-line". This allows to more easily include the
SB> this allows who?
=============================
4.4.7. Mapping redundancy
In a hierarchy of networks, there are nodes mapping to nodes, links
mapping to links, and termination points mapping to termination
points. Some of this information is redundant. Specifically, if the
link-to-links mapping known, and the termination points of each link
SB> link-to-links mapping IS known
============================
In the case of a physical network, nodes represent physical devices
and termination points physical ports. It should be noted that it is
also conceivable to augment the model for a physical network-type,
SB> do you mean conceivable or possible?
====================
That said,
it is conceivable that certain types of topology need to also be
SB> again I think you mean "it is possible"
configurable by an application. The model needs to support both
cases.
=====================
Another alternative would make use of a YANG extension to tag
specific network instances as "server-provided" instead of defining a
leaf object, or rely on the concept of YANG metadata [RFC7952] for
SB> perhaps "or relying on"
the same effect. The tag would be automatically applied to any
topology data that comes into being (respectively is configured) by
an embedded application on the network, as opposed to e.g. a
controller application.
========================
4.4.11. Identifiers of string or URI type
The current model defines identifiers of nodes, networks, links, and
termination points as URIs. An alternative would define them as
string.
SB> given "them" (plural) I think that should be "strings"
The case for strings is that they will be easier to implement. The
reason for choosing URIs is that the topology/node/tp exists in a
larger context, hence it is useful to be able to correlate
identifiers across systems. While strings, being the universal data
type, are easier for human beings (a string is a string is a string),
SB> Well maybe, it could be an ASCII string or an EBCDIC string etc