_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

__________________=
_____________________________
i2rs mailing =
list
i2rs@ietf.org
https://www.ietf.org/=
mailman/listinfo/i2rs
=
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.
=

=

=

=
Reviewer: Stewart =
Bryant
=
Review Date: 12 Dec =
2016
=
IETF LC End Date: 19 Dec =
2016
=
IESG Telechat date: 5 Jan =
2017
=

=

=
and the =
issues
=
are =
minor.
=

=
look =
into,
=
and a systematic English =
problem (missing pronouns) that the authors 
=
ought =
fix
=
to avoid the RFC Editor =
having to ask.
=

=

=
logic.
=
1.  =
Introduction
=

=
    data =
model to represent networks and topologies.  The data model =
is
=
    divided =
into two parts.
=

=
    network =
model that allows to define network hierarchies (i.e. =
network
=

=
SB> definition of" =
or "allows an operator to define".
=

=
(we don’t want to be =
specific as to whether that will be a devops guy, a controller =
application, an operator, or someone else.)
=
</ALEX>=
    stacks) =
and to maintain an inventory of nodes contained in a =
network.
=
<ALEX>=
We prefer to keep it, again =
because there are multiple roles who might interact with the =
model.  
=
</ALEX>=

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

=
<ALEX>=
The term network stack is =
explained in the surrounding context:  “network =
hierarchies”.  Added “… that are layered on top =
of each other” to make it even clearer. =
=
</ALEX>=

=
=3D=3D=3D=3D=3D=3D=3D=3D
=

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

=

=
Modified to “because =
it allows to” (but I think it is clear either way). =

=
</ALEX>=
    The =
model can be augmented to describe specifics of particular =
types
=

=
SB> describe THE =
specifics
=

=

=
</ALEX>=

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

=

=
    =
fashion.  This also facilitates the representation of =
network
=
    =
hierarchies and dependencies between different network components =
and
=
    network =
types.
=

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

=

=
    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?
=

=

=
    nodes =
and termination points across topologies.  An example of =
a
=
    topology =
stack is shown in the following figure.
=

=

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

=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
    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"
=

=
     &nbs=
p;  the representation of hierarchies of network subtypes within =
the instance information”
=
</ALEX>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=

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

=
<ALEX> changed to =
“allows for the definition =
of”</ALEX>
=

=
    =
simultaneous representation of layered network- and =
service
=
SB> Spurious =
"-"
=
<ALEX> =
“-“ removed </ALEX>
=
    =
topologies and physical instantiation.
=

=
    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?
=
<ALEX> changed to =
“allows also for the representation =
of”</ALEX>
=
    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.
=

=
    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/
=
<ALEX> fixed =
</ALEX>
=
    can be =
discovered.
=

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

=
</ALEX>=

=
    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/
=

=

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

=

=
    =
links.  An example of a termination point might be a physical =
or
=
    logical =
port or, more generally, an interface.
=

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

=
<ALEX> =

=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=

=
    nodes =
"in-line".  This allows to more easily include =
the
=
SB> this allows =
who?
=

=
<ALEX>=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

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

=
<ALEX> done =
</ALEX>
=

=
    and =
termination points physical ports.  It should be noted that it =
is
=
    also =
conceivable to augment the model for a physical =
network-type,
=

=
<ALEX> both. =
 Changed to possible </ALEX>
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
=

=
    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.
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
<ALEX> conceivable is =
on longer used in the document </ALEX>
=

=
    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"
=
<ALEX> the =
surrounding paragraph has been edited so comment no longer applies =
</ALEX>
=
    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.
=

=

=

=
    =
termination points as URIs.  An alternative would define them =
as
=
    =
string.
=
SB> given =
"them" (plural) I think that should be =
"strings"
=
<ALEX> changed =
</ALEX>
=
    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
=
<ALEX> well, I think =
the point should be clear </ALEX>
Hello,
=

