Hi Benoit agreed - the model should be independent of the protocol used to access it.
As mentioned earlier on the thread, OpenDaylight has implemented older versions of the model. Over time I’d expect each service in OpenDaylight that uses the models to upgrade to the upcoming RFC. In general OpenDaylight implements the models as read-only (i.e. in its operational data-store), though as Robert Varga has noted there’s a case where we use the config data-store for device inventory (longer term that will move to the ietf-network model but not ietf-network-topology - though there might be use cases where you’d have read-write access to ietf-network-topology, e.g when using it to express intent.) OpenDaylight enables access to topology data using NETCONF and RESTCONF as the north-bound protocoIs are independent of the models accessed. I believe there has also been some work on using AMQP as a north-bound protocol, and that the Kafka plug-in could be used to send data change notifications for the operational models (so you’d get a message when a link went up or down etc.) South-bound we have also used ODL to read topology data from a device using NETCONF/YANG (IIRC we showed a demo of this using Homenet running on OpenWrt at IETF a couple of years back). I’m also working with other groups such as MEF and OpenROADM to leverage the I2RS topology models for their YANG efforts. So clearly the models need to be used in a non-I2RS environment. Giles > On 24 Jan 2017, at 22:04, Benoit Claise <[email protected]> wrote: > > Dear all, > > The thread that grows faster than you can read... > > 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 > <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 >> Sue: >> >> The implication of that statement is that actual implementations (like >> ODL etc) now >> need to copy/paste this model without the I2RS text to use them in other >> ways. This seems >> strange and just about the most inefficient way to use these that I can >> think of. >> >> —Tom >> >> >> >>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> Anton: >>> >>> See earlier message to Martin. Topology models are I2RS YANG Models >>> designed for ephemeral state with specific security concerns. This is not >>> your basic YANG model no matter which data store ephemeral gets linked to. >>> Where is ephemeral state? By IESG Design of charter, I2RS is not in charge >>> of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them. >>> >>> Do not blame the messenger echoing NETMOD results, >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:[email protected] <mailto:[email protected]>] On >>> Behalf Of Anton Ivanov >>> Sent: Tuesday, January 24, 2017 8:30 AM >>> To: [email protected] <mailto:[email protected]> >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) >>> >>> On 24/01/17 11:52, Juergen Schoenwaelder wrote: >>>> Susan, >>>> >>>> so are these YANG models regular YANG models or are these YANG models >>>> specific to the yet to be defined I2RS protocol and yet to be defined >>>> datastores? >>>> >>>> I think this is the core of Martin's and my question. A simple clear >>>> and concise answer would be nice. >>> +1. >>> >>> A. >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/i2rs >>> <https://www.ietf.org/mailman/listinfo/i2rs> >>> >>> _______________________________________________ >>> i2rs mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/i2rs >>> <https://www.ietf.org/mailman/listinfo/i2rs> >> _______________________________________________ >> i2rs mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2rs >> <https://www.ietf.org/mailman/listinfo/i2rs> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
