Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-yang-l3-topology-10

Hello Lada,

Thank you very much for your detailed review.   Will plan to update the
draft over the coming two weeks or so (as I may be taking a few days off).
Most of the comments should be reasonably straightforward to accommodate.
However, I do have comments regarding #1 and #4.  

On #1 (presence containers vs identities).  Unless you feel very strongly
about this, we would prefer to keep this as is, not revert to identities.
This node is subject to quite a few "when" condition checks (when it comes
to topology-specific augmentations) which are very simple this way.
Changing this makes the conditions more complex and has ripple effects
through dependant modules.  Note that a topology can have multiple types; a
single leaf with identity would not be sufficient, it would need to be a
leaf-list.  On #4, (URIs) we had multiple discussions in the past but have
always come back to that; I would prefer to not change this at this point.
Please note that the model is implemented and deployed today, e.g. in Open
Daylight.  

Thanks
--- Alex

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, July 26, 2017 5:40 AM
To: 'Ladislav Lhotka' <lhotka@nic.cz>; yang-doctors@ietf.org
Cc: i2rs@ietf.org; ietf@ietf.org;
draft-ietf-i2rs-yang-l3-topology.all@ietf.org
Subject: Re: [i2rs] Yangdoctors early review of
draft-ietf-i2rs-yang-l3-topology-10

Lada:

Thank you for reviewing the draft with such a careful eye to now and the
future.  Please look for a response from Alex within a few days, .

Sue 

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz] 
Sent: Wednesday, July 26, 2017 4:46 AM
To: yang-doctors@ietf.org
Cc: i2rs@ietf.org; ietf@ietf.org;
draft-ietf-i2rs-yang-l3-topology.all@ietf.org
Subject: Yangdoctors early review of draft-ietf-i2rs-yang-l3-topology-10

Reviewer: Ladislav Lhotka
Review result: Ready with Issues

This YANG module and I-D belong to an extensible suite of data models
addressing multi-layered network topology. It is an interesting, even if
somewhat atypical, application of YANG.

The entire network topology suite seems well thought out, and it is apparent
that the document has already undergone several rounds of discussions and
iterations. It is also positive that the document deals with possible
overlaps with other YANG modules such as ietf-interfaces or ietf-hardware.
Of course, an ultimate acid test of the network topology suite will come
with applications to real-life network.

My review below raises several issues that need to be addressed (especially
#1). Some of them are related to design decisions described in
draft-ietf-i2rs-yang-network-topo. Apart from that, I believe the document
is ready to be published.

*** Comments to draft-ietf-i2rs-yang-network-topo-14:

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.

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?

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

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.

*** Comments to draft-ietf-i2rs-yang-l3-topology-10

5. The type of "router-id" should be "yang:dotted-quad" and not
   "inet:ip-address" because the latter means both IPv4 and IPv6
   address, possibly also with a zone index.

6. Both prefix and link attributes include the "metric" parameter. It
   should be explained what they mean. In the context of ietf-routing
   the option of including "metric" as a general route parameter was
   discussed and finally rejected because different routing protocol use
   metrics with different semantics and properties. I wonder if it is
   the same case here. 

*** Formal issues and typos

7. Both documents should refer to draft-ietf-netmod-yang-tree-diagrams
   rather than describe the notation of tree diagrams in the text.

8. Sec. 7 in draft-ietf-i2rs-yang-l3-topology-10: s/moodel/model/

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