Re: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review.
"Susan Hares" <shares@ndzh.com> Wed, 15 November 2017 02:43 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31E61201F2; Tue, 14 Nov 2017 18:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Level:
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiSwDTM7oarX; Tue, 14 Nov 2017 18:43:28 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD82120724; Tue, 14 Nov 2017 18:43:28 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.139.117;
From: Susan Hares <shares@ndzh.com>
To: 'Alexander Clemm' <ludwig@clemm.org>
Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, 'Ladislav Lhotka' <lhotka@nic.cz>, 'Benoit Claise' <bclaise@cisco.com>
References: <00c601d35b57$4764ff40$d62efdc0$@ndzh.com> <012601d35d30$4744c920$d5ce5b60$@clemm.org>
In-Reply-To: <012601d35d30$4744c920$d5ce5b60$@clemm.org>
Date: Tue, 14 Nov 2017 21:43:09 -0500
Message-ID: <00af01d35dbb$7ac932f0$705b98d0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01D35D91.91F4B190"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMH+QEmeKFJT7xE9IebCZTG+PE71ADBEUJ5oKV5V0A=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ooSNyqvkEsFHGed6dIrdCOLVxOM>
Subject: Re: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review.
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 02:43:31 -0000
Alex: I suggested some additions for Lada based on our conversation in email. However, I suggest that you submit the two revisions of the draft that contain the changes you've suggested in email (draft-ietf-i2rs-yang-network-topo-18.txt, and draft-ietf-i2rs-yang-l3-topology-11.txt). My suggestions to LADA were editorial nits in nature. I believe you have resolved all comments for draft-ietf-i2rs-yang-network-topo and we are ready for publication of this document. As soon as I see draft-ietf-i2rs-yang-network-topo-18.txt in the repository, I will request the publication for draft-ietf-i2rs-yang-network-topo-18.txt. Susan Hares Shepherd for draft-ietf-i2rs-yang-network-topo-18.txt From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm Sent: Tuesday, November 14, 2017 5:07 AM To: 'Susan Hares' Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org; 'Ladislav Lhotka' Subject: Re: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review. Hi Susan, all, Please find responses below, <ALEX> Thanks --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Sunday, November 12, 2017 9:41 AM To: 'Alexander Clemm' <ludwig@clemm.org> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo@ietf.org Subject: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review. 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 <ALEX> We do want to retain the ability to represent topologies of multiple types and 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'. So, we would like to keep it as is. </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? 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. <ALEX> We reread the document and believe this should remain as is. TEAS (one of our major use cases) also uses the term underlay; the term underlay is fairly common. An the same time, use of "supporting" in the model itself is appropriate since it expresses the dependency. </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". Comment from shepherd: If you can use the "system-controlled", it would be better. If you cannot, please indicate why in the definitions. <ALEX> Yes, this has been addressed. It is all system controlled now. </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. Comment from shepherd: A comment should be included on why URIs. Did I miss the comment? <ALEX> This 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... Unless Lada insists, we prefer to keep as is. It also avoids the need to perform augmentation to add URL to the model in addition to strings, as the Open Daylight folks have indicated they would otherwise have to do (and which clearly adds complexity that could just as easily be avoided.) </ALEX> 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
- [i2rs] Issues raised by Lada on draft-ietf-i2rs-y… Susan Hares
- Re: [i2rs] Issues raised by Lada on draft-ietf-i2… Alexander Clemm
- Re: [i2rs] Issues raised by Lada on draft-ietf-i2… Susan Hares
- [i2rs] Call for Papers for IEEE Communications St… Hesham ElBakoury