From nobody Tue Sep 5 01:07:48 2017 Return-Path: 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 C243F132705; Tue, 5 Sep 2017 01:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 JniFwHNUVd5p; Tue, 5 Sep 2017 01:07:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 A6BC2132396; Tue, 5 Sep 2017 01:07:36 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.71.191.170]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0McoSN-1e6wj63K4H-00Hz4I; Tue, 05 Sep 2017 10:07:34 +0200 From: "Alexander Clemm" To: "'Kent Watsen'" , Cc: , References: <150223663961.3605.4696763251648960641@ietfa.amsl.com> In-Reply-To: <150223663961.3605.4696763251648960641@ietfa.amsl.com> Date: Tue, 5 Sep 2017 01:07:31 -0700 Message-ID: <6be001d3261e$06fc2aa0$14f47fe0$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLosGLB+IujuUjZRAxhjJ25zul68qBltENw Content-Language: en-us X-Provags-ID: V03:K0:aJFgy5s1+hRwCWswe89jAXXIhkiUpHwcRzzI+5xBw3CZttrkaWk cMPYq/e4qnUXpSShJzzW080eKDyDHjxk3PsR2GzR+KfMH6ZPCS1Tx9+kgZgHAWLougIVQvc zoiBKAYWFgVdjqz8le3a6U1/oosUNLUUMJkd7h4imffGHGXrgD+dh+RXzktO+X/AWDqXD// In8IYryWL4IFdswACpIgA== X-UI-Out-Filterresults: notjunk:1;V01:K0:QOcENj+k92Y=:TCyP9lHLcsndAT7K9GNrqx F2GU9JunDb7GC27NXD94aHr9k7bh33VkyRO3xYHXEfnD2IuffJU6WdxP6ESDYoK+6DooaHhYx Ad1w38MQKpGT3G8jPUSszKIGZou7XmPaIq6lfpxA4yIu2mleEpmihohKhED7TSL0CcQwLPKi+ 7KAi+h8xM9v31oJyYHKuZ43sHOewtCYg6d1zPFM1UREdzHVhR0K5I/LZzzdnvTWpOhyKc05JT Sm3RBuyI8NhZtFiEdse4UuoUF7uFtMlu0Pdl/Zq/XgMIu50QYrTaoLBEm+mD/w1i+yVW4Q9JR Yvvdd/1EyLnY9uN2LakyDSlOAr3UfxPo/chI3HOpfcsTZrtxJhUmMN6kX/KF4J4/B9ejY1uHL LI0sHrioKwCp1mZ8dDjjelB8JxX2Lzsthk8Pm2qRbMaoHwlVky0pxfnNxHqZSWXpZRYrSv3UD XJzpAmHJcdmwI+tUUBWuXY6g60oSeyvD3AZ/qJEu1m+vpUWznVq/HAcnqFlGmFuwQ2izt9zkl fX/JeTVkimx2VLAKsADatVTd8pYAq34eggx/SYmRNe/MxgsHiyKtRKWAyqaJZJL6HI5HIhXZZ TFvIRTJZHDC+lSjPatzqdwyip0HRCGVznHGcVgkFfw/ritYxaihpWxTE+lu9LnBRAkNiyRKsr dS1jZW6qxuIbo9U8y/c+Xh9Qd6/1tgYz8aKsFGpCipxkPidTTM2cUTyyQCNaxfulOySs6dne0 WFj2LB72pf4EnOmUFavG9zPkQRbBNvdpBLmme5YGxz0BrL44hBiQK6MyLT0= Archived-At: Subject: Re: [i2rs] Yangdoctors last call review of draft-ietf-i2rs-yang-network-topo-14 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 08:07:46 -0000 Hi Kent, Thank you for your thorough review. =20 I am posting a rev 15 with the comments addressed, per responses inline, = --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, August 8, 2017 4:57 PM To: yang-doctors@ietf.org Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-network-topo.all@ietf.org Subject: [i2rs] Yangdoctors last call review of = draft-ietf-i2rs-yang-network-topo-14 Reviewer: Kent Watsen Review result: Almost Ready YANG Doctor review of draft-ietf-i2rs-yang-network-topo-14 (by Kent = Watsen) 4 modules are defined in the draft: - ietf-network@2017-06-30.yang - ietf-network-topology@2017-06-30.yang - ietf-network-state@2017-06-30.yang - ietf-network-topology-state@2017-06-30.yang No validation errors from either `pyang` or `yanglint`. 0 examples are defined in the draft. The -state modules appear to have all the correct changes from their = base modules. Regarding ietf-network@2017-06-30.yang: - prefix =E2=80=9Cnd=E2=80=9D, should be =E2=80=9Cnw=E2=80=9D? (in IANA = Considerations also) The prefixes are "historic". We could change them, but this = will have ripple effects on derived models.=20 - =E2=80=9Cimport ietf-inet-types=E2=80=9D should have a = =E2=80=98reference=E2=80=99 to RFC 6991 done - remove =E2=80=9CWG Chairs=E2=80=9D, per the template in rfc6087bis-13 = Appendix C. done - s/Editor/Author/? (this is a preference choice) left as is - I think "Editor" is what is commonly used. If you = feel strongly about this, please let us know. - defines =E2=80=98network-ref=E2=80=99 that is unused within module = (it=E2=80=99s used by ietf-network-topology) left as is. This might be useful also for other modules. Rather = than have it be redundantly defined elsewhere, IMHO this is the best = place to keep it. - leafref paths don=E2=80=99t include prefix (rfc6087bis S4.2) Prefixes added Regarding ietf-network-topology@2017-06-30.yang: - prefix =E2=80=9Clnk=E2=80=9D should be =E2=80=9Cnt=E2=80=9D or maybe = =E2=80=9Cnwtp=E2=80=9D? (in IANA Considerations also) The prefixes are "historic". We could change them, but this = will have ripple effects on derived models.=20 - =E2=80=9Cimport ietf-inet-types=E2=80=9D should have a = =E2=80=98reference=E2=80=99 to RFC 6991 - =E2=80=9Cimport ietf-network=E2=80=9D should have a = =E2=80=98reference=E2=80=99 to RFC XXXX - remove =E2=80=9CWG Chairs=E2=80=9D, per the template in rfc6087bis-13 = Appendix C. done - s/Editor/Author/? (this is a preference choice) left as is, consistent with above - defines grouping link-ref and tp-ref that are unused within module left as is. While it would be possible to strike these, we feel = they might eventually be useful for other modules that want to reuse = what arguably constitutes a "complex data type". Rather than have it be = redundantly defined elsewhere, IMHO this is the best place to keep it. = - mandatory true for source/dest-node/tp? It is true that in general this will be included, but there may = be instances when the fact that there is a link will need to be = represented, even if it is not properly connected yet. Therefore, we = would not make it mandatory. =20 =20 - replace =E2=80=9Ctp=E2=80=9D with =E2=80=9Cterm-pt=E2=80=9D? (both in = =E2=80=9C-tp=E2=80=9D and =E2=80=9Ctp-=E2=80=9C uses) prefer to keep. Regarding ietf-networ-statek@2017-06-30.yang: - similar comments to ietf-network@2017-06-30.yang: Regarding ietf-network-topology-state@2017-06-30.yang: - similar comments to ietf-network-topology@2017-06-30.yang. Analogous comments apply Comments on draft: 1) The document still has references to = =E2=80=9Cserver-provided=E2=80=9D. Not the YANG leaf of course, but in = general text. For instance =E2=80=9CThe model does allow to layer a = network that is configured on top of one that is = server-provided.=E2=80=9D I think that the statement is more about values being in = than how it was learned. All uses of =E2=80=9Cserver-provided=E2=80=9D = should be examined for correctness. Corresponding textual updates throughout 2) This sentence doesn=E2=80=99t make sense to me, how can a = server-provided model (you mean data?) access any information in = conventional datastores?: =E2=80=9CAn implementation's security policy MAY further restrict = what information the server-provided model is allowed to access in standard configuration data-stores,=E2=80=9D Either way, this text likely should be moved to the Security = Considerations section. I removed this sentence altogether. What we had originally in = mind was to refer to the fact that you could have a leafref point to an = object that has a different access authorization. This is nothing = specific to the model, but a corner case of NACM. I think it is safe = to remove this.=20 3) Should the last paragraph in Section 1 be removed now? Is the module = expected to continue to update? Yes, agree - removed. This was historic; we simply hadn't looked = at this section in the draft for a while:-) 4) S4.1, P3: the text here says new data nodes are augmented in, but the = YANG module itself says that only presence containers are allowed. I am not sure I see an issue here? The "network-types" node is a = container (not a presence container), which will serve as a target for = augmentation. The anticipated pattern is that nodes that are going to = be augmented in will be presence containers that indicate that a = network/topology of a certain type is present. =20 5) are the mandatory statement values set appropriately everywhere? (e.g., source-node?, source-tp?) Yes, we had a bunch of discussions on this in the past; mandatory = is not needed. 6) network-type is a presence container, not an identity? No where in = the draft is there an example showing it being used. The examples are in the L3 topology draft. Let me add a text = snippet referring to that 7) Section 4.4.8., why not use identities? This was our design choice. We did want to be able to represent = "type hierarchies", this we could do with containers (that can become = targets for augmentation). =20 8) S4.4.9 is a duplicate of some text in S4.1 Looking at the text, some things described in 4.4.9 are alluded = to in 4.1 (the general overview), but not in a way that I would consider = "overspecified" or redundant - would prefer to keep as is - the way it = is it flows well IMHO. =20 9) This statement is true, but I think misleading in context. = =E2=80=9CYANG requires data nodes to be designated as either = configuration or operational data, but not both=E2=80=9D. It seems that = the solution depends entirely on config true nodes, and NMDA to present = the operational value of those config true nodes. Right? This text of course predates the relatively recent NMDA stuff, = but NMDA does not make it false. I don't find the text misleading, but = I did make some edits to refer specifically to NMDA, to clarify that the = nodes are config true, and that NMDA is used for the distinction. =20 10) When using , you should have a note to the RFC Editor = to change the date to the date of publication, both in the filename as = well as in the module=E2=80=99s =E2=80=99revision=E2=80=99 statement. Thank you, done 11) IANA Considerations has comments =E2=80=9C(RFC form)=E2=80=9D - are = these supposed to be notes to RFC Editor to replace with final RFC = designation? Yes, this is what is meant here. Replaced this with a more = explicit statement "NOTE TO RFC EDITOR:" 12) Your Security Considerations section should follow the template = here: https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines I made updates, but do not list every single object with its = security implications which I find excessive. =20 13) create examples for the use-cases in Appendix A? Note, every draft = should have examples of its YANG modules... Really prefer not to unless we have to. We want to be done with = this. The model has been successfully used and extended; IMHO an = example is not needed to add for clarification. Nits: - why reference RFC6991 in the Introduction? removed - replace =E2=80=9Callows to define=E2=80=9D with =E2=80=9Cenables the = definition of=E2=80=9D ok - in a few places, you refer to =E2=80=9Cnetwork.yang=E2=80=9D, but the file is called =E2=80=9Cietf-network.yang=E2=80=9D. fixed - in a few places, you refer to =E2=80=9Cnetwork-topology.yang=E2=80=9D, but the file is called =E2=80=9Cietf-network-topology.yang=E2=80=9D. fixed - replace =E2=80=9C- X1 and X2 - mapping onto a single L3 network = element=E2=80=9D with =E2=80=9C(X1 and X3) mapping onto a single L3 network element = (Y2)=E2=80=9D ok - replace =E2=80=9Cdata-store=E2=80=9D with =E2=80=9Cdatastore=E2=80=9D ok - replace =E2=80=9Cmodel=E2=80=9D with =E2=80=9Cdata model=E2=80=9D = where it=E2=80=99s not already. not sure there were any ambiguities and it's been done in other = cases, but ok - replace =E2=80=9Cthe datastore=E2=80=9D with just = =E2=80=9C=E2=80=9D - replace =E2=80=9Cthe intended datastore=E2=80=9D with just = =E2=80=9C=E2=80=9D Updated most instances, i.e. those where it made sense, but left = some in place as I believe it flows better. - update Section 2 to also include a reference to RFC 8174 (see RFC = 8174) ok - pull the =E2=80=9Cdatastore=E2=80=9D term from the revised-datastores = draft? I think the definition here is good - NETCONF and YANG don=E2=80=99t need to be terms/defined, since = references to their RFCs are provided when they=E2=80=99re used. ok, removed - s/the network.yang module/the =E2=80=9Cietf-network=E2=80=9D YANG = module/ ok - your tree-diagram notation in S4.1 isn=E2=80=99t complete. And you = duplicate it in S4.2. Create a top-level section called =E2=80=9Ctree diagram = notation=E2=80=9D that both sections reference? For the notation description, I incorporated a reference to the = YANG tree diagrams draft - s/allows to represent/allows representation of/ - s/another container/a presence container called/ - s/allows to define more/allows definition of more/ - s/allows also to represent/allows representation of/ updated - s/configuration and intended datastores/conventional datastores/ I think the current reads better, prefer to keep - s/and show up only/and thus only appear/ - /ietf-network:networks/network/network-id - being the list=E2=80=99s = key, I was expecting this to the first element defined. - for the various leafrefs in both models, I see a lot of longish relative paths; suggest you change these to absolute paths if possible Prefer to keep; they work fine - /nd:networks/nd:network:/link/link-id is the list key but not the first leaf listed - incomplete sentence: =E2=80=9Caugmentations can in turn against = augmenting modules=E2=80=9D fixed - s/need to specified/need to be specified/ - s/if the link-to-links mapping known/if the link-to-links mapping are known/ - s/each link known/each link are known/ - s/the operational datastore// - s/into the data model without relying/into without = relying/ updated - s/in the following two companion modules/the following two companion = modules/ keeping this one, original reads better than the substitution = - s/that represent a state model/to represent the operational state/ ok Thanks, Kent _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Sep 5 09:07:45 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6B132D76; Tue, 5 Sep 2017 09:07:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150462766367.31828.18248110687142099961@ietfa.amsl.com> Date: Tue, 05 Sep 2017 09:07:43 -0700 Archived-At: Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:07:44 -0000 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 Data Model for Network Topologies Authors : Alexander Clemm Jan Medved Robert Varga Nitin Bahadur Hariharan Ananthakrishnan Xufeng Liu Filename : draft-ietf-i2rs-yang-network-topo-15.txt Pages : 47 Date : 2017-09-05 Abstract: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The data model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory data models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-15 https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-network-topo-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-15 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/ From nobody Mon Sep 11 03:40:35 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 301DE132D4A; Mon, 11 Sep 2017 03:40:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-i2rs-yang-network-topo@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org, Ladislav Lhotka X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150512643419.9724.17953376593038070088.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 03:40:34 -0700 Archived-At: Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-network-topo-15: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 10:40:34 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Preliminary note: I hope I'm doing the right thing by updating this DISCUSS point as I understand that the document is back to the WG. However, since I reviewed the version 15, since some of my ballot points have been addressed (thank you), and since I wanted to share my feedback publicly, here is my feedback. Please follow the YANG security guidelines template at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable data -- nodes (those are all the "config false" nodes, but also all other -- nodes, because they can also be read via operations like get or -- get-config) are sensitive or vulnerable (for instance, if they -- might reveal customer information or violate personal privacy -- laws such as those of the European Union if exposed to -- unauthorized parties) Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: I don't understand why the security considerations section of a YANG module document speaks about this: Rules expressed in NACM can be applied analogously also to other protocols that attempt access to YANG-defined data. In fact, it needs to be applied in the same way and should, like YANG, thus be considered independent of any particular protocol that is used to access YANG-defined data. Otherwise, access control rules defined by NACM could be very easily circumvented simply by using another access mechanism which does not enforce NACM. The alternative of mandating the introduction of mechanisms parallel to NACM that specify the same access control rules for other transports is clearly undesirable, as this would not only inhibit ease-of-use of systems that implement multiple protocols to access YANG data, but also open the specter of security holes due to inconsistencies in articulation and enforcement of rules across mechanisms that are essentially redundant. This is even confusing to speak about other protocols before/without specifying those protocols. You should remove this. OLD DISCUSS, FOR INFORMATION ONLY: To make sure both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my DISCUSS. As background, email sent to I2RS/IESG on Jan 24th 2017 Let me repeat what I mentioned already on the I2RS mailing list: This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol. This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol. Hence I'm advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details. This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally applicable to this draft-ietf-i2rs-yang-l3-topology draft. I still maintain this point of view: it would be a mistake to limit a data model usage to a particular protocol. These topology documents are not I2RS YANG models, these are YANG models, which can be used in different contexts. I'm very concerned if we start having per-WG or per context data models in the IETF. Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the requirements. We can't modify the current generic YANG security considerations for an I2RS control plane and a new datastore that are not yet specified. If you want to describe how I2RS will be using those topology YANG models (and any YANG models btw), then it's suitable to include this part of the I2RS protocol spec or part of an I2RS applicability statement. This is typically where you would describe some protocol specific information such as "write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID)". Let me make my point differently. Let's assume for a moment that I2RS needs to use the IETF interface YANG model, does it mean that you will require RFC 7223bis with an updated security considerations? This can't be. I still think the generic YANG security guidelines is suitable, as it relates to IETF specified protocols NETCONF and RESTCONF. Addition of some generic information about the data model (not I2RS protocol) might be useful though. For example, text around "there is a risk that a write to a topology may create a looping topology or overload a particular node". Note that I don't think the the security considerations is the best section for this though. Regards, Benoit ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: The data model obeys the requirements for the ephemeral state found in the document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the without relying on a configuration datastore. => operational state datastore, according to https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ From nobody Tue Sep 12 11:58:23 2017 Return-Path: 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 5DE70132D91; Tue, 12 Sep 2017 11:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 McYHntV6Vjad; Tue, 12 Sep 2017 11:58:13 -0700 (PDT) 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 0CF9113293A; Tue, 12 Sep 2017 11:58:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: "'Benoit Claise'" , "'The IESG'" Cc: , , , "'Ladislav Lhotka'" References: <150512643419.9724.17953376593038070088.idtracker@ietfa.amsl.com> In-Reply-To: <150512643419.9724.17953376593038070088.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 14:57:55 -0400 Message-ID: <015101d32bf9$0b435710$21ca0530$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJ9lcLxoHgZMC+mlFbay4njkr0QaLEBSQw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-network-topo-15: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:58:15 -0000 Benoit: I really appreciate you sending this DISCUSS information. I had = forgotten to check these in the drafts. Russ and I will make sure these = get handled prior to the second WG LC.=20 Sue Hares=20 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Monday, September 11, 2017 6:41 AM To: The IESG Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org; Ladislav Lhotka Subject: Benoit Claise's Discuss on = draft-ietf-i2rs-yang-network-topo-15: (with DISCUSS and COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-15: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Preliminary note: I hope I'm doing the right thing by updating this = DISCUSS point as I understand that the document is back to the WG. = However, since I reviewed the version 15, since some of my ballot points = have been addressed (thank you), and since I wanted to share my feedback = publicly, here is my feedback. Please follow the YANG security guidelines template at = https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines There are a number of data nodes defined in this YANG module = that are writable/creatable/deletable (i.e., config true, which is the = default). These data nodes may be considered sensitive or vulnerable in = some network environments. Write operations (e.g., edit-config) to = these data nodes without proper protection can have a negative effect = on network operations. These are the subtrees and data nodes and = their sensitivity/vulnerability: -- for all YANG modules you must evaluate whether any readable = data -- nodes (those are all the "config false" nodes, but also all = other -- nodes, because they can also be read via operations like get or = -- get-config) are sensitive or vulnerable (for instance, if they = -- might reveal customer information or violate personal privacy -- laws = such as those of the European Union if exposed to -- unauthorized = parties) Some of the readable data nodes in this YANG module may be = considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and = data nodes and their sensitivity/vulnerability: -- if your YANG module has defined any rpc operations -- = describe their specific sensitivity or vulnerability. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: I don't understand why the security considerations section of a YANG = module document speaks about this: Rules expressed in NACM can be applied analogously also to other protocols that attempt access to YANG-defined data. In fact, it needs to be applied in the same way and should, like YANG, thus = be considered independent of any particular protocol that is used to access YANG-defined data. Otherwise, access control rules = defined by NACM could be very easily circumvented simply by using another = access mechanism which does not enforce NACM. The alternative of = mandating the introduction of mechanisms parallel to NACM that specify the = same access control rules for other transports is clearly undesirable, = as this would not only inhibit ease-of-use of systems that implement multiple protocols to access YANG data, but also open the specter = of security holes due to inconsistencies in articulation and = enforcement of rules across mechanisms that are essentially redundant. This is even confusing to speak about other protocols before/without = specifying those protocols. You should remove this. OLD DISCUSS, FOR INFORMATION ONLY: To make sure both draft-ietf-i2rs-yang-network-topo and = draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my = DISCUSS. As background, email sent to I2RS/IESG on Jan 24th 2017 Let me repeat what I mentioned already on the I2RS mailing list: This document contains a YANG model, a generic YANG model that could = be accessed by NETCONF, RESTCONF, or the future I2RS protocol. This = document doesn't say (and that would be a mistake IMO if it would) that this = YANG model can only be accessed by the I2RS protocol. Hence I'm = advocating that the security considerations diligently follow https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and = that they don't go in the I2RS protocol specific details. This comment was made for draft-ietf-i2rs-yang-network-topo, but is = equally applicable to this draft-ietf-i2rs-yang-l3-topology draft. I = still maintain this point of view: it would be a mistake to limit a data = model usage to a particular protocol. These topology documents are not = I2RS YANG models, these are YANG models, which can be used in different = contexts. I'm very concerned if we start having per-WG or per context = data models in the IETF. Btw, I haven't seen a RFC specifying what the = I2RS protocol is, only the requirements. We can't modify the current = generic YANG security considerations for an I2RS control plane and a new = datastore that are not yet specified. If you want to describe how I2RS = will be using those topology YANG models (and any YANG models btw), then = it's suitable to include this part of the I2RS protocol spec or part of = an I2RS applicability statement. This is typically where you would = describe some protocol specific information such as "write contention = for two clients writing a node using I2RS priority (linked to I2RS = User-ID)". Let me make my point differently. Let's assume for a moment that I2RS = needs to use the IETF interface YANG model, does it mean that you will = require RFC 7223bis with an updated security considerations? This can't = be. I still think the generic YANG security guidelines is suitable, as it = relates to IETF specified protocols NETCONF and RESTCONF. Addition of = some generic information about the data model (not I2RS protocol) might = be useful though. For example, text around "there is a risk that a write to a topology may = create a looping topology or overload a particular node". Note that I = don't think the the security considerations is the best section for this = though. Regards, Benoit ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: The data model obeys the requirements for the ephemeral state found in the document [I-D.draft-ietf-i2rs-ephemeral-state]. For = ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the without = relying on a configuration datastore. =3D> operational state datastore, according to = https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ From nobody Fri Sep 15 08:32:21 2017 Return-Path: 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 B75F8132F65; Fri, 15 Sep 2017 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9c5FfjBLDVLp; Fri, 15 Sep 2017 08:32:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54F8132153; Fri, 15 Sep 2017 08:32:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3C7A6B80E60; Fri, 15 Sep 2017 08:31:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, i2rs@ietf.org Message-Id: <20170915153148.3C7A6B80E60@rfc-editor.org> Date: Fri, 15 Sep 2017 08:31:48 -0700 (PDT) Archived-At: Subject: [i2rs] RFC 8241 on Interface to the Routing System (I2RS) Security-Related Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 15:32:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8241 Title: Interface to the Routing System (I2RS) Security-Related Requirements Author: S. Hares, D. Migault, J. Halpern Status: Informational Stream: IETF Date: September 2017 Mailbox: shares@ndzh.com, daniel.migault@ericsson.com, joel.halpern@ericsson.com Pages: 20 Characters: 44786 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-i2rs-protocol-security-requirements-17.txt URL: https://www.rfc-editor.org/info/rfc8241 DOI: 10.17487/RFC8241 This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport. This document is a product of the Interface to the Routing System Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 15 08:32:43 2017 Return-Path: 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 9A10E133523; Fri, 15 Sep 2017 08:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 jxs_swT153pQ; Fri, 15 Sep 2017 08:32:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34801333FE; Fri, 15 Sep 2017 08:32:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2D685B80E6D; Fri, 15 Sep 2017 08:31:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, i2rs@ietf.org Message-Id: <20170915153159.2D685B80E6D@rfc-editor.org> Date: Fri, 15 Sep 2017 08:31:59 -0700 (PDT) Archived-At: Subject: [i2rs] RFC 8242 on Interface to the Routing System (I2RS) Ephemeral State Requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 15:32:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8242 Title: Interface to the Routing System (I2RS) Ephemeral State Requirements Author: J. Haas, S. Hares Status: Informational Stream: IETF Date: September 2017 Mailbox: jhaas@juniper.net, shares@ndzh.com Pages: 12 Characters: 25641 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-i2rs-ephemeral-state-23.txt URL: https://www.rfc-editor.org/info/rfc8242 DOI: 10.17487/RFC8242 "An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System (I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. This document is a product of the Interface to the Routing System Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Sep 19 11:11:03 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF99F1342B9; Tue, 19 Sep 2017 11:10:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150584465990.11709.1544110237550034475@ietfa.amsl.com> Date: Tue, 19 Sep 2017 11:10:59 -0700 Archived-At: Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 18:11:00 -0000 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 Data Model for Network Topologies Authors : Alexander Clemm Jan Medved Robert Varga Nitin Bahadur Hariharan Ananthakrishnan Xufeng Liu Filename : draft-ietf-i2rs-yang-network-topo-16.txt Pages : 48 Date : 2017-09-19 Abstract: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The data model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory data models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-16 https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-network-topo-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-16 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/ From nobody Tue Sep 19 12:08:38 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755013436F; Tue, 19 Sep 2017 12:08:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150584811699.11774.2566805855245365622@ietfa.amsl.com> Date: Tue, 19 Sep 2017 12:08:37 -0700 Archived-At: Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 19:08:37 -0000 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-topology-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l3-topology-11 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/ From nobody Tue Sep 19 13:26:33 2017 Return-Path: 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 0C682134398 for ; Tue, 19 Sep 2017 13:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 t0ht0Qjv3igY for ; Tue, 19 Sep 2017 13:26:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69AE1342DD for ; Tue, 19 Sep 2017 13:26:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOX81104; Tue, 19 Sep 2017 20:26:27 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 19 Sep 2017 21:26:26 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.114]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000; Tue, 19 Sep 2017 13:26:20 -0700 From: Alexander Clemm To: "i2rs@ietf.org" CC: Susan Hares Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-11.txt Thread-Index: AQHTMXrCqFkxG1Y37Uafa88AHGWZLKK8prnA Date: Tue, 19 Sep 2017 20:26:20 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA05F0@sjceml521-mbs.china.huawei.com> References: <150584811699.11774.2566805855245365622@ietfa.amsl.com> In-Reply-To: <150584811699.11774.2566805855245365622@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59C17D74.002E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.114, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6cc101d2790973de9b9f39236100a34c Archived-At: Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-11.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:26:32 -0000 Hi all, We posted new revisions to draft-ietf-i2rs-yang-l3-topology and draft-ietf-= i2rs-yang-network-topo today. =20 The updates to draft-ietf-i2rs-yang-network-topo are very minor and basical= ly limited to updating the security considerations per comments from Benoit= . =20 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 o= wn 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 exa= mple to bring it up to date with security considerations templates etc. =20 --- Alex, Hari, Jan, Xufeng, Nitin, Robert -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, September 19, 2017 12:09 PM To: i-d-announce@ietf.org Cc: i2rs@ietf.org 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 director= ies. 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-topology-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-yang-l3-topology-11 Please note that it may take a couple of minutes from the time of submissio= n 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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Sep 20 10:41:47 2017 Return-Path: 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 6D3FF13320B; Wed, 20 Sep 2017 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetdesign.onmicrosoft.com 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 MF06n5iCiAWQ; Wed, 20 Sep 2017 10:41:35 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0088.outbound.protection.outlook.com [104.47.42.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564D0133063; Wed, 20 Sep 2017 10:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetdesign.onmicrosoft.com; s=selector1-packetdesign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XVAHrpYo6iGz0jYNJ9molZtpV7MGbMnALdXMF36te8I=; b=a3lahUYsrJ2+Bk2GUHZWkUi+lX/giM9iOYC8wn6PvqOuNIVF5JVwInd8r+tYUNSJ5NHiNMhwAbeJywuEkOenaHQmBhelPTJfvKivF6yxwyCJ8yasiu06d3xHpojmpFZ/zGiluId5kUVCekEQzQQ4zjhPes9wDXwaOhqT27MoTu4= Received: from CY1PR0401MB0921.namprd04.prod.outlook.com (10.160.160.145) by CY1PR0401MB1420.namprd04.prod.outlook.com (10.161.213.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 20 Sep 2017 17:41:30 +0000 Received: from CY1PR0401MB0921.namprd04.prod.outlook.com ([10.160.160.145]) by CY1PR0401MB0921.namprd04.prod.outlook.com ([10.160.160.145]) with mapi id 15.20.0056.018; Wed, 20 Sep 2017 17:41:30 +0000 From: Hariharan Ananthakrishnan To: Ignas Bagdonas , "draft-ietf-i2rs-yang-l3-topology.all@ietf.org" CC: "i2rs@ietf.org" , "ops-dir@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-i2rs-yang-l3-topology-10 Thread-Index: AQHTBiHJsMDl1I9o20OVuhwPobft4aK+Yx2A Date: Wed, 20 Sep 2017 17:41:30 +0000 Message-ID: <55D5C108-FBC2-46EF-B90F-046C41958F43@packetdesign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hari@packetdesign.com; x-originating-ip: [38.99.127.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0401MB1420; 6:QAX4wNjY0/E4S+g2dveLhAiNlYUaL1tqjxCKKCWxDNknXtB6e81F6I72D42NiKJxXqbUce9X+d4wn3lH84H7RaELSCiZqheQmw51zYq/I3XmzKdP0Gc/nFZa+Z1T+BuNfaIrwpE92D8UI3haJp1gxlaXGxyXN4rGUZiaM1Mh+lFqMbvEv5xt718rD1hFub2ak+Tr3HWymwqXNLcLbMJBsTD2IQVDV23OYJOBztTpI/zL5eKTuh29ExhJUcm8PsCdBlLoorJm3Gs5eB7lYpcYl9/zY4zNBU8BhSpxCsffuTNVbMrrxkqzXiSa/kjWMG14m2z3imSoChuoYw10HanMpQ==; 5:A8RtqHd8+ygBeTSgvsCbMmHKnqz2Wf3EAcP+cFDDeM5SV2yuybbRcwj4okCzBUXXHSWmYlqfS95I5N7DHhMxRfiltqPZcwq9cOijq6lVkibvOFlLrdZbWiGYcbOO/9j+4wsCfPnWzzurvO0Y9TyP1w==; 24:ZljdpqpEqqymFM9Cij8+M77pvIGwWbueExSVSvzCDl463C4JxgY1t5FR5aMUBhc6BAGUsHXvCQrOU3YLBgSPNoO6cTat3LocXwmCUfnmUI4=; 7:EDJ5u19xGdUR6BTdavsekupfaePkDY+nAXB7f0MtdP5e7A9s6/Bu8VXlWKhl6zjxIxHkmybC6tnHMDTxLKPy4SQ9YtMv/boSPBDqtBywZiM92id4VPc7RAtXk6ahLR+L5AHlGqBenSTIQWwpuKetHGfeJJ74Fyv2eFXFmOFs6gi3rvC8w60VhnKtuGkdqXhCvGQfnGDJ0thdGLxa0lLx9ShmFWlqCiIkQWT52iIW+PE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9dfb4c66-cb25-4cf6-352a-08d5004ed3d7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(2017052603199)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0401MB1420; x-ms-traffictypediagnostic: CY1PR0401MB1420: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(2016111802025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0401MB1420; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0401MB1420; x-forefront-prvs: 04362AC73B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(51914003)(199003)(189002)(24454002)(6436002)(36756003)(6506006)(229853002)(76176999)(50986999)(54356999)(106356001)(86362001)(101416001)(2900100001)(6486002)(77096006)(54906003)(6116002)(105586002)(3846002)(102836003)(53936002)(8936002)(97736004)(82746002)(14454004)(4326008)(316002)(39060400002)(6246003)(2501003)(2906002)(478600001)(8676002)(81156014)(81166006)(7736002)(189998001)(6512007)(66066001)(25786009)(5660300001)(2950100002)(305945005)(33656002)(99286003)(68736007)(3280700002)(3660700001)(230783001)(53546010)(83716003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0401MB1420; H:CY1PR0401MB0921.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: packetdesign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6278EE3EFF46D945935D01922E1F8989@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: packetdesign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2017 17:41:30.1213 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1df5b6db-3686-4e87-9323-024e5bfe00f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1420 Archived-At: Subject: Re: [i2rs] OPS-DIR review of draft-ietf-i2rs-yang-l3-topology-10 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 17:41:39 -0000 SGkgSWduYXMsDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gV2UgaGF2ZSB1cGRhdGVkIHRoZSBk cmFmdCBhZGRyZXNzaW5nIHlvdXIgcmV2aWV3IGNvbW1lbnRzLiBUaGUgbXVsdGktdG9wb2xvZ3kg cmVmZXJlbmNlcyBoYXZlIGJlZW4gcmVtb3ZlZCBhbmQgZXhhbXBsZSBPU1BGIHRvcG9sb2d5IGhh cyBiZWVuIG1vdmVkIHRvIGFwcGVuZGl4LiBXZSBhbHNvIHJlbW92ZWQgdGhlIElTSVMgZXhhbXBs ZS4gVGhlIGludGVuZGVkIHVzZSBvZiB0aGlzIG1vZGVsIGlzIHRvIHByb3ZpZGUgYSBMMyBVbmlj YXN0IHRvcG9sb2d5IG1vZGVsLiBUaGUgdG9wb2xvZ3kgcmVsYXRlZCB1c2UgY2FzZXMgYXJlIGRl ZmluZWQgaW4gc2VjdGlvbiA2IG9mIGRyYWZ0LWkycnMtdXNlY2FzZS1yZXFzLXN1bW1hcnkuDQoN ClRoYW5rcywNCkhhcmksIEFsZXgsIEphbiwgWHVmZW5nLCBOaXRpbiwgUm9iZXJ0DQoNCi0gSGFy aQ0KDQpPbiAyNi8wNy8yMDE3LCAwODoxMywgIklnbmFzIEJhZ2RvbmFzIiA8aWJhZ2RvbmEuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgSGkgdGhlcmUsDQogICAgDQogICAgSSBoYXZlIGJl ZW4gc2VsZWN0ZWQgYXMgT1BTLURJUiByZXZpZXdlciBmb3IgdGhpcyBkb2N1bWVudC4NCiAgICAN CiAgICBEb2N1bWVudDogZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3ktMTANCiAgICAN CiAgICBSZXZpZXdlcjogSWduYXMgQmFnZG9uYXMNCiAgICANCiAgICBSZXZpZXcgcmVzdWx0OiBI YXMgaXNzdWVzLg0KICAgIA0KICAgIA0KICAgIE1ham9yIHF1ZXN0aW9uIHRoYXQgSSBnZXQgYWZ0 ZXIgcmVhZGluZyB0aGlzIGRvY3VtZW50IGlzIG9uIGhvdyB0aGUgDQogICAgcHJvcG9zZWQgbW9k ZWwgd291bGQgYmUgdXNlZCBhbmQgcHJvdmlkZSBwcmFjdGljYWxseSB1c2VmdWwgdG9wb2xvZ3kg DQogICAgYWJzdHJhY3Rpb24gaW50ZXJmYWNlLCBlc3BlY2lhbGx5IGluIHRoZSBjb250ZXh0IG9m IG11bHRpdG9wb2xvZ3kgDQogICAgcm91dGluZy4gVGhlIGRvY3VtZW50IGNvdmVycyBtdWx0aXRv cG9sb2d5IGFzIGF1Z21lbnRhdGlvbiB0byBMMyB1bmljYXN0IA0KICAgIHRvcG9sb2d5IG1vZGVs LCBhbmQgdGhpcyBleHBvc2VzIHBlci1wcm90b2NvbCBNVCBzcGVjaWZpY3MsIHdoaWNoIHNlZW1z IA0KICAgIHRvIGZhbGwgZXhhY3RseSBvcHBvc2l0ZSB0byB0aGUgaW50ZW50aW9uIG9mIHRoZSBk b2N1bWVudCB0byBwcm92aWRlIA0KICAgIGFic3RyYWN0ZWQgdG9wb2xvZ3kgdmlldy4gTVQgdG9w b2xvZ3kgdmlldyBpcyBhIHN1YnNldCBvZiBwcm90b2NvbCANCiAgICBzcGVjaWZpYyB0b3BvbG9n eSBwbHVzIGl0IGNhbiBjb250YWluIHJvdXRlcyBjb21pbmcgZnJvbSBvdGhlciBzb3VyY2VzIA0K ICAgIHRvbywgYW5kIHRoZSBtb2RlbCBhcHByb2FjaCBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVu dCBkb2VzIG5vdCBzZWVtIHRvIA0KICAgIGFsbG93IGZvciBleHByZXNzaW5nIHN1Y2ggY29uc3Ry dWN0cy4gT25lIHByYWN0aWNhbCB1c2UgY2FzZSBpcyANCiAgICBtdWx0aWNhc3QgUlBGIGxvb2t1 cCBjb250cm9sLCB0eXBpY2FsbHkgdGhhdCBpcyBhbiBJR1AgTVQgdmlldyBwbHVzIA0KICAgIGxv Y2FsIG92ZXJyaWRlIHJvdXRlcywgdHlwaWNhbGx5IHN0YXRpY2FsbHkgaW5qZWN0ZWQuIEZvciB0 aGlzIHVzZSBjYXNlIA0KICAgIHRoZSBtb2RlbCBkZXNjcmliZWQgd291bGQgcmVxdWlyZSB0aGUg dG9wb2xvZ3kgdG8gYmUgc3RyaWN0bHkgY29taW5nIA0KICAgIGZyb20gYSBzaW5nbGUgSUdQIHNv dXJjZSwgZWl0aGVyIElTLUlTIG9yIE9TUEYsIHdpdGggbm8gYWJpbGl0eSB0byANCiAgICBpbnRl cm1peCBib3RoLCBhbmQgd2l0aCBubyBhYmlsaXR5IHRvIHJlcHJlc2VudCByb3V0ZXMgZXh0ZXJu YWwgdG8gSVMtSVMgDQogICAgb3IgT1NQRiB0b3BvbG9neSBzb3VyY2VzLiBIYXZpbmcgc2VwYXJh dGUgbW9kZWxzIGZvciBJUy1JUyBhbmQgT1BTRiBmb3IgDQogICAgYXVnbWVudGluZyB0aGUgYmFz ZSBMMyB0b3BvbG9neSBtb2RlbCBkb2VzIG5vdCBhbGxvdyBmb3IgaGlkaW5nIHRoZSANCiAgICBk aWZmZXJlbmNlcyBpbiByZXByZXNlbnRhdGlvbiBvZiBJUy1JUyBhbmQgT1NQRiBkZXJpdmVkIHRv cG9sb2d5IA0KICAgIGFzcGVjdHMsIGluIHBhcnRpY3VsYXIgdGhlIE1UIGlkZW50aWZpZXJzLiBG b3IgdGhlIHVzZXIgdGhpcyB3b3VsZCANCiAgICByZXF1aXJlIHRvIGtub3cgd2hpY2ggb25lIG9m IHRoZSBJR1BzIGlzIHVzZWQgaW5zdGVhZCBvZiBnZXR0aW5nIGp1c3QgDQogICAgdGhlIHNwZWNp ZmljIHRvcG9sb2d5IHZpZXcgcmVnYXJkbGVzcyBvZiB3aGF0IGFyZSB0aGUgdW5kZXJseWluZyAN CiAgICB0b3BvbG9neSBzb3VyY2VzLiBXaGF0IGlzIHRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhpcyBt b2RlbCB0aGVuIC0gaXMgaXQgb24gDQogICAgcHJvdmlkaW5nIGludGVyZmFjZSB0byBwcm90b2Nv bCBzcGVjaWZpYyB0b3BvbG9neSAod2hpY2ggdGhlbiByYWlzZXMgYSANCiAgICBxdWVzdGlvbiBv biBob3cgaXQgY29ycmVsYXRlcyB0byBwcm90b2NvbCBzcGVjaWZpYyBtb2RlbHMnIG9wZXJhdGlv bmFsIA0KICAgIHBhcnQsIGFuZCBzZWN0aW9uIDEgc2Vjb25kIHBhcmFncmFwaCBtZW50aW9ucyBw cmVjaXNlbHkgdGhhdCksIG9yIGlzIGl0IA0KICAgIG9uIHByb3ZpZGluZyByb3V0aW5nIGluZm9y bWF0aW9uIHNvdXJjZSBpbmRlcGVuZGVudCBpbnRlcmZhY2UgdG8gDQogICAgdG9wb2xvZ3k/IEFz IGEgc3VtbWFyeSwgdGhlIGRvY3VtZW50IHdvdWxkIGJlbmVmaXQgZnJvbSBvcGVyYXRpb25hbCAN CiAgICBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRoYXQgd291bGQgZXhwbGFpbiB0aGUgaW50ZW5k ZWQgdXNlIG9mIHRoaXMgbW9kZWwgDQogICAgYW5kIGhvdyBpdCBjb3JyZWxhdGVzIGFuZCBpbnRl cndvcmtzIHdpdGggSUdQIHNwZWNpZmljIG1vZGVscy4gV2l0aG91dCBhIA0KICAgIGNsZWFyIGFu c3dlciB3aGVyZSB0aGUgbW9kZWwgaXMgcG9zaXRpb25lZCBpdCBpcyBkaWZmaWN1bHQgdG8gcHJv dmlkZSANCiAgICBtb3JlIGRldGFpbGVkIHJldmlldyBvbiB0aGUgbW9kZWwgc3RydWN0dXJlIGl0 c2VsZi4NCiAgICANCiAgICBNZXRyaWNzIGJlaW5nIGEgc2luZ2xlIHVpbnQzMiB2YWx1ZSAtIHRo YXQgbWF5IG5vdCBiZSBmbGV4aWJsZSBlbm91Z2ggdG8gDQogICAgcmVwcmVzZW50IHJlYWxpc3Rp YyBzY2VuYXJpb3Mgd2hlcmUgYSB0b3BvbG9neSBpbnN0YW5jZSBtYXkgaGF2ZSANCiAgICBkaWZm ZXJlbnQgcm91dGluZyBpbmZvcm1hdGlvbiBzb3VyY2VzIHdpdGggaW5jb21wYXRpYmxlIG9yIGlu Y29tcGFyYWJsZSANCiAgICBtZXRyaWNzLiBBdCBsZWFzdCB0d28gaW5kZXBlbmRlbnQgbWV0cmlj IGNvbXBvbmVudHMgd291bGQgYmUgbmVlZGVkIGZvciANCiAgICB0aGF0Lg0KICAgIA0KICAgIA0K ICAgIE5pdHM6DQogICAgDQogICAgVGl0bGUgcGFnZSBoYXMgNiBhdXRob3JzIGxpc3RlZC4NCiAg ICANCiAgICBBcmUgWHVmZW5nJ3MgY29udGFjdCBkZXRhaWxzIGNvcnJlY3Q/DQogICAgDQogICAg cy9OZXRjb25mL05FVENPTkYNCiAgICANCiAgICBzL1BhcmFudGhlc2VzL1BhcmVudGhlc2VzDQog ICAgDQogICAgTkVULWlkLCBORVQgSWQgc2hvdWxkIGFsbCBiZSBORVQNCiAgICANCiAgICBJU0lT IG1vZGVsIGhhcyBhIHJlZmVyZW5jZSB0byBPU1BGIE1UIFJGQy4NCiAgICANCiAgICBJU0lTIG1v ZGVsIGZvciBtdWx0aS10b3BvbG9neS1pZCBoYXMgbWF4LWVsZW1lbnRzICIxMjgiIGxpbWl0LiBN VCBUTFYgDQogICAgY2FuIGJlIHJlcGVhdGVkIGFuZCB0aHVzIGEgbGFyZ2VyIG51bWJlciBvZiB0 b3BvbG9neSBpZHMgY2FuIGJlIHNpZ25hbGxlZC4NCiAgICANCiAgICBzL3BhcGVyL2RvY3VtZW50 DQogICAgDQogICAgDQogICAgT3ZlcmFsbCB0aGUgZG9jdW1lbnQgd291bGQgYmVuZWZpdCBmcm9t IGdyYW1tYXIgY2hlY2suIEFic3RyYWN0LCANCiAgICBJbnRyb2R1Y3Rpb24sIGFuZCBPdmVydmll dyBzZWN0aW9ucyBjb250YWluIHF1aXRlIG11Y2ggb2YgcmVwZXRpdGl2ZSB0ZXh0Lg0KICAgIA0K ICAgIA0KICAgIFRoYW5rIHlvdS4NCiAgICANCiAgICBJZ25hcw0KICAgIA0KICAgIA0KICAgIA0K ICAgIA0KICAgIA0KDQo= From nobody Wed Sep 27 02:53:06 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DCA13492D; Wed, 27 Sep 2017 02:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-i2rs-yang-network-topo@ietf.org, Susan Hares , i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150650598443.24991.6685718690073279947.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 02:53:04 -0700 Archived-At: Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-yang-network-topo-16: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:53:04 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Preliminary note: I hope I'm doing the right thing by updating my ballot as I understand that the document is back to the WG. However, since I reviewed the versions 15 and 16, since some of my ballot points have been addressed (thank you), and since I wanted to share my feedback publicly, here is my feedback. Editorial: The data model obeys the requirements for the ephemeral state found in the document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the without relying on a configuration datastore. => operational state datastore, according to https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ From nobody Wed Sep 27 03:04:32 2017 Return-Path: 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 EAE85134965; Wed, 27 Sep 2017 03:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 8VwKBP6GjxxX; Wed, 27 Sep 2017 03:04:19 -0700 (PDT) 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 65BF6134960; Wed, 27 Sep 2017 03:04:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: "'Benoit Claise'" , "'The IESG'" Cc: , , References: <150650598443.24991.6685718690073279947.idtracker@ietfa.amsl.com> In-Reply-To: <150650598443.24991.6685718690073279947.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 06:04:12 -0400 Message-ID: <016701d33777$f85ce5f0$e916b1d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKSkvIPdFpCQO5D6aEvLWh6XZQuuqFJyYfg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-yang-network-topo-16: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 10:04:25 -0000 Benoit: Thank you for your quick update. We'll start the WG LC on the draft = after I confirm with Kathleen and Ben that her concerns regarding the = security section have been resolved. It appears to me to be resolved, = but I want to verify this fact. Hopefully, we can do this within a few = hours. =20 Sue Hares=20 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Wednesday, September 27, 2017 5:53 AM To: The IESG Cc: draft-ietf-i2rs-yang-network-topo@ietf.org; Susan Hares; = i2rs-chairs@ietf.org; shares@ndzh.com; i2rs@ietf.org Subject: Benoit Claise's No Objection on = draft-ietf-i2rs-yang-network-topo-16: (with COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-16: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Preliminary note: I hope I'm doing the right thing by updating my ballot = as I understand that the document is back to the WG. However, since I = reviewed the versions 15 and 16, since some of my ballot points have = been addressed (thank you), and since I wanted to share my feedback = publicly, here is my feedback. Editorial: The data model obeys the requirements for the ephemeral state found in the document [I-D.draft-ietf-i2rs-ephemeral-state]. For = ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the without = relying on a configuration datastore. =3D> operational state datastore, according to = https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/ From nobody Wed Sep 27 04:27:44 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 803951346E6; Wed, 27 Sep 2017 04:27:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150651166347.25031.14853928232011748822@ietfa.amsl.com> Date: Wed, 27 Sep 2017 04:27:43 -0700 Archived-At: Subject: [i2rs] I-D Action: draft-ietf-i2rs-security-environment-reqs-06.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 11:27:43 -0000 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 : I2RS Environment Security Requirements Authors : Daniel Migault Joel Halpern Susan Hares Filename : draft-ietf-i2rs-security-environment-reqs-06.txt Pages : 28 Date : 2017-09-27 Abstract: This document provides environment security requirements for the I2RS architecture. Environment security requirements are independent of the protocol used for I2RS. The security environment requirements are the good security practices to be used during implementation and deployment of the code related to the new interface to routing system (I2RS) so that I2RS implementations can be securely deployed and operated. Environmental security requirements do not specify the I2RS protocol seecurity requirements. This is done in another document (draft- ietf-i2rs-protocol-security-requirements). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2rs-security-environment-reqs-06 https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-security-environment-reqs-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-security-environment-reqs-06 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/ From nobody Wed Sep 27 05:52:08 2017 Return-Path: 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 90DC4134AC0 for ; Wed, 27 Sep 2017 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 DFkW1f68PyOV for ; Wed, 27 Sep 2017 05:52:05 -0700 (PDT) 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 38FDB134AB8 for ; Wed, 27 Sep 2017 05:52:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: Cc: "'Alia Atlas'" Date: Wed, 27 Sep 2017 08:52:02 -0400 Message-ID: <024a01d3378f$6a53e390$3efbaab0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024B_01D3376D.E343F140" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdM3jzC1A52bZFOfRT2yRCAIEovzvg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] Request for Sriganesh Kini to contact the Chairs X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 12:52:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024B_01D3376D.E343F140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sriganesh Kini - can you contact me offline. WG - I'm sorry for the noise on the list. I need to contact this author and all emails are bouncing. Sue Hares ------=_NextPart_000_024B_01D3376D.E343F140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Sriganesh Kini – can you contact me offline.  =

=  

= WG – I’m sorry for the noise on the list.  I need to = contact this author and all emails are bouncing. =

=  

= Sue Hares

------=_NextPart_000_024B_01D3376D.E343F140-- From nobody Wed Sep 27 06:01:08 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB16134B46; Wed, 27 Sep 2017 06:01:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: i2rs@ietf.org, skh@ndzh.com, i2rs-chairs@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150651726680.24774.14592334143851779195.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 06:01:06 -0700 Archived-At: Subject: [i2rs] i2rs - New Meeting Session Request for IETF 100 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 13:01:07 -0000 A new meeting session request has just been submitted by Susan Hares, a Chair of the i2rs working group. --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: idr i2nsf trill teas netmod netconf rtgwg Second Priority: rtgarea People who must be present: Susan Hares Russ White Alia Atlas Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: --------------------------------------------------------- From nobody Wed Sep 27 07:40:24 2017 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A176A134C90; Wed, 27 Sep 2017 07:40:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, shares@ndzh.com, i2rs-chairs@ietf.org, shares@ndzh.com, i2rs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150652322265.24969.3860334342840069904.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 07:40:22 -0700 Archived-At: Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-11: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 14:40:23 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-l3-topology-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Preliminary note: I hope I'm doing the right thing by updating this DISCUSS point as I understand that the document is back to the WG. However, since I reviewed the version 11, since some of my ballot points have been addressed (thank you), and since I wanted to share my feedback publicly, here is my feedback. 1. The examples. In the AUTH48 for the RESTCONF RFC, the example YANG module discussion came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology were also discussed. Here is the feedback from one YANG doctor, from a couple of days ago. Look at this: module example-ietf-ospf-topology { ... namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; ... description "This module defines a model for OSPF network topologies. Copyright (c) 2017 IETF Trust and the persons identified as authors of the code. They are using the IANA-controlled namespace w/o registering it. This module *really* looks like a proper normative module, rather than an example. They went to far in trying to mimic a real module. It is clear that we need more guidelines in 6087 for how to write example modules. I was going to ask if this module passed YANG doctor review - then I checked and saw that version -02 was reviewed, which didn't include this example. How should we (the YANG doctors) handle such a case? In this case they should: 1. change the name to example-ospf-topology 2. change the namespace to urn:example:ospf-topology 3. remove the top-level statements: organization, contact, revision 4. change the top-level description to what the text in the draft says: description "This module is intended as an example for how the Layer 3 Unicast topology model can be extended to cover OSFP topologies."; (same for the other example module) As I mentioned to the authors, respective chairs and AD already, we should follow the decision in this NETMOD email thread https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html This will hopefully resolve fast. Once settled, the examples should be updated. 4. leaf-list router-id { type inet:ip-address; description "Router-id for the node"; } My initial DISCUSS was: We don't want to wait for https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we should expedite this publication), but any good reason why this is aligned with its definition? typedef router-id { type yang:dotted-quad; description "A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System."; } My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, it makes sense to import its router-id ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - YANG definition "YANG: A data definition language for NETCONF" I would use: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols [RFC7950] - There are multiple slightly different definitions of the datastore in the different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the latest one) and mention the reference. - section 7 OLD: The moodel defines NEW: The model defines From nobody Wed Sep 27 12:52:11 2017 Return-Path: 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 3CE1F134FF9 for ; Wed, 27 Sep 2017 12:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 Vd9nDkn88i4h for ; Wed, 27 Sep 2017 12:52:07 -0700 (PDT) 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 7149D13500D for ; Wed, 27 Sep 2017 12:51:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: Cc: "'Russ White'" , "'Alia Atlas'" , "'Benoit Claise'" Date: Wed, 27 Sep 2017 15:51:38 -0400 Message-ID: <003501d337ca$08bcd1b0$1a367510$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01D337A8.81AC4320" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdM3yeyIvSrbT+mWQAGc37HAN3ptTg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 10/11/2017) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 19:52:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0036_01D337A8.81AC4320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo. This draft has been revised to comply with the netmod revised datastore architecture. The original WG approved data model has been slightly changed to align with the current state of this model, and the security considerations have been improved. You can find the draft at: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo Please consider in your comments if this yang model is ready for publication. The authors should indicate if they know of any IPR. By the way, all authors did this before the last revision but the chairs are required to request this information again to provide a clean IPR tracking. Susan Hares and Russ White ------=_NextPart_000_0036_01D337A8.81AC4320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo.   = This draft has been revised to comply with the netmod revised datastore = architecture.   The original WG approved data model has been = slightly changed to align with the current state of this model, and the = security considerations have been improved.

 

