"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). > #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. > 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? /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-consider> > 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-conside> > 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-topology/> > 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
