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?