=

=
Reviewer: Ines =
Robles
=
Review Date: =
07-25-2017
=
Intended status: Standards =
Track
=

=

=

=

=

=

=
<ALEX> Added a =
reference.=C2=A0 However, I note this is uncommon for documents that =
define YANG data models (as it is clear this is about a data model, not =
an information model.=C2=A0 =C2=A0=C2=A0
=
</ALEX>=

=
1- Section =
1
=

=

=
=C2=A0=C2=A0=C2=A0 The same =
for "Abstract Topology Model", should it be section =
4.2?
=

=
</ALEX> =

=

=

=
<ALEX> thank you, =
good catch
=
</ALEX>=

=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
1.b.2- " a single L3 network element", I would add in this =
case (Y2) "a single L3 (Y2) network =
element",
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
the same for "The figure shows a single "L3" network =
element mapped onto multiple "Optical" network =
elements.",
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I =
would add "The figure shows a single "L3" network element =
(Y2) mapped onto multiple "Optical" network elements [Z] and =
[Z1]."
=

=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
1.b.3- I would expand ROADMs --> Reconfigurable Optical Add/Drop =
Multiplexers (ROADMs)
=

=
2- Section =
2:
=

=
<ALEX> We reference =
RFC 7950, which is YANG 1.1. RFC 6020 needs to be referenced for its =
registries </ALEX>
=

=

=

=

=

=
<ALEX> removed this =
</ALEX>
=

=
<ALEX> done =
</ALEX>
=

=
=C2=A0=C2=A0 and TE links =
in a given TED. It forms the basis for a graph =
suitable
=
=C2=A0=C2=A0 for TE path =
computations." [https://tools.ietf.org/html/=
draft-ietf-teas-yang-te-topo-12]
=
<ALEX> No longer =
applicable, text in question has been struck.=C2=A0 Note that one of the =
coauthors is also author on the TE topology draft =
</ALEX>
=

=
<ALEX> done =
</ALEX>
=

=
<ALEX> I thought it =
was okay, but I changed it to =E2=80=9Cor managed system=E2=80=9D.=C2=A0 =
</ALEX>
=

Hello,
=
=C2=A0
I=
 have been selected as the Routing Directorate reviewer for this draft. The=
 Routing Directorate seeks to review all routing or routing-related drafts =
as they pass through IETF last call and IESG review, and sometimes on speci=
al request. The purpose of the review is to provide assistance to the Routi=
ng ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
=C2=A0
Although these comments are primarily for the use of the Routing ADs, i=
t would be helpful if you could consider them along with any other IETF Las=
t Call comments that you receive, and strive to resolve them through discus=
sion or by updating the draft.
=C2=A0
Document: draft-ietf-i2rs-yang-networ=
k-topo-14.txt
Reviewer: Ines Robles
Review Date: 07-25-2017
Intended stat=
us: Standards Track
=C2=A0
Summary:
I have some minor concerns about this doc=
ument that I think should be resolved before publication.
=C2=A0
Comments:=

=
=C2=A0
I believe the draft is technically good. This document is well written a=
nd clear to understand. The figures are clear and helpful.
=C2=A0<=
/u>
Major Issue=
s:
=C2=A0
No major issues found.
=C2=A0
Minor Issues:=C2=A0
Since this documen=
t specifies a data model, I would include some text related to the Informat=
ion Model [RFC 3444]. How would it be in this context?=
<ALEX> Added a =
reference.=C2=A0 However, I note this is uncommon for documents that define=
 YANG data models (as it is clear this is about a data model, not an inform=
ation model.=C2=A0 =C2=A0=C2=A0
</ALEX>
<=
span style=3D"font-size:10.5pt;color:black">=C2=A01- Section 1
=C2=A0=
=C2=A0 =
1.a following Figure 1 (Page 4):
=C2=A0
=C2=A0=C2=A0=C2=A0 I would add in t=
he figure the corresponding section that explain the module. e.g. Abstract =
Network Model, I would add in the figure "Abstract (base) Network Mode=
l" and "section 4.1".
=C2=A0=C2=A0=C2=A0 The same for "=
;Abstract Topology Model", should it be section 4.2?
=C2=A0
<ALEX>=
 The text talks about the abstract (based) network YANG module and subseque=
ntly uses the term abstract, not base, to describe the boxes depicted in th=
e diagram. Therefore we would prefer to keep it as is.=C2=A0 =
</ALEX> =
=
=C2=A0
=C2=A0 1.b -following Figure 2 (Page 5):
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 1.b.1- " X1 and X2 - mapping onto... ",=C2=A0 I think i=
t would be "X1 and X3 mapping onto..."=
<ALEX> thank you, goo=
d catch
</ALEX>
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.b.2- " a si=
ngle L3 network element", I would add in this case (Y2) "a single=
 L3 (Y2) network element",=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the same for =
"The figure shows a single "L3" network element mapped onto =
multiple "Optical" network elements.",<=
/pre>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 I would add "The figure shows a single "L3" networ=
k element (Y2) mapped onto multiple "Optical" network elements [Z=
] and [Z1]."
=C2=A0
<ALEX> done </ALEX>=
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 1.b.3- I would expand ROADMs --> Reconfigurable Optical Add/Dr=
op Multiplexers (ROADMs)
=C2=A0
<ALEX> done </ALEX>=
2- Section 2:<=
u><=
u>=C2=A0
=C2=A0 2.1- I would add a reference to RFC 6020, since the document us=
es terminology e.g container, augment, etc. which are defined in 6020. Even=
 if this RFC is mentioned in the normative reference, still I would add it =
here as well.
<ALEX> We reference RFC 7950, which is YANG 1.1. RFC 602=
0 needs to be referenced for its registries </ALEX>
=C2=A0
3- Section 3=
:
=C2=A0
 =C2=A03.1-=C2=A0 ReST is mentioned here but not in the rest of the =
draft, is this correct?
=C2=A0
<ALEX> removed </ALEX>
=C2=
=A0
Nits=
:
=C2=A0
1- Pag. 18: is that correct?: "(a string is a string is a strin=
g)"
<ALEX> removed this </ALEX>
<=
pre style=3D"margin-bottom:7.9pt;background:#fffdf5;border:none;padding:0in=
">=C2=A0<=
/pre>2- pag. 34: I would ex=
pand NMS -> NMS (Network Management System)
<ALEX> done </ALEX&g=
t;
=C2=A0
3- pag. 34: I would add a definition about TE Topology : "TE-T=
opology: The TE Topology is a schematic arrangement of TE nodes
=C2=A0=C2=A0=
 and TE links in a given TED. It forms the basis for a graph suitable
=C2=A0=
=C2=A0 for TE path computations." [https://tools.ietf.org/html/draft-ietf-=
teas-yang-te-topo-12]
<ALEX> No longer applicable, te=
xt in question has been struck.=C2=A0 Note that one of the coauthors is als=
o author on the TE topology draft </ALEX>
<=
pre style=3D"margin-bottom:7.9pt;background:#fffdf5;border:none;padding:0in=
">=C2=A0<=
/pre>4- pag. 34: topoogical=
 -> topological
<ALEX> done </ALEX>=C2=A0
5- pag 35: "ube=
r-network device" -> over-network device?<ALEX> I thought it =
was okay, but I changed it to =E2=80=9Cor managed system=E2=80=9D.=C2=A0 &l=
t;/ALEX>
=C2=A0
Thanks,
=C2=A0
Ines.

review-ietf-i2rs-yang-network-topo-14-rtgdir-lc-robles-= 2017-07-24

review-ietf-i2rs-= yang-network-topo-14-rtgdir-lc-robles-2017-07-24