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

[Ladislav Lhotka <[e-mail]>]

Hi Sue,

please see my responses inline.

Susan Hares <[e-mail]> writes:

> Lada:
>
> During your review of the draft-ietf-i2rs-yang-l3-topology-10.txt, you
> raised the following issues.  As part of the shepherd's review of
> draft-ietf-i2rs-network-topo-14, I have investigated the resolution.  
> I found that these comments have not be resolved.  Could  you review this
> email to see if it resolves the questions on
> draft-ietf-i2rs-network-topo-14?   The current draft is
> draft-ietf-i2rs-network-topo-14.txt.   
>
> The suggest changes below would go into draft-ietf-i2rs-network-topo-17.  
>
> Thank you, Susan Hares 
>
>
>
> *** 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.
>
> Suggested text: 
> [This topology model utilizes presence containers in order to support
> correlated topologies. 
> While identities (with multiple inheritance), might be used to support these
> network 
> topologies - it would prevent the support of network topologies.]

I don't know exactly what "correlated topologies" mean but multiple
inheritance of identities should allow for representing multiple
orthogonal aspects in the same identity. In fact, the creative use of
containers in the I2RS topology draft motivated me to propose multiple
inheritance of identities for YANG 1.1. On the other hand, there is
nothing wrong with using the containers, it is just more verbose.

>
> Question: Do you agree with Robert's comment below, and this resolution to
> the text. 
>
> 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?
>
> Response:  These terms have specific in the body of work that the TEAS WG
> has. 
> See section 2 and section 5.8 in draft-ietf-teas-yang-te-topo-13.txt for the
> use of overlay/underlay 
> terminology.  Your comment points out that we have a common understanding 
> in the I2RS and the routing-area's understanding of TEAS topology.    
>
> Suggested text addition:   
> [draft-ietf-teas-yang-te-topo-13.txt] provides a description of supporting
> network 
> and underlay network in sections 2 and section 5.8 for traffic engineering
> topology. ]

OK, I didn't know the context.

>
>
> 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".
>
> "server-provider has been removed" by version 17.

Good.

>
> 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.
>
> Response: Lada - Robert Wilton feels this choice is a design preference
> as do the authors.  Please review the message below, and determine if
> you wish to discuss this further.

URIs are no silver bullet for unique naming, and quite often thay can be
substituted by simpler means, perhaps using DNS information, if it is
available.

