Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Martin Bjorklund <[e-mail]>]

"Susan Hares" <[e-mail]> 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:[e-mail]] 
> Sent: Monday, January 23, 2017 6:47 AM
> To: [e-mail]
> Cc: [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> 
>  
> 
> Hi,
> 
>  
> 
> "Susan Hares" < <mailto:[e-mail]> [e-mail]> 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:[e-mail]>
> mailto:[e-mail]]
> 
> > Sent: Monday, January 23, 2017 3:39 AM
> 
> > To: Susan Hares
> 
> > Cc: 'Kathleen Moriarty'; 'The IESG';
> 
> >  <mailto:[e-mail]>
> [e-mail];  <mailto:[e-mail]>
> [e-mail]; 
> 
> >  <mailto:[e-mail]> [e-mail]
> 
> > 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:[e-mail]>
> mailto:[e-mail]]
> 
> > > Sent: Thursday, January 19, 2017 10:34 AM
> 
> > > To: Susan Hares
> 
> > > Cc: 'Kathleen Moriarty'; 'The IESG'; 
> 
> > >  <mailto:[e-mail]>
> [e-mail];  <mailto:[e-mail]>
> [e-mail]; 
> 
> > >  <mailto:[e-mail]> [e-mail]
> 
> > > 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:[e-mail]>
> mailto:[e-mail]]
> 
> > > > Sent: Wednesday, January 18, 2017 9:44 PM
> 
> > > > To: The IESG
> 
> > > > Cc:  <mailto:[e-mail]>
> [e-mail];  <mailto:[e-mail]>
> [e-mail]; 
> 
> > > >  <mailto:[e-mail]> [e-mail];
> <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]>
> [e-mail]
> 
> > > > 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:[e-mail]> [e-mail]
> 
> > > >  <https://www.ietf.org/mailman/listinfo/i2rs>
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> > > 
> 
> > > -- 
> 
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> 
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> 
> > > Fax:   [phone]         < <http://www.jacobs-university.de/>
> http://www.jacobs-university.de/>
> 
> > > 
> 
> > 
> 
> > -- 
> 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> 
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> 
> > Fax:   [phone]         < <http://www.jacobs-university.de/>
> http://www.jacobs-university.de/>
> 
> > 
> 
> > _______________________________________________
> 
> > i2rs mailing list
> 
> >  <mailto:[e-mail]> [e-mail]
> 
> >  <https://www.ietf.org/mailman/listinfo/i2rs>
> https://www.ietf.org/mailman/listinfo/i2rs
> 
> > 
>