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

["Susan Hares" <[e-mail]>]

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.  Does a note in the text plus a note at the
beginning of the data model suffice? 


>> 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.  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