[i2rs] Reply to review-ietf-i2rs-yang-network-topo-09-genart-lc-bryant-2016-12-12-01
"Alexander Clemm" <ludwig@clemm.org> Tue, 14 November 2017 08:10 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 8E481124234 for <i2rs@ietfa.amsl.com>; Tue, 14 Nov 2017 00:10:18 -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 c62ScIV9Q6vc for <i2rs@ietfa.amsl.com>; Tue, 14 Nov 2017 00:10:10 -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 B88BA128DF6 for <i2rs@ietf.org>; Tue, 14 Nov 2017 00:10:09 -0800 (PST)
Received: from LAPTOPR7T053C2 ([115.42.147.243]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LszzY-1fBGz71noI-012QK9; Tue, 14 Nov 2017 09:09:52 +0100
From: Alexander Clemm <ludwig@clemm.org>
To: 'Susan Hares' <shares@ndzh.com>, 'Stewart Bryant' <stewart.bryant@gmail.com>
Cc: i2rs@ietf.org
Date: Tue, 14 Nov 2017 16:09:50 +0800
Message-ID: <00af01d35d1f$f4e2a5e0$dea7f1a0$@clemm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01D35D63.030A0490"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdNdH9uW9kUsc9iUT1GntnBowIBGxA==
Content-Language: en-us
X-Provags-ID: V03:K0:4mK8tNbGUf6JhT39O0XxoEWZ1F0wETOAY190m+SPcYx8zjxXtTa nVs4ylVDRkvPq5VvGYnKzJ0vHxsWdFEwQguM6n89fD4tPrZcaGgvGLgXmLWU5l0GFRpiqO7 XBUhXBnAT4sS1BhDYHDPbMTbA3Olm+1M+UIvjw6dVU3k35WqgnEwyTRyet8G9a0WT+I4XNI E0QPdMEoOVw5mcHpxfvAQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:FOdJk7ud9qg=:V65tQFRRgZbJAYYQ8ESJpV 1eC4aGdTTdSEXEEaBMSnBL/FPZOW4e50B2sYRx3rJbE2dFUIEzlpBb213XCjymB4T29IGCnB5 gf7RavdEQkjZMrgnJw+Y0UTiCcswLo62/irCGnAzoiwvvEBSekk19ML+qoCZ12A0DhaTPosjr sab9FuwerXwBzdCaoSpo4LHbzNph83H8DQtf59M189Xy/P+gcInsqrZHWpuFOWAp8V4A7ogci U+U8RhWkEJxO/WO6FMTWb5FHdboqrOyirCRX4n9yp/6/nYQhUKQBSK1nDrQxINmgtNAyqpR7L GqMeEyBgrTw93IwWyUm4TEzKE4/RbYFqIwtwVd2+HKQg3rc7fYpjRVZLRCmaOgMLMiO6IYfiX VS30Oi3seVDYWg7uDdLpEP+OEYko1zBM4Zy0hCL08HOm0mgi3TLPl7eJIzUIZFomwvk27Pey+ rp7afHbyIT4r8gG0+vdwV629SBEGODxakedkstC6YWjbGaS/kPo2qrMYDJ7Uift30vvxdKdTM bC2AqG3DyqSuizio4/4Z7FoA90erXriLeTuedbZGDfxZC0o2/e66fu+TnWbLdAwjYR8R3Gv6Z AzG6RrGErUj6VXHO3+zztmVK8CLcOYgUeDxaWWuqP31rCSSTD2fliEl0DnCEISOwupjqAHR5h 9xzDcAEtS4S47W6LVEawJS0xSwMg2UfyzyCS7+WdDq5XEfXkhy9Yzfz6We44PrkmciISOtSW1 yQ/xfe1wYqyKZcg5fWLP/bF7tLyjnZaf6dfSTFgaRNhnoyFapar47+/1IR0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/MzwIwyx4eWS3ZqArB5-gAmVD-T0>
Subject: [i2rs] Reply to review-ietf-i2rs-yang-network-topo-09-genart-lc-bryant-2016-12-12-01
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 08:10:18 -0000
Hello Stewart, Thank you for your comments. I am just going through them as advised by Sue - I am not so familiar with the whole procedure of getting this to the finishing line, hence the late response. Actually, most of them had already been taken care of , even if I did not send a response (my apologies.). Sue, please chime in if from your end anything is missed. Please see my replies inline, <ALEX>. Thank you --- Alex I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at < <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-i2rs-yang-network-topo-09 Reviewer: Stewart Bryant Review Date: 12 Dec 2016 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: Ready with issues This is a well written document and is basically ready for publication and the issues are minor. There are a number of minor issues that the responsible AD needs to look into, and a systematic English problem (missing pronouns) that the authors ought fix to avoid the RFC Editor having to ask. There are six authors which I assume is acceptable. I am not a YANG expert and have therefore not checked the YANG syntax or logic. Detail: ========= 1. Introduction This document introduces an abstract (base) YANG [RFC7950] [RFC6991] data model to represent networks and topologies. The data model is divided into two parts. The first part of the model defines a network model that allows to define network hierarchies (i.e. network SB> minor English problem : "allows to define" perhaps "allows the SB> definition of" or "allows an operator to define". <ALEX> Changed to "that enables the definition of network hierarchies" (we don't want to be specific as to whether that will be a devops guy, a controller application, an operator, or someone else.) </ALEX> stacks) and to maintain an inventory of nodes contained in a network. <ALEX> We prefer to keep it, again because there are multiple roles who might interact with the model. </ALEX> SB> same problem as above. SB> Also I am a little worried that the term "network stack" is going to SB> to confuse a lot of people. Many will confuse network stack with SB> protocol stack. There probably needs to be some text explaining SB> the difference. <ALEX> The term network stack is explained in the surrounding context: "network hierarchies". Added ". that are layered on top of each other" to make it even clearer. </ALEX> ======== While it would be possible to combine both parts into a single model, the separation facilitates integration of network topology and network inventory models, by allowing to augment network inventory information separately and without concern for topology into the network model. SB> same English problem - "by allowing to augment" <ALEX> Modified to "because it allows to" (but I think it is clear either way). </ALEX> The model can be augmented to describe specifics of particular types SB> describe THE specifics of networks and topologies. For example, an augmenting model can <ALEX> I changed it. (I actually liked it better before; to me the "the" assumes that all specifics needs to be specified, whereas just having "specifics" leaves the possibility open that some models may only specify some specifics.) </ALEX> SB> Not sure is that should be augmenting or augmented (same further SB> down the para). ============= The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The models allow applications to operate on an inventory or topology of any network at a generic level, where specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type does comes into play and the model is augmented, the instantiated data still adheres to the same structure and is represented in consistent SB> nit: in a consistent <ALEX> done </ALEX> fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types. The abstract (base) network YANG module introduced in this document, entitled "network.yang", contains a list of abstract network nodes and defines the concept of network hierarchy (network stack). The abstract network node can be augmented in inventory and topology SB> nit possibly "augmented in both the inventory" SB> either way I think at least a "the" is missing <ALEX> I reread it and think this is good? </ALEX> models with inventory and topology specific attributes. Network ========================== A network can contain multiple topologies, for example topologies at different layers and overlay topologies. The model therefore allows to capture SB> English: "allows to capture" - who does it allow to make a capture? <ALEX> well, the users of the model. Added "users". </ALEX> relationships between topologies, as well as dependencies between nodes and termination points across topologies. An example of a topology stack is shown in the following figure. =========================== 3. Definitions and Acronyms HTTP: Hyper-Text Transfer Protocol SB> HTTP is stared in the "well known" list and so does not need expanding SB> also it is only used once in the text <ALEX> removed </ALEX> =========================== When a network is of a certain type, it will contain a corresponding data node. Network types SHOULD always be represented using presence containers, not leafs of empty type. This allows to represent SB> missing word "This allows who or what to represent" <ALEX> changed to "This allows the representation of hierarchies of network subtypes within the instance information" </ALEX> =========================== This (physical) network, respectively the (entities) nodes in that network, can then be referred to as underlay network and nodes from the other (logical) networks and nodes, respectively. Note that the model allows to SB> allows who to define? <ALEX> changed to "allows for the definition of"</ALEX> define more than one underlay network (and node), allowing for simultaneous representation of layered network- and service SB> Spurious "-" <ALEX> "-" removed </ALEX> topologies and physical instantiation. Similar to a network, a node can be supported by other nodes, and map onto one or more other nodes in an underlay network. This is captured in the list "supporting-node". The resulting hierarchy of nodes allows also to represent device stacks, where a node at one SB> Allows who to also? <ALEX> changed to "allows also for the representation of"</ALEX> level is supported by a set of nodes at an underlying level. For example, a "router" node might be supported by a node representing a route processor and separate nodes for various line cards and service modules, a virtual router might be supported or hosted on a physical device represented by a separate node, and so on. Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that SB> s/annother/another/ <ALEX> fixed </ALEX> can be discovered. SB> I don't understand the end of the previous para. I think you are SB> covering the case of SDN and classic self-learning networks where SB> information is discovered from neighbours. If that is the case SB> it is not clear from the text above. <ALEX> I reread it and think it is clear. I did change however to "controlled by the system" (instead of populated by the server") to make it very analogous to the way things are worded in NMDA. </ALEX> If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be SB> s/be/being/ <ALEX> The text in question has been changed, but thanks for pointing this out. </ALEX> reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. ========================== A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface. SB> When I read this I immediately wondered about multi-point links SB> You clear up later that your model does not support them. It SB> would be kind to the reader to pre-empt the question here. <ALEX> This is later explained in a separate subsection. Since the paragraph in question is just providing a general overview, for the sake of editorial brevity I prefer to keep it as is. <ALEX> =========================== 4.4.4. Use of groupings The model makes use of groupings, instead of simply defining data nodes "in-line". This allows to more easily include the SB> this allows who? <ALEX> changed to "This makes it easier to" <ALEX> ============================= 4.4.7. Mapping redundancy In a hierarchy of networks, there are nodes mapping to nodes, links mapping to links, and termination points mapping to termination points. Some of this information is redundant. Specifically, if the link-to-links mapping known, and the termination points of each link SB> link-to-links mapping IS known <ALEX> done </ALEX> ============================ In the case of a physical network, nodes represent physical devices and termination points physical ports. It should be noted that it is also conceivable to augment the model for a physical network-type, SB> do you mean conceivable or possible? <ALEX> both. Changed to possible </ALEX> ==================== That said, it is conceivable that certain types of topology need to also be SB> again I think you mean "it is possible" configurable by an application. The model needs to support both cases. ===================== <ALEX> conceivable is on longer used in the document </ALEX> Another alternative would make use of a YANG extension to tag specific network instances as "server-provided" instead of defining a leaf object, or rely on the concept of YANG metadata [RFC7952] for SB> perhaps "or relying on" <ALEX> the surrounding paragraph has been edited so comment no longer applies </ALEX> the same effect. The tag would be automatically applied to any topology data that comes into being (respectively is configured) by an embedded application on the network, as opposed to e.g. a controller application. ======================== 4.4.11. Identifiers of string or URI type The current model defines identifiers of nodes, networks, links, and termination points as URIs. An alternative would define them as string. SB> given "them" (plural) I think that should be "strings" <ALEX> changed </ALEX> The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology/node/tp exists in a larger context, hence it is useful to be able to correlate identifiers across systems. While strings, being the universal data type, are easier for human beings (a string is a string is a string), SB> Well maybe, it could be an ASCII string or an EBCDIC string etc <ALEX> well, I think the point should be clear </ALEX>
- [i2rs] Reply to review-ietf-i2rs-yang-network-top… Alexander Clemm