Last Call Review of draft-ietf-i2rs-yang-network-topo-18
review-ietf-i2rs-yang-network-topo-18-opsdir-lc-wu-2017-12-08-00

Reviewer: Qin Wu
Review result: Ready with Nits
I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments. Document reviewed:
 draft-ietf-i2rs-yang-network-topo-18

Summary:
This document defines a base YANG data model for
network/service topologies and inventories. It can extended with technology
specific details. The draft is ready for publication. But it be great to
sequeeze water from it.

Major issue: None
Minor issue: Editorial
o The document does not pass IDnits,e.g.,

  == Outdated reference: A later version (-07) exists of
     draft-ietf-netmod-revised-datastores-02

  == Outdated reference: draft-ietf-i2rs-ephemeral-state has been published
     as RFC 8242

  == Outdated reference: A later version (-13) exists of
     draft-ietf-i2rs-yang-l3-topology-11

  == Outdated reference: A later version (-11) exists of
     draft-ietf-netconf-yang-push-10

o Section 1,the 10th paragraph said:
"
The data model can also be used to create or modify network
   topologies such as might be associated with an inventory or with an
   overlay network.
"
Can not parse this sentence, who might be associated with an inventory, how an
inventory is related to network topologies modification and creation.

O Section 4.1, the 3rd paragraph said:
"
A network can even have multiple types simultaneously.
"
From the base model, it is not clear to me how to prove it support multiple
types simultaneously.

O Section 4.1, the 7th paragraph said:
"
   In cases where the same entity takes part in multiple networks, or at
   multiple layers of a networking stack, the same entity will be
   represented by multiple nodes, one for each network.
"
How do I know multiple nodes belonging to multiple network represents the same
entity. To be honest, we only know node A in one network can be mapped to node
B in another network, It looks the same entity you described here is mapping
between node at different layer or in different network. Is the same entity you
described here is Representing the same device in multiple networks described
in section 4.4.9?

O Section 4.1, the 8th paragraph said:
"
Similar to a network, a node can be supported by other nodes, and map
   onto one or more other nodes in an underlay network.
"
How the same entity represented by multiple nodes, one for each network  is
different from mapping between one node in one layer and other node in another
layer?

O section 4.1, last paragraph:
"It will be up to the
   client application to resolve the situation and ensure that the
   reference to the supporting resources is configured properly. "

I think it is up to both the client application and SDN controller to resolve
the situation and ensure the reference to the supporting resource is configured
properly, since the SDN controller may be the first one to know supporting
resoucr doesn’t exist if topology data is learned from the network.

O Section 4.3 the 2nd paragraph said:
" We start with augmentations against the ietf-network.yang module.
   First, a new network type needs to be defined. For this, a presence
   container that resembles the new network type is defined.
"
resembles? What do we mean resembles?

O Section 4.3, last paragraph said:
“network-types usages has been repeated in many places, would it be great to
consolidate them in the same place? Also sub-type and super-type doesn’t exist
in any other place.”

network-types usage examples have been repeated in many places, would it be
great to consolidate them in the same place? Also sub-type and super-type
doesn’t exist in any other place.

O Section 4.4.1 said:
"
Therefore, path specifiers used to refer to
   specific nodes, be it in management operations or in specifications
   of constraints, can remain relatively compact.
"
What is path specifiers? Or path identifier?

O Section 4.4.10
Suppose the network topology information is discovered, how do I use NMDA
complaint YANG model for network topology to represent it? Designates all data
s config false?

O Section 7:
Do we need to register namespace URIs for ietf-network-state and
ietf-network-topology-state two modules that are defined in the Appendix?