"Susan Hares" <[email protected]> wrote: > Martin: > > Answers inline. > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Martin Bjorklund > Sent: Monday, January 23, 2017 10:32 AM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > "Susan Hares" <[email protected]> wrote: > >> Martin: > >> > >> > >> > >> Thank you for your insightful questions. My answer to your questions > >> come from my understanding of the draft-ietf-netmod-revised-datastores-00 > and > >> discussions with that design team at IETF 97. We have been moving many > >> things in parallel at the IETF rather than do single threaded work. The > >> Topoology work was completed 1 year in advance of the > >> draft-ietf-netmod-revised-datastores-00.txt. > > >Right; this is why I think an additional note in these modules are > necessary. If you just read these topoly drafts, you will find a normal > YANG module that has a "config true" subtree. > >Without additional guidance, it is not clear that these data models "do not > utilize the configuration data store" (if this is true). > > Sue: Sounds like a good idea. I'll suggest this to the authors as the > document shepherd. > > >> #1) model's nodes are "config true", and that "The YANG module defined > >> in this memo is designed to be accessed via the NETCONF protocol". If > >> it is true that these data models do not utilize the configuration > >> data stores, what does the "server-provided" leaf, and the text about > "client-configured" > >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? > >> > >> If the server-provided leaf is true, it indicates that the data is > >> populated by the I2RS Agent (aka netconf server) > > >Doesn't this procedure involve the normal configuration data stores? > >If it does, I think we're good. If it doesn't, I think the additional note > should be added. > > Sue: The model is in the I2RS control plane data store. According to > draft-ietf-netmod-revised-datatstores-00.txt this is note the normal > configuration data store.
Ok. Just to make sure I understand this correctly - these topology models are intended to be I2RS-specific, and they cannot be used for any other purpose. If anyone needs a general topology model outside of the I2RS protocol, they will have to design their own model. Is this correct? > Does a note in the text plus a note at the > beginning of the data model suffice? To me, it feels weird that a model that is designed solely for the I2RS protocol is published *before* the details of the I2RS protocol are defined. But it this is what the WG wants, then a note that explains this would be useful. I assume that the idea is that vendors will use some proprietary mechanism for now. > >> rather than the I2RS Client (aka > >> netconf client). The I2RS architecture has aligned the two > architecture > >> concepts so the I2RS protocol is designed to be a re-use protocol for > >> the NETCONF protocol and the RESTCONF protocols as its message > >> transport protocols. > >> > >> draft-ietf-netmod-revised-datastores-00 states the following three > >> suggestions for supporting different datastores: > >> > >> > >> o For systems supporting <intended> or <applied> configuration > >> > >> datastores, the <get-config/> operation may be used to retrieve > >> > >> data stored in these new datastores. > >> > >> > >> > >> o A new operation should be added to retrieve the operational > >> state > >> > >> data store (e.g., <get-state/>). An alternative is to define a > >> > >> new operation to retrieve data from any datastore (e.g., > >> > >> <get-data> with the name of the datastore as a parameter). In > >> > >> principle <get-config/> could work but it would be a confusing > >> > >> name. > >> > >> > >> > >> o The <get/> operation will be deprecated since it returns data > >> from > >> > >> two datastores that may overlap in the revised datastore model. > >> > >> > >> > >> Based on this input, the I2RS ephemeral control plane data store > >> should use a "get-data I2RS-ephemeral" to get data from the I2RS > ephemeral data store > >> (CT, RW). To retrieve information from the applied configuration data > >> store, the "get-config" may be used. To retrieve state from the > >> operational state "get-state" should be used. > >> > >> > >> 2) Your suggestion to add another note about configuration true > >> > >> The config "true" is being implemented as the > >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see > diagram). > >> It is just in a different data store. Where and how the data store > >> information is stored, is unclear to me at this time. Where do you > >> think it belongs? > > > I always thought that the topology models could be written to through the > normal configuration data stores, in which case the server would set the > "server-provided" leaf to "false". It seems that you have some other > mechanism in mind? > > The design team for drat-ietf-netmod-revised-datastores-00.txt indicated > that the client written topology with "server-provided" leaf set to "false" > is written in the I2RS Control Plane data store. Ok. As you might know, I am the editor for drat-ietf-netmod-revised-datastores-00, and thus part of the design team, and I haven't seen any discussion about this. Was it discussed on the I2RS ML? /martin > An I2RS implementation > then combines the I2RS Control Plane data store with the intended > configuration data store (based on internal configuration knobs) and > installs this in a node. A client can query the topology data nodes in the > applied configuration data store. The response giving the topology nodes > will indicate that a dynamic control plane protocol inserted these nodes. > > I am only trying to interpret the netmod design and align the I2RS data > models (topology, RIB, FB-RIB) to this design. > > Thank you for your suggestions on the data model. > > Sue Hares > > > > > > /martin > > > > > 3) implementations > > > > > > > > Right now, the ODL implementation can utilize "get-config" to obtain > > the I2RS topology model since the I2RS topology database has no > > equivalent in the intended config. After the > > draft-ietf-netmod-revised-datastore is implemented, the "get-config" > > will return from the applied configuration the Topology model with an > indication that it is dynamic (see > > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > > implementation can simply augment its current get-config with an > indication > > that the topology model is a "dynamic" data store. > > > > > > > > As another example, my understanding is that a change to the ConfD > > implementation would be to allow a "get-data" and "write-data" that allows > > the specification of a data store such as the I2RS data store. A > > get-config of the applied data store should have a "dynamic" flag for > > the topology database. > > > > > > > > 4) Notifications - I am unclear how these are tagged to a datastore, > > but I am behind on event email. > > > > > > > > Cheerily, > > > > > > > > Sue > > > > > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:[email protected]] > > Sent: Monday, January 23, 2017 6:47 AM > > To: [email protected] > > Cc: [email protected]; > > [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected] > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > Hi, > > > > > > > > "Susan Hares" < <mailto:[email protected]> [email protected]> wrote: > > > > > Juergen: > > > > > > > > > > Let's focus on your second point. The topology drafts are I2RS > > > drafts > > > > > designed for the I2RS ephemeral control plane data store. How can > these > > be > > > > > generic YANG modules when the following is true: > > > > > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > > > > > This was not clear to me. I note that the data model's nodes are > > "config true", and that "The YANG module defined in this memo is > > designed to be accessed via the NETCONF protocol". > > > > > > > > If it is true that these data models do not utilize the configuration > > data stores, what does the "server-provided" leaf, and the text about > > "client-configured" in section 4.4.10 of > > draft-ietf-i2rs-yang-network-topo refer to? > > > > > > > > If in fact this is correct, I think it would be helpful if a note was > > added to the YANG modules, that explains that these models are not > > supposed to be implemented in the same way as other "config true" data > > models. In the best of worlds it would also describe how they are > > supposed to be implemented (but I assume that this is up to each vendor > for now). > > > > > > > > I also note that it is not clear how such models would be advertised > > by a NETCONF server. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > > > configuration data store, > > > > > 3) I2RS Data models require the use of priority to handle the > > > > > multi-write contention problem into the I2RS Control Plane data > > > store, > > > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > > > mandatory-to-implement transport, > > > > > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > > > the discussion should be taken up with netmod WG list. > > > > > Do you disagree with i2rs-protocol-security-requirements? That > > > issue > > > > > is closed based on IESG approval. > > > > > > > > > > Sue Hares > > > > > > > > > > -----Original Message----- > > > > > From: Juergen Schoenwaelder > > > > > [ <mailto:[email protected]> > > mailto:[email protected]] > > > > > Sent: Monday, January 23, 2017 3:39 AM > > > > > To: Susan Hares > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > <mailto:[email protected]> > > [email protected]; <mailto:[email protected]> > > [email protected]; > > > > > <mailto:[email protected]> [email protected] > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > Susan, > > > > > > > > > > I consider tagging a YANG object statically and universally in the > > > > > data model as "does not need secure communication" fundamentally > > > > > flawed; I am not having an issue with insecure communication in > > > certain > > deployment contexts. > > > > > > > > > > The topology drafts are regular generic YANG models that just happen > > > > > to be done in I2RS - I believe that using the generic YANG security > > > > > guidelines we have is good enough to progress these drafts. > > > > > > > > > > /js > > > > > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > > > Juergen: > > > > > > > > > > > > I recognize that dislike insecure communication. You made a > > > > similar > > > > > > comment during the WG LC and IETF review of > > > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > > > draft-ietf-i2rs-protocol-security-requirements were passed by the > > > > > > I2RS WG and approved by the IESG for RFC publication and it > > > > contains > > > > > > the non-secure communication. The mandate from the I2RS WG for > > > > this > > > > > > shepherd/co-chair is clear. > > > > > > > > > > > > As the shepherd for the topology drafts, I try to write-up > > > > something > > > > > > that might address Kathleen's Moriarty's concerns about the > > > > topology > > > > > > draft's security issues about privacy and the I2RS ephemeral > > > > control > > > > > > plane > > > > > data > > > > > > store. I welcome an open discussion on my ideas > > > > > > ( > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consid > > > > er> > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > > > The > > > > > > yang doctor's YANG security consideration template > > > > > > ( <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> > > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > > > the privacy related RFCs (RFC6973) note that some information is > > sensitive. > > > > > > Hopefully, this document extends these guidelines to a new data store. > > > > > > > > > > > > > Cheerily, > > > > > > Sue Hares > > > > > > > > > > > > -----Original Message----- > > > > > > From: Juergen Schoenwaelder > > > > > > [ <mailto:[email protected]> > > mailto:[email protected]] > > > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > > > To: Susan Hares > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > <mailto:[email protected]> > > [email protected]; <mailto:[email protected]> > > [email protected]; > > > > > > <mailto:[email protected]> [email protected] > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > For what it is worth, I find the notion that data models may be > > > > > > written for a specific non-secure transport plain broken. There is > > > > > > hardly any content of a data model I can think of which is > > > > generally > > > > > > suitable for insecure transports. > > > > > > > > > > > > Can we please kill this idea of _standardizing_ information that > > > > is > > > > > > suitable to send over non-secure transports? I really do not see > > > > how > > > > > > the IETF can make a claim that a given piece of information is > > > > never > > > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > > > deployment information is shipped in whatever way but this is then > > > > a > > > > > > property of the _deployment_ and not a property of the _information_. > > > > > > > > > > > > /js > > > > > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > > > Kathleen: > > > > > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > > > modules > > > > > > which are designed to exist in the I2RS Ephemeral Control Plane > > > > data > > store > > > > > > (configuration and operational state). > > > > > > > > > > > > > > Draft location: > > > > > > > > > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons > > > > > ide> > > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > > > r/ > > > > > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > > > OPS/NM ADs, > > > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data > > > > model > > > > > > (L3) and the base I2RS topology model should both provide updated > > > > > > YANG Security Considerations sections. I would appreciate if > > > > Benoit > > > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Kathleen Moriarty [ > > > > > <mailto:[email protected]> > > mailto:[email protected]] > > > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > > > To: The IESG > > > > > > > Cc: <mailto:[email protected]> > > [email protected]; <mailto:[email protected]> > > [email protected]; > > > > > > > <mailto:[email protected]> [email protected]; > > <mailto:[email protected]> [email protected]; <mailto:[email protected]> > > [email protected] > > > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > Kathleen Moriarty has entered the following ballot position for > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: 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> > > 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-topolo > > > > > gy/> > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > > > -- > > > > > > > -- > > > > > > > -- > > > > > > > COMMENT: > > > > > > > ---------------------------------------------------------------- > > > > > -- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > > > consideration > > > > > > section guidelines need to be followed and this shouldn't go > > > > forward > > > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > i2rs mailing list > > > > > > > <mailto:[email protected]> [email protected] > > > > > > > <https://www.ietf.org/mailman/listinfo/i2rs> > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > > Fax: +49 421 200 3103 < <http://www.jacobs-university.de/> > > http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 < <http://www.jacobs-university.de/> > > http://www.jacobs-university.de/> > > > > > > > > > > _______________________________________________ > > > > > i2rs mailing list > > > > > <mailto:[email protected]> [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
