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 protected]<mailto:[email protected]>> wrote: Hi Sue, please see my responses inline. Susan Hares <[email protected]<mailto:[email protected]>> 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: 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: Alexander Clemm [mailto:[email protected]] Sent: Monday, November 13, 2017 9:54 PM To: Róbert Varga; Susan Hares Cc: Alexander Clemm; [email protected]<mailto:[email protected]>; 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 protected]] Sent: Monday, November 13, 2017 7:08 PM To: Alexander Clemm <[email protected]<mailto:[email protected]>>; Susan Hares <[email protected]<mailto:[email protected]>> Cc: Alexander Clemm <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Xufeng Liu <[email protected]<mailto:[email protected]>>; Jan Medved (jmedved) <[email protected]<mailto:[email protected]>>; Hariharan Ananthakrishnan <[email protected]<mailto:[email protected]>>; 'Nitin Bahadur' <[email protected]<mailto:[email protected]>> 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 protected]] Sent: Monday, November 13, 2017 2:27 AM To: Susan Hares <[email protected]<mailto:[email protected]>> Cc: Alexander Clemm <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Xufeng Liu <[email protected]<mailto:[email protected]>>; Jan Medved (jmedved) <[email protected]<mailto:[email protected]>>; Róbert Varga <[email protected]<mailto:[email protected]>>; Hariharan Ananthakrishnan <[email protected]<mailto:[email protected]>>; 'Nitin Bahadur' <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]> Cc: Susan Hares <[email protected]<mailto:[email protected]>> 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 protected]] On Behalf Of internet- [email protected]<mailto:[email protected]> Sent: Tuesday, September 19, 2017 12:09 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> 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://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 protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]> 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= -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ yang-doctors mailing list [email protected]<mailto:[email protected]> 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=
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
