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: 
> 
> Answers inline. 
> 
> -----Original Message-----
> From: i2rs [mailto:[e-mail]] On Behalf Of Martin Bjorklund
> Sent: Monday, January 23, 2017 10:32 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)
> 
> "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).
> 
> 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:[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-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:[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-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:[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-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:[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
> > 
> > > 
> > 
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>