[i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review.

["Susan Hares" <[e-mail]>]

Alex: 

In doing my final shepherd's review of draft-ietf-yang-network-topo for
-17.txt version I found a few Yang Doctor's comments you need to resolve. 

The review of draft-ietf-i2rs-yang-l3-topology-10 contains comments from
Lada on Comments to draft-ietf-i2rs-yang-network-topo-14.  See the message
linked to by: 

https://mailarchive.ietf.org/arch/msg/yang-doctors/ZdwwMUpvXaBiCQN6A3hm76joS
7Q

In this reviewing, draft-ietf-i2rs-yang-network-topo-17.txt, I do not see
the following addressed: 

1.  With YANG 1.1, the network type information looks like a perfect
candidate for identities (with multiple inheritance). Instead, it is
modelled with presence containers, which is cumbersome and redundant. I
don't see any reasons for doing so, if there are any, then they should be
explained in sec. 4.4.8.

Comment from shepherd:  I do not see the explanation Lada requested in for
"why containers" in: 

https://mailarchive.ietf.org/arch/msg/yang-doctors/ZdwwMUpvXaBiCQN6A3hm76joS
7Q

https://mailarchive.ietf.org/arch/msg/yang-doctors/0AcgU2Zr6RoMgF-vEx-3NHFh6
dM

 

2.  The document defines "supporting network" and then says "A supporting
network is in effect an underlay network." In the subsequent text "underlay
network" is used almost exclusively. So perhaps the term "supporting
network" should be dropped altogether?

Comment from shepherd: If you wish to keep supporting network to align with
TEAS or other work please just point to it.  Or if you wish to keep the term
because of common use, make that comment.  Either way - please resolve or
respond to LADA with reason. 

 

3.  The text should be better aligned with the terminology of
draft-ietf-netmod-revised-datastores. In particular,  "system-controlled"
should be used instead of "server-provided".

Comment from shepherd: If you can use the "system-controlled", it would be
better. If you cannot, please indicate why in the definitions. 

 

4.  Is it necessary to use URIs for identifying all objects in the data
model. 

URIs are difficult to use, so applications are likely to introduce some
abbreviations and keep an internal mapping, which could cause problems, e.g.
when matching objects in notifications with a GUI representation. In my
view, it should be sufficient to use URIs for network-id and plain strings
for other IDs, because all other objects are encapsulated inside a network,
so their name conflicts shouldn't matter.

                Comment from shepherd:   A comment should be included on why
URIs.  Did I miss the comment? 

 

Perhaps we can chat today at the social on where you are with these changes.
Let's see if we can both celebrate IETF 100 by submitting the base topology
draft and l3 draft to the IESG. 

 

Sue Hares