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 <[email protected]> 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:[email protected]] On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 8:30 AM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