You can find = the draft at:  https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo=

 

Please consider in your comments if this yang model is = ready for publication.

 

The authors = should indicate if they know of any IPR.  By the way, all authors = did this before the last revision but the chairs are required to request = this information again to provide a clean IPR tracking.  =

 

Susan Hares and Russ White =

------=_NextPart_000_0036_01D337A8.81AC4320-- From nobody Fri Sep 29 10:38:19 2017 Return-Path: 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 C60DC133342 for ; Fri, 29 Sep 2017 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 z5sT9tE7h2oU for ; Fri, 29 Sep 2017 10:38:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 55C83133328 for ; Fri, 29 Sep 2017 10:38:16 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.71.191.170]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MC2Zq-1e6ovG1E80-008oSY; Fri, 29 Sep 2017 19:37:58 +0200 From: "Alexander Clemm" To: "'Susan Hares'" , Cc: "'Russ White'" , "'Benoit Claise'" , "'Alia Atlas'" References: <003501d337ca$08bcd1b0$1a367510$@ndzh.com> In-Reply-To: <003501d337ca$08bcd1b0$1a367510$@ndzh.com> Date: Fri, 29 Sep 2017 10:38:03 -0700 Message-ID: <014f01d33949$b49202a0$1db607e0$@clemm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0150_01D3390F.08339FD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHVQgGjDP9PBhwSYq6AVmLyC0Ayc6LIDwiA Content-Language: en-us X-Provags-ID: V03:K0:+W0yyZ/dy5/ZxnVjdBULI3XtYEdFvoyrxCjOLNJcxLdpchUjfa1 5ZOzHiXJWZTPNr9bQcLIDtVFiMPD16iBFTUlJ3thUI/6A3P0k1CMkUGZQj8hLS7qB1NV3xI nzQdwzQbD5z2JD7F/vw2Ofq61Dr9kJznIEqWpWfWMmgG2J0oOeaJZpTa5TG2AdLs1J2UNo2 CZQHqCxqA4iibIFtAVUFQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:sVDeJ2G+vIU=:6zkiSUBr+VNcB1giPG9xJi TKlAT875xqO3MEIfxiSSvXmdjvl4KJHqMUJP4K0EJdKcGfWSWDmy8xmLbF2Hu5l9JCOEOX3Ff 8PXrd++z7JEMIZFPHu28R12KXO37EC4Z0SmIOIDHZVXCMhZxzsRXxvP7iuDDUpn6pgzzpD4Xe Zs+mCMeVi7CEuI5lDNavEc5MCUEuld1MoPknfz7ZPByUms4iBYcogj4v8OP6/vLYi0qbI+gbZ aIwIu2bdyQgY9kfjZ8uOHuMoaAgv8mRQMcUhJg9PrpAN7vwxg4VPEt4WYSk5e/1YNYNStfUiV UqY5daTmKwuF49LV+jlu+uLM9EDnSK3wsxwWi06QxPZsi5TInm6zttOtz5VZsWyvvi3F+cNXx vwXZJJJP5D3Sr3L6HbhCaCjyajSIALmahMAfD9FQ2rL69vXlyDb5i19MpZcAY0Q+/JGo8PV0w gGy4t1p+l8sxclMyYBjMO3/9e0Msns1mgOsO1O51kyiDEztRgUw4qmNV+R+HCW+aY5VJ6nnsq 4pXbYa0TJrtXrC+5agWrCSvPnOKsx8gwuBX93cu86eLmmwdKTHPIu4mpHyfU2SCbhW6zC9BJx b+St4aFGW+IbQSwpLIs9KxmUqApXNrcCKCAVeqtPNFmsW7SXFs4F1L4WMQUjIkPdrL/B/JKeZ fU6CK5Gp8uZ9qk32DPLQkl856wEX4qzi2c1qxFT40MaNVGo2typv3qHJkVqKQzN+vBEgO5MIs B0UyyX2gQgY4hC+vlMwh4zi2Um6IHm6ljv/F9/G/DpAVY3vvcKILdR+OXk0= Archived-At: Subject: Re: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 10/11/2017) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 17:38:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0150_01D3390F.08339FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Susan and Russ, Thank you for initiating the WGLC. To your question, I am not aware of any IPR pertaining to this draft (nor the other draft, draft-ietf-i2rs-yang-l3-topology). --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, September 27, 2017 12:52 PM To: i2rs@ietf.org Cc: 'Russ White' ; 'Benoit Claise' ; 'Alia Atlas' Subject: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo (9/27/2017 to 10/11/2017) This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo. This draft has been revised to comply with the netmod revised datastore architecture. The original WG approved data model has been slightly changed to align with the current state of this model, and the security considerations have been improved. You can find the draft at: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo Please consider in your comments if this yang model is ready for publication. The authors should indicate if they know of any IPR. By the way, all authors did this before the last revision but the chairs are required to request this information again to provide a clean IPR tracking. Susan Hares and Russ White ------=_NextPart_000_0150_01D3390F.08339FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Susan and Russ,

 

Thank you = for initiating the WGLC.  To your question, I am not aware of any = IPR pertaining to this draft (nor the other draft, = draft-ietf-i2rs-yang-l3-topology). 

 

--- = Alex

 

From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Wednesday, September 27, 2017 12:52 = PM
To: i2rs@ietf.org
Cc: 'Russ White' = <russ@riw.us>; 'Benoit Claise' <bclaise@cisco.com>; 'Alia = Atlas' <akatlas@gmail.com>
Subject: [i2rs] WG LC on = draft-ietf-i2rs-yang-network-topo (9/27/2017 to = 10/11/2017)

 

This begins = a 2 week WG LC on draft-ietf-i2rs-yang-network-topo.   This = draft has been revised to comply with the netmod revised datastore = architecture.   The original WG approved data model has been = slightly changed to align with the current state of this model, and the = security considerations have been improved.

 

You can find = the draft at:  https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo=

 

Please consider in your comments if this yang model is = ready for publication.

 

The authors = should indicate if they know of any IPR.  By the way, all authors = did this before the last revision but the chairs are required to request = this information again to provide a clean IPR tracking.  =

 

Susan Hares and Russ White =

------=_NextPart_000_0150_01D3390F.08339FD0--