In my view, URIs would be OK as long as human users are not exposed to
them (I don't know if it is going to be the case or not). Anyway, this
blog post by James Clark about the use of URIs as namespace identifiers
in XML was quite an educative reading for me:

http://blog.jclark.com/2010/01/xml-namespaces.html

Thanks, Lada

>
> Sue Hares 
>
> -----Original Message-----
> From: Alexander Clemm [mailto:[e-mail]] 
> Sent: Monday, November 13, 2017 9:54 PM
> To: Róbert Varga; Susan Hares
> Cc: Alexander Clemm; [e-mail]; Xufeng Liu; Jan Medved (jmedved);
> Hariharan Ananthakrishnan; 'Nitin Bahadur'
> Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-11.txt
>
> Thanks for your feedback, Robert!
> --- Alex
>
>> -----Original Message-----
>> From: Róbert Varga [mailto:[e-mail]]
>> Sent: Monday, November 13, 2017 7:08 PM
>> To: Alexander Clemm <[e-mail]>; Susan Hares 
>> <[e-mail]>
>> Cc: Alexander Clemm <[e-mail]>; [e-mail]; Xufeng 
>> Liu <[e-mail]>; Jan Medved (jmedved) 
>> <[e-mail]>; Hariharan Ananthakrishnan 
>> <[e-mail]>; 'Nitin Bahadur' <[e-mail]>
>> Subject: RE: [i2rs] I-D Action: 
>> draft-ietf-i2rs-yang-l3-topology-11.txt
>> 
>> Hello,
>> 
>> The first issue is a problem, as it would make it impossible to 
>> construct correlated topologies, which is a major ODL use case: 'I 
>> want to see both OpenFlow and NETCONF view of my device state in one
> place.'
>> 
>> The second issue is a matter of design preference -- using strings is 
>> certainly possible, but it has the downside of being a flat namespace, 
>> which does not have any semantic meaning outside of YANG model. With 
>> URIs, the identifier is structured and it has an inherent property 
>> that it is something someone somewhere may be able to resolve -- such 
>> that a node's identifier can be turned into, say, RESTCONF URL to 
>> access the management endpoint... I don't particularly care either 
>> way, as the URI can be added as an augmentation where appropriate.
>> 
>> Regards,
>> Robert
>> 
>> > -----Original Message-----
>> > From: Alexander Clemm [mailto:[e-mail]]
>> > Sent: Monday, November 13, 2017 2:27 AM
>> > To: Susan Hares <[e-mail]>
>> > Cc: Alexander Clemm <[e-mail]>; [e-mail];
>> Xufeng
>> > Liu <[e-mail]>; Jan Medved (jmedved) 
>> > <[e-mail]>; Róbert Varga <[e-mail]>; 
>> > Hariharan Ananthakrishnan <[e-mail]>; 'Nitin Bahadur'
>> > <[e-mail]>
>> > Subject: RE: [i2rs] I-D Action:
>> > draft-ietf-i2rs-yang-l3-topology-11.txt
>> > Importance: High
>> >
>> >
>> > Hi Sue,
>> >
>> > I apparently sent this message one day after Lada posted his review.
>> > I  had thought I had responded earlier.
>> >
>> > To my coauthors- Robert, Xufeng, Hari, Jan, Nitin:
>> >
>> > There are two issues that Lada brings up:
>> >
>> > - A request to move network type from presence containers to identities.
>> > Implication is that this will no longer make it possible to have 
>> > topologies that are "hybrid" accommodating different types at the 
>> > same point in time.  Would that be an issue?
>> > - A request to move identifiers from type URI to type string.  I 
>> > remember we had discussions on this in the past.  I believe having 
>> > URIs facilitated consistency/ referential integrity checking.  Any 
>> > strong feeling if all identifiers are moved to string?
>> >
>> >
>> > Sue,
>> >
>> > Is there anything else open beyond Lada's comments?
>> >
>> > --- Alex
>> >
>> > Looking at the items:
>> >
>> > 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.
>> > <ALEX>
>> > 	.
>> > I am not sure what Lada considers redundant.  The current 
>> > implementations are based on presence container, and people at the 
>> > time expressed preference for that.  (I have to dig up the 
>> > communication, probably quite a while ago.) One advantage of doing 
>> > it in the current way is that we could accommodate also "hybrid"
>> > topologies.  I feel presence container is superior and more flexible 
>> > because of this reason.  However, I don't really care at this point.
>> > Let me check with my coauthors if they would be okay; if Lada feels
>> strongly we can accommodate.  But I am really wary of yet more churn.
>> >
>> > Here is the explanation we currently have:
>> > Network types SHOULD always be represented using presence
>> >    containers, not leafs of empty type.  This allows representation of
>> >    hierarchies of network subtypes within the instance information.
>> > </ALEX>
>> >
>> > 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?
>> >
>> > <ALEX>
>> > Is this really an issue?  The wording worked fine so far.  We 
>> > certainly don't want to change the model here.
>> > In the text it often talks about underlays in the sense of "underlay
>> topology".
>> > This is an established term, more so than "supporting".
>> > </ALEX>
>> >
>> > 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".
>> > <ALEX>
>> > This has been addressed
>> > </ALEX>
>> >
>> > 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.
>> >
>> > <ALEX>
>> > We had various communications on this years ago.  Frankly, I don't 
>> > care
>> either
>> > way.   Let me check with the coauthors.  I am not involved in any
>> > implementation.  If people want string instead of URI, I can change it.
>> > </ALEX>
>> >
>> > *** Comments to draft-ietf-i2rs-yang-l3-topology-10
>> >
>> > <ALEX> These have been addressed </ALEX>
>> >
>> > 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/
>> >
>> > <ALEX> These have been addressed </ALEX>
>> >
>> > > -----Original Message-----
>> > > From: Alexander Clemm
>> > > Sent: Wednesday, September 27, 2017 1:10 AM
>> > > To: 'Susan Hares' <[e-mail]>
>> > > Subject: FW: [i2rs] I-D Action:
>> > > draft-ietf-i2rs-yang-l3-topology-11.txt
>> > >
>> > > Hi Sue,
>> > >
>> > > What are the next steps - is there anything else we need to do 
>> > > from our side?
>> > >
>> > > As mentioned, I believe all comments have been addressed, 
>> > > including Benoit's, Kent's, and Ignas'.  Still hoping we can get 
>> > > this closed before Singapore
>> > >
>> > > Thanks
>> > > --- Alex
>> > >
>> > > -----Original Message-----
>> > > From: Alexander Clemm
>> > > Sent: Tuesday, September 19, 2017 1:26 PM
>> > > To: [e-mail]
>> > > Cc: Susan Hares <[e-mail]>
>> > > Subject: RE: [i2rs] I-D Action:
>> > > draft-ietf-i2rs-yang-l3-topology-11.txt
>> > >
>> > > Hi all,
>> > >
>> > > We posted new revisions to draft-ietf-i2rs-yang-l3-topology and
>> > > draft-ietf- i2rs-yang-network-topo today.
>> > >
>> > > The updates to draft-ietf-i2rs-yang-network-topo are very minor 
>> > > and basically limited to updating the security considerations per 
>> > > comments from Benoit.
>> > >
>> > > The updates to draft-ietf-i2rs-yang-l3-topology take comments 
>> > > received from Ignas and others into account.  The OSPF example has 
>> > > been moved into its own appendix; we have also removed the IS-IS 
>> > > example as this did not appear really necessary.  In addition, 
>> > > there are various minor text edits, for example to bring it up to 
>> > > date with security considerations
>> > templates etc.
>> > >
>> > > --- Alex, Hari, Jan, Xufeng, Nitin, Robert
>> > >
>> > > -----Original Message-----
>> > > From: i2rs [mailto:[e-mail]] On Behalf Of internet- 
>> > > [e-mail]
>> > > Sent: Tuesday, September 19, 2017 12:09 PM
>> > > To: [e-mail]
>> > > Cc: [e-mail]
>> > > Subject: [i2rs] I-D Action: 
>> > > draft-ietf-i2rs-yang-l3-topology-11.txt
>> > >
>> > >
>> > > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > > This draft is a work item of the Interface to the Routing System 
>> > > WG of the IETF.
>> > >
>> > >         Title           : A YANG Data Model for Layer 3 Topologies
>> > >         Authors         : Alexander Clemm
>> > >                           Jan Medved
>> > >                           Robert Varga
>> > >                           Xufeng Liu
>> > >                           Hariharan Ananthakrishnan
>> > >                           Nitin Bahadur
>> > > 	Filename        : draft-ietf-i2rs-yang-l3-topology-11.txt
>> > > 	Pages           : 31
>> > > 	Date            : 2017-09-19
>> > >
>> > > Abstract:
>> > >    This document defines a YANG data model for layer 3 network
>> > >    topologies.
>> > >
>> > >
>> > > The IETF datatracker status page for this draft is:
>> > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/
>> > >
>> > > There are also htmlized versions available at:
>> > > https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-11
>> > > https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-l3-topo
>> > > lo
>> > > gy
>> > > -11
>> > >
>> > > A diff from the previous version is available at:
>> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l3-topology
>> > > -1
>> > > 1
>> > >
>> > >
>> > > Please note that it may take a couple of minutes from the time of 
>> > > submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> > >
>> > > Internet-Drafts are also available by anonymous FTP at:
>> > > ftp://ftp.ietf.org/internet-drafts/
>> > >
>> > > _______________________________________________
>> > > i2rs mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/i2rs
>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67