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

From: "Susan Hares" <[email-masked]>
Date: Tue, 14 Nov 2017 20:54:35 -0500

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

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

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. 

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. 

Sue Hares 

-----Original Message-----
From: Alexander Clemm [mailto:[email-masked]] 
Sent: Monday, November 13, 2017 9:54 PM
To: Róbert Varga; Susan Hares
Cc: Alexander Clemm; [email-masked]; 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:[email-masked]]
> Sent: Monday, November 13, 2017 7:08 PM
> To: Alexander Clemm <[email-masked]>; Susan Hares 
> <[email-masked]>
> Cc: Alexander Clemm <[email-masked]>; [email-masked]; Xufeng 
> Liu <[email-masked]>; Jan Medved (jmedved) 
> <[email-masked]>; Hariharan Ananthakrishnan 
> <[email-masked]>; 'Nitin Bahadur' <[email-masked]>
> 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:[email-masked]]
> > Sent: Monday, November 13, 2017 2:27 AM
> > To: Susan Hares <[email-masked]>
> > Cc: Alexander Clemm <[email-masked]>; [email-masked];
> Xufeng
> > Liu <[email-masked]>; Jan Medved (jmedved) 
> > <[email-masked]>; Róbert Varga <[email-masked]>; 
> > Hariharan Ananthakrishnan <[email-masked]>; 'Nitin Bahadur'
> > <[email-masked]>
> > 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' <[email-masked]>
> > > 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: [email-masked]
> > > Cc: Susan Hares <[email-masked]>
> > > 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:[email-masked]] On Behalf Of internet- 
> > > [email-masked]
> > > Sent: Tuesday, September 19, 2017 12:09 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/i2rs

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 11:59:36 +0800

Hi Sue,

please see my responses inline.

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

> and underlay network in sections 2 and section 5.8 for traffic engineering

OK, I didn't know the context.

> "server-provider has been removed" by version 17.

Good.

> 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

> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Nov 2017 08:08:47 +0000

Lada, did you link the right article?  The linked article is entitled  “Getting involved with M”...

PS: please excuse my company’s URL mangler  ;)
K.

Sent from my iPhone

On Nov 14, 2017, at 10:58 PM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sue,

Susan Hares <[email-masked]<mailto:[email-masked]>> writes:

Lada:

Thank you, Susan Hares

Suggested text:

Suggested text addition:

Good.

https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.jclark.com_2010_01_xml-2Dnamespaces.html&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=TdVg3bDUmf49jN3l0uRAR_G5EH4FnohUc8FZ0zc05-k&e=

Thanks, Lada

Sue Hares

-----Original Message-----
From: Róbert Varga [mailto:[email-masked]]
Sent: Monday, November 13, 2017 7:08 PM
To: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; Susan Hares
<[email-masked]<mailto:[email-masked]>>
Cc: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Xufeng
Liu <[email-masked]<mailto:[email-masked]>>; Jan Medved (jmedved)
<[email-masked]<mailto:[email-masked]>>; Hariharan Ananthakrishnan
<[email-masked]<mailto:[email-masked]>>; 'Nitin Bahadur' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt

Hello,

Regards,
Robert

-----Original Message-----
From: Alexander Clemm [mailto:[email-masked]]
Sent: Monday, November 13, 2017 2:27 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: Alexander Clemm <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
Xufeng
Liu <[email-masked]<mailto:[email-masked]>>; Jan Medved (jmedved)
<[email-masked]<mailto:[email-masked]>>; Róbert Varga <[email-masked]<mailto:[email-masked]>>;
Hariharan Ananthakrishnan <[email-masked]<mailto:[email-masked]>>; 'Nitin Bahadur'
<[email-masked]<mailto:[email-masked]>>
Subject: RE: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt
Importance: High

Hi Sue,

Sue,

--- Alex

Looking at the items:

<ALEX>

<ALEX>

-----Original Message-----
From: Alexander Clemm
Sent: Wednesday, September 27, 2017 1:10 AM
To: 'Susan Hares' <[email-masked]<mailto:[email-masked]>>
Subject: FW: [i2rs] I-D Action:

Hi Sue,

Thanks
--- Alex

-----Original Message-----
From: Alexander Clemm
Sent: Tuesday, September 19, 2017 1:26 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: RE: [i2rs] I-D Action:

Hi all,

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of internet-
[email-masked]<mailto:[email-masked]>
Sent: Tuesday, September 19, 2017 12:09 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [i2rs] I-D Action:
draft-ietf-i2rs-yang-l3-topology-11.txt

Abstract:

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopology_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=e4nhHmx83mz_CfjZixUg_jpTiimD--X5oJQwNigZeRs&e=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopology-2D11&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=R84Hq4KDTeJ0oaup_ZpnQHkE2S3VQhnJmVlZgRR_16M&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopo&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=qQy1xD3vtFLzMj0CEEeejnwLir5jlW69q15MffGej_I&e=
lo
gy
-11

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Di2rs-2Dyang-2Dl3-2Dtopology&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=qyMDKPz7n_bVjmefj9AvYAMQ_XWI0bJmJxPI10kPvaA&e=
-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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=1LSwgdesNm5n9rGxEn9TCcMdUr1ARduyQ1qNLlDRiis&e=

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2rs&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=j8lGTxKMellmv1ApX87GzFdKuSOrQBcE0xp2W6SIIXQ&e=

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=3brt9jSI9QIP4ytEMqM_W_RvigMmB5gQDzVFEIucm38&e=

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5lF9qRRdfczeRIQDxsTAmTgeMgRGs0TV24MNAeiDEZI&s=3brt9jSI9QIP4ytEMqM_W_RvigMmB5gQDzVFEIucm38&e=