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

[Benoit Claise <[e-mail]>]

Dear all,

The thread that grows faster than you can read...

Let me repeat what I mentioned already on the I2RS mailing list:

    This document contains a YANG model, a generic YANG model that could be accessed by NETCONF, RESTCONF, or the future I2RS protocol.
    This document doesn't say (and that would be a mistake IMO if it would) that this YANG model can only be accessed by the I2RS protocol.
    Hence I'm advocating that the security considerations diligently followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they don't go in the I2RS protocol specific details.

This comment was made for draft-ietf-i2rs-yang-network-topo, but is 
equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a 
data model usage to a particular protocol. These topology documents are 
not I2RS YANG models, these are YANG models, which can be used in 
different contexts. I'm very concerned if we start having per-WG or per 
context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only the 
requirements.
We can't modify the current generic YANG security considerations for an 
I2RS control plane and a new datastore that are not yet specified. If 
you want to describe how I2RS will be using those topology YANG models 
(and any YANG models btw), then it's suitable to include this part of 
the I2RS protocol spec or part of an I2RS applicability statement. This 
is typically where you would describe some protocol specific information 
such as "write contention for two clients writing a node using I2RS 
priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS 
needs to use the IETF interface YANG model, does it mean that you will 
require RFC 7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it 
relates to IETF specified protocols NETCONF and RESTCONF. Addition of 
some generic information about the data model (not I2RS protocol) might 
be useful though. For example, text around "there is a risk that a write 
to a topology may create a looping topology or overload a particular 
node". Note that I don't think the the security considerations is the 
best section for this though.

Regards, Benoit
> 	Sue:
>
> 	The implication of that statement is that actual implementations (like ODL etc) now
> need to copy/paste this model without the I2RS text to use them in other ways. This seems
> strange and just about the most inefficient way to use these that I can think of.
>
> 	—Tom
>
>
>
>> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares <[e-mail]> wrote:
>>
>> Anton:
>>
>> See earlier message to Martin.  Topology models are I2RS YANG Models
>> designed for ephemeral state with specific security concerns.  This is not
>> your basic YANG model no matter which data store ephemeral gets linked to.
>> Where is ephemeral state?  By IESG Design of charter, I2RS is not in charge
>> of defining ephemeral state solution.  NETMOD/NETCONF are.  Go ask them.
>>
>> Do not blame the messenger echoing NETMOD results,
>>
>> Sue
>>
>> -----Original Message-----
>> From: i2rs [mailto:[e-mail]] On Behalf Of Anton Ivanov
>> Sent: Tuesday, January 24, 2017 8:30 AM
>> To: [e-mail]
>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>
>> On 24/01/17 11:52, Juergen Schoenwaelder wrote:
>>> Susan,
>>>
>>> so are these YANG models regular YANG models or are these YANG models
>>> specific to the yet to be defined I2RS protocol and yet to be defined
>>> datastores?
>>>
>>> I think this is the core of Martin's and my question. A simple clear
>>> and concise answer would be nice.
>> +1.
>>
>> A.
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs