Re: [i2rs] Issues raised by Lada on draft-ietf-i2rs-yang-network-topo in draft-ietf-i2rs-yang-l3-topology-10 review.

"Alexander Clemm" <ludwig@clemm.org> Tue, 14 November 2017 10:07 UTC

Return-Path: <ludwig@clemm.org>
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 407521270A7; Tue, 14 Nov 2017 02:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham 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 mlYw1LMiFR4F; Tue, 14 Nov 2017 02:07:03 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 8AE0F126FB3; Tue, 14 Nov 2017 02:07:03 -0800 (PST)
Received: from LAPTOPR7T053C2 ([115.42.147.243]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LyCFX-1fJlsS2kx3-015SKo; Tue, 14 Nov 2017 11:06:42 +0100
From: Alexander Clemm <ludwig@clemm.org>
To: 'Susan Hares' <shares@ndzh.com>
Cc: i2rs@ietf.org, draft-ietf-i2rs-yang-network-topo@ietf.org, 'Ladislav Lhotka' <lhotka@nic.cz>
References: <00c601d35b57$4764ff40$d62efdc0$@ndzh.com>
In-Reply-To: <00c601d35b57$4764ff40$d62efdc0$@ndzh.com>
Date: Tue, 14 Nov 2017 18:06:40 +0800
Message-ID: <012601d35d30$4744c920$d5ce5b60$@clemm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01D35D73.55691A90"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMH+QEmeKFJT7xE9IebCZTG+PE71KCqa0UA
Content-Language: en-us
X-Provags-ID: V03:K0:wydkLwWVuR258yAmxRhPwhritzB08gfG3subWYeehVXpyiNAIyO dZt6d3iBwiM9bL5gqIZyiU4X13+eol52OAibzpKIQ5k4K+q9xZZRXuPKyxD7NXDOQXCgTS5 kBLb6fFQsE4/YubSvtF3Zea43BWWwDUSeAd1l+W1R1a3g5eVC4dExAv0aNobXEZctjgoF7v 15zU94+kCdxncGXPlDVKw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:hCRn8vK4HoQ=:KnkYBzeo8klfb7SeO7vUlb Bs9LwQNF80ygogYfSjeCLoavlpMjSgH2zPkH11jjbNETJHCCjp9P+QGujfOm5pFrBM5ZsQfes 4a4DYrRjqlHy6TefieiDHczKUQS1eGAOz9r+nksdnMRNiCMtcGNfxAdAUCjsvLchSU3cGRV6q SIVSnBP5neOPd62hDJn0+p8ZJE0eBcKdXpNBkiuQ33mtubb5jxnS9binhkJ6PboXpsR7AZzdk d6f4z4T4h+zy7b3MXnG312zY8/9zVXqmRBnklcf/IONWku7bO4KoemmsJht53D+L8p0YtM74I axbHR+MY8jQ8iYaNyG0uVqO8XQHAg09IHGTV+BPfphUNBPMm/jSWE6BI3/ioEvMeaqzwSZuX6 vbTzR/LofdY/ZTWgVtEGLX6hhi5ITuyK7AxZqKSmTWIs21WC0vwSG6tzkvB2G8WIgG2PVqwli BxA0L5v69JGGX6tioxY+3ClKXK4orrfwmFEYa1RiMv6x1tKWgXGDbjVXBz0iCmdKfDbZU9Q18 noJruQBIh+W2LeSWUw06wiztSnCViY2r1kKCg++8cSbC2WlDq2C3BoN/qIT7gdXhsf3jtFTZD K2arCZ2XpTQ0VYNaJ9DZGwX/M+8QEg69LSx+wtd+J2ITo6+pKPizEYBrN2Na877TWgGBDM6Lu f7Yean9ycTTAR2hlIpvc9wiZZB6QXJl7n9tKLmLnPthCH6zaWMRlUm9K7TzO0HLTB/YSCG0VK /OlS7+E2hgulUmKlMGEwstjVIxgvqV6UkT0XdQoKcRjABGEAao0ELEir/Vc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/iSDEZ3e2S_5mrm1DGfwQOPDHU5M>
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: Tue, 14 Nov 2017 10:07:10 -0000

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