Re: [i2rs] topo model use of NACM

[Andy Bierman]

On Tue, Feb 21, 2017 at 1:33 AM, Robert Wilton <rwil...@cisco.com> wrote:

> Hi Andy,
>
> On 16/02/2017 22:36, Andy Bierman wrote:
>
>
>
> On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <
> alexander.cl...@huawei.com> wrote:
>
>> There are actually a number of interesting implications with regards to
>> NACM.  NACM could indeed be a key to the solution if it provides sufficient
>> flexibility with regards to articulating and enforcing authorization
>> rules.  Regarding this, I have a number of questions/comments:
>>
>>
>>
>> -  If a subtree contains objects that a client does not have
>> write privileges for, will the client be prevented from locking the
>> subtree? How about the case when the client does not even have read
>> privileges?
>>
>
> locking and NACM are 2 different things.
> NETCONF has datastore (global) locks and subtree (partial) locks.
> There is no mechanism in NACM or elsewhere that constrains the values
> that a particular client can use. (NACM controls access to the rpc, with no
> control over specific input paramters).
>
>
>
>>
>> The current NACM-bis draft states in section 3.7.2 that this is not the
>> case – i.e. a client is able to lock an entire subtree, even in cases when
>> there is not a single object in that subtree that the client actually has
>> access privileges to.
>>
>>
>>
>> To me, this does not seem right.  It just invites abuse.
>>
>>
>>
>> Now, there is still the possibility to restrict access to the operation
>> overall.  But again, this means that you have to give a users an
>> all-or-nothing choice.  Too inflexible.  By the same token that partial
>> locks were supported to avoid requiring anyone who needs the ability to
>> conduct a transaction to lock down the entire server, there should be the
>> ability to restrict access to the lock and partial-lock operation by
>> targeted subtree.  However, this capability is currently missing.
>>
>
>
> NACM was designed to be simple to implement.
> Some complex features that were in VACM were intentionally left out of
> NACM.
> NETCONF locking is also intentionally simple.
>
> I would rather have NETCONF 2.0 use a mandatory implicit, optimistic
> concurrent
> locking model, rather than more band-aids on the optional explicit,
> pessimistic
> serialized locking model we have now.
>
> This is interesting.  If you have time, then at some point, please can you
> expand on this idea, perhaps on the NETCONF alias?
>
>
NETCONF does not really support concurrent transactions.
It supports serialized transactions with explicit locks.
More than that is complicated, so it's probably not going to change
any time soon.


Thanks,
> Rob
>
>

Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo

[Andy Bierman]

On Thu, Feb 16, 2017 at 1:19 PM, Martin Bjorklund  wrote:

> "Xufeng Liu"  wrote:
> >
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> Bjorklund
> > > Sent: Tuesday, February 14, 2017 11:41 AM
> > > To: kwat...@juniper.net
> > > Cc: i2rs@ietf.org
> > > Subject: Re: [i2rs] modeling options for draft-ietf-i2rs-yang-network-
> topo
> > >
> > > Kent Watsen  wrote:
> > > >
> > > >
> > > > [moving yang-doctors to BCC]
> > > >
> > > >
> > > > >> OPTION 1: separate /foo and /foo-state trees
> > > > >> 
> > > > >>
> > > > >> This option was/is described here:
> > > > >> https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html.
> > > > >>
> > > > >> PROS:
> > > > >>   a) does NOT break legacy clients (how we got here)
> > > > >>   b) consistent with convention used in many IETF modules
> > > > >>   c) able to show if/how opstate may differ from configured values
> > > > >>
> > > > >> CONS:
> > > > >>   a) questionably valid YANG leafref usage
> > > > >
> > > > > What does this mean?
> > > >
> > > > I'm referring to how the description statement explains that the
> > > > server may look to operational state in order to resolve the leafref,
> > > > which is to result in behavior similar to pre-configuration in RFC
> > > > 7223.
> > >
> > > Ok, I didn't pay close attention to the proposal in the quoted email.
> > >
> > > I would design this a bit differently.  The config true leaf
> "dependency"
> > should
> > > have a leafref to the config false node name, with require-instance
> false.
> > The
> > > description should explain that the configuration item will be used by
> the
> > server
> > > if all dependencies exist.  When the configuration item is used, it
> shows
> > up in the
> > > config false list.
> > >
> > > This way, the leafref usage is valid and straight forward.
> > >
> > > > >>   b) complex server implementation (to handle require-instance
> > > > >> false)
> > > > >
> > > > >Can you elaborate on this one?
> > > >
> > > > This is primarily a reflection of the CON listed above, in that it
> > > > seems that a server would need to have special handling for when
> > > > dependencies transition from being present to not-present and vice
> > > > versa, much like the code to handle when a physical card is plugged
> in
> > > > or removed.
> > >
> > > Yes, but I think this is inherent to the problem at hand.  Even with
> the
> > config true
> > > solution defined in the current draft, it is not clear how things that
> > were created
> > > by the server would be deleted (if there were references to them).
> > >
> > > > Note: I should've listed this as a CON for OPTION 2 as well.
> > > >
> > > >
> > > >
> > > > >>   c) eventually the module would need to migrate to the long-term
> > > > >>  solution, which would result in needing to also rewrite all
> > > > >>  modules that have augmented it (e.g., ietf-te-topology).
> > > > >>   d) leafref path expressions really only work for configuration
> > data,
> > > > >>  though a clever server could have a special ability to peak
> at
> > > > >>  the opstate values when doing validations.  Of course, with
> > > > >>  require-instance is false, the value of leafref based
> validation
> > > > >>  checking is negated anyway, even for config true nodes, so
> this
> > > > >>  may not matter much.
> > > > >>
> > > > >>
> > > > >>
> > > > >> OPTION 2: explicit client-option to also return tagged opstate
> data
> > > > >> 
> ---
> > > > >>
> > > > >> This option takes a couple forms.  The first is module-specific
> and
> > > > >> the second is generic.  In both cases, the idea is modeled after
> > > > >> the with-defaults solution (RFC6243), wherein the client passes a
> > > > >> special flag into  causing the server to also return
> > > > >> opstate data, having a special metadata flag set, intermingled
> with
> > > > >> the configuration data.
> > > > >>
> > > > >>
> > > > >> 2A: Module-specific version
> > > > >>
> > > > >>module foo {
> > > > >>   import ietf-netconf { prefix nc; }
> > > > >>   import ietf-yang-metadata { prefix md; }
> > > > >>   md:annotation server-provided {
> > > > >>  type boolean;
> > > > >>   }
> > > > >>   container nodes {
> > > > >>  config true;
> > > > >>  list node {
> > > > >> key "name";
> > > > >> leaf name { type string; }
> > > > >> leaf dependency {
> > > > >>type leafref {
> > > > >>  path "../node/name"
> > > > >>  require-instance false;
> > > > >>}
> > > > >> }
> > > > >>  }
> > > > >>   }
> > > > >>   augment /nc:get-config/nc:input {
> > > > >>  leaf with-server-provided {
> > > > >>

Re: [i2rs] topo model use of NACM

[Andy Bierman]

On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <alexander.cl...@huawei.com
> wrote:

> There are actually a number of interesting implications with regards to
> NACM.  NACM could indeed be a key to the solution if it provides sufficient
> flexibility with regards to articulating and enforcing authorization
> rules.  Regarding this, I have a number of questions/comments:
>
>
>
> -  If a subtree contains objects that a client does not have
> write privileges for, will the client be prevented from locking the
> subtree? How about the case when the client does not even have read
> privileges?
>

locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc, with no
control over specific input paramters).



>
> The current NACM-bis draft states in section 3.7.2 that this is not the
> case – i.e. a client is able to lock an entire subtree, even in cases when
> there is not a single object in that subtree that the client actually has
> access privileges to.
>
>
>
> To me, this does not seem right.  It just invites abuse.
>
>
>
> Now, there is still the possibility to restrict access to the operation
> overall.  But again, this means that you have to give a users an
> all-or-nothing choice.  Too inflexible.  By the same token that partial
> locks were supported to avoid requiring anyone who needs the ability to
> conduct a transaction to lock down the entire server, there should be the
> ability to restrict access to the lock and partial-lock operation by
> targeted subtree.  However, this capability is currently missing.
>


NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of NACM.
NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic
concurrent
locking model, rather than more band-aids on the optional explicit,
pessimistic
serialized locking model we have now.



>
> -  Where can NACM rules originate from?   The current model seems
> to assume that rules will always be explicitly configured from an external
> client and constitute part of configuration. Now, what about the case when
> rules are to be enforced automatically by the server?   I think NACM should
> allow for that, and having a mix of both.  (The server-provided topologies
> are one potential example where this would be very useful.  In fact, if
> this capability were supported, I don’t think we would be having the
> server-provided discussion in the topology context – NACM would be all we
> need.  However, there are other use cases for this.  Think e.g. an
> intrusion protection component on the server, that you would not want to
> override by an external user administration client application that you
> would still want to allow as well.  Or cases when some authorizations get
> signaled, e.g. in the case of autonomic peer-to-peer type of applications.)
>
>
I don't think any YANG configuration module precludes server-created
entries.
The configuration is created somehow.  The YANG module discusses the data
model
instances without saying how they got there.



>
>
> --- Alex
>


Andy


>
>
> *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Thursday, February 16, 2017 12:49 PM
> *To:* Susan Hares <sha...@ndzh.com>
> *Cc:* i2rs@ietf.org
> *Subject:* Re: [i2rs] topo model use of NACM
>
>
>
> Hi,
>
>
>
> I am most concerned about getting the architecture right.
>
> We have ignored server-created nodes until now.
>
> I am glad I2RS WG is trying to deal with the problem.
>
> Just make sure we have a reusable solution.
>
>
>
> Also concerned about tool automation.
>
> There was some discussion of a 'server-created' extension at some point I
> think.
>
> This would help, because the server-created leaf is not really
> deterministic.
>
> It is just a convention.
>
>
>
> e.g.
>
>
>
>
>
>   container networks {
>
>  list network {
>
>  i2rs:server-created;
>
>  ...
>
>  leaf server-created { ... }
>
>  ...
>
>  }
>
>   }
>
>
>
>
>
> Andy
>
>
>
>
>
> On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <sha...@ndzh.com> wrote:
>
> Andy:
>
> 
>
>
>
> AFAIK – I believe the revised data store model is right approach.   It is
> an important question to ask whether the ability to have a mixture of
> “server-provided” and “configured” is important for all topology models.  I
&

Re: [i2rs] topo model use of NACM

[Andy Bierman]

Hi,

I am most concerned about getting the architecture right.
We have ignored server-created nodes until now.
I am glad I2RS WG is trying to deal with the problem.
Just make sure we have a reusable solution.

Also concerned about tool automation.
There was some discussion of a 'server-created' extension at some point I
think.
This would help, because the server-created leaf is not really
deterministic.
It is just a convention.

e.g.


  container networks {
 list network {
 i2rs:server-created;
 ...
 leaf server-created { ... }
 ...
 }
  }


Andy


On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
> 
>
>
>
> AFAIK – I believe the revised data store model is right approach.   It is
> an important question to ask whether the ability to have a mixture of
> “server-provided” and “configured” is important for all topology models.  I
> hope Xufeng and other topology models will comment on this point.
>
>
>
>
>
> Does the NETCONF data store in the revised data-store future include the
> control plane data stores? I thought the answer was “no” it does not.
>  Here’s some text from draft-ietf-netconf-rfc6536bis that leads me to
> believe that
>
>
>
> On NACM, draft-ietf-netconf-rfc6536bis it says:
>
>
>
>It is necessary to control access to specific nodes and subtrees
>
>within the NETCONF datastore, regardless of which protocol operation,
>
>standard or proprietary, was used to access the datastore.
>
>
> 3.2
> <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00#section-3.2>.
> Datastore Access
>
>The same access control rules apply to all datastores, for example,
>
>the candidate configuration datastore or the running configuration
>
>datastore.
>
>
>
>Only the standard NETCONF datastores (candidate, running, and
>
>startup) are controlled by NACM.  Local or remote files or datastores
>
>accessed via the  parameter are not controlled by NACM.  A
>
>standalone RESTCONF server (i.e., not co-located with a NETCONF
>
>server) applies NACM rules to a conceptual datastore, since
>
>datastores are not supported in RESTCONF.
>
>
>
>
>
> ===
>
>
>
> The I2RS security environment actually looks at 3 policies on the server
>
>
>
> Network Access ß-à server ß-à routing-system access
>
>   (aka I2RS agent)
>
> |ßà System access
>
>
>
> It also looks at application access to the client
>
>
>
>   Network accessßà client ßà application-access
>
>
>
>
>
> The protocol only needs to consider the NACM Access, but the routing
> infrastructure need to consider the server to/from routing system, and
> server to/from system.  My understanding is that the Routing system access
> control module (RACM) and the system access control module (SACM) functions
> were not in NACM.
>
>
>
> Thanks again for posting,
>
>
>
> Sue
>
>
>
> *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Thursday, February 16, 2017 2:00 PM
> *To:* i2rs@ietf.org
> *Subject:* [i2rs] topo model use of NACM
>
>
>
> Hi,
>
>
>
> The use of NACM for server-provided data is under-specified (at best)
>
>
>
>
>
> from sec. 4.1:
>
>
>
>Finally, there is an object "server-provided".  This object is state
>
>that indicates how the network came into being.  Network data can
>
>come into being in one of two ways.  In one way, network data is
>
>configured by client applications, for example in case of overlay
>
>networks that are configured by an SDN Controller application.  In
>
>annother way, it is populated by the server, in case of networks that
>
>can be discovered.
>
>
>
>If server-provided is set to false, the network was configured by a
>
>client application, for example in the case of an overlay network
>
>that is configured by a controller application.  If server-provided
>
>is set to true, the network was populated by the server itself,
>
>respectively an application on the server that is able to discover
>
>the network.  *Client applications SHOULD NOT modify configurations of*
>
> *   networks for which "server-provided" is true.*  When they do, they
>
>need to be aware that any modifications they make are subject to be
>
>reverted by the server.  For servers that support NACM (Netconf
>
>Access Control Model), *data node rules should ideally prevent* write
>
>access by other clients to net

[i2rs] topo model use of NACM

[Andy Bierman]

Hi,

The use of NACM for server-provided data is under-specified (at best)


from sec. 4.1:

   Finally, there is an object "server-provided".  This object is state
   that indicates how the network came into being.  Network data can
   come into being in one of two ways.  In one way, network data is
   configured by client applications, for example in case of overlay
   networks that are configured by an SDN Controller application.  In
   annother way, it is populated by the server, in case of networks that
   can be discovered.

   If server-provided is set to false, the network was configured by a
   client application, for example in the case of an overlay network
   that is configured by a controller application.  If server-provided
   is set to true, the network was populated by the server itself,
   respectively an application on the server that is able to discover
   the network.  *Client applications SHOULD NOT modify configurations of
   networks for which "server-provided" is true.*  When they do, they
   need to be aware that any modifications they make are subject to be
   reverted by the server.  For servers that support NACM (Netconf
   Access Control Model), *data node rules should ideally prevent* write
   access by other clients to network instances for which server-
   provided is set to true.


The SHOULD NOT above is really odd, considering is not supported by YANG
or the NC/RC protocols.

"data node rules should ideally prevent"

s/should/SHOULD/

Ideally prevent?
Is that a new engineering term?
Either this new usage of NACM works or it doesn't.

Also, there is no guidance or examples of the NACM config that the
server is supposed to magically create for server-provided topology data.
There is nothing in NACM at all about server-created data rules.
This is not supported by NACM.

Does the I2RS text imply that the server-provided property extends
to the NACM sub-trees? They are also subject to replacement by the server?
The client SHOULD NOT change these NACM rules?

IMO the way this server-provided property is being done is a short-sighted
point solution, but this should be a fundamental part of the revised
datastores work.
Is there something special about network topology such that
server-provided data for a different module will require a different
solution? If not, is the topo module solution reusable?


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Andy Bierman]

On Wed, Jan 25, 2017 at 11:05 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> Just search for ephemeral in the document and you will hit this:
>
>The model foresees control-plane datastores that are by definition
>not part of the persistent configuration of a device.  In some
>contexts, these have been termed ephemeral datastores since the
>information is ephemeral, i.e., lost upon reboot.  The control-plane
>datastores interact with the rest of the system through the 
>or  datastores, depending on the type of data they
>contain.  Note that the ephemeral datastore discussed in I2RS
>documents maps to a control-plane datastore in the revised datastore
>model described here.
>
>


The modules in draft-ietf-i2rs-yang-l3-topology-08
and draft-ietf-i2rs-yang-network-topo-10
appear to contain only configuration data nodes. They are mandatory to
implement.


>From RFC 7950:

7.21.1.  The "config" Statement

   The "config" statement takes as an argument the string "true" or
   "false".  If "config" is "true", the definition represents
   configuration.  Data nodes representing configuration are part of
   configuration datastores.

   If "config" is "false", the definition represents state data.  Data
   nodes representing state data are not part of configuration
   datastores.


If these nodes are not intended to be part of configuration datastores,
then the nodes need to marked as "config false".




> /js
>
>
Andy



> On Wed, Jan 25, 2017 at 01:58:13PM -0500, Susan Hares wrote:
> > Juergen:
> >
> > Where do you think the revised data store model in that draft suggests
> ephemeral data stores live?
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> > Sent: Wednesday, January 25, 2017 1:54 PM
> > To: Susan Hares
> > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topol...@ietf.org; 'Alia
> Atlas'; 'Giles Heron'; i...@ietf.org; 'Lou Berger'
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> >
> > Sue,
> >
> > the current thinking is documented in
> > draft-ietf-netmod-revised-datastores-00.txt.
> >
> > /js
> >
> > On Wed, Jan 25, 2017 at 12:52:47PM -0500, Susan Hares wrote:
> > > Juergen:
> > >
> > > "And with the revised datastore model it will also be straight forward
> to have an implementation that just exposes topological data via the
> operational state datastore.  And the revised datastore model also paves
> the path to support datastores that can also inject ephemeral data."
> > >
> > > Where do you believe the revised data store model suggest ephemeral
> data can be injected - (?written)?
> > >
> > > Sue
> > >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen
> > > Schoenwaelder
> > > Sent: Wednesday, January 25, 2017 10:33 AM
> > > To: Giles Heron
> > > Cc: draft-ietf-i2rs-yang-l3-topol...@ietf.org; i2rs@ietf.org; Lou
> > > Berger; i...@ietf.org; Alia Atlas
> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> > >
> > > On Wed, Jan 25, 2017 at 03:19:58PM +, Giles Heron wrote:
> > > >
> > > > > On 25 Jan 2017, at 15:18, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> > > > >
> > > > > On Wed, Jan 25, 2017 at 10:07:45AM -0500, Alia Atlas wrote:
> > > > >>
> > > > >> So - if one has models - such as a writable topology - where
> > > > >> there can be dependencies on dynamic data, then those models
> > > > >> can't be in the configuration data-store as currently defined.
> > > > >>
> > > > >
> > > > > Yes
> > > >
> > > > but isn’t this confusing models and implementation?
> > >
> > > I just confirmed that the old datastore model does not support
> writable ephemeral datastores. No more no less. And there is work in NETMOD
> (and NETCONF) to revise the datastore model and to make data model reuse in
> different datastores even simpler.
> > >
> > > > if you have a case where you have a dependency on dynamic data then
> you can’t put that instantiation of the model in the configuration
> data-store.
> > > >
> > > > but if your implementation never depends on dynamic data then it
> ought to be fine.
> > >
> > > Yes. This should be fine.
> > >
> > > And with the revised datastore model it will also be straight forward
> to have an implementation that just exposes topological data via the
> operational state datastore.  And the revised datastore model also paves
> the path to support datastores that can also inject ephemeral data.
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103 
> > >
> > > ___
> > > i2rs mailing list
> > > 

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

[Andy Bierman]

On Mon, Jan 23, 2017 at 2:06 PM, Susan Hares  wrote:

> Robert and Martin:
>
> I agree with Robert that the current implementations of the ODL topology
> models are handled as part of the configuration data store with ephemeral
> state.   I will point out that these implementation are pre-standards
> implementations of the I2RS YANG Data model.
>
> While standardizing the topology data models, the I2RS WG have been asked
> to
> align with the draft-ietf-netmod-revised-datastores-00.txt NETMOD WG
> document.  This NETMOD WG document moves the I2RS ephemeral data store from
> configuration data store to a Control Plane data store.   If we follow this
> draft, the I2RS Topology models are part of the I2RS ephemeral data store.
> If you disagree with the placement of the Topology data models, please
> indicate this to the NETMOD WG and to Benoit.  Could you propose a way that
> you would see the ephemeral state working with the configuration data store
> to the NETMOD WG?
>


This was discussed many times, going back to the NYC interim for NETMOD WG.

There are 2 choices that are backward compatible

1) I2RS nodes are config=true
This is OK if the data nodes represent configuration that can be
overridden
 by the values in the ephemeral datastore.  NETCONF can write the
configuration datastore. I2RS can write the ephemeral datastore

2) I2RS nodes are config=false
   This is OK if the data nodes represent I2RS-only data that cannot be
written
   to a configuration datastore. I2RS can write to this data in the
ephemeral datastore only





> Quite frankly, I feel a bit of whip-lash on this topic.   NETMOD WG asks
> for
> Control Plane Data store.  You ask for configuration data store (which was
> the I2RS initial proposal).   It is possible for either one to work for
> I2RS
> Topology models - if the right details are taken care of.   How do we make
> progress on choosing one method so we can write the I2RS Topology Models
> security considerations.?
>
> Sue
>


Andy


>
> -Original Message-
> From: Robert Varga [mailto:n...@hq.sk]
> Sent: Monday, January 23, 2017 4:11 PM
> To: Martin Bjorklund; sha...@ndzh.com
> Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topol...@ietf.org;
> j.schoenwael...@jacobs-university.de; i2rs-cha...@ietf.org;
> kathleen.moriarty.i...@gmail.com; i...@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
> On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
> >> I'm pulling your questions to the top of this email.
> >>
> >>
> >>
> >> Question 1: 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?
> >>
> >>
> >>
> >> Response 1:  Not really.
> > Ok, so are you saying that the models are in fact generic, and can be
> > used outside of I2RS?  I.e., they *can* be used with the normal
> > configuration datastores?
> >
>
> >From implementation experience, yes, they can be used for storing
> configuration. OpenDaylight uses (an ancient predecessor of)
> yang-network-topo to store configure details about devices in its managed
> networks.
>
> Regards,
> Robert
>
>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Andy Bierman]

On Mon, Jan 23, 2017 at 1:19 PM, Martin Bjorklund  wrote:

> Robert Varga  wrote:
> > On 01/23/2017 09:26 PM, Martin Bjorklund wrote:
> > >> I'm pulling your questions to the top of this email.
> > >>
> > >>
> > >>
> > >> Question 1: 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?
> > >>
> > >>
> > >>
> > >> Response 1:  Not really.
> > > Ok, so are you saying that the models are in fact generic, and can be
> > > used outside of I2RS?  I.e., they *can* be used with the normal
> > > configuration datastores?
> > >
> >
> > From implementation experience, yes, they can be used for storing
> > configuration. OpenDaylight uses (an ancient predecessor of)
> > yang-network-topo to store configure details about devices in its
> > managed networks.
>
> Robert, this sub-thread started with Susan's statement:
>
>1) I2RS Data models do not utilize the configuration data store,
>
> i.e., despite the fact that the data model is config true, it cannot
> be edited via running etc in NETCONF (or normal edit in RESTCONF).
>
> My comment on this was that *if* this is true, it should be noted in
> the document.  At this point, I am not sure if it is true or not.
>
>
Agreed.

But a larger issue is the balkanization of YANG.
To every YANG reader, the YANG data-def-stmts look exactly
like those that would be interpreted as configuration and state data nodes.

I little note that says "This is not regular YANG that is intended for
NETCONF or RESTCONF servers" is not really a solution.
RFC 7950 says YANG is for NETCONF, which is extra confusing.



> /martin
>
>
Andy


>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

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

[Andy Bierman]

Hi,

I realized that the NACM "default-deny-write" and "default-deny-all" tags
are
very similar.  We are deciding (in the data model) that the data node
can never be sent without an explicit NACM rule allowing it.
(I have never heard from a customer that they want this NACM rule ignored).
We do not abuse these NACM tags. They are rarely used.
I think the same will be true for the I2RS extension.


Andy


On Thu, Jan 19, 2017 at 10:47 AM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
>
>
> You are right to comment that – the “flip side of this extensions is that
> any node not properly tagged must not be SENT”.   The purpose of tagging is
> devices which test protocol conformation can test these portions of the
> model.  If buyers demand that these restrictions are followed, then these
> restrictions will not be ignored.  Like you and Juergen, I really hope that
> the IESG will very carefully evaluate any I2RS YANG Model that suggest
> sending data over non-secure transport.
>
>
>
> Sue Hares
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Thursday, January 19, 2017 1:31 PM
> *To:* Susan Hares
> *Cc:* Juergen Schoenwaelder; draft-ietf-i2rs-yang-l3-topol...@ietf.org;
> i2rs@ietf.org; Kathleen Moriarty; The IESG; i2rs-cha...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>
>
>
> Hi,
>
>
>
> I strongly agree with Juergen on this issue.
>
> But you can easily design a YANG extension that indicates a data node
>
> is OK for insecure transport.
>
>
>
> I trust that the IESG will evaluate every object of this type and
>
> decide whether it is really OK for disclosure in every possible
>
> usage scenario.
>
>
>
> The flip-side of this extension is that any node not properly tagged
>
> MUST NOT be sent without the proper security protocols.
>
> This rule will likely be ignored, since (as Juergen pointed out)
>
> this is a deployment decision, not a modeling decision.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Thu, Jan 19, 2017 at 10:15 AM, Susan Hares <sha...@ndzh.com> 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).
>  The
> yang doctor's YANG  security consideration template
> (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:j.schoenwael...@jacobs-university.de]
> Sent: Thursday, January 19, 2017 10:34 AM
> To: Susan Hares
> Cc: 'Kathleen Moriarty'; 'The IESG';
> draft-ietf-i2rs-yang-l3-topol...@ietf.org; i2rs@ietf.org;
> i2rs-cha...@ietf.org
> 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 a

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

[Andy Bierman]

Hi,

I strongly agree with Juergen on this issue.
But you can easily design a YANG extension that indicates a data node
is OK for insecure transport.

I trust that the IESG will evaluate every object of this type and
decide whether it is really OK for disclosure in every possible
usage scenario.

The flip-side of this extension is that any node not properly tagged
MUST NOT be sent without the proper security protocols.
This rule will likely be ignored, since (as Juergen pointed out)
this is a deployment decision, not a modeling decision.


Andy


On Thu, Jan 19, 2017 at 10:15 AM, 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).
>  The
> yang doctor's YANG  security consideration template
> (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:j.schoenwael...@jacobs-university.de]
> Sent: Thursday, January 19, 2017 10:34 AM
> To: Susan Hares
> Cc: 'Kathleen Moriarty'; 'The IESG';
> draft-ietf-i2rs-yang-l3-topol...@ietf.org; i2rs@ietf.org;
> i2rs-cha...@ietf.org
> 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-consider/
> >
> > 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:kathleen.moriarty.i...@gmail.com]
> > Sent: Wednesday, January 18, 2017 9:44 PM
> > To: The IESG
> > Cc: draft-ietf-i2rs-yang-l3-topol...@ietf.org; sha...@ndzh.com;
> > i2rs-cha...@ietf.org; sha...@ndzh.com; i2rs@ietf.org
> > 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
> > 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/
> >
> >
> >
> > --
> > 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 

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

On Tue, Aug 23, 2016 at 12:27 PM, Susan Hares <sha...@ndzh.com> wrote:

> Jeff:
>
> Thank you your comments.   I agree with your assessment of the WG's
> desires.
> It provides a helpful context for the IESG members.
>
> As I mentioned in another email, one of the first mechanisms is to describe
> what portions of an data model can be sent in the PUB/SUB Push via a
> non-secure HTTP session or what require a secure HTTP session.
>
> Sue
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Monday, August 22, 2016 3:46 PM
> To: Andy Bierman
> Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger;
> Susan Hares; draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
> I'm lagging in my email, as usual.  However, this one caught my eye:
>
> On Fri, Aug 19, 2016 at 07:23:47AM -0700, Andy Bierman wrote:
> > We could have been tagging MIB objects all along, but we don't.
> > Imagine if there was a debate for every single OBJECT-TYPE macro "is
> > this leaf OK for noAuth/noPriv?"
> >
> > Are there even clear SEC-DIR guidelines on how one would decide this
> > debate in a WG? Does SEC-DIR really want to be flooded with review
> > requests so they become a bottleneck in YANG RFC publication process?
>
> I wanted to point out some of the per-object security evaluation that is
> already imposed on MIB modules.  Consider the following text from RFC 4273:
>
> :There are a number of managed objects in this MIB that contain
> :sensitive information regarding the operation of a network.  For
> :example, a BGP peer's local and remote addresses might be sensitive
> :for ISPs who want to keep interface addresses on routers confidential
> :in order to prevent router addresses used for a denial of service
> :attack or spoofing.
> :
> :Therefore, it is important in most environments to control read
> :access to these objects and possibly to even encrypt the values of
> :these object when sending them over the network via SNMP.
>
> In some respect, the discussion with regard to I2RS annotation of yang
> nodes
> with security considerations have precedence.  It could be done in the
> containing documents' security considerations section.  It could be part of
> the description clause for the node.
>
> Having some notion of the consideration available as a machine-parseable
> markup thus doesn't seem completely unreasonable.
>
> The essence of your point, Andy, and I believe Juergen's is given a
> presmise
> of "secure by default", is it okay to mark things as "the author of this
> module believes this to be okay to be insecure by default"?
>
> Possibly not.  As you both mention, it will depend on the circumstances of
> a
> given operator's deployment.
>


I believe the actual annotation needs to apply to a specific subtree.
There are corner-cases where the module-wide annotation does not work
(such as groupings used in a different module).

IMO the annotation needs to apply only to descendant-or-self nodes
in the same module namespace.



>
> The underlying I2RS question is how to mark nodes in such a way that the
> insecure transport protocols may be permitted to publish them without
> requiring every single node to be audited if you have relatively weak
> deployment considerations?  If the answer is "read the security
> considerations and write a filter", it's not the answer i2rs is looking
> for.
>
>
> -- Jeff
>


Andy



>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

On Tue, Aug 23, 2016 at 9:31 AM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
>
>
> Rather than state “data model as 'non-confidential' remains a flawed” in
> the abstract, can we simply discuss the specifics I listed?
>
>
>

That was Juergen's comment.

I think the tagging proposal is OK if the standard protocol that YANG Push
designates as non-secure (HTTP?) is not allowed to send any YANG data
that is not properly tagged.

(If the protocol is allowed to ignore this extension, then the extension is
pointless.)

1)  BGP information publically sent as part of route-views
>
> Sent as an  event stream from an I2RS client
>
>
>
> 2)  Web server “up” messages sent as an event
>
> With the text similar to:   “go-to-me.com web server is up”  where
> “go-to-me” is a public name.
>
>
>
> Please consider in terms of an Event stream model we are working in the
> push.  Remember the configuration of the stream is via secure servers, and
> what we are talking about is listeners to the stream.
>


The actual data sent to listeners can be altered in flight.
This may be a low risk.  This is part of the decision WGs will
have to make to support non-secure transport of data in the data models.



>
>
> Sue Hares
>


Andy


>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Monday, August 22, 2016 1:07 PM
> *To:* Juergen Schoenwaelder; Susan Hares; Andy Bierman; Lou Berger;
> i2rs@ietf.org; Alissa Cooper; i2rs-cha...@ietf.org; Kathleen Moriarty;
> IESG; Jeffrey Haas; Joel Halpern; draft-ietf-i2rs-protocol-
> security-requireme...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
>
>
>
>
> On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote:
> > Andy:
> >
> >
> >
> > The easy of reviewing per leaf – is why I suggested the per leaf.
> >
> > I also agree it is important to mention this non-secure/secure
> requirement to the PUSH work team we are both on.
> >
> >
> >
> > Should I change:
> >
> > Old: /
> >
> >A non-secure transport can be used for publishing telemetry data or
> >
> >other operational state that was specifically indicated to non-
> >
> >confidential in the data model in the Yang syntax. /
> >
> > New:
> >
> > /   A non-secure transport can be used for publishing telemetry data or
> >
> >other operational state that was specifically indicated to non-
> >
> >confidential in the data model. /
> >
>
> Tagging something in the data model as 'non-confidential' remains a
> flawed idea. What can be considered 'non-confidential' depends on the
> deployment scenario. It is even worse to standardize some piece of
> information as 'non-confidential'. How can the IETF claim that
> something is always 'non-confidential'? (And note, a non-secure
> transport is not just about confidentiality, it also implies that
> boxes on the path can arbitrarily change the information.)
>
>
>
> This additional note is quite interesting.
>
> It is 1 thing to decide if the data is public info or not.
>
> (Assume security guidelines could be provided that clearly define that.)
>
>
>
> It is quite another to say "it's OK if the monitoring data gets modified
> in flight".
>
> I can't imagine any use-cases for that.
>
>
>
>
>
> In case this is not clear: What we have done for ~30 years is to have
> the decision which information goes into an insecure transport be
> taken by an access control model. This makes the decision runtime
> configurable and thus things can be deployment specific. This has
> worked for 30 years and I have no problem with this. What I am
> struggling with is the idea to standardize parts of YANG data models
> as 'non-confidential'.
>
> /js
>
>
>
>
>
> Andy
>
>
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote:
> > Andy:
> >
> >
> >
> > The easy of reviewing per leaf – is why I suggested the per leaf.
> >
> > I also agree it is important to mention this non-secure/secure
> requirement to the PUSH work team we are both on.
> >
> >
> >
> > Should I change:
> >
> > Old: /
> >
> >A non-secure transport can be used for publishing telemetry data or
> >
> >other operational state that was specifically indicated to non-
> >
> >confidential in the data model in the Yang syntax. /
> >
> > New:
> >
> > /   A non-secure transport can be used for publishing telemetry data or
> >
> >other operational state that was specifically indicated to non-
> >
> >confidential in the data model. /
> >
>
> Tagging something in the data model as 'non-confidential' remains a
> flawed idea. What can be considered 'non-confidential' depends on the
> deployment scenario. It is even worse to standardize some piece of
> information as 'non-confidential'. How can the IETF claim that
> something is always 'non-confidential'? (And note, a non-secure
> transport is not just about confidentiality, it also implies that
> boxes on the path can arbitrarily change the information.)
>
>
This additional note is quite interesting.
It is 1 thing to decide if the data is public info or not.
(Assume security guidelines could be provided that clearly define that.)

It is quite another to say "it's OK if the monitoring data gets modified in
flight".
I can't imagine any use-cases for that.


In case this is not clear: What we have done for ~30 years is to have
> the decision which information goes into an insecure transport be
> taken by an access control model. This makes the decision runtime
> configurable and thus things can be deployment specific. This has
> worked for 30 years and I have no problem with this. What I am
> struggling with is the idea to standardize parts of YANG data models
> as 'non-confidential'.
>
> /js
>
>

Andy


> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

Hi,

That is simple.
There needs to be consensus on the syntax and semantics of each
statement in the YANG module.

Since security is MTI and MTU for NETCONF and RESTCONF, there
is no point debating which objects are OK without security.

Andy



On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
>
>
> Thank you for your comments.   Perhaps you can provide for the IESG the
> list of things that are needed to move a Yang module forward in the IETF.
>
>
>
> Sue
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Friday, August 19, 2016 10:24 AM
> *To:* Lou Berger
> *Cc:* Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Cooper;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel
> Halpern; draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Hi,
>
>
>
> I agree with Juergen.
>
> There are already too many details that need consensus to move
>
> a YANG module forward in the IETF.  It takes too long already.
>
>
>
> We could have been tagging MIB objects all along, but we don't.
>
> Imagine if there was a debate for every single OBJECT-TYPE macro
>
> "is this leaf OK for noAuth/noPriv?"
>
>
>
> Are there even clear SEC-DIR guidelines on how one would decide this
>
> debate in a WG? Does SEC-DIR really want to be flooded with review
>
> requests so they become a bottleneck in YANG RFC publication process?
>
>
>
> Standardized insecure access is a big change from what we have done
>
> for 30 years.  There could be a good reason why we left this out of scope
>
> all this time.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger <lber...@labn.net> wrote:
>
>
> Sue,
>
> My message said three things:
>
> 1) Juergen's comment resonates with me.
>
> 2) I think the current text is acceptable.
>
> 3) I see changing the SHOULD to a MUST as problematic.
> I understood one of the other messages on this thread proposing this
> change which is what triggered my message.   If I misunderstood that
> message, feel free to interpret my message as supporting the current
> text in question.
>
> Note that I am only speaking for myself (including in my role as NETMOD
> co-chair) and not representing the consensus opinion of any WG.
>
> Lou
> On 8/19/2016 8:07 AM, Susan Hares wrote:
> > Lou:
> >
> > I am clear that Juergen does not want not want to place transport
> requirements within the data model for NETMOD.  His opinion was considered
> in the rough for the I2RS WG. If this requirement is a problem for
> NETCONF/NETMOD,  the text currently says:
> >
> > REQ-SEC-09 states:
> >
> >   The default mode of transport is secure so data models SHOULD clearly
> annotate what data nodes can be
> >passed over an insecure connection.
> >
> > However, if this means the NETCONF/NETMOD WG will not even entertain
> proposal for marking the insecure functions in yang text -- then the two WG
> (I2RS/NETMOD) have a problem and should stop this standardization process
> going forward.
> >
> > Sue
> >
> >
> > -Original Message-
> > From: Lou Berger [mailto:lber...@labn.net]
> > Sent: Friday, August 19, 2016 7:34 AM
> > To: Susan Hares; 'Juergen Schoenwaelder'
> > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-cha...@ietf.org; 'Kathleen
> Moriarty'; 'IESG'; jh...@pfrc.org; 'Joel Halpern';
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
> >
> > Sue,
> >
> > I don't see Juergen as arguing against model access via non-secure
> transport. I read his point as that the transport security requirements
> don't belong scattered within a data model.
> >
> > I have to say that from a model complexity (definition, process, review,
> implementation - take your pick) , language and NETMOD co-chair
> perspective, his comment resonates with me.
> >
> > I think this makes the key text:
> >
> >The default mode of transport is
> >secure so data models SHOULD clearly annotate what data nodes can be
> >passed over an insecure connection.
> >
> >
> > As this isn't a MUST, I personally think we can live with the text and
> we can debate the issue further in the context of specific solutions.  I
> would strongly object 

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
>secure transport and optionally MAY be able to transfer data over a
>non-secure transport.
>
>
>
I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>
> *“ the IETF needs to agree that there could never possibly be any
> deployment that would not want to allow exposure of the data.*
>
> *Not now. Not 20 years from now.”*
>
>
>


I see your point now.
This draft makes no mention of the YANG data model marking objects that can
be nonsecure.


SEC-REQ-08 is fine.
The other requirement (sorry I don't have the number) is the one that
should be removed.


Andy

I had thought that the security-directorate and other reviewers would look
> at each module that is insecure, and  consider whether it was reasonable
> for the use case at this time.   This is what I understood from Russ
> Housley’s first review of this technology.  Since like you, I believe the
> operator is going to  configure what modules are allowed on systems.   I
> agree that this requirement provides a full scope of the work, but
> implementers will require network operators to configure these features on.
>
>
>
> Sue
>
>
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Thursday, August 18, 2016 2:53 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Hi,
>
>
>
> I did not think Juergen's comment was about running code.
>
>
>
> In order for a data node to get the "ok-for-nonsecure-transports" approval
>
> in an IETF module, the IETF needs to agree that there could never possibly
> be
>
> any deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.
>
>
>
> I can see a vendor making that decision for their own proprietary modules,
>
> but it seems less likely for standard modules.
>
>
>
> Seems like the operator is going to have to configure what is allowed
>
> for nonsecure transport anyway, so just let them decide.
>
> I don't really object to the extension or the requirement.
>
> It doesn't help much but it doesn't hurt much either.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <sha...@ndzh.com> wrote:
>
> Alissa:
>
> Just a little input you may not know.  My background is 15 years
> (1995-2010)  developing a routing/switching platform (denoted as GateD)
> which was sold to over 200 companies.   We developed XML and a binary XML
> based product that configured this product.  It could do 100K configuration
> lines and reboot in less than a second on most hardware.  We also provide
> status messages in secure streams and non-secure streams.I sold early
> version of this code to companies that Alia has worked for  - so she has
> personal viewed the code.   At the height of our work, our development team
> ran to 50 people which I directed (First as VP of Engineering, and then as
> CTO). It is due to this level of experience that Alia selected me for the
> co-chair.   Russ White has understood Cisco's process, and has also
> directed software development teams for routing.
>
> In order to freshen my direct experience with I2RS on open source work, I
> am working on a publically available work in Quagga based on the confD
> product suggested by Cisco.
>
> In contrast, Juergen is a university professor who has worked on
> proto-types.   He is not working on an implementation.   I hope he will.
>
> I hope you will consider this background in my response to your comments
> below.
>
> Sue
>
>
> -Original Message-
> From: Alissa Cooper [mailto:ali...@cooperw.in]
> Sent: Thursday, August 18, 2016 12:54 PM
> To: Joel Halpern
> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; jh...@pfrc.org;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> C

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

Hi,

I guess we disagree on how easy it will be for the IETF to
decide all instances of certain objects can be read using
nonsecure protocols.  This seems like a log of effort for
something the operator should be deciding anyway.


Andy




On Thu, Aug 18, 2016 at 1:05 PM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
>
>
> If we create a yang data model that is insecure, and mount on another data
> model – does it have the same issue as module augmentation?   Of course, we
> could create a mount point for all insecure data modules, and all data
> placed under that mount point – would be insecure.
>
>
>
> For the BGP route-views use case, this would make it clear that data had
> to be transformed to be insecure transmission.
>
>
>
> Sue
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Thursday, August 18, 2016 4:02 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <sha...@ndzh.com> wrote:
>
> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
>secure transport and optionally MAY be able to transfer data over a
>non-secure transport.
>
>
>
> I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>
> *“ the IETF needs to agree that there could never possibly be any
> deployment that would not want to allow exposure of the data.*
>
> *Not now. Not 20 years from now.”*
>
>
>
>
>
>
>
> As I understand it, this requirement has another requirement associated
> with it
>
> that says the data has to be identified as OK-for-nonsecure-transport.
>
>
>
> An extension in the data model says that all instances of the object in
>
> all possible deployments cannot be considered sensistive and therefore
>
> needs disclosure protection.
>
>
>
> It may seem like even a simple octet counter is safe to send in the clear,
>
> but not if that opens up correlation attacks.  (e.g., I can send data to
> some
>
> host.  I can see that index 455992 is incrementing the in-octets counters
>
> in a way that strongly correlates to my test traffic.  Therefore I can
> learn
>
> that arbitrary index 455992 is really John Doe or really suite #14, etc.
>
>
>
>
>
> I had thought that the security-directorate and other reviewers would look
> at each module that is insecure, and  consider whether it was reasonable
> for the use case at this time.   This is what I understood from Russ
> Housley’s first review of this technology.  Since like you, I believe the
> operator is going to  configure what modules are allowed on systems.   I
> agree that this requirement provides a full scope of the work, but
> implementers will require network operators to configure these features on.
>
>
>
> Sue
>
>
>
> Andy
>
>
>
>
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Thursday, August 18, 2016 2:53 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Hi,
>
>
>
> I did not think Juergen's comment was about running code.
>
>
>
> In order for a data node to get the "ok-for-nonsecure-transports" approval
>
> in an IETF module, the IETF needs to agree that there could never possibly
> be
>
> any deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.
>
>
>
> I can see a vendor making that decision for their own proprietary modules,
>
> but it seems less likely for standard modules.
>
>
>
> Seems like the operator is going to have to configure what is allowed
>
> for nonsecure transport anyway, so just let them decide.
>
> I don't really object to the extension or the requirement.
>
> It doesn't help much but it doesn't hurt much either.

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <sha...@ndzh.com> wrote:

> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
>secure transport and optionally MAY be able to transfer data over a
>non-secure transport.
>
>
>
> I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>
> *“ the IETF needs to agree that there could never possibly be any
> deployment that would not want to allow exposure of the data.*
>
> *Not now. Not 20 years from now.”*
>
>
>


As I understand it, this requirement has another requirement associated
with it
that says the data has to be identified as OK-for-nonsecure-transport.

An extension in the data model says that all instances of the object in
all possible deployments cannot be considered sensistive and therefore
needs disclosure protection.

It may seem like even a simple octet counter is safe to send in the clear,
but not if that opens up correlation attacks.  (e.g., I can send data to
some
host.  I can see that index 455992 is incrementing the in-octets counters
in a way that strongly correlates to my test traffic.  Therefore I can learn
that arbitrary index 455992 is really John Doe or really suite #14, etc.



> I had thought that the security-directorate and other reviewers would look
> at each module that is insecure, and  consider whether it was reasonable
> for the use case at this time.   This is what I understood from Russ
> Housley’s first review of this technology.  Since like you, I believe the
> operator is going to  configure what modules are allowed on systems.   I
> agree that this requirement provides a full scope of the work, but
> implementers will require network operators to configure these features on.
>
>
>
> Sue
>

Andy


>
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Thursday, August 18, 2016 2:53 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Hi,
>
>
>
> I did not think Juergen's comment was about running code.
>
>
>
> In order for a data node to get the "ok-for-nonsecure-transports" approval
>
> in an IETF module, the IETF needs to agree that there could never possibly
> be
>
> any deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.
>
>
>
> I can see a vendor making that decision for their own proprietary modules,
>
> but it seems less likely for standard modules.
>
>
>
> Seems like the operator is going to have to configure what is allowed
>
> for nonsecure transport anyway, so just let them decide.
>
> I don't really object to the extension or the requirement.
>
> It doesn't help much but it doesn't hurt much either.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <sha...@ndzh.com> wrote:
>
> Alissa:
>
> Just a little input you may not know.  My background is 15 years
> (1995-2010)  developing a routing/switching platform (denoted as GateD)
> which was sold to over 200 companies.   We developed XML and a binary XML
> based product that configured this product.  It could do 100K configuration
> lines and reboot in less than a second on most hardware.  We also provide
> status messages in secure streams and non-secure streams.I sold early
> version of this code to companies that Alia has worked for  - so she has
> personal viewed the code.   At the height of our work, our development team
> ran to 50 people which I directed (First as VP of Engineering, and then as
> CTO). It is due to this level of experience that Alia selected me for the
> co-chair.   Russ White has understood Cisco's process, and has also
> directed software development teams for routing.
>
> In order to freshen my direct experience with I2RS on open source work, I
> am working on a publically available work in Quagga based on the confD
> product suggested by Cisco.
>
> In contrast, Juergen is a university professor who has worked on
> proto-types.   He is not working on an implementation.   I hope he will.
>
> I hope you will consider this background in my response to your comments
> below.
>
>

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Andy Bierman]

Hi,

I did not think Juergen's comment was about running code.

In order for a data node to get the "ok-for-nonsecure-transports" approval
in an IETF module, the IETF needs to agree that there could never possibly
be
any deployment that would not want to allow exposure of the data.
Not now. Not 20 years from now.

I can see a vendor making that decision for their own proprietary modules,
but it seems less likely for standard modules.

Seems like the operator is going to have to configure what is allowed
for nonsecure transport anyway, so just let them decide.
I don't really object to the extension or the requirement.
It doesn't help much but it doesn't hurt much either.


Andy



On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares  wrote:

> Alissa:
>
> Just a little input you may not know.  My background is 15 years
> (1995-2010)  developing a routing/switching platform (denoted as GateD)
> which was sold to over 200 companies.   We developed XML and a binary XML
> based product that configured this product.  It could do 100K configuration
> lines and reboot in less than a second on most hardware.  We also provide
> status messages in secure streams and non-secure streams.I sold early
> version of this code to companies that Alia has worked for  - so she has
> personal viewed the code.   At the height of our work, our development team
> ran to 50 people which I directed (First as VP of Engineering, and then as
> CTO). It is due to this level of experience that Alia selected me for the
> co-chair.   Russ White has understood Cisco's process, and has also
> directed software development teams for routing.
>
> In order to freshen my direct experience with I2RS on open source work, I
> am working on a publically available work in Quagga based on the confD
> product suggested by Cisco.
>
> In contrast, Juergen is a university professor who has worked on
> proto-types.   He is not working on an implementation.   I hope he will.
>
> I hope you will consider this background in my response to your comments
> below.
>
> Sue
>
>
> -Original Message-
> From: Alissa Cooper [mailto:ali...@cooperw.in]
> Sent: Thursday, August 18, 2016 12:54 PM
> To: Joel Halpern
> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; jh...@pfrc.org;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
> Jumping in here because this is relevant to my DISCUSS, hope nobody minds
> (but if you do, I can go back to the other thread).
>
> >> On Aug 18, 2016, at 10:30 AM, Joel Halpern 
> wrote:
> >>
> >> Let me try a different take approach to this particular question.
> >>
> >> Let me start by putting aside the question of where things are marked,
> and come back to that afterwards.
> >>
> >> There are a number of cases that I2RS has been asked to cover of high
> rate telemetry data.  This may be BGP update information, it may be
> frequent information about line card activity.  There are other cases, some
> of which have been documented.
> >>
> >> While not completely insensitive, the operators have made clear that
> they see protecting this data as unnecessary.  While I would hope over time
> to move to a domain where all of it is protect, that is not trivial.  As
> the I2RS Architecture points out, it is expected that what we describe as a
> single I2RS >communication between a client and agent is actually
> associated with multiple channels of communication.
> >>
> >> Now, if you want to say that the I2RS protocol requirements cannot
> allow for unprotected channels, I guess we have disconnect between the IESG
> and the WG.
> >>
> >> If we say that we can allow for unprotected channels, we then get to
> the question of which data can be sent over such channels.  While
> architecturally I agree with Juergen that the model is a bad place to
> specify it, the obverse is also true.  Not having some limits on what can
> be sent unprotected >causes concern about insufficient protection.  If I
> recall correctly, earlier security reviews called us to task for being too
> broad in what we allowed.
> >>
> >> So, if the IESG wants us to just allow it anywhere, because the model
> is an awkward place to define the limitation, I can live with that.  What I
> can't live with is being told both that the model is a bad place to define
> it and that there must be restrictions on what is sent unprotected,
> >> without any proposal on how we are to move forward.
>
> > Thank you Joel, this explanation helps me a lot. I think there is a
> disconnect about how the restrictions are expressed. From reading the email
> traffic about this document, it strikes me that trying to express the
> restrictions programmatically doesn’t make much sense in this case.
> > I agree with Juergen that it will be challenging to make a 

Re: [i2rs] [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input

[Andy Bierman]

Hi Lou,

I would say 2 steps ahead.
Step 1 seems to be to reconfirm the meeting room consensus from Yokohama
(model-based vs. protocol-based)

Step 2 is usually picking a starting point for a solution draft.

Step 3 is when people can start detailed solution reviews.

IMO [4] is a good starting point but there are many open issues that need
to be resolved,
possibly addressed in the other drafts.


Andy


On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger  wrote:

> Sue,
>
> I think you're looking a step beyond the scope of decision we're
> considering now. This is a fine thing, and certainly the right thing to
> be thinking about from the I2RS (or any other WG working on YANG models
> that is considering operational state for that matter) perspective.
>
> The decision at hand is to choose between directions A and B.  I think
> you are saying you that you like direction B but that the details aren't
> sufficient for your (WG's) needs.  Is this correct?
>
> If so, then I think you're point is that [4] and [5] need work.  We
> agree with this statement and we believe consistent with the statement in
> B:
>
> -- and that the WG needs to
>formalize an opstate solution based on the approach
>discussed in [4] and [5].
>
> So, once the WG closes on direction B (before Berlin), the WG can then
> start discussing details of the WG's version of [4] and [5] -- and
> issues on ephemeral support makes sense to discuss then if they still
> haven't been addressed.   Of course discussion on the individual drafts
> don't need to wait for the decision on basic direction.
>
> Make sense?
>
> Lou
>
> On 6/8/2016 12:10 PM, Susan Hares wrote:
> > Lou:
> >
> > Thank you for your work on the two options.  I'd like to comment on the
> > following statement in your message statement, and reference a few
> things in
> > [4] and [5] regarding ephemeral state:
> >
> > You state:
> > "  2) Model OpState using a revised logical datastore definition
> >as introduced in [4] and also covered in [5]. There is
> >also a variant of this that we believe doesn't significantly
> >impact this choice.
> >With this approach, model definitions need no explicit
> >changes to support applied configuration."
> >
> > In [4], the author states:
> >
> >"o  The model foresees ephemeral datastores that are by definition not
> >   part of the persistent configuration of a device.  These ephemeral
> >   datastores are considered to interact with the rest of the system
> >   like any other control-plane mechanisms (e.g., routing protocols,
> >   discovery protocols).  [XXX Note that this is different from what
> >   is described in some of the I2RS documents.  XXX]"
> >
> > In [5], the author states:
> >
> > "5.5.  Ephemeral Configuration Datastore (Optional)
> >This document does not intend to formally define an Ephemeral
> >Configuration Datastore.  In particular, it must be noted that the
> >ephemeral configuration datastore described here does not match that
> >described in version -09 of draft-ietf-i2rs-ephemeral-state
> >[I-D.ietf-i2rs-ephemeral-state].  Instead, it describes conceptually
> >how such a datastore (restricted to configuration only) might fit
> >into a conceptual refined datastore model."
> >
> > Therefore, the result of I2RS WG spending 2 years writing requirements
> for
> > the ephemeral data store that both option 2 documents "do not  match" the
> > I2RS ephemeral requirements set.  [4] lumps ephemeral with operational
> > state.  [5] provides an ephemeral architecture closer to I2RS ephemeral
> > requirements, but does not understand that
> draft-ietf-i2rs-ephemeral-state
> > is a requirements document.Your statement " With this approach, model
> > definitions need no explicit changes to support applied configuration"
> > cannot be true if you consider the I2RS data models (RIB, topology).
> >
> > How is option (2) a reasonable design for ephemeral state?  I have spent
> the
> > last week answering questions to Juergen [4] on the I2RS ephemeral state.
> > After our discussion, he did not have any specific suggestions to change
> > these requirements
> > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html).
> >
> > Can I have an option 2b that considers ephemeral state based on the
> > requirements listed by I2RS?
> >
> >  Sue Hares
> >  I2RS WG-chair
> >
> > -Original Message-
> > From: Rtg-yang-coord [mailto:rtg-yang-coord-boun...@ietf.org] On Behalf
> Of
> > Lou Berger
> > Sent: Wednesday, June 08, 2016 9:06 AM
> > To: rtg-yang-co...@ietf.org
> > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:
> > update and request for WG input
> >
> > FYI this decision is likely to have some impact on models under
> development,
> > including in the routing area. Comments on the message itself should go
> to
> > netmod.
> >
> > Lou
> >
> >
> > --- Forwarded message ---
> > From: 

Re: [i2rs] YANG validation and opstate

[Andy Bierman]

On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:

> When we started on the I2RS work, the explicit request from the operators
> was to make this as simple as practical and as efficient as practical.
>
> In regard to constraints on what they could do, the specific request was
> "let us shoot ourselves in the foot."  That is, if some change will break
> the network, so be it.  it is the operators problem.  If the change only
> causes the box to reboot, that is less dangerous.  So it seems to fall
> within "let me shoot my foot."
>
> I expect that there are some forms of validation that need to take place
> just to attempt to apply the RPC.  But everything beyond that was requested
> to be not performed.  Whether we can actually achieve that is a different
> question.
> It does strike me that we can also go back and ask the operators again
> what they meant, if you think it is likely we misunderstood.
>
>
In my example "when IPv4" is ignored so IPv6 parameters are
accepted as valid.

Does this mean the server faithfully applies the wrong parameters that
make no sense whatsoever?  Probably not.  It means the client developer
and operator have no idea what a server implementation is SUPPOSED to
accept as a valid edit.  (Which diminishes the standards value of I2RS)

My original point was that extra flags for I2RS like "I ignore all leafrefs"
are worthless. It is better to declare that validation is not part of
the ephemeral datastore.  It is an implementation detail whether accepted
data in that datastore  ever gets used.


Yours,
> Joel
>

Andy


>
> On 6/6/16 8:26 PM, Andy Bierman wrote:
>
>> Hi,
>>
>> I am still a little confused on the intent of the partial YANG validation.
>> It seems trivial to adapt the NETCONF or RESTCONF validation points to
>> I2RS.
>> The only difference is that I2RS data can have constraints pointing at
>> config=false
>> nodes, so this is more complicated and expensive to implement than NETCONF
>> or RESTCONF.
>>
>> The argument for partial validation I have heard is "We only support 1
>> client and
>> we know the client already checks the data, so we know the data is valid."
>> This is not arguing that there will be invalid data in the datastore.
>> It is arguing
>> that the client can be trusted to be correct and bug-free so why bother
>> spending
>> server resources duplicating the validation.
>>
>> Typically in NM standards we assume more than 1 client is allowed in the
>> design
>> and a client cannot be trusted.  A client could be malicious or buggy.
>> Either way, if the server crashes or allows a security breach
>> it's still the server vendor's fault.
>>
>> I2RS seems like an implementation detail (not a standard) if vendors plan
>> on
>> writing both client and server code and not intending to support
>> any 3rd party implementations.
>>
>>
>> Andy
>>
>>
>>
>> On Mon, Jun 6, 2016 at 4:25 PM, Susan Hares <sha...@ndzh.com
>> <mailto:sha...@ndzh.com>> wrote:
>>
>> Andy: 
>>
>> __ __
>>
>> I’m not sure the context you are referring to as “I2RS agent pick
>> which Yang statements they will implement”.  
>>
>> __ __
>>
>> From the context, I guess you are investigating Ephemeral
>> Configuration State.  If “the server MAY do YANG validation
>>
>> on the ephemeral datastore”, and then check it in operational state
>> – this clearly works.  However, I’m struggling to fit the normal
>> Ephemeral Configuration State validation into section 8.3 of
>> RFC6020bis.   There are three steps in constraint enforcement
>> (section 8.3 of RFC6020bis).  
>>
>>o  during parsing of RPC payloads - 
>>
>>o  during processing of the  operation
>>
>>o  during validation
>>
>> __ __
>>
>> Currently section 8.3.3 says: 
>>
>> __ __
>>
>> “8.3.3.  Validation
>>
>> __ __
>>
>>When datastore processing is complete, the final contents MUST
>> obey  all validation constraints.  This validation processing is
>> performed  at differing times according to the datastore.   
>>
>> __ __
>>
>> If the datastore is "running" or "startup",   these constraints MUST
>> be enforced at the end of the  or 
>> operation.  If the datastore is "candidate", the c

[i2rs] YANG validation and opstate

[Andy Bierman]

Hi,

I don't really agree with idea that I2RS agents pick which
YANG statements they will implement, but I think there is
a way to handle this correctly in the datastore framework.

The proposed enumeration for server validation
capabilities (e.g., full, XPath, leafref) is not really needed.
This enum is too course-grained to be useful.

IMO it is better to say the server MAY do YANG validation
on the ephemeral datastore.  Whether or not the server uses
data from the ephemeral datastore is left as an implementation detail.
The server could use invalid input parameters or ignore them
or reject them in the first place.

The client needs to check operational state to know if/when the
ephemeral data was applied to the system.



Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

[Andy Bierman]

Hi,

IMO ephemeral data needs to specify all ancestor nodes.
This decouples ephemeral and local config.
e.g,  ephemeral "ipv4" MUST include ancestors /interfaces/interface/ipv4.
It MUST NOT borrow the "/interfaces/interface" nodes from local config.

I2RS config validation can refer to config=false nodes.
This handles the case where the installed ephemeral data depends
on operational state.


Andy


On Wed, Jun 1, 2016 at 1:58 PM, Susan Hares <sha...@ndzh.com> wrote:

> Andy
>
> See below.
>
>
>
> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
> ---- Original message 
> From: Andy Bierman <a...@yumaworks.com>
> Date: 6/1/2016 4:41 PM (GMT-05:00)
> To: Susan Hares <sha...@ndzh.com>
> Cc: i2rs@ietf.org, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>, Linda Dunbar <
> linda.dun...@huawei.com>, Benoit Claise <bcla...@cisco.com>, Jeffrey Haas
> <jh...@pfrc.org>, Alia Atlas <akat...@gmail.com>
> Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure ,
> not on how end point handle the "DataStore"?
>
>
>
> On Wed, Jun 1, 2016 at 1:32 PM, Susan Hares <sha...@ndzh.com> wrote:
>
>>
>> Ah.. Interesting  viewpoint on the word "overwrite". And I find nothing
>> wrong with your viewpoint.
>>
>> If i2rs only config does not resolve to installable state, how would you
>> handle it.  Is this a case where i2rs config value does not exist so local
>> config is used?  I am showing partial installation of i2rs rib model.
>>
>> If I can see how this works, maybe I can find a way to understand
>> juergen's model.
>>
>>
> Why would this work?
> You mean the I2RS agent incorrectly accepts an edit that cannot be
> installed
> because it is invalid, or there are insufficient resources?
>
> Sue:: valid config.  Route needs to resolve next hop to specific interface.
>
> This is the same as the "no-validate" case for I2RS.
> If there is a "when IPv4" clause that is ignored by the agent, such that
> the agent
> appears to accept "IPv4" fields in an "IPv6" entry, what happens?
> (IMO this is 1 reason the no-validate mode is so broken).
>
> Sue: not the same case. Not invalid config.  Just not resolve to interface
> to send packet out
>
> Does the hopelessly invalid data stay in the ephemeral datastore?
> Does the agent attempt to (incorrectly) apply the IPv4 parameters to an
> IPv6 entry
> or does the agent ignore the data (i.e., must be validating the data
> somehow
> if it knows to ignore it)
>
> Sue: not this case.  Ephemeral config has been validated like all yang
> validation.
>
> Sue
>>
>
>
> Andy
>
>
>>
>> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
>>  Original message 
>> From: Andy Bierman <a...@yumaworks.com>
>> Date: 6/1/2016 3:11 PM (GMT-05:00)
>> To: Susan Hares <sha...@ndzh.com>
>> Cc: Linda Dunbar <linda.dun...@huawei.com>, i2rs@ietf.org, Juergen
>> Schoenwaelder <j.schoenwael...@jacobs-university.de>, Alia Atlas <
>> akat...@gmail.com>, Benoit Claise <bcla...@cisco.com>, Jeffrey Haas <
>> jh...@pfrc.org>
>> Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure
>> , not on how end point handle the "DataStore"?
>>
>>
>>
>> On Wed, Jun 1, 2016 at 12:04 PM, Susan Hares <sha...@ndzh.com> wrote:
>>
>>> Andy
>>>
>>> We currently are specifying i2rs rib model which can overwrite the local
>>> config.Implementations experience will provide us with input on the
>>> protocols.
>>>
>>>
>> I don't view it that way.
>> The local config remains untouched throughout.
>> The higher priority ephemeral config value is used instead of the local
>> config value.
>> The operational state should reflect that ephemeral config is overriding
>> the local config.
>> The data model for the I2RS version does not have to be the local config
>> model.
>>
>>
>>
>>> Sue
>>>
>>>
>>>
>> Andy
>>
>>
>>>
>>> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
>>>  Original message 
>>> From: Linda Dunbar <linda.dun...@huawei.com>
>>> Date: 6/1/2016 12:34 PM (GMT-05:00)
>>> To: Andy Bierman <a...@yumaworks.com>
>>> Cc: i2rs@ietf.org, Juergen Schoenwaelder <
>>> j.schoenwael...@jacobs-university.de>, Alia Atlas &

Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

[Andy Bierman]

On Wed, Jun 1, 2016 at 1:32 PM, Susan Hares <sha...@ndzh.com> wrote:

>
> Ah.. Interesting  viewpoint on the word "overwrite". And I find nothing
> wrong with your viewpoint.
>
> If i2rs only config does not resolve to installable state, how would you
> handle it.  Is this a case where i2rs config value does not exist so local
> config is used?  I am showing partial installation of i2rs rib model.
>
> If I can see how this works, maybe I can find a way to understand
> juergen's model.
>
>
Why would this work?
You mean the I2RS agent incorrectly accepts an edit that cannot be installed
because it is invalid, or there are insufficient resources?

This is the same as the "no-validate" case for I2RS.
If there is a "when IPv4" clause that is ignored by the agent, such that
the agent
appears to accept "IPv4" fields in an "IPv6" entry, what happens?
(IMO this is 1 reason the no-validate mode is so broken).

Does the hopelessly invalid data stay in the ephemeral datastore?
Does the agent attempt to (incorrectly) apply the IPv4 parameters to an
IPv6 entry
or does the agent ignore the data (i.e., must be validating the data somehow
if it knows to ignore it)


Sue
>


Andy


>
> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
>  Original message 
> From: Andy Bierman <a...@yumaworks.com>
> Date: 6/1/2016 3:11 PM (GMT-05:00)
> To: Susan Hares <sha...@ndzh.com>
> Cc: Linda Dunbar <linda.dun...@huawei.com>, i2rs@ietf.org, Juergen
> Schoenwaelder <j.schoenwael...@jacobs-university.de>, Alia Atlas <
> akat...@gmail.com>, Benoit Claise <bcla...@cisco.com>, Jeffrey Haas <
> jh...@pfrc.org>
> Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure ,
> not on how end point handle the "DataStore"?
>
>
>
> On Wed, Jun 1, 2016 at 12:04 PM, Susan Hares <sha...@ndzh.com> wrote:
>
>> Andy
>>
>> We currently are specifying i2rs rib model which can overwrite the local
>> config.Implementations experience will provide us with input on the
>> protocols.
>>
>>
> I don't view it that way.
> The local config remains untouched throughout.
> The higher priority ephemeral config value is used instead of the local
> config value.
> The operational state should reflect that ephemeral config is overriding
> the local config.
> The data model for the I2RS version does not have to be the local config
> model.
>
>
>
>> Sue
>>
>>
>>
> Andy
>
>
>>
>> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
>>  Original message 
>> From: Linda Dunbar <linda.dun...@huawei.com>
>> Date: 6/1/2016 12:34 PM (GMT-05:00)
>> To: Andy Bierman <a...@yumaworks.com>
>> Cc: i2rs@ietf.org, Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de>, Alia Atlas <akat...@gmail.com>,
>> Benoit Claise <bcla...@cisco.com>, Jeffrey Haas <jh...@pfrc.org>, Susan
>> Hares <sha...@ndzh.com>
>> Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure
>> , not on how end point handle the "DataStore"?
>>
>> Andy,
>>
>>
>>
>> Agree with your suggested approach.
>>
>>
>>
>> Linda
>>
>>
>>
>> *From:* Andy Bierman [mailto:a...@yumaworks.com]
>> *Sent:* Tuesday, May 31, 2016 9:05 PM
>> *To:* Linda Dunbar
>> *Cc:* Jeffrey Haas; Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder;
>> Susan Hares; Alia Atlas
>> *Subject:* Re: Can I2RS focus on the "Over the Wire" data structure ,
>> not on how end point handle the "DataStore"?
>>
>>
>>
>> Hi,
>>
>>
>>
>> If your graphic advice means "the requirements are good enough, move on"
>>
>> then I agree.
>>
>>
>>
>> The datastore framework would be nice to have, but it is very close
>>
>> to the implementation details.  It is also attempting to be a superset of
>> all
>>
>> "accepted" implementation choices.
>>
>>
>>
>> By "on the wire" we usually mean a protocol specification.
>>
>> IMO, all that is needed (for editing) is a set of RESTCONF extensions.
>>
>> Some people want to describe the I2RS desired behavior wrt/ how it
>>
>> interacts with the local config. (and many more features...)
>>
>>
>>
>> Perhaps a good first step would be ephemeral data models that do not
>>
>> interact with the local config at all.  I2RS is the only proto

Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

[Andy Bierman]

On Wed, Jun 1, 2016 at 12:04 PM, Susan Hares <sha...@ndzh.com> wrote:

> Andy
>
> We currently are specifying i2rs rib model which can overwrite the local
> config.Implementations experience will provide us with input on the
> protocols.
>
>
I don't view it that way.
The local config remains untouched throughout.
The higher priority ephemeral config value is used instead of the local
config value.
The operational state should reflect that ephemeral config is overriding
the local config.
The data model for the I2RS version does not have to be the local config
model.



> Sue
>
>
>
Andy


>
> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
>  Original message 
> From: Linda Dunbar <linda.dun...@huawei.com>
> Date: 6/1/2016 12:34 PM (GMT-05:00)
> To: Andy Bierman <a...@yumaworks.com>
> Cc: i2rs@ietf.org, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de>, Alia Atlas <akat...@gmail.com>,
> Benoit Claise <bcla...@cisco.com>, Jeffrey Haas <jh...@pfrc.org>, Susan
> Hares <sha...@ndzh.com>
> Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure ,
> not on how end point handle the "DataStore"?
>
> Andy,
>
>
>
> Agree with your suggested approach.
>
>
>
> Linda
>
>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Tuesday, May 31, 2016 9:05 PM
> *To:* Linda Dunbar
> *Cc:* Jeffrey Haas; Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder;
> Susan Hares; Alia Atlas
> *Subject:* Re: Can I2RS focus on the "Over the Wire" data structure , not
> on how end point handle the "DataStore"?
>
>
>
> Hi,
>
>
>
> If your graphic advice means "the requirements are good enough, move on"
>
> then I agree.
>
>
>
> The datastore framework would be nice to have, but it is very close
>
> to the implementation details.  It is also attempting to be a superset of
> all
>
> "accepted" implementation choices.
>
>
>
> By "on the wire" we usually mean a protocol specification.
>
> IMO, all that is needed (for editing) is a set of RESTCONF extensions.
>
> Some people want to describe the I2RS desired behavior wrt/ how it
>
> interacts with the local config. (and many more features...)
>
>
>
> Perhaps a good first step would be ephemeral data models that do not
>
> interact with the local config at all.  I2RS is the only protocol of
> concern and the
>
> highest priority client.  I2RS just needs to support read/write/notify of
> ephemeral data.
>
> If this is not acceptable then be prepared to wait until all the framework
> stuff is settled
>
> and standardized.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
> On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <linda.dun...@huawei.com>
> wrote:
>
> IETF has been successful for past 20 years  in focusing on “Over the Wire”
> data structure.  It would be so much cleaner and straight forward if the
> YANG modules developed by I2RS  focusing on the “Over the Wire” data
> structure (and with NETMOD to focus on other aspects).
>
> The “I2RS ephemeral State” has the needed description for the desired
> behavior  of the data received over I2RS interface. If we follow the IETF
> practice,  it is good enough.
>
> Internal implementation framework is always controversial, hard to
> converge, usually ending up with a document (if completed) that is too big
> and difficult to read.
>
>
>
> Providing some source code to show the internal implementation would be
> much more useful as a reference implementation.
>
>
>
> The draft-schoenw-netmod-revised-datastores-00 is on the architectural
> framework for datastores as they are used by network management protocols.
> IMHO, how data stores are used are internal to the end points.
>
>
>
> [image:
> http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg]
> <http://www.google.com/url?sa=i=j==s=images==rja=8=0ahUKEwj50KWat4XNAhULxGMKHRhqDPQQjRwIBw=http%3A%2F%2Fwww.urbanblissmedia.com%2Fentrepreneur-rules-done-is-better-than-perfect%2F=AFQjCNGKEiPB2iHSqyBiF5609pd72H0L7w=1464822503865777>
>
>
>
> Linda Dunbar
>
>
>
> *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, May 31, 2016 4:09 PM
> *To:* Jeffrey Haas
> *Cc:* Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder; Susan Hares;
> Alia Atlas
> *Subject:* Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am -
> 11:00am - Topic: Ephemeral State Requirements
>
>
>
> Hi,
>
>
>
> I am not conv

Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

[Andy Bierman]

Hi,

If your graphic advice means "the requirements are good enough, move on"
then I agree.

The datastore framework would be nice to have, but it is very close
to the implementation details.  It is also attempting to be a superset of
all
"accepted" implementation choices.

By "on the wire" we usually mean a protocol specification.
IMO, all that is needed (for editing) is a set of RESTCONF extensions.
Some people want to describe the I2RS desired behavior wrt/ how it
interacts with the local config. (and many more features...)

Perhaps a good first step would be ephemeral data models that do not
interact with the local config at all.  I2RS is the only protocol of
concern and the
highest priority client.  I2RS just needs to support read/write/notify of
ephemeral data.
If this is not acceptable then be prepared to wait until all the framework
stuff is settled
and standardized.


Andy




On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <linda.dun...@huawei.com>
wrote:

> IETF has been successful for past 20 years  in focusing on “Over the Wire”
> data structure.  It would be so much cleaner and straight forward if the
> YANG modules developed by I2RS  focusing on the “Over the Wire” data
> structure (and with NETMOD to focus on other aspects).
>
> The “I2RS ephemeral State” has the needed description for the desired
> behavior  of the data received over I2RS interface. If we follow the IETF
> practice,  it is good enough.
>
> Internal implementation framework is always controversial, hard to
> converge, usually ending up with a document (if completed) that is too big
> and difficult to read.
>
>
>
> Providing some source code to show the internal implementation would be
> much more useful as a reference implementation.
>
>
>
> The draft-schoenw-netmod-revised-datastores-00 is on the architectural
> framework for datastores as they are used by network management protocols.
> IMHO, how data stores are used are internal to the end points.
>
>
>
> [image:
> http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg]
> <http://www.google.com/url?sa=i=j==s=images==rja=8=0ahUKEwj50KWat4XNAhULxGMKHRhqDPQQjRwIBw=http%3A%2F%2Fwww.urbanblissmedia.com%2Fentrepreneur-rules-done-is-better-than-perfect%2F=AFQjCNGKEiPB2iHSqyBiF5609pd72H0L7w=1464822503865777>
>
>
>
> Linda Dunbar
>
>
>
> *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, May 31, 2016 4:09 PM
> *To:* Jeffrey Haas
> *Cc:* Benoit Claise; i2rs@ietf.org; Juergen Schoenwaelder; Susan Hares;
> Alia Atlas
> *Subject:* Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am -
> 11:00am - Topic: Ephemeral State Requirements
>
>
>
> Hi,
>
>
>
> I am not convinced the IETF can be forced to function as if it were
>
> a dev-group in some corporation.  This is a volunteer organization so
>
> usually solution proposals come from people who have created a solution
>
> and they want the WG to standardize it.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <jh...@pfrc.org> wrote:
>
> Andy,
>
> On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> > At some point the WG needs to agree on normative text instead of
> iterating
> > on requirements forever.
>
> IMO, it would be in I2RS's best interests if netconf/netmod provided drafts
> in appropriately normative language covering I2RS requirements.  However,
> we've been in a pathological cycle of:
> "We don't understand, please give us requirements"
> "We don't understand your requirements"
> "You provided examples with your requirements that appear to be attempts to
> change our protocol - don't do that."
>
> The most recent revised-datastore draft would be a good place to document
> where netmod(/netconf) believes ephemeral datastores (if that's the
> instantiation) could live, and also how ephemeral configuration state could
> interact with candidate, startup and running configuration.
>
> yang-push covers much of our desired pub-sub behavior. (Yay!)
>
> Discussion is required for how to tag security considerations impacting
> transport into the yang model, in particular for notification.
>
> Proposals for secondary identity and priority are also needed.
>
> -- Jeff
>
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

[Andy Bierman]

Hi,

I am not convinced the IETF can be forced to function as if it were
a dev-group in some corporation.  This is a volunteer organization so
usually solution proposals come from people who have created a solution
and they want the WG to standardize it.


Andy


On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <jh...@pfrc.org> wrote:

> Andy,
>
> On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> > At some point the WG needs to agree on normative text instead of
> iterating
> > on requirements forever.
>
> IMO, it would be in I2RS's best interests if netconf/netmod provided drafts
> in appropriately normative language covering I2RS requirements.  However,
> we've been in a pathological cycle of:
> "We don't understand, please give us requirements"
> "We don't understand your requirements"
> "You provided examples with your requirements that appear to be attempts to
> change our protocol - don't do that."
>
> The most recent revised-datastore draft would be a good place to document
> where netmod(/netconf) believes ephemeral datastores (if that's the
> instantiation) could live, and also how ephemeral configuration state could
> interact with candidate, startup and running configuration.
>
> yang-push covers much of our desired pub-sub behavior. (Yay!)
>
> Discussion is required for how to tag security considerations impacting
> transport into the yang model, in particular for notification.
>
> Proposals for secondary identity and priority are also needed.
>
> -- Jeff
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

[Andy Bierman]

Hi,


I agree with your concerns.  The opstate design team should not be ignoring
ephemeral state
and the I2RS WG should not be ignoring the opstate work.  I prefer to see 1
RFC on datastores
that defines a coherent and cost-effective framework that works for years
to come.
New implementations should opt-in to using new datastores.  Old
implementations must
continue to work even if the new datastores are ignored.

Isn't all operational state ephemeral by definition?
Doesn't proper management of a system with ephemeral data require
just 1 view of operational data which reflects current system behavior?

At some point the WG needs to agree on normative text instead of iterating
on requirements forever.  Some of them will fall out as important vs.
irrelevant
if there is an actual protocol spec to review.  E.g. secondary ID cannot
be "may keep" and "SHOULD report".  Either the standard protocol has an
official use for secondary client ID or it doesn't.


Andy


On Tue, May 31, 2016 at 10:13 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, May 31, 2016 at 11:12:13AM -0400, Susan Hares wrote:
> > Juergen:
> >
> > Thank you for your quick response.  See my comments below.   I believe as
> > you said " I may be ignorant but we have to look at how things fit
> together"
> > - so I have provided more information.  I believe the I2RS model is
> > workable, and I look forward to your informed review of this information.
> >
> > Version -09 of Ephemeral-state is released to make it clear ephemeral
> state
> > has ephemeral configuration and ephemeral operational state.   Click
> below
> > for the draft:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> > Sent: Tuesday, May 31, 2016 10:26 AM
> > To: Susan Hares
> > Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Benoit Claise'; 'Alia Atlas'
> > Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am -
> 11:00am
> > - Topic: Ephemeral State Requirements
> >
> > On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote:
> > >> Juergen:
> > >>
> > >>
> > >>
> > >> Thank you for the second response.The questions were on version 8
> of
> > the
> > >> draft.  Jeff wanted to review version 8 before posting - so I delayed
> > >> posting of version 8 until this morning.I've answered your
> questions
> > >> based on version 08.
> > >>
> > >> I think you understood that the ephemeral datastores defined by i2RS
> > >> are not what you defined in
> draft-schoenw-netmod-revised-datastores-00:
> > >>
> > >>o  The model foresees ephemeral datastores that are by definition
> not
> > >>   part of the persistent configuration of a device.  These
> ephemeral
> > >>   datastores are considered to interact with the rest of the
> system
> > >>   like any other control-plane mechanisms (e.g., routing
> protocols,
> > >>   discovery protocols).  [XXX Note that this is different from
> what
> > >>   is described in some of the I2RS documents.  XXX]
> > >>
> > >> The difference is that I2RS defines ephemeral configuration and
> > >> ephemeral operational state.  You see this in all of the I2RS data
> > >> modules.  I have augmented your diagram with the proposed I2RS
> datastore.
> > >>
> > >>
> > >> ++
> > >> |  |  //  Subject to validation
> > >> | (ct, ro)   | //   e.g., missing resources or
> delays
> > >> ++   // Here I2RS ephemeral
> configuration
> > fits
> > >>   | //  so missing resources/delays
> can
> > be handled
> > >>   v
> > >> ++
> > >> |   |- here I2RS defines ephemeral
> > >> | (ct, ro)   |  configuration data store
> > >> ++
> > >>   | // e.g., autodiscovery of values
> > >>   v
> > >>   ++
> > >>   | |<-- control plane and
> > >>   | (ct + cf, ro)  |ephemeral datastores
> >
> > >> +--+
> > >>
> > >>
> > >> Your definitions ignored the WG requirements and the existing
> > discussions.
> > >> Is there a reason why?  I2RS follows the break between operational
> > >> state and configuration data store.
> > >
> >
> > >There needs to be _one_ architectural model.
> > > I may be ignorant but we have to look at how things fit together.
> > >What you are drawing is ignoring for instance the fact that 
> is
> > the subject of configuration
> > > validation while I2RS explicitly states that ephemeral is not part of
> > configuration validation.
> > >So your model is not a workable solution either.
> >
> > Not 

Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node transport security

[Andy Bierman]

On Thu, May 26, 2016 at 11:35 AM, Joel M. Halpern 
wrote:

> Hmmm.
> I tend to assume that the ability to support non-secure transport is at a
> device level.  That is, and I2RS Agent supports both, or it doesn't.
>
> If we want enforceable controls over which data can be sent over which
> channels, we are opening a very large additional can of worms.  No, the
> Module is not the right basis, since a module typically includes writeable,
> readable, and notification related information.
>
> The Node seems equally bad, since trying to guess at Module design team
> which nodes will be needed by which monitoring and telemetry operations, or
> will be provided by which kinds of devices, or will be used within vs
> across organizational boundaries, seems unknowable.
>
> Given that the I2RS approach is to let the operator use the tools in the
> way he wants, I think the only practical solution is to let him use the
> channels the way he wants.
>
>

I think I agree with you.
Take SNMP no-auth/no-priv as an example.
It is a deployment decision whether or not to allow that.
NETCONF and RESTCONF do not support non-secure transports
so I assume a new document standardizing new transports
would be needed.  The RFCs actually say the protocol MUST NOT
be used over a non-secure transport, so maybe a different protocol
has to be used for this purpose.

The NACM extensions make sense for subtree-level tagging.
These alter the default NACM behavior for the subtree.
The I2RS tag could be useful it there was agreement
the node was non-secure in every possible application and no
operator could ever disagree with this WG decision for any reason.
IMO that will never happen.

It is fairly easy in the server implementation to check whether the node
being sent on a non-secure stream is tagged as "nonsecure OK".
It is harder on readers and writers than tool makers.




> Yours,
> Joel
>

Andy


>
> On 5/26/16 2:16 PM, Susan Hares wrote:
>
>> Joel:
>> 
>> 
>>
>> Here's what [draft-ietf-i2rs-ephemeral-state-07.txt] says:
>>
>> SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a
>>secure transport and optionally MAY be able to transfer data over a
>>non-secure transport.  A secure transport MUST provide data
>>confidentiality, data integrity, and replay prevention.
>>
>>The default I2RS transport is a secure transport.
>>
>>A non-secure transport can be can be used for publishing telemetry
>>data or other operational state that was specifically indicated to
>>non-confidential in the data model in the Yang syntax.
>>
>>The configuration of ephemeral data in the I2RS Agent by the I2RS
>>client SHOULD be done over a secure transport.  It is anticipated
>>that the passing of most I2RS ephemeral state operational status
>>SHOULD be done over a secure transport.  As
>>[I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate
>>whether the transport exchanging the data between I2RS client and
>>I2RS agent is secure or insecure.  The default mode of transport is
>>secure so data models SHOULD clearly annotate what data nodes can be
>>passed over an insecure connection.
>> =
>>
>> Are you trying to suggest that the ability to do secure transports should
>> be
>> at the data model level? If so, does this text change work for you:
>>
>> Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that
>> nodes have the following properties: ephemeral, writable/not-writable and
>> status/configuration.  Yang MUST have a way to indicate
>> whether data models can be passed over secure or non-secure transport.
>> (If you desire examples, please see [I-D.hares-i2rs-protocol-strawman] for
>> potential yang syntax).
>>
>> Sue
>>
>> -Original Message-
>> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: Thursday, May 26, 2016 1:47 PM
>> To: Susan Hares; i2rs@ietf.org
>> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - per-node
>> transport security
>>
>> We could take the view that all nodes in a model being used by I2RS had to
>> have the potential to be ephemeral.  While that would be attractive for
>> consistency, it puts a massive burden on the routing system implemention.
>> So we agreed that ephemeral marking was on a per-node basis.  Yes, that
>> means that the model designer has to look at the usage.  Unfortunate, but
>> a
>> tradeoff.
>>
>> When it comes to securing the transfer, the situation is very different.
>>   Most importantly, the cost for supporting sending whatever the client
>> requests over an unsecure transport is small.  And trying to guess which
>> information will be needed by monitoring or telemetry seems like to end up
>> with "all".  Yes, there is a security risk with saying that telemetry
>> information may be send unencrypted.  But either wwe accept that or we
>> don't.  Trying to do node based marking does not seem to help the
>> situation,
>> and it 

Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification

[Andy Bierman]

On Thu, May 26, 2016 at 11:03 AM, Susan Hares  wrote:

> Joel:
>
> 
>
> This requirement is not about forking I2RS protocol off the
> NETCONF/RESTCONF
> stream.
>
> My requirement is to have a parameter in some NETCONF model (? Extension to
> draft-ietf-netconf-yang-library) that that indicates I2RS protocol version
> 1
> (with all its requirements) are supported (true/false).
>
> Otherwise, as a developer of an implementation - you must go to check all
> the different types of netconf.  It would seem to me that causing the
> implementation to check all of the specific NETCONF and model support would
> be much more work that indicating a I2RS protocol version support.   I
> think
> your mechanism is a lot more work for the I2RS client querying 1 variable.
>
>

The protocol identification was removed from the YANG library.
It was decided that each protocol would return the view of the library
that is supported in the protocol.  Only NETCONF and RESTCONF
were considered, but if I2RS uses these protocols then it is covered.
IMO there should be an optional capability for "ephemeral" that
indicates the I2RS extensions (to NETCONF or RESTCONF) are supported.
There really isn't a separate I2RS protocol (e.g., entry points are the
same)



> Sue
>
>
Andy


>
> -Original Message-
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: Thursday, May 26, 2016 1:42 PM
> To: Susan Hares; i2rs@ietf.org
> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
> identification
>
> First, I would prefer that we express our requirements, and let the
> protocol
> developers determine what is the best way of meeting those requirements.
> That is what I want when I receive requirements, so I try to meet that
> standard when I send them.
>
> As for a proposed mechanism, I would again separate pieces.  The I12RS
> Client needs to know if certain capabilities are present.  These include
> support for specific models (already present in netConf), support for
> specific additional capabilities such as Ephemeral handling, and support
> for
> the attribution mechanisms.  There may be others.  Depending upon how these
> needs are met, there are multiple ways to indicate these capabilities
> within
> the NetConf and YANG framework.
>
> Further, and part of the reason for my concerns, is that I would want to
> know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a future
> YANG 1.2 or 2.0.  Without having to change the I2RS "protocol"
> indication.
>
> If we were really in a situation where I2RS support was a fork from the
> base
> protocols, then a protocol version would be appropriate.  That situation
> would be extremely unfortunate.  I believe we are avoiding that.
>
> yours,
> Joel
>
> On 5/26/16 12:55 PM, Susan Hares wrote:
> > Joel:
> >
> > I2RS protocol as a re-use protocol is specifying a set of changes to
> > NETCONF or RESTCONF.  We have two ways it can be identified:
> >
> > 1) Implementations can "value" (I2RS protocol version) to query that
> > indicates the NETCONF implementation or the RESTCONF implementation
> > provides all the features requested by I2RS protocol requirements.
> >
> > 2) Implementations query the NETCONF implementation or the RESTCONF
> > implementation supports all the features required for the I2RS protocol.
> >
> > It seemed reasonable to me to specify that NETCONF or RESTCONF set-up
> > a value that implementations can query to indicate it supports I2RS
> > protocol requirements.
> >
> > Did you have a better way to do this?
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel Halpern
> > Sent: Wednesday, May 25, 2016 10:04 PM
> > To: i2rs@ietf.org
> > Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
> > identification
> >
> > Mostly, this looks very good.
> >
> > I find it odd and overspecified that the first requirement for netConf
> > and Restconf is described as indicating I2RS support via the protocol
> version.
> >
> > It seems unlikely that the protocol version is the right way to
> > represent this.  And it seems that the I2RS WG should specify the
> > need, not the mechanism used to represent it.
> >
> > Yours,
> > Joel
> >
> > On 5/25/16 9:39 PM, internet-dra...@ietf.org wrote:
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >> This draft is a work item of the Interface to the Routing System of
> >> the
> > IETF.
> >>
> >> Title   : I2RS Ephemeral State Requirements
> >> Authors : Jeff Haas
> >>   Susan Hares
> >>  Filename: draft-ietf-i2rs-ephemeral-state-07.txt
> >>  Pages   : 14
> >>  Date: 2016-05-25
> >>
> >> Abstract:
> >>This document covers requests to the NETMOD and NETCONF Working
> >>Groups for functionality to support the ephemeral state requirements
> >>to implement the I2RS 

Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --

[Andy Bierman]

On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote:
> > Juergen:
> >
> >
> >
> > Thank you for your comments on the ephemeral state.
> >
> >
> >
> > On Ephemeral-REQ-05, does this clarify the requirement:
> >
> >
> >
> > Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of
> > objects) that have the property of being ephemeral.  An object defined as
> > Yang module,
> >
> > schema tree, a schema node, submodule or components of a submodule
> (derived
> > types, groupings, data node, RPCs, actions, and notifications).
>
> I have no clue what the above sentence is trying to say. Please try to
> use YANG terminology.
>
> > Any ephemeral object must be able to be identified by a yang key word.
>
> Why does there have to be a YANG keyword?
>
>

This could be an extension and not a keyword, depending on how it is done.
The extension vs. keyword debate will not be rehashed here, but there is
an issue wrt/ how the data definition is interpreted by tools/protocols
that do not understand the extension and just ignore it.

Shared:

   list foo {
  i2rs:ephemeral true;
  
}

I2RS-only:

   i2rs:ephemeral {
  list foo {  ... }
   }



> > On Ephemeral-REQ-06, does this text restrict the definition to just
> > requirements:
> >
> >
> >
> > "Ephemeral-REQ-06:  Yang MUST have a way to
> >
> > indicate in a data model that nodes have the following
> >
> > properties: ephemeral, writable/not-writable, status/configuration,
> >
> > and secure/non-secure transport.
> >
> > (If you desire examples, please see draft-hares-i2rs-protocol-strawman
> for
> >
> > potential yang syntax).  "
>
> We do have config true/false this implies writable/not-writable. I
> find the idea strange that a data model defines secure/non-secure
> transport as a property of an data model definition since it usually
> depends on the deployment context whether it is acceptable to carry
> data over a non-secure transport.
>
>

This is a very expensive feature wrt/ standards resources.
First the WG has to agree that all the subtree data is OK to send in the
clear
under all circumstances. (Including augmenting nodes?)  Then this needs to
be
carefully reviewed by the SECDIR and IESG.  Both steps will require lots of
IETF time.

I agree that operators need to have the final say.
This extension is the opposite of the nacm:default-deny-all extension.
But it is designed to allow operators to configure access through NACM.
How does an operator override the extension?
And if the operator can override, why is an extension even needed?
If not, then what criteria is used to decide the data is universally
non-secure?


Andy




> > On Ephemeral-REQ-07,  NETCONF chairs asked for conceptual changes to
> NETCONF
> > and RESTCONF.  Does change to Ephemeral-REQ-07 requirement set work for
> you?
> > If it does, I will create a similar reduction for Ephemeral-REQ-08:
> >
> > -
> >
> > Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to
> required to
> > support the I2RS protocol are the following:
> >
> >  1) protocol version support for I2RS protocol modifications -  (e.g.
> I2RS
> > version 1);
>
> I do not understand what this is supposed to mean since NETCONF
> extensions usually are identified by a capability URN. So why is
> there a need for something else?
>
> > 2) support ephemeral model scope indication - which indicates whether a
> > module is ephemeral only, mixed config module (config with ephemeral),
> mixed
> > derived state (ephemeral and config),
>
> Not sure what this means.
>
> > 3) multiple message support - uses the I2RS "all or none"
> > (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF
> > "roll-back-on-error".
>
> So what is the requirement here?
>
> > 4) Support for the following  NETCONF protocol specifications:
> >
> >  NETCONF [RFC6241],
> >
> >  yang pub-sub push [draft-ietf-netconf-yang-push],
> >
> >  Yang module library [draft-ietf-netconf-yang-library],
> >
> >  call-home support [draft-ietf-netconf-call-home],
> >
> >  zero-touch support [draft-ietf-netconf-zero-touch], and
> >
> >  server model [draft-ietf-netconf-server-module]  with
>
> Why do you list this under changes to NETCONF?
>
> > 7) The ability to restrict insecure transports to specific portions of a
> > data model marked as valid to transfer via an insecure protocol,
>
> See above.
>
> > 8) ephemeral overwriting of ephemeral MUST be controlled by the following
> > two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1):
> >
> >* Policy Knob 1: ephemeral configuration overwrites local
> configuration
> > (normal value: true)
> >
> >*Policy Knob 2: update of local configuration value supersedes and
> > overwrites the ephemeral configuration value (normal value: false)
>
> And if I set both to true we run into a race?
>
> I am stopping here. I do 

Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1

[Andy Bierman]

On Mon, May 9, 2016 at 3:09 PM, Susan Hares <sha...@ndzh.com> wrote:

> Andy and Joel:
>
> These are good points.
>
> What happens if the data model has some ephemeral sections and the I2RS
> agent is not supported by the routing system.  The data model would specify
> the ephemeral section, but there would be no support by i2rs.  Is the
> support of the ephemeral not a variable  condition to be indicated in Yang
> module library?
>
>
The server should have a deviations file for the parts it does not support.

   deviation /some/ephemeral/node {
  deviate delete {
 i2rs:ephemeral;
  }
   }


Sue
>


Andy



> Sent via the Samsung Galaxy Note5, an AT 4G LTE smartphone
> ---- Original message 
> From: Andy Bierman <a...@yumaworks.com>
> Date: 5/7/2016 12:53 PM (GMT-05:00)
> To: "Joel M. Halpern" <j...@joelhalpern.com>
> Cc: i2rs@ietf.org, Netconf <netc...@ietf.org>, Susan Hares <
> sha...@ndzh.com>
> Subject: Re: [i2rs] FW: New Version Notification for
> draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1
>
>
>
> On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern <j...@joelhalpern.com>
> wrote:
>
>> Reading the latest revision, in section 3.1.1, the text in bullet 5 says
>> that the data model indicates which portions are ephemeral.  That makes
>> sense to me.
>>
>> Then bullet 6 says that the management protocol needs to signal (in its
>> yang library) which parts are ephemeral.
>>
>> Why the second requirement?  If the data model is supported, and the data
>> model states that certain items are ephemeral, what would it mean if the
>> signaling did not also say that.  Conversely, what would it mean if the
>> signaling said something was ephemeral that the model does not define as
>> ephemeral?
>>
>> It may be that I am misreading bullet 6.  Please explain.
>>
>>
>
> I think you are correct that the YANG library does not need any changes
> to identify ephemeral data.  Only the variable components of
> YANG conformance are contained in the library.
>
>
> Thank you,
>> Joel
>>
>>
>
> Andy
>
>
>> ___
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt

[Andy Bierman]

Hi,

I have not have enough time to work on this draft yet, but here are my
initial concerns.
I won't comment on the details yet.

1) datastores

There is an opstate design team working on everything except ephemeral.
We need 1 RPC defining the datastore framework and each specific datastore
(known at this time).
The I2RS protocol should not be that document.

2) requirements

There should not be any duplication of requirements.
There should just be normative text defining the protocol, and
non-normative examples.

3) YANG validation

As stated in BA, I am strongly against protocol documents redefining how
YANG works
for their spot solution.  The YANG designer and operator want the data
models to be as
protocol-independent as possible.



Andy


On Thu, May 5, 2016 at 11:13 PM, Susan Hares <sha...@ndzh.com> wrote:

> 
> This version of the protocol strawman is the result of all the suggestions
> from the I2RS meeting and inputs from other reviews.
> Please let us know if you have additional reviews.
>
> Sue, Amit, and Andy
>
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Friday, May 06, 2016 2:11 AM
> To: Amit Daas; amit.d...@ericsson.com; Andy Bierman; Susan Hares
> Subject: New Version Notification for
> draft-hares-i2rs-protocol-strawman-02.txt
>
>
> A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt
> has been successfully submitted by Susan Hares and posted to the IETF
> repository.
>
> Name:   draft-hares-i2rs-protocol-strawman
> Revision:   02
> Title:  I2RS protocol strawman
> Document date:  2016-05-05
> Group:  Individual Submission
> Pages:  52
> URL:
> https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/
> Htmlized:
> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02
>
> Abstract:
>This strawman proposal for the I2RS protocol supports I2RS
>requirements for ephemeral data store, management data flows, and
>protocol security.  It proposes additions to the NETCONF, RESTCONF,
>and YANG for these requirements.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Comments on last-write-wins (strawman)

[Andy Bierman]

On Tue, Apr 5, 2016 at 11:39 AM, Joe Clarke  wrote:

> I wanted to follow up to my comments from the meeting and to the strawman
> I-D.  The example shown in the meeting where ephemeral config overlays the
> running config in a single pane of glass makes a lot of sense.  However,
> what happens when the next write isn't from another I2RS Client, but
> instead a "normal" NETCONF client?
>
> In that case, the last-write-wins rule takes effect, and the pane of glass
> holding the ephemeral config "shatters" leaving the running config as the
> derived state.  I realize this is the default, but I definitely see use
> cases where I would not want the running config to win if it's the last
> write.
>
> As such, I'd like it to be mandatory that implementations include both the
> last-write-wins and the ephemeral wins options.  What I see in the default
> case is that I may change the running config, which triggers an update to
> the I2RS Client holding the current ephemeral config, that Client then
> re-makes its change to overlay running, and now I have state churn that I
> may not want.
>
>
I am confused by last-write wins, especially since all this stuff about
client
priority is intended to provide first-one-wins to prevent flapping.
Also, the static intended config (running datastore) is validated and
managed
independently of the I2RS ephemeral data. NETCONF clients can update
/foo all day but it has no affect whatsoever on the applied /foo config
because I2RS is always higher priority.

I think the I2RS client has to delete ephemeral /foo in order for
the static /foo to be used by the server.



Joe
>
>
Andy


> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

[Andy Bierman]

On Thu, Mar 31, 2016 at 1:16 PM, Steve Braaten (sbraaten) <
sbraa...@cisco.com> wrote:

> Ephemeral = “short-lived” or “changes frequently”
>
>
>
> There is nothing to stop an implementation from storing the latest
> “ephemeral” state in a “persistent” way such that it returns to that state
> (the last known state) if it restarts for any reason (planned or
> un-planned).
>
>
>
> My humble opinion.
>

There is little (or no) difference between a NETCONF server that
boots and gets its startup config from a configuration server,
and an I2RS agent that boots and gets its ephemeral state from an I2RS
client.

In NETCONF, NV-storage is mostly an implementation detail.
In I2RS, the architecture says its data MUST NOT persist across a reboot.
(No explanation why interoperability is harmed if an agent persisted its
I2RS data).



>
>
> Steve
>
>
>

Andy


>
>
> *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, March 31, 2016 1:09 PM
> *To:* Dean Bogdanovic ; Susan Hares 
> *Cc:* Joel Halpern Direct ; ops-...@ietf.org;
> i2rs@ietf.org; BRUNGARD, DEBORAH A ; Gunter Van De Velde <
> guntervandeveld...@icloud.com>
> *Subject:* Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Is “ephemeral” same as “volatile” (whose opposite state is
> ”non-volatile”)?
>
>
>
> Is “non- ephemeral”  same as “persistent”  or “ non-volatile”?
>
> Linda
>
>
>
> *From:* OPS-DIR [mailto:ops-dir-boun...@ietf.org
> ] *On Behalf Of *Dean Bogdanovic
> *Sent:* Friday, March 25, 2016 2:39 PM
> *To:* Susan Hares
> *Cc:* Joel Halpern Direct; ops-...@ietf.org; BRUNGARD, DEBORAH A; Gunter
> Van De Velde; i2rs@ietf.org
> *Subject:* Re: [OPS-DIR] [i2rs] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Sue,
>
>
>
> IMO, ephemeral has two meaning in i2rs architecture
>
>
>
> 1. it doesn’t survive reboot
>
> 2. you can’t roll back to a previous ephemeral state
>
>
>
> Dean
>
>
>
> On Mar 25, 2016, at 10:01 AM, Susan Hares  wrote:
>
>
>
> Deborah:
>
>
>
> Section 2 is exactly the place I would put the definition of ephemeral.
>
>
>
> Sue
>
>
>
> *From:* BRUNGARD, DEBORAH A [mailto:db3...@att.com ]
> *Sent:* Friday, March 25, 2016 9:50 AM
> *To:* Susan Hares; 'Fred Baker (fred)'; 'Gunter Van De Velde'
> *Cc:* i2rs@ietf.org; ops-...@ietf.org; 'Joel Halpern Direct'
> *Subject:* RE: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Hi all,
>
>
>
> As Alia is a co-author, I was assigned as the responsible AD for this
> document. The document is not with the RFC Editor – it’s been approved by
> the IESG with a revised ID needed to address comments raised by the IESG.
> And so the current discussion.
>
>
>
> I had also raised the concern on needing more clarity on the definition of
> ephemeral during my AD review. The authors added some information. That
> clearly was not enough. As the term is used multiple times in the document
> and is the basis for another draft on requirements
> (draft-ietf-i2rs-ephemeral-state) which refers extensively to the
> architecture document, I agree the authors need to add more definition.
> Fred has a good suggestion – the term should be visible in a glossary
> section early in the document. It’s not currently included in Section 2’s
> Terminology – Sue, how about adding it to that section?
>
>
>
> I think the authors know what is needed and thank everyone for the
> discussion and their time reviewing.
>
>
>
> Thanks,
>
> Deborah
>
>
>
>
>
>
>
> *From:* i2rs [mailto:i2rs-boun...@ietf.org ] *On
> Behalf Of *Susan Hares
> *Sent:* Friday, March 25, 2016 9:18 AM
> *To:* 'Fred Baker (fred)' ; 'Gunter Van De Velde' <
> guntervandeveld...@icloud.com>
> *Cc:* i2rs@ietf.org; ops-...@ietf.org; 'Joel Halpern Direct' <
> jmh.dir...@joelhalpern.com>
> *Subject:* Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word -
> (3/24 to 4/3) Call for opinion
>
>
>
> Fred:
>
>
>
> Thank you for the review, and your comments here.  I wished I’d asked
> about the word ephemeral earlier.
>
>
>
> Sue
>
>
>
> *From:* Fred Baker (fred) [mailto:f...@cisco.com ]
> *Sent:* Thursday, March 24, 2016 2:59 PM
> *To:* Gunter Van De Velde
> *Cc:* Susan Hares; i2rs@ietf.org; ops-...@ietf.org; Joel Halpern Direct
> *Subject:* Re: [OPS-DIR] Ephemeral - Should we use another word - (3/24
> to 4/3) Call for opinion
>
>
>
> My comment was a review comment, that the word was being used in a way
> that wasn't consistent with its dictionary definition (something with a
> short lifetime, quite irrespective of birth/death processes) or common
> usage (at least in my context). At this point, the draft has been sent to
> the RFC Editor, so to my mind this discussion is mostly moot. If in your
> other drafts you 

Re: [i2rs] [OPS-DIR] Ephemeral - Should we use another word - (3/24 to 4/3) Call for opinion

[Andy Bierman]

On Thu, Mar 24, 2016 at 11:59 AM, Fred Baker (fred)  wrote:

> My comment was a review comment, that the word was being used in a way
> that wasn't consistent with its dictionary definition (something with a
> short lifetime, quite irrespective of birth/death processes) or common
> usage (at least in my context). At this point, the draft has been sent to
> the RFC Editor, so to my mind this discussion is mostly moot. If in your
> other drafts you are pointing people to a glossary in the architecture
> document (which I imagine you already are) and the architecture document
> defines the term as you are using it, you have probably done enough.
>
>

I never liked this term in I2RS, mostly because I keep misspelling it ;-)

The thing about the ephemeral datastore that is interesting is that it
overrides the local running datastore. But I am not suggesting a name change
at this late date.



Andy


On Mar 24, 2016, at 11:07 AM, Gunter Van De Velde <
> guntervandeveld...@icloud.com> wrote:
>
> I am ok nowadays with using the terminology “Ephemeral”, although for a
> non-natve speaker it is non-trivial exotic word, particular if the intended
> usage doesn’t 100% reflect the Webster dictionary intended meaning.
>
> It is only about a year ago i started reading up on i2rs and discovered
> this particular terminology, and at the time a google search on this
> terminology was not very conclusive and resulted to some confusion.
> I understand very well the confusion at play here from non-native english
> speaker perspective.
>
> Adding text to explain the context in which the term Ephemeral is
> useful/advised. fwiw now that i am used to seeing ‘Ephemeral' as
> non-permanent config across reboot, i’m adapted its intended purpose…
>
> Is the goal to explain the intended meaning in each draft/rfc mentioning
> it?
>
> Be well,
> G/
>
> On 24 Mar 2016, at 18:02, Susan Hares  wrote:
>
> Hi all:
>
> 
> The draft-ietf-i2rs-architecture document has been approved as an RFC.  In
> the review, the OPS-DIR review indicated that “ephemeral” meant more than
> “does not survive a reboot”. They have asked the I2RS working group if
> replacing “ephemeral” with non-persistent (across power on/off or reboot
> cycles) would be a better choice.
>
> What do you think – leave at it at “ephemeral” or change to
> “non-persistent (across power on/off or reboot cycles) ? We will have a 1
> week call on
>
> This would mean every place that “ephemeral” is listed, the authors would
> replace with “non-persistent”.  In the first instance, we will indicate
> “non-persistent (across power on/off or reboot cycles).
>
> 
>
> As the author, I think we are better to define ephemeral at the beginning
> as “non-persistent (across power on /off or reboot).  Changing the
> definition at this point, I suspect will simply confuse people.
>
> Sue Hares
>
> ___
> OPS-DIR mailing list
> ops-...@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
> ___
> OPS-DIR mailing list
> ops-...@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Mon, Nov 30, 2015 at 1:26 PM, Joel M. Halpern <j...@joelhalpern.com>
wrote:

> I agree Andy.  We have our choice of poison.  We can perform full
> validation, which is likely to be slow, but very useful.  Or we can omit
> validation, which introduces risks.  I don't know if I would call those
> security risks in general, although one can probably get some security
> risks out of validation failures.  (We do still assume that permissions are
> checked.)
>
> The conclusion after discussion last time around, and particularly the
> request from the operators who were in the room at the time, was that the
> operators were happy with a situation where they could gain significant
> performance at the risk of shooting themselves in the foot.
>
>

That's fine with me.
The agent developer will be under pressure not to let the router segfault
just to be a little faster (as always).  A buffer overrun is still a problem
whether a YANG constraint like "max-elements" exists or not .


Yours,
> Joel
>

Andy


>
> On 11/30/15 3:20 PM, Andy Bierman wrote:
>
>> Hi,
>>
>> I think it is fairly clear that the server will only be able to
>> detect a direct overlap.  In any case, the client that is getting
>> data removed needs to use pub/sub to be told what is going on.
>> The I2RS agent will not set up any pub/sub for any client.
>> The client must do this itself via  pub/sub configuration.
>> The agent will just return an error if the edit is not accepted.
>>
>> The current YANG design is clear: No client is allowed to cause
>> an edit that will leave the datastore invalid wrt/ YANG validation.
>> That means that a high priority client WILL LOSE if it attempts
>> to overwrite partial data in a way that breaks validation.
>> (This is not what the I2RS arch says to do).  A "solution" might be
>> to ignore all YANG validation in the ephemeral datastore.
>> Full YANG validation will be slow and even more complicated
>> than plain NETCONF. No validation will be a huge security hole.
>>
>>
>>
>> Andy
>>
>>
>>
>>
>> On Mon, Nov 30, 2015 at 11:30 AM, Joel M. Halpern <j...@joelhalpern.com
>> <mailto:j...@joelhalpern.com>> wrote:
>>
>> I am not understanding your comment.
>> As I understand it, Andy was asking about indirect collisions or
>> side effects, where modification of item A by entity B (either an
>> over-write or just a modification of something that was in base
>> config) make the modification C that was done by entity D
>> incorrect.  We had discussed that, and agreed that as a general
>> matter, such indirect problem detection was not something we want
>> (wanted) to address.
>> There are some cases that are represented by YANG constraints.  I
>> don't think our decision on this reflects an opinion on what and
>> which YANG constraints should be enforced by I2RS.  The issue is
>> generally about side effects that are not anticipated by model
>> designers.
>>
>> The assumption ew made was that at least the application designer
>> had a hope of anticipating them, and therefore the client could
>> monitor objects when there is a state dependency.  (If no one
>> realizes there is a dependence, things will break.  I don't see a
>> way around that.)
>>
>> Yours,
>> Joel
>>
>> On 11/30/15 2:23 PM, Susan Hares wrote:
>>
>> Joel and Andy:
>>
>> For the first version of the I2RS protocol, the WG did agree
>> that the
>> I2RS agent is required to detect and report on collisions.
>> However,
>> Andy is asking a valid question on how to detect the linkage
>> within
>> models or between models.
>>
>> Andy's example is one of the group portions of a model (eg. An
>> I2RS RIB
>> route) or group portions between multiple models (BGP policy +
>> BGP peer
>> or BGP Policy and BGP local route).
>>
>> I tried to present this concept at IETF 94 to start this
>> discussion.
>>
>> The solutions can be: a)  model structure or language in yang to
>> detect
>> grouping within a model, b) Yang library information to detect
>> modules,
>> or c) something else.
>>
>> Sue
>>
>> -Original Message-
>> From: i2rs [mailto:i2rs-boun...@ietf.org
>> <mailto:i2rs-boun...@ietf.org>] On Behalf Of Joel M. Halpern
>&

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Tue, Nov 24, 2015 at 8:53 AM, Joel M. Halpern <j...@joelhalpern.com>
wrote:

> That is indeed a good question.
>
> As I understand the WG agreement, some validations of changes are to be
> performed, but as little as possible.  So an agent can reject a change for
> validation, but we hoped to keep it as simple as possible.
> I am not sure that hop[e is achievable.
>
> One of the assumptions in making any ephemeral change is that if some
> other changes can affect what a client has done, it is the clients
> responsibility to subscribe to notifications about those other changes, and
> to undertake remedial actions if a problem is introduced.  So if /foo[19]
> and /bar[1] interact with /baz[7] (or /foo[42]) then it is the clients job
> to monitor /baz[7] (or /foo[42]).  The agent can't sort that out.
> As an example of an ugly case, suppose that /baz[7] has a value created by
> some other I2RS client.  The changes to /foo[19] and /bar[1] might depend
> upon that value.  When the other client removes its changes, the value
> reverts to the config value.  That reversion clearly must take place.  That
> can potential create problems for /foo[19] and /bar[1].  It seems to me
> that we have to leave it to the client to sort that out.
>
>

This is not much different from clients colliding in persistent config.
Operators can use NACM access control to protect one client or another.
As you have said, these high level collisions are operational errors.
Returning 'access-denied' is better than stomping on data and sorting it
out later.


> Yours,
> Joel
>

Andy


>
> On 11/24/15 11:28 AM, Andy Bierman wrote:
>
>>
>>
>> On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern <j...@joelhalpern.com
>> <mailto:j...@joelhalpern.com>> wrote:
>>
>> The agent is required to detect and report direct collisions.
>> It is not required or expected to detect indirect collisions, which
>> are the complex source of wedgies and other interesting behaviors.
>>
>>
>> OK, punting the problem is fair enough.
>>
>> What happens when the YANG validation for /foo[19] and /bar[1]
>> now fails because /foo[42] was changed?  Does the agent reject
>> the edit from the higher priority client?  Does I2RS ignore YANG
>> validation,
>> assuming the YANG authors really didn't mean what they wrote?
>>
>>
>> Yours,
>> Joel
>>
>>
>>
>> Andy
>>
>> PS: The WG discussed requiring a maintained connection between the
>> client and agent, and agreed not to do that.  Which means that no,
>> agents do not delete state just because clients have disappeared.
>>
>>
>> On 11/24/15 11:01 AM, Andy Bierman wrote:
>>
>>
>>
>> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern
>> <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
>> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>> wrote:
>>
>>  I believe that determining whether two independent and
>> internally
>>  consistent sets of changes can, in combination, produce a
>> wedgie or
>>  other failure is a research problem.
>>  As far as I know, the I2RS working group concluded that it
>> was a
>>  sufficiently hard problem that we did not expect the I2RS
>> agent to
>>  get involved in trying to detect, much less remediate, such
>>  cross-object inconsistencies.
>>
>>
>>
>> But the I2RS agent is responsible for identifying an edit
>> collision between
>> a new low-priority request and existing higher priority edits.
>> That sounds
>> involved to me.  So the agent cannot possibly solve this problem
>> yet it is responsible for precisely that in order to implement
>> client
>> priority.
>>
>> The agent can see that /foo[42] exists in the request and
>> /foo[42] exists
>> in the ephemeral datastore, and call that a collision.
>>
>> However, if /foo[1] or /bar[19] are also part of the "edit",
>> such that
>> simply replacing
>> /foo[42] will break things, then the agent will not know. It
>> will simply
>> overwrite
>> /foo[42] and leave /foo[1] and /bar[19] in the datastore.
>>
>> So is the low-priority client responsible for removing /foo[1]
>> and /bar[19]?
>> Seems the answer is n

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Tue, Nov 24, 2015 at 8:14 AM, Joel M. Halpern <j...@joelhalpern.com>
wrote:

> The agent is required to detect and report direct collisions.
> It is not required or expected to detect indirect collisions, which are
> the complex source of wedgies and other interesting behaviors.
>
>
OK, punting the problem is fair enough.

What happens when the YANG validation for /foo[19] and /bar[1]
now fails because /foo[42] was changed?  Does the agent reject
the edit from the higher priority client?  Does I2RS ignore YANG validation,
assuming the YANG authors really didn't mean what they wrote?


Yours,
> Joel
>
>

Andy



> PS: The WG discussed requiring a maintained connection between the client
> and agent, and agreed not to do that.  Which means that no, agents do not
> delete state just because clients have disappeared.
>
>
> On 11/24/15 11:01 AM, Andy Bierman wrote:
>
>>
>>
>> On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern <j...@joelhalpern.com
>> <mailto:j...@joelhalpern.com>> wrote:
>>
>> I believe that determining whether two independent and internally
>> consistent sets of changes can, in combination, produce a wedgie or
>> other failure is a research problem.
>> As far as I know, the I2RS working group concluded that it was a
>> sufficiently hard problem that we did not expect the I2RS agent to
>> get involved in trying to detect, much less remediate, such
>> cross-object inconsistencies.
>>
>>
>>
>> But the I2RS agent is responsible for identifying an edit collision
>> between
>> a new low-priority request and existing higher priority edits. That sounds
>> involved to me.  So the agent cannot possibly solve this problem
>> yet it is responsible for precisely that in order to implement client
>> priority.
>>
>> The agent can see that /foo[42] exists in the request and /foo[42] exists
>> in the ephemeral datastore, and call that a collision.
>>
>> However, if /foo[1] or /bar[19] are also part of the "edit", such that
>> simply replacing
>> /foo[42] will break things, then the agent will not know. It will simply
>> overwrite
>> /foo[42] and leave /foo[1] and /bar[19] in the datastore.
>>
>> So is the low-priority client responsible for removing /foo[1] and
>> /bar[19]?
>> Seems the answer is no. The client can go away and there are no cleanup
>> requirements mentioned in the architecture.
>>
>>
>>
>> Yours,
>> Joel
>>
>>
>>
>> Andy
>>
>>
>> On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote:
>>
>> Hi Russ,
>>
>> I’m trying to identify the differences between interactions with
>> routing protocols in I2RS and what is purely conflicts between
>> clients. Currently I see too many issues overlapping and I fear
>> that the trees are not letting us see the forest.
>>
>> So my take on routing protocols and wedgies might have been too
>> compact :-) Let me give it a second try: Stepping outside the
>> I2RS problem space, there is a lot of work that shows that the
>> origin for BGP-4 instability is that our beloved route-maps
>> create metrics that are not monotonically increasing or
>> decreasing and that makes the routing protocols meta-stable.
>> (BTW, I’m the first culprit when it comes to the use of them, I
>> have created more than one wedgie :-P ) Acknowledging that this
>> is a significant (and quite complex) problem for the Internet in
>> general, I feel that it should be treated somewhere else (GROW?).
>>
>> The perspective I would like to take here is:
>> - assume that we have two or more clients that produce perfectly
>> sound routing information (no wedgies there)
>> - assume they talk to the same agent
>> - now my questions
>>   1.- is there any way to detect whether the clients
>> produce contradicting/conflicting information?
>>   2.- is there any way to resolve these
>> contradictions/conflicts?
>>
>> BR, /PA
>> ---
>> Dr. Pedro A. Aranda Gutiérrez
>>
>> Technology Exploration -
>> Network Innovation & Virtualisation
>> email: pedroa d0t aranda At telefonica d0t com
>> Telefónica, Investigación y Desarrollo
>> C/ Zurbarán,12
>> 28010 Madrid, Spain
>>
>> Fragen sind nich

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Tue, Nov 24, 2015 at 7:36 AM, Joel M. Halpern <j...@joelhalpern.com>
wrote:

> I believe that determining whether two independent and internally
> consistent sets of changes can, in combination, produce a wedgie or other
> failure is a research problem.
> As far as I know, the I2RS working group concluded that it was a
> sufficiently hard problem that we did not expect the I2RS agent to get
> involved in trying to detect, much less remediate, such cross-object
> inconsistencies.
>
>

But the I2RS agent is responsible for identifying an edit collision between
a new low-priority request and existing higher priority edits. That sounds
involved to me.  So the agent cannot possibly solve this problem
yet it is responsible for precisely that in order to implement client
priority.

The agent can see that /foo[42] exists in the request and /foo[42] exists
in the ephemeral datastore, and call that a collision.

However, if /foo[1] or /bar[19] are also part of the "edit", such that
simply replacing
/foo[42] will break things, then the agent will not know. It will simply
overwrite
/foo[42] and leave /foo[1] and /bar[19] in the datastore.

So is the low-priority client responsible for removing /foo[1] and /bar[19]?
Seems the answer is no. The client can go away and there are no cleanup
requirements mentioned in the architecture.



Yours,
> Joel
>


Andy


>
> On 11/24/15 10:32 AM, PEDRO ANDRES ARANDA GUTIERREZ wrote:
>
>> Hi Russ,
>>
>> I’m trying to identify the differences between interactions with routing
>> protocols in I2RS and what is purely conflicts between clients. Currently I
>> see too many issues overlapping and I fear that the trees are not letting
>> us see the forest.
>>
>> So my take on routing protocols and wedgies might have been too compact
>> :-) Let me give it a second try: Stepping outside the I2RS problem space,
>> there is a lot of work that shows that the origin for BGP-4 instability is
>> that our beloved route-maps create metrics that are not monotonically
>> increasing or decreasing and that makes the routing protocols meta-stable.
>> (BTW, I’m the first culprit when it comes to the use of them, I have
>> created more than one wedgie :-P ) Acknowledging that this is a significant
>> (and quite complex) problem for the Internet in general, I feel that it
>> should be treated somewhere else (GROW?).
>>
>> The perspective I would like to take here is:
>> - assume that we have two or more clients that produce perfectly sound
>> routing information (no wedgies there)
>> - assume they talk to the same agent
>> - now my questions
>>  1.- is there any way to detect whether the clients produce
>> contradicting/conflicting information?
>>  2.- is there any way to resolve these contradictions/conflicts?
>>
>> BR, /PA
>> ---
>> Dr. Pedro A. Aranda Gutiérrez
>>
>> Technology Exploration -
>> Network Innovation & Virtualisation
>> email: pedroa d0t aranda At telefonica d0t com
>> Telefónica, Investigación y Desarrollo
>> C/ Zurbarán,12
>> 28010 Madrid, Spain
>>
>> Fragen sind nicht da, um beantwortet zu werden.
>> Fragen sind da, um gestellt zu werden.
>> Georg Kreisler
>>
>>
>>
>>
>>
>>
>>
>>
>> -Mensaje original-
>> De: Russ White <7ri...@gmail.com>
>> Fecha: lunes, 23 de noviembre de 2015, 14:06
>> Para: paag <pedroa.ara...@telefonica.com>, 'Jeffrey Haas' <jh...@pfrc.org
>> >
>> CC: "i2rs@ietf.org" <i2rs@ietf.org>, "'Joel M. Halpern'" <
>> j...@joelhalpern.com>, 'Andy Bierman' <a...@yumaworks.com>, Sue Hares <
>> sha...@ndzh.com>
>> Asunto: RE: [i2rs] Conversation on Priority and Panes
>>
>>
>>> Re the metric 'problem', just to be more precise in what would be needed,
>>>> we are looking a metric that grows or decreases monotonically across the
>>>> whole network.
>>>>
>>>
>>> I assume you mean in the routing space, and not in the controller/client
>>> space, correct? In terms of a distributed protocol? So, you're saying the
>>> delay could use "metrics" between 11 and 20, while the bandwidth could use
>>> "metrics" between 21 and 30, etc? And then you just add them all together?
>>> That's what IS-IS has done for years... Even BGP really only has one
>>> "metric," with following "tie breakers..." So if you have something like
>>> weight/local pref/etc, such that they occupy different "spaces" in a bit
>>> pattern (something sugge

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas <akat...@gmail.com> wrote:

> Hi Russ & Andy,
>
> I certainly understand the desire for different behavior when a priority
> override happens.
> However, this is one area where the working group was extremely clear.
> Sue and I had
> ideas of store-if-not-best and handling overwrites and so on.  There was a
> very clear
> push back against any such complexity.  Feel free to take a read through
> the archive.
>
> While it is tempting to expand the scope and functionality of I2RS to
> handle this as not
> an error, I would ask that we respect the WG consensus and get agreement
> and implementations
> going on the basics.
>
> We have a serious case of too many saying "This is an interesting soup.
> Let's watch it." and
> far too few people putting wood on the fire and experimenting.
>
>
It's hard to get a protocol built here just by throwing requirements over
the wall.
Standards track documents should be past the experimentation stage
(although that is far too common in the IETF). There should be multiple
vendors saying "This is how we solved this problem.  Use our solution."

There are several distinct problems here.

(1) what is an edit overlap?
This is actually a hard problem. Obviously duplicates of running datastore
instances overlap, but not so obvious are the shared ancestor nodes or
data model specific interactions between disjoint objects.  This needs to
be solved
even if there was only 1 client, because running and ephemeral datastores
can overlap.

(2) what needs to happen in the client and server to make the backup data
active?
It concerns me that the implementations of proprietary I2RS use caching
instead of introducing a distributed control loop here.  If you think
caching is
hard, just wait until you try to get 10X - 100X faster performance out of
your
notification system to implement a tight control loop.  There is complexity
in both approaches. The pub/sub work is brand new as well, so it will not
be stable for awhile.

A workaround is to implement a single client, which itself is a broker,
and handles all the caching.  It will try to delete the old data and add
the backup
in 1 step. The alternative will be around 1 sec. latency to install the
backup.



Regards,
> Alia
>


Andy


>
> On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman <a...@yumaworks.com> wrote:
>
>>
>>
>> On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7ri...@gmail.com> wrote:
>>
>>>
>>> > First, is the case of two I2RS clients modifying the same "thing"
>>> > something we consider normal and desirable, or is it an error.  The
>>> earlier
>>> > discussions was that it is an error.  In discussing the many different
>>> kinds of
>>> > direct and indirect collateral issues that arise, we concluded that we
>>> could
>>> > not expect the I2RS agent to be able to determine the "right" thing to
>>> do
>>> in
>>> > the general case.
>>>
>>> So, assume the following --
>>>
>>> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
>>> 2. In order to move traffic off a "hot link" in a fabric, a
>>> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
>>> 3. An attack vector is detected in a flow destined to some host on
>>> 10.1.1.0/24 that causes a separate client/controller to install a route,
>>> 10.1.1.0/24 via 192.168.150.1 for five seconds
>>>
>>> If I were the operator who owned this network, I wouldn't call this an
>>> "error." I would call this "normal operation," -- in fact, the ability
>>> to do
>>> the above would be the very reason I would deploy I2RS on the network in
>>> the
>>> first place. Further, I would expect the entire process to unwind
>>> properly
>>> and _quickly_. I don't care how it happens, I just want the removal of
>>> the
>>> second client's route to leave the first client's in the table as the
>>> current route, and the removal of the first client's path leave the BGP
>>> route as the best path. To go farther, why are there client priorities at
>>> all if this is an "error?" If all overwrites of "ephemeral state" are an
>>> error, the agent should simply reject any attempt to overwrite any such
>>> state.
>>>
>>>
>>
>> I agree that a priority override is not an error. In a multi-client
>> environment,
>> client A is not going to know about the other clients added to the system.
>> This is true whether the clients are primary

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Fri, Nov 6, 2015 at 7:20 PM, Russ White <7ri...@gmail.com> wrote:

> > It does.  One other point that Jason Coleman, Jason Sterne and I were
> > discussing yesterday is how we handle config in this same pane of glass
> > model.  That is, if I want to override a route via config, how would
> > that work with existing ephemeral state?
> >
> > The idea proposed was to be able to assign a priority to those [static]
> > routes that would, in essence, make them ephemeral with the associated
> > priority.  This would allow one from the CLI participate in the I2RS
> > process.
>
> Static routes are always the monster under the bed for this sort of
> stuff...
> The main problem (it seems to me) is how they've been implemented over the
> years -- I don't know enough about every implementation to know if treating
> them as "just another process" would be painful. Here's where some folks
> currently maintaining actual code stepping in and saying, "this would be
> really painful," or, "this wouldn't be a problem," would be really helpful.
> If it's going to be painful, then we might need some way to indicate which
> clients can do what.
>

The RESTCONF server has its own internal mechanisms to deal
with the interface between the protocol and the internal instrumentation.
To some degree, this hides ordering details, etc. from the client.


> I think the main problem with this entire way of looking at things is
> Joel's
> point on complexity, particularly in the agent. It would also be helpful to
> try and nail what that complexity looks like, and if there is any way to
> reduce it, such as --
>
> Would treating a complete set of "things" as a single "object" that cannot
> be broken apart be helpful? What do those sets of things look like?
>
>

This is exactly the sort of thing that the YANG model needs to tell
the server in machine-readable terms.   Implementation of stop-on-error
and continue-on-error is actually harder than it seems.
We never leave invalid data in the running datastore.
Pruning the error data and just accepting the good data is
mostly arbitrary, wrt/ pruning the least amount of the ancestor subtree.
Pruning data can cause a ripple effect wrt/ other validation rules,
such as must/mandatory/min-elements.

Knowing what constitutes a complete set of a "thing" is not in scope in
YANG.
IMO, YANG Packages could solve this problem. ;-)


Would limiting this sort of capability to a small number of objects in the
> model be helpful in some way? IE, this doesn't seem useful to me for links,
> but it does for routes. Can we figure out what the use cases are, and try
> to
> limit the number of objects for which such a capability is to a minimal
> number?
>


Yes -- this is the purpose of the "ephemeral true | false" statement
that we want to add to YANG.  It could be added to a data model
(either directly or from another module somehow) to indicate what
an I2RS server is expected to support.



> Would it be helpful to combine these two concepts? IE, only objects that
> can
> be treated as a "single atomic thing" can have a backup? Is it useful to
> tie
> these concepts together to limit the scope of adding more than one plane to
> the object?
>
>
What if the nature of "single atomic thing" is use-case specific or
even operator preference specific?

As soon as you have 2 use-cases that can share the same data,
the possibility of an edit-collision from normal operation exists.

It also may not really be safe to have the ephemeral client take over
entire sub-trees (e.g. replace instead of merge).  There could be
new nodes or augmentations unknown to the ephemeral client
that may not need to be disabled.



I don't know the answers here, just trying to find a middle path that works,
> and doesn't introduce too much complexity in return.


> :-)
>
> Russ
>
>
Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7ri...@gmail.com> wrote:

>
> > First, is the case of two I2RS clients modifying the same "thing"
> > something we consider normal and desirable, or is it an error.  The
> earlier
> > discussions was that it is an error.  In discussing the many different
> kinds of
> > direct and indirect collateral issues that arise, we concluded that we
> could
> > not expect the I2RS agent to be able to determine the "right" thing to do
> in
> > the general case.
>
> So, assume the following --
>
> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
> 2. In order to move traffic off a "hot link" in a fabric, a
> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
> 3. An attack vector is detected in a flow destined to some host on
> 10.1.1.0/24 that causes a separate client/controller to install a route,
> 10.1.1.0/24 via 192.168.150.1 for five seconds
>
> If I were the operator who owned this network, I wouldn't call this an
> "error." I would call this "normal operation," -- in fact, the ability to
> do
> the above would be the very reason I would deploy I2RS on the network in
> the
> first place. Further, I would expect the entire process to unwind properly
> and _quickly_. I don't care how it happens, I just want the removal of the
> second client's route to leave the first client's in the table as the
> current route, and the removal of the first client's path leave the BGP
> route as the best path. To go farther, why are there client priorities at
> all if this is an "error?" If all overwrites of "ephemeral state" are an
> error, the agent should simply reject any attempt to overwrite any such
> state.
>
>

I agree that a priority override is not an error. In a multi-client
environment,
client A is not going to know about the other clients added to the system.
This is true whether the clients are primary or secondary behind a broker.

The notification to a client that some or all of its data was just
overridden
is a separate matter from whether the client wants all or part of its
data to be removed or altered.

One proposal to the design team is the notion that the server
supports an advertised (static) number of clients (max client panes).
Each client must be assigned a priority, such that every client
has its own pane, so adding a valid edit does not fail. Activating
the edit is a separate matter. Each client can flush all or part of its own
pane.


:-)
>
> Russ
>
>

Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

Hi,

This raises a data modeling issue.
Should every "backup parameter" be modeled explicitly in
the YANG module, or can the ephemeral datastore be used
for that, without any additional data model objects?

The I2RS architecture supports this "backup" concept (lower priority
client),
except it requires a notification from the agent and subsequent request
from the client to make the backup active.  With NETCONF or RESTCONF
today, that round-trip will probably take around  500 to 1000 milli-seconds.
Probably much worse during high loads.

Our original proposal to the design team included a pane of glass
for each client (and unique priorities for each client), because some people
were talking about sub-milli-sec latency, and I know there is no way NETCONF
or RESTCONF is going to support this sort of tight control loop.

Whether the server rejects lower-priority edits right away, or whether
the agent caches the request in the form of a client-specific pane,
the client still needs to observe the data resources with pub/sub
and decide whether its own particular state is still relevant.
IMO the client complexity is the same either way, especially
since the caching is only done if the client requests it.

The only difference is likely to be almost a million times faster
fail-over to the backup on the server.


Andy




On Mon, Nov 2, 2015 at 8:32 PM, Susan Hares  wrote:

> Russ thank you for kicking off this discussion.  It is an interesting
> approach. I know that certain RIB implementations allows a back-up route.
>
> Sue
>
> -Original Message-
> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Russ White
> Sent: Monday, November 02, 2015 7:39 PM
> To: i2rs@ietf.org
> Subject: [i2rs] Conversation on Priority and Panes
>
> Y'all --
>
> After sleeping on the discussion last night, I think the panes of glass (or
> is it pains of glass?? :-)  ) is still by and large another expression of
> the priority concept within I2RS. The concept does bring up one specific
> point of interest, however -- what about backup information? Some vendor
> RIBs, for instance, allow a routing process to install not only the best
> path as calculated by the process -- but if the process fails to install,
> some RIB implementations allow the process to place the route in the
> "backup
> pool." This allows the local RIB process to drop to the "second best path,"
> in terms of priority, so the local RIB doesn't need to query the routing
> processes to switch in the case of a withdraw or change in topology.
>
> To convert this to I2RS terms, it does seem worthwhile to me to have the
> capability for a local agent to accept an install instruction for some
> particular ephemeral state, and if the install fails, to hold that state
> for
> future use. This would apply to any sort of ephemeral data, including that
> which is configured locally on the network device. Rather than trying to
> think of this as "panes of glass," though, this would convert it to simply
> a
> backup list of lower priority items the local agent can use in the case of
> the failure of the highest priority item currently in use.
>
> The nice thing about this view is that it doesn't require a lot of changes
> at the protocol level. The only thing that needs to be available is the
> option for an agent to send three different types of answers to an install
> request --
>
> 1. This ephemeral state was installed and is now being used.
> 2. This ephemeral state was rejected/not installed -- with potential codes
> for why (out of range parameter, etc.) 3. This ephemeral state was not
> installed, but is being held as a backup.
>
> Using these semantics, the actual implementation of such a feature is up to
> the local agent. It might be that some agents don't know how to hold backup
> information, or that it doesn't make any sense to hold some sorts of
> information in a backup list. This is fine -- the install can just be
> rejected without further note. Locally configured information could simply
> be treated as an item on the backup list, such that the priorities can be
> considered as always in deciding what to install when any particular action
> is taken.
>
> It seems, to me, that this is a simpler way to consider the same problem
> set, and reduces to an actual protocol mechanism that appears (?) to be
> fairly simple, and leaves as much flexibility as possible for any given
> agent implementation.
>
> Thoughts?
>
> :-)
>
> Russ
>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Mon, Nov 2, 2015 at 6:05 PM, Joel Halpern Direct <
jmh.dir...@joelhalpern.com> wrote:

> What we side with regard to the atomicity of collisions was that the model
> needed to specify that.  So if the model writer concludes that the leaves A
> and B in your example are so closely coupled that bad things will happen if
> different people write different parts, then they can say the container is
> the granularity.  Usually, I would expect the leaf to be the granularity.
> We do not expect the I2RS agent (or the underlying system) to guess the
> granularity.
>
>
OK -- so it is part of the data model definition.  Good.
These are the details wrt/ "first wins" that need to be understood.
The WG and proto-dt needs to think about what YANG extensions would be
needed
to describe these boundaries in machine-usable form.

Yours,
> Joel
>
>
Andy


> On 11/2/15 9:02 PM, Andy Bierman wrote:
>
>>
>>
>> On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com
>> <mailto:7ri...@gmail.com>> wrote:
>>
>>
>>  > For example, if state gets over-ridden, but preserved, then even
>> though it
>> is
>>  > not doing any good, the client which installed the state must still
>> monitor for
>>  > any related dependenecies so as to not leave incorrect pending
>> state.
>>  > Which also means that a client has to be able to remove state it
>> has
>> created,
>>  > even though that state has been over-ridden.  And probably has to
>> be able
>>  > to create state which won't take effect.  Which in turns means
>> that you
>> need
>>  > to be able to read your own effects and the current state
>> separately.
>>
>> I would think this should be a client specific implementation
>> detail... I
>> don't see why, from a protocol level, it should be disallowed, when
>> the
>> changes involved would be minor (or at least it seems to me?).
>>
>>
>> I am not sure I understand edit collision processing.
>> The proposals is that the ephemeral datastore contains data
>> from 1 or more clients.  The data from different clients is
>> non-overlapping
>> (for some definition of that).
>>
>> I will avoid running config + ephemeral leaf-override for now.
>> Assume the data model is entirely for I2RS:
>>
>>container foo {
>>   leaf A { type int32; }
>>   leaf B { type int32; }
>>}
>>
>> 1) client-worst set /foo/A to 42{ "foo": { "A":42 } }
>>
>> 2) client-best sets /foo/B to 7   { "foo": { "B":7 } }
>>
>> 3) Is client-best going to knock out data owned by client-worst?
>> what happens to /foo/A?
>>
>> Q1) Is this a collision because /foo is written by both clients?
>>if not, does client-best own /foo and /foo/A, and client-worst owns
>> /foo/B?
>>If yes, then step (2) is effectively a PUT, no matter what method is
>> really used
>>
>> Q2) what notifications are sent to client-worst, if any (depending on
>> answer to Q1)
>> (client-worst either lost ownership of /foo or /foo and /foo/A)
>>
>> Consider that A and B can be arbitrary subtrees, not just leafs.
>>
>> How are the edit collision boundaries specified?
>> Simple YANG overlap will cause lots of deletions.
>> More granular/complex boundary specification would help
>> avoid such deletions where the 2 clients could actually co-exist.
>>
>>
>> :-)
>>
>> Russ
>>
>>
>>
>> Andy
>>
>> ___
>> i2rs mailing list
>> i2rs@ietf.org <mailto:i2rs@ietf.org>
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Conversation on Priority and Panes

[Andy Bierman]

On Mon, Nov 2, 2015 at 5:28 PM, Russ White <7ri...@gmail.com> wrote:

>
> > For example, if state gets over-ridden, but preserved, then even though
> it
> is
> > not doing any good, the client which installed the state must still
> monitor for
> > any related dependenecies so as to not leave incorrect pending state.
> > Which also means that a client has to be able to remove state it has
> created,
> > even though that state has been over-ridden.  And probably has to be able
> > to create state which won't take effect.  Which in turns means that you
> need
> > to be able to read your own effects and the current state separately.
>
> I would think this should be a client specific implementation detail... I
> don't see why, from a protocol level, it should be disallowed, when the
> changes involved would be minor (or at least it seems to me?).
>
>
I am not sure I understand edit collision processing.
The proposals is that the ephemeral datastore contains data
from 1 or more clients.  The data from different clients is non-overlapping
(for some definition of that).

I will avoid running config + ephemeral leaf-override for now.
Assume the data model is entirely for I2RS:

  container foo {
 leaf A { type int32; }
 leaf B { type int32; }
  }

1) client-worst set /foo/A to 42{ "foo": { "A":42 } }

2) client-best sets /foo/B to 7   { "foo": { "B":7 } }

3) Is client-best going to knock out data owned by client-worst?
   what happens to /foo/A?

Q1) Is this a collision because /foo is written by both clients?
  if not, does client-best own /foo and /foo/A, and client-worst owns
/foo/B?
  If yes, then step (2) is effectively a PUT, no matter what method is
really used

Q2) what notifications are sent to client-worst, if any (depending on
answer to Q1)
(client-worst either lost ownership of /foo or /foo and /foo/A)

Consider that A and B can be arbitrary subtrees, not just leafs.

How are the edit collision boundaries specified?
Simple YANG overlap will cause lots of deletions.
More granular/complex boundary specification would help
avoid such deletions where the 2 clients could actually co-exist.




> :-)
>
> Russ
>
>

Andy



> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] WG LC for Topology (10/1 to 10/14)

[Andy Bierman]

> > > > > > Hi Martin,
> > > > > >
> > > > > > One model for the data that is server-provided is to assume an
> > > > > > app (which could be embedded on the same server) that knows how
> > > > > > to discover the network, then populates the data accordingly.
> > > > > >
> > > > > > [Of course, we would not want any random client app just being
> > > > > > able to "mess" with that data.  The expectation is generally
> > > > > > clearly access to this will be restricted / controlled.  The
> > > > > > topology instances that were populated by the "server-provided
> > > > > > app" should not be "touched" by other apps - it is the
> > > > > > "server-provided" app that is responsible for maintaining them.]
> > > > > >
> > > > > > So I assume the answer to your question is "yes", but with a
> > > > > > bunch of caveats.
> > > > >
> > > > > So how is the server-provided leaf supposed to be implemented, and
> > > > > how is it supposed to be used?
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > >
> > > > > > --- Alex
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Martin
> > > > > > Bjorklund
> > > > > > Sent: Monday, October 19, 2015 11:32 AM
> > > > > > To: Alexander Clemm (alex) <a...@cisco.com>
> > > > > > Cc: a...@yumaworks.com; i2rs@ietf.org;
> > > > > > j.schoenwael...@jacobs-university.de; lho...@nic.cz;
> > > > > > akat...@gmail.com; jh...@pfrc.org; sha...@ndzh.com
> > > > > > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14)
> > > > > >
> > > > > > Alex,
> > > > > >
> > > > > > Is the idea that the server-provided data is normal config?
> > > > > > I.e., if the server wants to modify this data it behaves like a
> > > > > > normal client?
> > > > > > (conceptually...)  And the server-provided data can be modified
> > > > > > by anyone with proper access rights?
> > > > > >
> > > > > >
> > > > > > /martin
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Alexander Clemm (alex)" <a...@cisco.com> wrote:
> > > > > > > Hi Juergen,
> > > > > > >
> > > > > > > I think one of the key statements you make below is this:
> > > > > > > " Recall also that YANG does not allow configuration data to
> > > > > > > depend on state data."
> > > > > > >
> > > > > > > Note that this is not the case in the current model.  The
> > > > > > > current model is essentially all configuration data.  Of
> > > > > > > course, we have this flag to indicate who supplied that data
> > > > > > > (and is hence maintaining it).
> > > > > > >
> > > > > > > You argue that we should instead "split" the model and
> > > > > > > introduce operational data to reflect what is populated by the
> server.
> > > > > > > However, doing that introduces precisely new issues - and you
> > > > > > > have just brought another argument why this may be a bad idea
> > > > > > > and may not even work.
> > > > > > > Topologies _are_ layered, and we need to be able to express
> > > > > > > that in the model.  Now, if we have a topology that is
> > > > > > > server-provided, hence (per your statement) to be represented
> > > > > > > by operational data only, how do we build an overlay topology
> > > > > > > that is "configured" on top of it?  If the answer is "we
> > > > > > > can't, unless we replicate the server-provided topology into
> > > > > > > the network configuration (which makes no sense)", we are
> screwed.
> > > > > > > Now, we might build it on top if we remov

Re: [i2rs] inteirm 10/7/20

[Andy Bierman]

On Sun, Oct 11, 2015 at 10:51 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Sun, Oct 11, 2015 at 09:55:31AM -0700, Andy Bierman wrote:
> > On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote:
> > > > The 10/7/2015 interim discussed the ephemeral portion of the protocol
> > > >
> > > >
> > > >
> > > > 1)  Ephemeral state is not unique to zI2RS
> > > >
> > > > 2)  The ephemeral datastore is a datastore holds
> > > >
> > > > configuration that is intended to not survive a reboot.
> > > >
> > >
> > > Configuration as YANG config true or a subset thereof?
> > >
> >
> >
> > config=true nodes only.
>
> good
>
> > Some way is needed to specify I2RS conformance for
> > a given YANG module, unless every persistent config leaf
> > is expected to also be supported as ephemeral data.
> >
> > If not, a YANG "ephemeral-stmt" is probably needed, since
> > config=true is insufficient to support I2RS conformance.
>
> One question is whether this needs to be inline in the data model or
> not. If conformance is the goal, then you know what having things
> defined inline has limits. If we would address conformance in more
> general terms, perhaps I2RS conformance falls out as a special case.
>
> > One ephemeral datastore.
> > No client panes.  That was to support caching, but
> > the architecture forbids caching, so that was taken out.
> >
> > One ephemeral pane that overrides the running datastore
>
> good
>
> > > Identities? I assume you mean schema nodes, do you?  Adding by
> > > defining an YANG extension such as i2rs:ephemeral true? How does such
> > > an i2rs:ephemeral true interplay with config true/false? What about
> > > contexts for must/when expressions? Or is the idea to settle on
> > > RESTCONF and to work with YANG patch?
> > >
> >
> > I think a real keyword is needed not an extension.
> > Otherwise YANG groupings cannot be utilized w/ statements
> > that are refined in the uses-stmt to set the ephemeral flag.
>
> I fail to understand the groupings argument.
>


The refine-stmt is defined to work on YANG statements, not external
statements.

A YANG extension is (by definition) something external to the YANG language.
The WG needs to decide if the ephemeral property should be specific to
an I2RS YANG module or should be basic property of the YANG data modeling
language.  YANG keywords must be supported and they do not need
to be imported from a YANG module to be used.



> > NETCONF has no edit ordering or ability to return a partial
> > error. IMO only RESTCONF is needed.  Proposals to
> > improve NETCONF editing to support YANG Patch have
> > already been made, and the WG had higher priorities.
> > I don't see why 2 protocols are needed instead of 1.
>
> Perhaps the WG should discuss and decide. If all the WG wants is
> RESTCONF, then we can simplify the discussion.



>
>
/js
>
>

Andy



> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] inteirm 10/7/20

[Andy Bierman]

On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote:
> > The 10/7/2015 interim discussed the ephemeral portion of the protocol
> >
> >
> >
> > 1)  Ephemeral state is not unique to zI2RS
> >
> > 2)  The ephemeral datastore is a datastore holds
> >
> > configuration that is intended to not survive a reboot.
> >
>
> Configuration as YANG config true or a subset thereof?
>


config=true nodes only.
Some way is needed to specify I2RS conformance for
a given YANG module, unless every persistent config leaf
is expected to also be supported as ephemeral data.

If not, a YANG "ephemeral-stmt" is probably needed, since
config=true is insufficient to support I2RS conformance.



> > 3)  The ephemeral datastore is never locked.
> >
> > 4)  I2RS is using a 2 panes of glass mechanisms
> >
> > Pane 1: normal configuration
> >
> > Pane 2:  ephemeral state
> >
> >
> >
> > The I2RS agent and configuration software on
> >
> >   the node  must handle this complexity.
>
> So is there one ephemeral datastore or are there multiple?  Some
> slides say one per client, others seem to indicate one for all
> clients.
>
>

One ephemeral datastore.
No client panes.  That was to support caching, but
the architecture forbids caching, so that was taken out.

One ephemeral pane that overrides the running datastore


> >
> > 5)  The key word "ephemeral" can be used to identify
> >
> > Identities which are ephemeral in data models.
> >
> > Does anyone have any concerns with adding this to
> > Yang?
>
> Identities? I assume you mean schema nodes, do you?  Adding by
> defining an YANG extension such as i2rs:ephemeral true? How does such
> an i2rs:ephemeral true interplay with config true/false? What about
> contexts for must/when expressions? Or is the idea to settle on
> RESTCONF and to work with YANG patch?
>

I think a real keyword is needed not an extension.
Otherwise YANG groupings cannot be utilized w/ statements
that are refined in the uses-stmt to set the ephemeral flag.

NETCONF has no edit ordering or ability to return a partial
error. IMO only RESTCONF is needed.  Proposals to
improve NETCONF editing to support YANG Patch have
already been made, and the WG had higher priorities.
I don't see why 2 protocols are needed instead of 1.




>
> /js
>
>

Andy


> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Review comments to draft-mglt-i2rs-security-environment-reqs-00 (was RE: draft-mglt-i2rs-security-requirements-00 2 Week WG adoption call (8/17 to 8/31)

[Andy Bierman]

Hi,

I will leave it to the Security ADs to decide whether a non-secure transport
for I2RS should be standardized.

The lean I2RS seems to be a proprietary controller and agent
with no multi-headed control support. This will almost certainly
mean that the router will not work if any unofficial
controller is used instead of the vendor controller.

If this really is the expected usage then why bother with a standard?


Andy

On Mon, Aug 24, 2015 at 10:37 AM, Linda Dunbar linda.dun...@huawei.com
wrote:

 Joel,

 Agree with you that “we don’t need to build different protocol stacks for
 the different deployments”.
 But the “environment-req” draft is not about “Protocol”, but about
 security issues under different “environment”.

 Among all our customers who are interested in I2RS, majority of them
 (90%) will deploy them in a closed environment, i.e. physically secured
 connection between I2RS agent and I2RS client. Therefore, it is important
 to “provides an analysis of the security issues of” of this commonly
 deployed environment.

 I suggest adding this Figure to Section 1 of the document:

 Closed  (over open Chnl ###)  Open (over secure Chnl ---)
 +-+
 |  ***   |  ***  |
 |   *Application A*   |  *Application B*  |
 |   * *   |  * *  |
 |   *  ++ *   |  *  ++ *  |
 |   *  |   Client A | *   |  *  |   Client B | *  |
 |   *  ++ *   |  *  ++ *  |
 |   *** ^ *   |  * ^ ** ^ **  |
 |   # ||| |
 |   # |||   |-|
 |   #   | |   |
 |   v * * * * |   * v * v 
 |  *  +-+ |   *  +-+ *
 |  *  | Agent 1 | |   *  |Agent 2  | *
 |  *  +-+ |   *  +-+ *
 |  * ^^  ^   ^|   * ^^  ^   ^*



 Just think about this fact: today’s router configuration in production
 environment can only be performed by a few authorized people with EMS/NMS
 physically and securely separated. If the majority of the I2RS environment
 requirement is about open connection, I2RS WG will spend a lot energy
 developing the very sophisticated protocols which is expensive to develop
 and harder to deploy.

 I am not against this development, but IMHO, to gain wider and quicker
 I2RS deployment in production environment, it is necessary to have a very
 *lean* I2RS solution first, and to have a well documented security
 requirement for the common deployment environment. E.g. a single Controller
 (or the I2RS client) directly connected to their devices via their internal
 network, where the connection is physically isolated from other network and
 protected by separate mechanisms. Also remember, many operators will use
 I2RS to control a small number of selective routers (mostly routers at
 ingress/egress boundary) for value added services.



 Some of my detailed questions and comments to the “security-requirements”
 are still applicable to the “environment-req” document because they have
 the same text. Plus a few more for the “environment-req” document. Hope the
 authors can address them.


 Section 3:

 What are the key differences with regard to the security requirements for
  I2RS plane and for management plane?  Section 3.1 describes the
 interaction between I2RS plane and management plane. But I see the security
 requirement for the management plane are all applicable to the security
 requirement to I2RS plane . If you think that they are very different, can
 you elaborate more?

 Section 3.4 has title “Recommendations”, but the content are all
 requirements. Why not name the section “Requirement”?

 REQ 2: Does it that a different IP address than the one used by the
 management system?

 REQ 21: is more about I2RS requirement, less about “Security” requirement.

 REQ 24: isn’t it the general goal of I2RS? Not really security per se.
 (should be included in the general I2RS requirement or architecture).


 REQ 26: simply controlling the resource can hardly prevent DoS. Malicious
 client can occupy the resource while the valid one can't access.

 Thanks for your consideration,
 Linda


 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org i2rs-boun...@ietf.org] On
 Behalf Of Joel M. Halpern
 Sent: Friday, August 21, 2015 12:20 PM
 To: Linda Dunbar; i2rs@ietf.org
 Cc: 'Jeffrey Haas'; daniel.miga...@ericsson.com; 'Alia Atlas'
 Subject: Re: [i2rs] draft-mglt-i2rs-security-requirements-00 2 Week WG
 adoption call (8/17 to 8/31)

 Yes, one of the two last calls is for the environment document.

 

Re: [i2rs] some doubt about draft-ietf-i2rs-ephemeral-state-00.// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

[Andy Bierman]

On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas jh...@pfrc.org wrote:

 Joel,

 On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
  To amplify my previous reply on priority, priority is associated
  with the I2RS Client.  it does not change even if the client is
  acting on behalf of multiple secondary identities.  (If the use case
  requires that variability, use multiple primary identities, with
  separate sessions.)

 To attempt to reduce this to an example:
 Basis case: Multiple clients speaking directly to an agent.  Clients have
 distinct priorities.  Priority causes config to tie-break appropriately
 among the various client interactions.

 Proxy case: Agent is against as root from a proxy, potentially with the
 a single priority.  As long as the proxy maintains the tie-breaking as if
 it
 had implemented the agent operations, it's okay that the resultant nodes
 may
 have the same priority associated with them?

 Gloss: We still haven't concluded our discussion as to whether the nodes
 are
 decorated as owned by an identity or have a priority.

 Note that the gloss has an interesting impact.  If nodes are expected to
 get
 their priority via identity, this makes things very messy if you don't
 maintain multiple identities to have distinct priorities in the proxy case.


But the secondary identity is just extra meta-data to be stored by
the agent.  If there is a priority associated with each secondary client
then that becomes the client-id.

The design does not directly support different priorities per broker.
The broker needs to pretend to be different clients, and each session
will have a different client-id and priority.  This is non-optimal but not
broken.




-- Jeff


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] some doubt about draft-ietf-i2rs-ephemeral-state-00.// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

[Andy Bierman]

On Tue, Jul 14, 2015 at 11:39 AM, Jeffrey Haas jh...@pfrc.org wrote:

 Joel,

 On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote:
  The architecture does not have a proxy.  It only has Clients, who
  may be acting on behalf of applications.  Those applications are not
  consider, by the I2RS system, to be I2RS Clients.
 
  Secondary identity is not a full proxy mode.  secondary identities
  are not authenticated.  They do not have priorities.  They are
  included in the architecture to ease attribution.

 It is understood that secondary-identity is only a traceability detail.

  So no, if A and B are applications, working through a common I2RS
  client, then their operations are handled by the client.  The
  requirements only call for the client priority to be assigned to
  those operations.

 Given the above, I think it is fair to say that proxies are completely out
 of scope.  While this simplifies things, I'm not sure it's the best thing
 long-term.


The entire northbound API from the client is out of scope.
The secondary identity is just decoration in the standard.

In reality, a broker might be the only client, so its priority
is worthless for resolving conflicts.  The applications using
the broker are the ones needing priority to resolve conflicts.

I can imagine data-specific controllers meaning if an app
for vendor X want to write a particular set of data structures,
it goes through the client designed to provide a simplified
(proprietary) API for this purpose.

Since this is all out of scope I suppose it doesn't matter,
but some types of brokers won't work very well.





 As a nice-to-have, allowing clients to specify different priorities
  for different operations is acceptable.  But it is not necessary.

 As a nice-to-have, I don't believe the architecture clearly explains such
 an
 ability to alter priority.  Please work with Alia to update the
 architecture
 document to clarify this if you believe this property is important.

 -- Jeff



Andy


 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] some doubt about draft-ietf-i2rs-ephemeral-state-00.// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

[Andy Bierman]

On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern j...@joelhalpern.com
wrote:

 The flexibility Jeff has described, and you have commented upon, is
 permitted but not required by (what I understand of) the agreements of the
 WG.  If it can be easily done, it seems like a nice thing to do.


It means the priority, client-ID, and 2nd-id all need to be saved per
subtree.

What happens if a client priority mapping is deleted or does not exist?
Does that client just get the worst possible priority or is it an error
or is all data deleted for that client?

What if the server is aware a client id was removed completely?
Does that matter for existing data for that client?

Yours,
 Joel



Andy


 On 7/13/15 9:04 PM, Andy Bierman wrote:



 On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas jh...@pfrc.org
 mailto:jh...@pfrc.org wrote:

 Joel,

 On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
   To amplify my previous reply on priority, priority is associated
   with the I2RS Client.  it does not change even if the client is
   acting on behalf of multiple secondary identities.  (If the use
 case
   requires that variability, use multiple primary identities, with
   separate sessions.)

 To attempt to reduce this to an example:
 Basis case: Multiple clients speaking directly to an agent.  Clients
 have
 distinct priorities.  Priority causes config to tie-break
 appropriately
 among the various client interactions.

 Proxy case: Agent is against as root from a proxy, potentially
 with the
 a single priority.  As long as the proxy maintains the tie-breaking
 as if it
 had implemented the agent operations, it's okay that the resultant
 nodes may
 have the same priority associated with them?

 Gloss: We still haven't concluded our discussion as to whether the
 nodes are
 decorated as owned by an identity or have a priority.

 Note that the gloss has an interesting impact.  If nodes are
 expected to get
 their priority via identity, this makes things very messy if you don't
 maintain multiple identities to have distinct priorities in the
 proxy case.



 OK -- it is becoming clearer now -- in order to support a broker, the
 priority is saved with the node, not the client.

 The operator configured priority is really the best allowed.
 Let's say lower priorities are better, and client A is assigned the
 value 10.  That means client A is allowed to use priorities 10 .. 255.

 Each edit from client A can have a priority that is associated with
 the secondary client.

 rpc
edit-config
   targetephemeral //target
   config  ... /config
   secondary-identityapp27/secondary-identity
   priority42/priority
/edit-config
 /rpc

 An error is returned if priority is 9 or lower in this example.

 IMO this is better than requiring client A to open a session as a
 different user name for each priority value needed.



 -- Jeff



 Andy


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] some doubt about draft-ietf-i2rs-ephemeral-state-00.// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

[Andy Bierman]

On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas jh...@pfrc.org wrote:

 On Sat, Jul 04, 2015 at 11:25:29AM +0800, dai.xianx...@zte.com.cn wrote:
  I have some doubt about draft-ietf-i2rs-ephemeral-state-00.
 
  1.Chapter 6 Requirements regarding Identity, Secondary-Identity and
  Priority
 
  I2RS permits RPC operation to carry priority and a secondary identity as
  attribute parameters.
  In this draft, it describes that This secondary identity meta-data MUST
  be read-only. operations attempting to alter it MUST be silently ignored.
  
  Since identity attribute cannot be changed until the session terminates,
  why don't we permit client to send hello message with such infos during
   session establishment.
   e.g,
  hello xmlns=urn:ietf:params:xml:ns:netconf:base:1.0
   capabilities
 capability
   urn:ietf:params:netconf:base:1.0
 /capability
 capability
 
 
 urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1priority=10
 /capability
   /capabilities
 /hello
  It means in this session, the secondary-identity is named user1, the
  default priority is 10

 This would be an acceptable means of encoding the secondary-identity.  Does
 anyone working on a netconf implementation have any opinions about this
 form
 vs. what is in the draft?

 Note that the priority MUST not be user-supplied.  It should be derived
 from
 the credentials.  Letting the user set the priority may be inappropriate
 security.




This approach would mean that the I2RS client acting as a broker
would need a different session for each secondary client.
It seems more useful to allow the client to use 1 session,
and just require that each edit be from a specific secondary identity.

(e.g., add a secondary-identity parameter to the edit operation).
The proposed solution of an XML attribute allows every node
in an edit to be from a different secondary identity.


 then,if the session wants to change its priority while RPC operation,as
  follows
   foo xmlns:i2rs=https://ietf.example.com/i2rs;
  i2rs:i2rs-priority=47
...
  /foo
  It means now in this session, the secondary-identity is named user1,
 the
  priority is 47
 
  furthermore, we can define set-i2rs-priority to change current
 session's
  priority,such as
  set-i2rs-priority
  xmlns:i2rs=urn:ietf:params:i2rs:capability:i2rs:1.0
  priority20/priority
  /set-i2rs-priority

 I believe having the priority set per-session likely matches our use case.
 In the event a different priority is expected, the user would use a
 different session with different credentials.


I thought the client priority is configured in advance by the
administrator.  It makes no sense to have each client
state their own priority.  This is useless for resolving conflicts
between clients.






  2.In this draft, Priority is defined as a numeric value,how about its
  range statements? Is i2rs-priority = 255 is the highest?

 At the moment, I think we're a bit early on this specific detail.  Once we
 have further clarification from the netconf working group, we can clarify
 this point.


IMO, priority 0 is the highest, and can only be used
by the system itself.  Priority 1 is the next highest.




  3.config ephemeral
  In this draft,The YANG config keyword is extended,like config
  true/false/ephemeral ,and the basic netconf operation should be
 extended,
  like get-config edit-config and so on.
  why don't we define a new kind of operations,like get-i2rs edit-i2rs?

 There has been some level of feedback from the netmod/netconf Working Group
 participants that this might be the way to go.  Consider the prior
 proposal draft-bjorklund-netmod-operational.

 The specific details of this will resolve once the underlying concepts of
 how we'll represent the ephemeral configuration state have been better
 defined.  The proposals in the current draft are merely discussion points
 to
 try to start a conversation as to what the mechanism could look like.

 We're looking forward to that discussion within netconf.

 -- Jeff



Andy



 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] some doubt about draft-ietf-i2rs-ephemeral-state-00.// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

[Andy Bierman]

On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas jh...@pfrc.org wrote:

 Joel,

 On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
  To amplify my previous reply on priority, priority is associated
  with the I2RS Client.  it does not change even if the client is
  acting on behalf of multiple secondary identities.  (If the use case
  requires that variability, use multiple primary identities, with
  separate sessions.)

 To attempt to reduce this to an example:
 Basis case: Multiple clients speaking directly to an agent.  Clients have
 distinct priorities.  Priority causes config to tie-break appropriately
 among the various client interactions.

 Proxy case: Agent is against as root from a proxy, potentially with the
 a single priority.  As long as the proxy maintains the tie-breaking as if
 it
 had implemented the agent operations, it's okay that the resultant nodes
 may
 have the same priority associated with them?

 Gloss: We still haven't concluded our discussion as to whether the nodes
 are
 decorated as owned by an identity or have a priority.

 Note that the gloss has an interesting impact.  If nodes are expected to
 get
 their priority via identity, this makes things very messy if you don't
 maintain multiple identities to have distinct priorities in the proxy case.



OK -- it is becoming clearer now -- in order to support a broker, the
priority is saved with the node, not the client.

The operator configured priority is really the best allowed.
Let's say lower priorities are better, and client A is assigned the
value 10.  That means client A is allowed to use priorities 10 .. 255.

Each edit from client A can have a priority that is associated with
the secondary client.

   rpc
  edit-config
 targetephemeral //target
 config  ... /config
 secondary-identityapp27/secondary-identity
 priority42/priority
  /edit-config
   /rpc

An error is returned if priority is 9 or lower in this example.

IMO this is better than requiring client A to open a session as a
different user name for each priority value needed.



-- Jeff



Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [netmod] extended datastores slide

[Andy Bierman]

On Thu, Jun 25, 2015 at 9:35 AM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierman wrote:
 
  I prepared 1 slide (based on Kent's slide).
  I am trying to understand the types of data
  and how they are identified in YANG and conceptually
  separated for protocol access.
 

 I do not understand the 'config ephemeral' on the left side. I think
 it is the implementation (or its configuration) that decides which
 data models also exist in the ephemeral data store.



This is to allow for data that can only be edited in the ephemeral datastore
instead of running or ephemeral datastore.  It allows the XPath (and other
rules)
to be different than the existing rules for the running datastore.

My slide did not go as far as Jeff wanted wrt/ allowing ephemeral data
to reference operational data, but I think this would be OK.

As Jeff pointed out, the ephemeral data does not exist until
a controller creates it, unlike the persistent config that will be
applied at boot-time before the operational state exists.



/js



Andy


 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [netmod] extended datastores slide

[Andy Bierman]

On Wed, Jun 24, 2015 at 10:14 AM, Phil Shafer p...@juniper.net wrote:

 Andy Bierman writes:
  How is that expressed in the data model?  auto would not be an
  operational value for duplex.  none would not be a valid
  configuration value, but would be the operational value for an
  empty port.
 
 good point -- the operational instance would not exist is the status is
 'none'

 Why not?  The interface might exist but not have an ethernet
 cable plugged in.  show interfaces would show the physical
 instance, but duplex could be none.



OK -- good point

In NETCONF terms, a new get parameter or
a new get-operational operation could be used
to read the operational datastore.


 Thanks,
  Phil



Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

[Andy Bierman]

Hi,

I am still fairly confused how the running configuration interacts
with ephemeral data, but I will wait to see some concrete solution
proposals.

The proposal does not mention what changes would be required to
YANG to add config=ephermal.  There are 1000s of lines
of text that would be impacted by this change.  This change
might break a YANG 1.0 tool, which would violate the NETMOD charter
for YANG 1.1.

This solution does seem to suggest that I2RS can never alter any
value that is config=true.  These nodes can only be changed by NETCONF.
This of course means that no client priority or secondary identity
could be supported for config=true nodes.  Ephemeral data cannot
really rely on any local config, since any client can alter it at any time.
This might be fine, but I2RS clients need to be careful not to
assume any particular running configuration in order to work.
You cannot safely add an ephemeral leaf to a configuration container
or list.

It also means that I2RS can never be used to override a config=true
value (since the data models do not overlap).  A special add-on I2RS
module would be needed to define the specific I2RS override knobs.

sec 6.2 adds client priority to the NACM group list.
Users can be in multiple groups, so you need to specify how
the client priority is determined as the group membership
configuration is changed.

   +--rw groups
  |  +--rw group [name]
  | +--rw name group-name-type
  | +--rw user-name*   user-name-type
  | +--rw i2rs:i2rs-priority i2rs-priority-type



Sec 6.3. shows the client setting its own priority.
This does not seem correct if the administrator is supposed to
set the client priorities.

   foo xmlns:i2rs=https://ietf.example.com/i2rs;
   i2rs:i2rs-secondary-identity=user1 i2rs:i2rs-priority=47
  ...
  /foo



Andy




On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares sha...@ndzh.com wrote:

 Andy:



 Thank you for the feedback on draft-ietf-i2rs-pehemeral-state-00.txt.
  This document is now a WG document – so suggestions on changing the text
 are welcome.   It is a work-in-progress so I appreciate your help in
 refining this draft.  Please suggest alternate text for the draft.  My
 comments on individual points are below.



 At the front of this document are the top 10 requirements for the I2RS
 protocol.  All other details within this draft are to provide more detail
 to these requirements, and do not dictate a solution to the NETCONF/NETMOD
 working group.  I hope my message to netconf/netmod/I2rs further clarifies
 this point.



 The I2RS 6/24/2015 interim will continue to discuss the I2RS requirement
 on web-ex.  Please join us at the interim and continue to discuss the
 requirements on this mail list.



 Sue Hares



 *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman
 *Sent:* Tuesday, June 23, 2015 2:09 PM
 *To:* internet-dra...@ietf.org
 *Cc:* i2rs@ietf.org; i-d-annou...@ietf.org
 *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt



 Hi,



 This draft seems to propose very specific solutions, not requirements.





 This text is in the section explaining why an ephemeral datastore won't
 work:



The most obvious disadvantage of such a fully separate datastore is

that interaction with the network element's operational or

configuration state becomes significantly more difficult.



 I don't see any evidence or examples in the draft to support this claim.





 [Sue: This is correct.  The authors recorded what they heard at the I2RS
 interims.  If you would like to clarify this – please do.  I have heard
 this is implementation dependent.  Is this true?



 The requirements do not make it clear how a YANG module is implemented

 by I2RS vs. implemented by NETCONF or RESTCONF.  It is not clear at all

 how YANG data-def-stmts are handled correctly by each protocol.

 Perhaps you can provide some data model examples.



 [Sue: I have given the I2RS yang module list in the netconf announcement
 for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB.   These data
 modules provide you with some examples, and I welcome a specific discussion
 of these modules on the list or at the I2RS interim.



 Andy







 On Tue, Jun 23, 2015 at 9:52 AM, internet-dra...@ietf.org wrote:


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.
  This draft is a work item of the Interface to the Routing System Working
 Group of the IETF.

 Title   : I2RS Ephemeral State Requirements
 Authors : Jeff Haas
   Susan Hares
 Filename: draft-ietf-i2rs-ephemeral-state-00.txt
 Pages   : 13
 Date: 2015-06-23

 Abstract:
This document covers requests to the netmod and netconf Working
Groups for functionality to support the ephemeral state requirements
to implement the I2RS architecture.


 The IETF datatracker

Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

[Andy Bierman]

Hi,

It is all too easy for IETF work to fall apart because of charter overlap.
It's way too easy to confuse process with progress.

Since the IETF is comprised of volunteers, it usually takes the involvement
of stake-holders all the way through to RFC publication to get work done.
My guess that unless I2RS people are involved and doing most of the work,
the NETCONF WG is not likely to make much progress or even get started.


Andy




On Fri, Jun 19, 2015 at 8:08 AM, Joel M. Halpern j...@joelhalpern.com
wrote:

 While I would expect most of the detail work on a solution to be done in
 NetConf, it would be very unusual to treat the requirements as something
 thrown over the wall, with the ensuing work done only in NetConf.  If
 NetConf wants its work to be suitable to meet the I2RS requirements, then
 experience with many cross-WG activities tells us the proposal will need to
 also be reviewed and discussed with I2RS.

 If NetConf wants to do what it judges is best, and merely hope that I2RS
 adopts it when it is done, then the NetConf WG is certainly free to do
 that.  But the odds of meeting the requirements are low, and the odds of
 I2RS waiting around on the assumption that the right magic will be thrown
 back over the wall is also low.

 Yours,
 Joel

 On 6/19/15 2:46 AM, Juergen Schoenwaelder wrote:

 On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote:

 Juergen:

 chair hat on
 The I2RS WG still needs a written draft proposing how this would work to
 have an effective discussion.
 chair hat off


 My understanding is that I2RS formulates requirements and the solution
 is done in NETCONF. If this is correct, then there is in principle no
 point in sending solution drafts to I2RS.

 Yes, I understand that requirements are often written with certain
 solutions in mind and this is why requirement processes usually are
 frustrating.

 /js


 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

[Andy Bierman]

Hi,

I think I understand Juergen's concerns about I2RS requirements.
Some of them are not specified as functionality, but rather as solutions.

Most notably, the NETCONF WG needs to decide the best way to
integrate ephemeral configuration into the existing framework.
That may end up being a query-tag or a datastore or something new, but that
is
a standards implementation detail, not a requirement.


Andy

On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares sha...@ndzh.com wrote:

 Juergen:

 chair hat on
 The I2RS WG still needs a written draft proposing how this would work to
 have an effective discussion.
 chair hat off

 If it has these benefits you mention, it would be good to write itup.

 Best wishes,

 Sue

 -Original Message-
 From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
 Sent: Wednesday, June 10, 2015 8:45 AM
 To: Jeffrey Haas
 Cc: Susan Hares; i2rs@ietf.org; 'Joel M. Halpern'; i2rs-cha...@ietf.org;
 'Alia Atlas'
 Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

 On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote:
  Juergen,
 
  On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote:
   Frankly, there is no full alternate proposal either. The overlay
   model has been discussed at quite some detail at a NETMOD interim. I
   am happy to point at the meeting minutes. The question perhaps
   really is whether (a) I2RS has requirements to be addresses and
   NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a
   solution into stone to be run through the NETCONF working group or
   whether (c) creates a solution on its own independently of any other
   NETMOD/NETCONF requirements.
 
  During that interim, we did discuss a number of details regarding
 overlays.
  We also discussed a number of issues that overlays have when ephemeral
  state was not disjoint from static configuration state.
 
  As a result of that discussion and further presentation at a later
  I2RS meeting regarding the Venn diagram interactions of static and
  ephemeral configuration state, my latest draft attempts to codify
  behaviors that shouldn't be problematic in either proposed form or in
 overlay.
 
  The point of frustration for all parties seems to be that while the
  paragraph from you above seems to indicate that there is some
  understanding of the requirements, I am unable to provide text that
  illustrates either requirement or potential solution to the matter.
  All parties are spending their resources saying I think I understand
 this
 point, but this is wrong.
  If the points are understood well enough to disagree with potential
  solutions, I would suggest that they may be clear enough for both
  protocol and data modeling experts to contribute text that either
  clarifies the requirements to the collective experts' needs or
  similarly a proposal documenting a solution.
 
  These fundamental failures suggest a few possibilities:
  1. There is a complete failure to properly communicate.  If so, we should
 find replacement parties to carry on the work.  We had some declared
 interest in a design team.  Sue has, I believe, contacted people about
 it.
 Those individuals should take over the work.
  2. Netconf/restconf/yang are inappropriate tools and we have wasted the
 Working Group's time.  I don't believe this as my employer has
 ephemeral datastores in an upcoming release.  It does not, however,
 have
 full I2RS properties such as priority or secondary-id.
  3. The relevant experts are trying to get I2RS ephemeral state work to
 die.
 If so, let's have the relevant discussion either publicly or privately
 so
 we can stop wasting people's IETF cycles.

 I can assure you that, at least from my side, 3. is not the case.

 My perspective is likely slightly different from yours since I (not
 surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS
 itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps
 YANG), I believe we will have to envision more usages of that feature than
 just I2RS. Looking at things from a wider and longer term perspective, I am
 concerned about (i) duplicated data modeling work and I am concerned about
 (ii) use-case specific merge logic that needs to be supported. From this
 perspective, the overlay model has been prety attractive because it comes
 with a single merge logic and it minimizes (or even eliminates) duplicated
 data modeling work.

 /js

 PS: Out of curiosity: Can you disclose what your employer's ephemeral
 datastore solution coming out as a product soon looks like? Is it
 closer to an overlay approach or is it closer to what you
 described in your I-D?

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

 ___
 i2rs mailing list
 

Re: [i2rs] storage of priority and client ID with a node

[Andy Bierman]

On Wed, Jun 10, 2015 at 11:54 AM, Alia Atlas akat...@gmail.com wrote:
 Hi Andy,

 On Wed, Jun 10, 2015 at 1:15 PM, Andy Bierman a...@yumaworks.com wrote:

 On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas akat...@gmail.com wrote:
  no-hat
  As I mentioned in the virtual interim, I'd like to explain a little
  further
  about what I see as semantics and desired behavior around the storing
  and
  managing of priority and client ID.
 
  First, the priority mechanism is intended to handle error cases of
  colliding writes in a predictable way that results in a consistent
  mechanism.  It is true that the same mechanism could be used if they
  weren't
  considered errors.  I think this is a nice property - but it is also
  important to minimize the impact of the priority mechanism.
 
  Second, if there is a priority conflict where both clients (Client_A and
  Client_B) share the same priority, the client that wrote first wins.
  This
  is to avoid network oscillation if two clients are fighting over
  writing
  the same state.  When there are multiple clients and the time arrival of
  the
  messages may not be predictable (network transit differences, which
  socket
  is read, software differences), basing state on last arrival time
  doesn't
  give consistent and predictable behavior.
 

 Neither does first wins.  It is just as arbitrary and based on the same
 unpredictable network.


 [Alia] Sure - but doing first wins in the event of the same priority
 ensures that
 it won't oscillate.  Doing  last arrival time lets it oscillate.



OK  -- I forgot I2RS clients might be coded to send an edit if
they get the notification for your data was deleted.
If 2 with the same priority do that, they will oscillate.
NETCONF is more set-it-and-forget-it.


Andy

 I think the higher priority wins could be useful for I2RS
 where multiple applications are touching the same RIB data structures.
 This is a new twist -- competing configuration management apps
 don't usually occur so it has not been an issue for NETCONF.


 [Alia] Agreed - IMHO, a network operator would assign different priorities
 to
 each client so that the conflicts with the same priority don't happen.  I
 can see
 different clients managing different services or such.


  That gives behavior as in the following time-line:
  Time_1:  Client_A writes X=N with priority 10
  Time_2:  Client_B attempts to write X=K with priority 10 and is
  rejected
  Time_3:  Client_A writes X=P with priority 10 and succeeds
 
  For the I2RS Agent to properly handle these actions, it is necessary to
  know
  that X is owned by Client_A.  Priority alone is not sufficient because
  the
  basis for rejecting Client_B's write but accepting Client_A's write is
  that
  Client_A is the owner.
 
  Thus, I believe that it is necessary to store the Client Identity with
  the
  nodes that it owns.
  This could be in an I2RS-specific overlay that is only used by the I2RS
  agent and only contains the nodes that have been written by I2RS.
 

 IMO a tie is an error (as Joel put it).
 First one in a tie or last one in a tie is just as arbitrary
 and unpredictable.  Last one does not require saving the client.
 First one does.


 [Alia] I agree that last one wouldn't require saving the client - but it
 also
 wouldn't prevent oscillations if there were two clients fighting over
 writing
 their state.

 But IMO it is useful to save the client so it can be returned in meta-data
 or filtered (e.g. GET(all-for-client-A)), so first-one wins is not
 a big deal to support.


 Agreed that saving the client can be useful for filtering or monitoring
 apps.


  Third, a question has come up regarding what the behavior of priority is
  if
  a client's priority changes and whether priority needs to be stored with
  each node when that node is written.
 
  In my keep-it-simple perspective, priority is associated with a Client
  and
  is only used on a conflict.  This would mean that priority isn't stored
  with
  a node when that node is written.  Instead, the Client Identity is
  stored
  with the node and the Client's priority is looked up in a client table
  that
  the I2RS Agent can access.  That client table could be populated via
  configuration, via a AAA protocol, via NACM, etc.

 
  The semantic implications are as follows:
Time_1:  Client_A writes X=N with priority 10
Time_2:  Client_A's priority is changed (UNUSUAL) to priority 6
   *Time_3:  Client_B writes X=K with priority 8  (succeeds since 8 
  6)
   *Time_4:  Client_A attempts to write X=N with priority 6  (fails
  b/c 8
  6)
Time_5:  Client_B's priority is changed (UNUSUAL) to priority 7
Time_6   Client_B writes X=P with priority 7 and succeeds (same
  owner,
  no priority check)
 
  The alternate approach would have store the priority with which a node
  was
  written.  That is more like a priority lock that could only be changed
  by a
  client with higher priority or by the same client

Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

[Andy Bierman]

Hi,

IMO NETCONF notifications are probably not the best choice for
the high-performance low-latency signalling that I2RS wants
between agent and client.  There is a lot of overhead in
the filtering, replay, YANG schema processing, XML encoding, etc.

Binary notifications that contain hard-wired standard messages
specially written to implement the I2RS protocol would be much faster
and less expensive to implement.  If this is to be as fast as a signalling
protocol then it would be wise to consider protocol performance issues.


Andy


On Fri, Jun 5, 2015 at 12:43 PM, Susan Hares sha...@ndzh.com wrote:
 Andy and Joel:

 As my chair note stated, the chairs know they are providing extra details 
 with the requirements.  However, in the past the feedback from various 
 NETMOD/NETCONF participants has been not enough detail.  The use of NACM to 
 control input to a I2RS agent and assign priority to a client - is one of 
 those extra info.  I believe the tight notification guarantees to support a 
 I2RS control loop is a requirement rather than extra suggestions.

 Hopefully, that the NETMOD/NETCONF chairs will review through the initial 
 ephemeral state document and describe what they feel is requirements versus 
 added suggestions.   The I2RS chairs will clean-up that requirements document 
 next week.

 Sue

 -Original Message-
 From: Andy Bierman [mailto:a...@yumaworks.com]
 Sent: Friday, June 05, 2015 12:38 PM
 To: Joel M. Halpern
 Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; i2rs-cha...@ietf.org; Alia Atlas
 Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

 On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern j...@joelhalpern.com wrote:
 I would describe it somewhat differently from any of the choices you list.

 A) I2RS has some a set of architectural requirements.  These were not
 as cleanly described as one might like but they were very clearly
 accepted by the working group and understood to be needed for the protocol 
 choice.
 B) The working group has decided that it will use NetConf/RestConf if
 that can meet the requirements.


 I would say the arch is a mixture of architecture and functional requirements.
 Almost as if the authors had a design in mind and reverse-engineered the 
 requirements from the design.

 As Juergen pointed out, the requirement to assign a priority to a client does 
 not require NACM.  NACM is a design choice for that requirement.

 I have some concerns about the tight notification control loop that is 
 proposed.  IMO, this is going to be too slow and too complicated.  It seems 
 to me that the only company that has implemented something close to I2RS is 
 using a design that does not rely on a near real-time reliable notification 
 loop.

 I don't have a strong preference for ephemeral datastore vs. tagging 
 non-config data.  The current NETCONF datastores only apply to config=true 
 objects.  YANG design allows for the config=false data to be further 
 partitioned, but this is not required for I2RS to work.


 The corrolary is that if neither NetConf nor RestConf can meet the
 requirements, then the working group will, in my opinion, have to do
 something else.

 That would be OK too, if you want to completely
 decouple I2RS from configuration.   This simplifies some
 things if was invisible to NETCONF/RESTCONF and YANG.



 Yours,
 Joel

 Andy


 On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote:

 On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote:

 Juergen:

 I understand your technical point on being concerned about

 solutions that require (i) separate data models for ephemeral state
 and
 (ii) data model specific merge logic. While this may work for I2RS,
 this approach does not scale or has a very high cost of scaling to
 other ephemeral state editing needs.

 If you have full overlay model proposal, we would be glad to receive it.
 However, no one else has proposed a full overlay model.


 Frankly, there is no full alternate proposal either. The overlay
 model has been discussed at quite some detail at a NETMOD interim. I
 am happy to point at the meeting minutes. The question perhaps really
 is whether (a) I2RS has requirements to be addresses and
 NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a
 solution into stone to be run through the NETCONF working group or
 whether (c) creates a solution on its own independently of any other
 NETMOD/NETCONF requirements.

 Other answers are below.

 Sue

 -Original Message-
 From: Juergen Schoenwaelder
 [mailto:j.schoenwael...@jacobs-university.de]
 Sent: Thursday, June 04, 2015 2:24 AM
 To: Susan Hares
 Cc: i2rs@ietf.org; jh...@pfrc.org; 'Joel M. Halpern';
 i2rs-cha...@ietf.org; 'Alia Atlas'
 Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

 On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote:

 The minutes for the I2RS meeting are at:



 www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-in
 ter
 im-201
 5-i2rs-8

Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

[Andy Bierman]

Hi,

Re 2(a) and (b):

Are changes to RFC 5277 being proposed to make notifications
highly reliable, or is there an assumption that implementations
will just provide adequate memory to buffer notifications?

Real time guarantees on getting data sounds like RAI work
is needed?  Are any changes needed to RESTCONF or
NETCONF to support this requirement?  Or is there just
an expectation that implementations will be fast.

IMO, the standard should be silent on response times
and packets per second issues.  Unless a certain speed
is required for interoperability, then it seems inappropriate
to mention in an RFC.


Andy


On Wed, Jun 3, 2015 at 5:49 PM, Susan Hares sha...@ndzh.com wrote:
 The minutes for the I2RS meeting are at:



 www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-2015-i2rs-8



 These minute provide a lengthy of issues in the requirements.  From these
 minutes, there are the following 6 conclusions on the protocol requirements
 that Jeff stated:



 1)  There will be no consideration of an overlay model unless a fully
 formed proposal is presented.

 Jeff and I appreciate Ken Watsen’s comments on the list, but we have had
 lots of suggestions regarding

 an overlay proposal – but no full proposal.  At this time, the WG will only
 consider full proposals and not

 suggestions toward a proposal.



 2)  Jeff’s document provides details on ephemeral state requirements
 that have not changed.  These requirements include:

 a.   Highly reliable notifications (but not perfectly reliable
 notifications)

 b.  High bandwidth, asynchronous interface, with real-time guarantees on
 getting data,

 c.   Node identification of clients that write by client identity,
 secondary identity, and priority.  Data models will determine what is the
 “node” unit.  For example, the I2RS RIB node unit is the route.

 d.  There is one priority per client.

 e.  Priority is kept in the NACM at the client level [rather than path
 level (5/27 meeting) or group level (list discussion).



 3)  Joel suggests that large data write may be best done in netconf with
 guarantees

 a.   I2RS will be focused on highly asynchronous interfaces with less
 than full routing tables.

 b.  A client whose large data is interrupted by a notification has a
 difficult time determine when the notification happened in the stream – so
 the I2RS client must ask the agent again.

 c.   Logging for traceability is different than event notification.



 4)  Secondary identity data is meta-data that is stored in the agent.
 Agent does not do anything with the meta-data. The client has to do one edit
 per secondary at a time.



 5)  Secondary identity data is read-only meta-data that is stored in the
 agent associated with a data model node that is being created or updated
 (write-access) in the data store.





 6)  I2RS Client and Agent Identities are mutually authenticated by
 Authentication server (AAA),

 The values of identities are originally set by operators.





 Does anyone have any concerns regarding these requirements?



 Sue Hares




 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman]

On Fri, May 29, 2015 at 9:25 AM, Juergen Schoenwaelder
j.schoenwael...@jacobs-university.de wrote:
 Thanks for all the details but I am missing an answer to my question.
 Shall I repeat it once more?

The proposal is that the priority is a property of each NACM rule.
Since NACM rules can be shared by multiple groups this design will
not actually work.  As Martin pointed out, rules common to multiple
groups will produce data with the same priority.  It should also
be noted that NACM has default behavior that is followed even
if no rules are actually configured.

IMO priority is associated with the client.
A client can be placed in multiple NACM groups.
When an edit request is made the client does not
indicate which group should be used.  The server will
pick the highest priority group that the user is a member,
and use that for the priority. (Therefore priority is
not the property of the group either).

It has been suggested that the client can connect multiple times,
and each transport connection will somehow convey a different
priority to the server.  I don't see how this will work.  It seems
that different client names are needed.  This is true whether NACM
or a client mapping table is used.  The system must produce a different
client name in order to use a different priority.




 /js

Andy


 On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote:
 Juergen:



 Thank you for asking the question again. I appreciate your patience as I
 attempt to answer your question carefully.



 Short answer: I2RS strategy is re-use of other protocols rather than invent,
 and this seemed a reasonable place to put it.



 Context: Jeff's document is a proposal for the requirements for I2RS to the
 NETCONF/NETMOD WG on ephemeral state.  Feedback on the earlier descriptions
 from the I2RS group had been too vague so Jeff's document is providing
 detailed requirements.  I2RS is not designing thing for NETCONF only making
 known in detailed terms our requirements to aid the NETCONF group's response
 on whether the I2RS design requirements can be met.



 Longer Answer:  His proposal arises out of section 4.2 in the I2RS
 architecture document.  This section states:



 An approach to a similar access control problem is defined in the NetConf
 Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be
 specified for a data node instance identifier while defining meaningful
 manipulable defaults.  The identity within NACM [RFC6536] can be specifying
 as either a user name or a group user name (e.g.  Root), and this name is
 linked a scope policy that contained in a set of access control rules.
 Similarly, it is expected the I2RS identity links to one role which has a
 scope policy specified by a set of access control rules.  This scope policy
 is can be provided via Local Config, exposed as an I2RS Service for
 manipulation by authorized clients, or via some other method (e.g.   AAA
 service).



 You can see in this point that the client identity is being linked to the
 scope policy controlling read or write.  Section 7.8 points out that
 priority ensures predictability in write conditions between two I2RS
 Clients trying to write data in one agent, or between an I2RS client and the
 local config.   Jeff's requirements flow out of these two sections in the
 architecture document.



 What you can do: If you have an alternate suggestion for priority for Jeff's
 document, please make a suggestion and indicate why you think it fits within
 the I2RS architecture document (please list sections).



 Sue



 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
 Sent: Friday, May 29, 2015 2:10 AM
 To: Susan Hares
 Cc: i2rs@ietf.org; chen@zte.com.cn; 'Andy Bierman'; 'Alia Atlas';
 'Jeffrey Haas'; 'Joel M. Halpern'
 Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00



 On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote:

  Andy:

 

  Thank you for your question.  Let me precise.

 

  Jeff proposes that clients specify the priority mechanism is an attribute
 that is stored in the NACM list on the agent (see Section 5.2 as described
 in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).   The
 client-Agent identities are load in a mechanism which is out-of-band from
 the I2RS protocol these values.  Into the Client, the Agent's ID is loaded.
 Into the Agent, the valid client's identity is loaded along with the
 client's priority.  AAA (Radius/Diameter) is an example of an out-of-band
 mechanism to pass the information with.  IMU (in my understanding), the NACM
 on the agent is created based on this AAA loading.  The i2rs secondary
 identity is loaded via an edit-config mechanism in a config operation (see
 section 5.1 of Jeff's document.).  Please let me know if my understanding of
 NACM creation based on AAA input is correct.

 



 So I will ask again: If the priority is a property of the I2RS client (this
 is how I understand

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman]

On Fri, May 29, 2015 at 2:55 PM, Susan Hares sha...@ndzh.com wrote:
 Andy:



 On all actions working or not – you should look at section 7.9 of the
 architecture.  It allows “perform all or none”, “perform until error”, and
 “perform all storing errors.”I will propose an addition to section 2.4
 to Jeff’s document:



OK -- I remember these options now.

It should be clear in the document that stopping on error or recording
errors does not mean the agent will leave the datastore in an invalid
state.  Most YANG validation errors can be pruned from the datastore.
This may or may not leave the datastore in an operationally useful state.
The must/min-elements/unique statements can cause validation errors
on nodes outside the edit list.

NETCONF does not allow validation errors in the running datastore.
I2RS should not allow validation errors in the ephemeral data.


Andy


 2.4 ) Transaction to ephemeral state:



 The ephemeral state should support a multiple parts of a operation occurring
 in a single message, but it does not require multi-message atomicity and
 rollback. Three types of error handling should be supported:



Perform all or none:   This traditional SNMP semantic indicates that

   other I2RS agent will keep enough state when handling a single

   message to roll back the operations within that message.  Either

   all the operations will succeed, or none of them will be applied

   and an error message will report the single failure which caused

   them not to be applied.  This is useful when there are, for

   example, mutual dependencies across operations in the message.



Perform until error:   In this case, the operations in the message

   are applied in the specified order.  When an error occurs, no

   further operations are applied, and an error is returned

   indicating the failure.  This is useful if there are dependencies

   among the operations and they can be topologically sorted.



Perform all storing errors:   In this case, the I2RS Agent will

   attempt to perform all the operations in the message, and will

   return error indications for each one that fails.  This is useful

   when there is no dependency across the operation, or where the

   client would prefer to sort out the effect of errors on its own.



In the interest of robustness and clarity of protocol state, the

protocol will include an explicit reply to modification or write

operations even when they fully succeed.





 Will this cover the architecture document 7.9 transactions impact on
 ephemeral state?



 Sue Hares



 From: Susan Hares [mailto:sha...@ndzh.com]
 Sent: Friday, May 29, 2015 1:44 PM
 To: 'Andy Bierman'
 Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
 'i2rs@ietf.org'; 'chen@zte.com.cn'; 'Alia Atlas'
 Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00



 Andy:



 I missed the second part of the email
 (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in my
 earlier message:



.  The last paragraph sounds like some nodes will be accepted and others
 rejected.

If any nodes are rejected, the entire edit should be rejected.



 RESTCONF does an atomic action within a http session.   NETCONF within a
 commit.  Section 6.2 of the I2RS architecture document describes state
 storage for I2RS, and it does not have the atomic requirement for the
 protocol.  Instead section 3.3 of the I2RS architecture document calls for
 this to be model driver.  Let me provide examples from the 2 major I2RS
 protocol independent models:



 The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00)  proposes that
 each route will be associated with the following: route preference, active,
 installed.  Notifications for route change will be given if route is
 installed, active, and a reason given, or if the route commit fails. Some
 routes may be accepted, and some routes rejected for installation to the
 RIB.   The concept is the client will be able to detect when a route is
 rejected.



 The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses the
 challenge that topology models are not: configuration data only or
 operational data only – but a combination of both in ephemeral state.
 Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology model
 which is operational (read-only) that contains data from: a) only read from
 operational units, b) a configured topology, and c) combination topology
 (operational state and configured).  (A second alternative is to just have
 “a” and “b”, but for now let’s focus on a, b, and c).  The “C” combination
 topology may be generated based on priority of configured topology versus
 operational data.  The inclusion in “c” may also be validated (E.g.
 interface up, or L3 link runs on tunnel over interface which is up)).



 These two model documents show why atomic state may be on a very small
 section of the whole

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman]

On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern j...@joelhalpern.com wrote:
 Some of the discussions in the working group earlier (not formally captured
 in the archtiecture, and not clarified in discussion) were of the form
 If the operator wants to shoot himself in the foot, I2RS' job is to let
 him.
 If that is the model that the working group is assuming, then I am not sure
 that consistency / validity enforcement is desired.

 I don't have a strong opinion one way or another.  I believe at least some
 people saw the omission of such checks as a path to improvd transaction
 rates.

 My only concern is to avoid accidentally chaning a working group agreement.



IMO it is extremely difficult to implement a datastore that is allowed
to have schema-invalid contents.  It is one thing to accept the good
edits and reject the bad edits.  It is quite another to force the server
to accept bad edits.

I don't think the text is very clear at all.
Let's say I have an edit list with 5 edits.
Edits 1, 3, and 5 are good and edits 2 and 4 are bad:

1) all-or-none: (NETCONF: rollback-on-error)
 - no changes to datastore;
 - errors logged for #2 and #4 (or maybe just #2)

2) until-error: (NETCONF stop-on-error)
 - edit #1 applied to datastore;
 - error logged for #2

3) all storing errors: (NETCONF continue-on-error)
- edits #1 and #3 and #5 applied
- errors logged for #2 and #4

This is my understanding of the 3 options.



 yours,
 Joel

Andy


 On 5/29/15 9:59 PM, Susan Hares wrote:

 Andy:

 See one question below.  If alter to not store invalid values in the
 datastore - is my addition to Jeff's 2.4 addition acceptable?

 Sue

 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Andy Bierman
 Sent: Friday, May 29, 2015 8:42 PM
 To: Susan Hares
 Cc: i2rs@ietf.org; Jeff Haas; chen@zte.com.cn; Juergen Schoenwaelder;
 Alia Atlas; Jeffrey Haas; Joel M. Halpern
 Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

 On Fri, May 29, 2015 at 2:55 PM, Susan Hares sha...@ndzh.com wrote:

 Andy:



 On all actions working or not – you should look at section 7.9 of the
 architecture.  It allows “perform all or none”, “perform until error”,
 and
 “perform all storing errors.”I will propose an addition to section
 2.4
 to Jeff’s document:



 OK -- I remember these options now.


 It should be clear in the document that stopping on error or recording
 errors does not mean the agent will leave the datastore in an invalid
 state.  Most YANG validation errors can be pruned from the datastore.
 This may or may not leave the datastore in an operationally useful state.
 The must/min-elements/unique statements can cause validation errors on
 nodes outside the edit list.

 NETCONF does not allow validation errors in the running datastore.
 I2RS should not allow validation errors in the ephemeral data.


 [sue]:  On case: or if perform and until error / or perform and record
 error - you are assuming these are a validation error?
 You are commending I2RS should not store values with invalid data.   Are
 you against logging the validation errors?

 Andy


 2.4 ) Transaction to ephemeral state:



 The ephemeral state should support a multiple parts of a operation
 occurring in a single message, but it does not require multi-message
 atomicity and rollback. Three types of error handling should be
 supported:



 Perform all or none:   This traditional SNMP semantic indicates that

other I2RS agent will keep enough state when handling a single

message to roll back the operations within that message.  Either

all the operations will succeed, or none of them will be applied

and an error message will report the single failure which caused

them not to be applied.  This is useful when there are, for

example, mutual dependencies across operations in the message.



 Perform until error:   In this case, the operations in the message

are applied in the specified order.  When an error occurs, no

further operations are applied, and an error is returned

indicating the failure.  This is useful if there are
 dependencies

among the operations and they can be topologically sorted.



 Perform all storing errors:   In this case, the I2RS Agent will

attempt to perform all the operations in the message, and will

return error indications for each one that fails.  This is
 useful

when there is no dependency across the operation, or where the

client would prefer to sort out the effect of errors on its own.



 In the interest of robustness and clarity of protocol state, the

 protocol will include an explicit reply to modification or write

 operations even when they fully succeed.





 Will this cover the architecture document 7.9 transactions impact on
 ephemeral state?



 Sue Hares



 From: Susan Hares [mailto:sha...@ndzh.com]
 Sent

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman]

On Thu, May 28, 2015 at 4:22 PM, Susan Hares sha...@ndzh.com wrote:
 Andy:

 Yes - the client with priority and secondary identity are inherently simple 
 additions.   Can you confirm my understanding below based on Jeff's document?


Not sure what you mean.
i don't think the client should provide the priority in request messages.
This is configured on the agent, not requested by the client.


 Can you explain  your statement I do not want to change NETCONF or RESTCONF 
 to use client priority?  What are you proposing that you do not want to add 
 the NACM list the priority?

I don't want to change NETCONF and RESTCONF so that config=true
objects use priority.  Only I2RS should use it.


 Sue

Andy

 ===

 Example
 
 1) any multiple TCP sessions from a client application will use a different 
 ID if they want a different priority for write of an object
  Application 1:  TCP session 1 -  priority 1,  secondary-identity 
  pub-sub monitor
  Application 1:  TCP session 2 - priority 10, secondary-identity 
 tracing monitor
 Application 1:  TCP session 3 -  priority 20, opaque Weekly config
 Application 1:  TCP session 4 -  priority 55, opaque Emergency 
 config

 Jeff's META-data  example:

   foo xmlns:i2rs=https://ietf.example.com/i2rs;
 i2rs:i2rs-secondary-identity=user1 i2rs:i2rs-priority=47
...
/foo

 For my example TCP session 1
foo xmlns:i2rs=http:s//ietf.example.com/i2rs
 I2rs:i2rs-secondary-identity=pub-sub montior i2rs:i2rs-priority=1

 Juergen's client example:

 list i2rs-client {
key name;
   leaf name {
  description The client name;
  type i2rs:client-name;
}
leaf priority {
   description The priority value assigned to this client.;
  type i2rs:client-priority;
   }
 }

+--rw rule-list [name]
   +--rw name string
   +--rw group*   union
   +--rw rule [name]
  +--rw name string
  +--rw module-name?  union
  +--rw (rule-type)?
  |  +--:(protocol-operation)
  |  |  +--rw rpc-name?  union
  |  +--:(notification)
  |  |  +--rw notification-name?  union
  |  +--:(data-node)
  | +--rw path node-instance-identifier
  +--rw access-operations?  union
  +--rw action action-type
  +--rw comment?  string
  +--rw i2rs:i2rs-priority i2rs-priority-type

 Are you proposing something different than Jeff's proposal?

 Sue

 -Original Message-
 From: Andy Bierman [mailto:a...@yumaworks.com]
 Sent: Thursday, May 28, 2015 11:17 AM
 To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey Haas; 
 i2rs@ietf.org; chen@zte.com.cn; Alia Atlas; Susan Hares
 Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

 On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder 
 j.schoenwael...@jacobs-university.de wrote:
 On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote:

 Although I should be promoting use of NACM, I am not so sure it
 should be mandatory for I2RS or required to configure I2RS client priority.

list i2rs-client {
   key name;
   leaf name {
  description The client name;
  type i2rs:client-name;
   }
   leaf priority {
 description The priority value assigned to this client.;
 type i2rs:client-priority;
  }
   }

 So what is i2rs:client-name - is it any different from a
 NETCONF/RESTCONF username?


 Is is probably not different.


 NACM maps user names into groups and NACM allows to have the mapping
 supplied by an external source (e.g. RADIUS). If this priority mapping
 is kept separate from NACM, would we need to provision means to get
 the priority from AAA as well?


 My point showing the 2 item list is that the information needed to implement 
 I2RS client priority is rather trivial.
 It can certainly be made really complicated by the IETF, but it is an 
 inherently trivial configuration.

 And the bigger question: Do we create something specific for I2RS or
 are we going to extend the generic YANG/NC/RC framework to provide the
 tools I2RS needs? This is probably a question the NETCONF WG has to
 answer.

 It is good to make reusable features.
 I don't want to change NETCONF or RESTCONF to use client priority.
 Let I2RS prove it is useful first.  I am not convinced it will really help.
 It seems like an implementation detail that is being turned into ad 
 administrative task.  If multiple clients from multiple vendors are stepping 
 on each other, then the likely outcome of a priority change by the 
 administrator will be to select which clients should continue working and 
 which should be broken.



 /js


 Andy

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman]

On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder
j.schoenwael...@jacobs-university.de wrote:
 On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote:

 Although I should be promoting use of NACM, I am not so sure it should
 be mandatory for I2RS or required to configure I2RS client priority.

list i2rs-client {
   key name;
   leaf name {
  description The client name;
  type i2rs:client-name;
   }
   leaf priority {
 description The priority value assigned to this client.;
 type i2rs:client-priority;
  }
   }

 So what is i2rs:client-name - is it any different from a
 NETCONF/RESTCONF username?


Is is probably not different.


 NACM maps user names into groups and NACM allows to have the mapping
 supplied by an external source (e.g. RADIUS). If this priority mapping
 is kept separate from NACM, would we need to provision means to get
 the priority from AAA as well?


My point showing the 2 item list is that the information
needed to implement I2RS client priority is rather trivial.
It can certainly be made really complicated by the IETF,
but it is an inherently trivial configuration.

 And the bigger question: Do we create something specific for I2RS or
 are we going to extend the generic YANG/NC/RC framework to provide the
 tools I2RS needs? This is probably a question the NETCONF WG has to
 answer.

It is good to make reusable features.
I don't want to change NETCONF or RESTCONF to use client priority.
Let I2RS prove it is useful first.  I am not convinced it will really help.
It seems like an implementation detail that is being turned into
ad administrative task.  If multiple clients from multiple vendors
are stepping on each other, then the likely outcome of a priority
change by the administrator will be to select which clients
should continue working and which should be broken.



 /js


Andy

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman]

On Wed, May 27, 2015 at 4:35 PM, Joel M. Halpern j...@joelhalpern.com wrote:
 I believe that most of us expect that in I2rs:
 Priority is associated with a client.
 A client does not get to change its priority (although adminsitrators
 clearly can).
 When a client performs an operation, the client identity and priority are
 recorded both for traceability and for future comparison.
 If a later action attempts to modify the same item, the acting client
 identity and priority are compared with the stored values.

 (While I read the architecture as saying that, I could be too close to the
 document.)


Sounds right to me.

Jeff suggested in the conf-call that the i2rs-priority can be moved to
the 'group' list.
(I prefer the term 'client-priority').

Although I should be promoting use of NACM, I am not so sure it should
be mandatory for I2RS or required to configure I2RS client priority.


   list i2rs-client {
  key name;
  leaf name {
 description The client name;
 type i2rs:client-name;
  }
  leaf priority {
description The priority value assigned to this client.;
type i2rs:client-priority;
 }
  }

I think I2RS interaction with NACM needs to be clearly defined.
NACM implementations do not currently check write requests
on config=false data. It is possible some edits to NACM are needed
even if no objects are added to the data structure.

In either case there is the issue of what happens to existing data if
the client priority is changed by the administrator. Does it keep
the old priority or change to the new priority?



 Yours,
 Joel


Andy


 On 5/27/15 6:09 PM, Juergen Schoenwaelder wrote:

 On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote:

 [discussion about priority]

 . [Jeff]: It is stored in the NACM for client, and the client
 identity is tagged to a node (E.g. per route).


 This further implies that priority is an attribute that is stored in
 the NETCONF Access Control Model [RFC6536
 https://tools.ietf.org/html/rfc6536 ] as part of a rule-list.
 E.g.:



 +--rw rule-list [name]

+--rw name string

+--rw group*   union

+--rw rule [name]

   +--rw name string

   +--rw module-name?  union

   +--rw (rule-type)?

   |  +--:(protocol-operation)

   |  |  +--rw rpc-name?  union

   |  +--:(notification)

   |  |  +--rw notification-name?  union

   |  +--:(data-node)

   | +--rw path node-instance-identifier

   +--rw access-operations?  union

   +--rw action action-type

   +--rw comment?  string

   +--rw i2rs:i2rs-priority i2rs-priority-type


 I am confused since sometimes it sounds like the priority is a
 property of an I2RS client and yet at other times it sounds like the
 priority is associated with a scope accessible for an I2RS client.

 If I understand Jeff correctly, then he proposes that a data node
 remembers the identity of the I2RS client that created / last modified
 it and the priority is obtained at the time a confict needs to be
 resolved (and hence the priority may be different from the priority
 that was in effect when the data node was created / last modified).

 Note that NETCONF/RESTCONF so far allows every client with proper
 access rights to modify data nodes. There is no notion of ownership in
 the sense that if something got written by A then B cannot update it
 unless B has higher priority. If A and B have the same priority (which
 is so far always the case), then the last write wins.  The I2RS
 architecture document, however, requires that the first write blocks
 any subsequent writes:

 remains in effect.  In the case of priority ties, the first client
 whose attribution is associated with the data will keep control.

 If NETCONF/RESTCONF gets extended with ownership and priorities, I
 think it would be desirable if the current behaviour (where all
 clients have the same priority) would still fall out naturally.

 /js


 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] 2 week WG adoption call for draft-dong-i2rs-l2-network-topology-01.txt

[Andy Bierman]

On Tue, Apr 7, 2015 at 7:17 AM, Thomas D. Nadeau
tnad...@lucidvision.com wrote:

 On Apr 7, 2015:9:39 AM, at 9:39 AM, Susan Hares sha...@ndzh.com wrote:


 Juergen:

 This is good feedback on the L2 topology versus interface module.

 Stating taking out all objects that are interface specific is a bit broad,
 but in principle specifics that belong to interfaces should be in the
 interfaces module.  The L2 specification is part of a virtual topology that
 reflects interfaces, links, nodes, and terminating points. There will be
 some references to the virtual principles.  Some things chassis-id imply a
 shared group resources (interfaces in a chassis) which creates a shared risk
 group.  The virtual topology needs to indicate which interfaces are within a
 shared risk group.  As Jie has mentioned, he will take into account your
 comments in the next revision of the draft.

 I agree with Juergen on the interfaces point. I also want to remind 
 folks
 that the chassis-related stuff are being broken off and put into the
 effort to build the Entity-MIB Yang Model.  There is a design team that
 I kicked off in NETMOD to do this work. Jimmy is part of that DT and
 should be able to sync up with that effort.


Hi,

The design team met for several hours in Dallas.
I will be producing an initial draft based on those discussions.
I will send meeting notes to the WG mailing list first.

We most focused on how to adapt the existing ENTITY MIB modules,
not on missing data that I2RS needs beyond the adapted MIB modules.


 --Tom

Andy



 I have already spoken to some IEEE people about who to talk to about the
 LLDP yang modules.  It appears the appropriate group is the 802.1 working
 group, and I will send a note to the chair today.

 Sue

 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder
 Sent: Tuesday, April 07, 2015 5:45 AM
 To: Dongjie (Jimmy)
 Cc: i2rs@ietf.org; Susan Hares
 Subject: Re: [i2rs] 2 week WG adoption call for
 draft-dong-i2rs-l2-network-topology-01.txt

 On Tue, Apr 07, 2015 at 09:36:18AM +, Dongjie (Jimmy) wrote:
 Hi Juergen,

 Thanks for your comments on this L2 topology model. Please see some
 replies inline.

 -Original Message-
 From: Juergen Schoenwaelder
 [mailto:j.schoenwael...@jacobs-university.de]
 Sent: Monday, April 06, 2015 11:18 PM
 To: Susan Hares
 Cc: i2rs@ietf.org; Dongjie (Jimmy)
 Subject: Re: [i2rs] 2 week WG adoption call for
 draft-dong-i2rs-l2-network-topology-01.txt

 On Mon, Apr 06, 2015 at 09:11:39AM -0400, Susan Hares wrote:
 This begins a 2 week adoption call for
 draft-dong-i2rs-l2-network-topology-01.

 Please indicate in your comments support or no support and
 discuss how this draft will allow I2RS client-agent pairs to query
 information about L2 topology.  The draft can be found at:

 http://datatracker.ietf.org/doc/draft-dong-i2rs-l2-network-topolog
 y/

 http://datatracker.ietf.org/doc/draft-clemm-i2rs-yang-l3-topo/

 I wonder how this will interwork with any possible IEEE work.
 Bridges and VLANs had been modeled as MIBs back in a day but we
 meanwhile transferred work all over to IEEE. I think there should be
 some IEEE liaison interaction here.

 I also wonder to what extend this data model is repeating things
 that are already in the interfaces abstraction we have. There is no
 mention of RFC 7223 yet there is overlap.

 As a topology model, the L2 topology model is focusing on the overview of
 connectivity between the network entities from layer-2's perspective, thus
 the detailed config and operational information of interfaces will not be
 covered in this model, only those which are used as the identifiers of nodes
 and termination-points are included. We will take a look at whether the
 interface model should be referenced here.


 Are you saying you will take out all objects that are interface specific? I
 think there should be text explaining the relationship to the
 ietf-interfaces model and extensions of it.

 The chassis-id here has the same meaning as it is in LLDP. Currently its
 type is set to mac-address as one common implementation. This could be
 updated with a more generic type.

 Well, it is simply under specified what it is. And there is the model of
 physical entities where a chassis has a specific meaning. Anyway, there
 needs to be more relationship sections explaining all this. But at this
 point, many things are simply too vague to understand what they mean and it
 is unclear where the information would come from.

 /js

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

 ___
 i2rs mailing list
 i2rs@ietf.org
 

Re: [i2rs] I-D Action: draft-ietf-i2rs-pub-sub-requirements-01.txt

[Andy Bierman]

Hi,

This draft says it addresses 2 deficiencies w/ existing mechanisms:

 The existing YANG technology ecosystem
   is proving insufficient for those applications due to:

   o  a reliance on RPC-style interactions where data is configured or
  fetched on-demand by applications.

   o  change notifications which identify a node associated with the
  config change, without the actual data updates


I don't understand why RFCs for configuration are a problem.
The nice thing about polling is that the server is fairly
sure the client is alive and still wants the updated info.

I certainly agree that things could be simpler on the client by
moving complexity to all the servers instead.  Not sure the
extra work each device will do is worth the increase in required
resources.

Currently, NETCONF/NACM does not support the access control
granularity that would be required to prune unauthorized data
from notifications (e.g., netconf-config-change for some unauthorized
data requires the new value to be removed from the payload,
depending on the user-id of the recipient).

Keeping the config data out of the notification was
a deliberate decision by the NETCONF WG, because of increased complexity
on the server, increased payload size, and lack of access-control support.



Andy




On Mon, Mar 9, 2015 at 3:03 PM,  internet-dra...@ietf.org wrote:

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.
  This draft is a work item of the Interface to the Routing System Working 
 Group of the IETF.

 Title   : Requirements for Subscription to YANG Datastores
 Authors : Eric Voit
   Alex Clemm
   Alberto Gonzalez Prieto
 Filename: draft-ietf-i2rs-pub-sub-requirements-01.txt
 Pages   : 16
 Date: 2015-03-09

 Abstract:
This document provides requirements for a service that allows client
applications to subscribe to updates of a YANG datastore.  Based on
criteria negotiated as part of a subscription, updates will be pushed
to targeted recipients.  Such a capability eliminates the need for
periodic polling of YANG datastores by applications and fills a
functional gap in existing YANG transports (i.e.  Netconf and
Restconf).  Such a service can be summarized as a pub/sub service
for YANG datastore updates.  Beyond a set of basic requirements for
the service, various refinements are addressed.  These refinements
include: periodicity of object updates, filtering out of objects
underneath a requested a subtree, and delivery QoS guarantees.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-01

 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pub-sub-requirements-01


 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [secdir] Asynchronous Nature of the I2RS Protocol - vs RESTCONF and NETCONF

[Andy Bierman]

On Fri, Mar 6, 2015 at 10:04 AM, Jeffrey Haas jh...@pfrc.org wrote:
 On Thu, Mar 05, 2015 at 09:18:02AM +0100, Juergen Schoenwaelder wrote:
 On Wed, Mar 04, 2015 at 03:57:50PM -0800, Andy Bierman wrote:
   The simple solution is to make A B C one atomic edit.
  
 
 
  We use entity tags and If-Match in RESTCONF so the client can
  be sure it is editing the correct version of the resource instance.
  This works nicely for persistent configuration, especially if
  the server can reboot with the same config ETags.
 
  If-Match will cause the edit to fail if the server reboots and the
  I2RS state is gone.
  The client will get a 412 Precondition Failed response and know it might 
  have to
  start over.
 
  RESTCONF only requires the server to maintain an ETag for the config root.
  Finer granularity (e.g., the parent resource has an ETag) is probably 
  needed
  to support multiple concurrent edits.
 

 Thanks, this all makes sense. So there is a viable mechanism to create
 a sequence of linked edits. The main trade-off, however, between a
 single atomic edit and a sequence of linked edits is who is taking the
 pain to cleanup the mess if things fail in the middle. If you write a
 client, you love the server to do it. If you write a server, you love
 the client to do it. ;-)

 It's all pain, but some component has to deal with it.

 I'm glad that restconf seems to have this situation covered, Andy.  Is there
 a similar mechanism in netconf that I've missed?  If so, this completely
 deals with the need for i2rs to have to ask for anything new. :-)


NETCONF has no support at all for this sort of thing.

 -- Jeff

Andy

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I2RS Interim Meeting

[Andy Bierman]

On Thu, Jan 22, 2015 at 10:26 AM, Susan Hares sha...@ndzh.com wrote:
 The slides and minutes for the I2RS meeting are at:



 http://www.ietf.org/proceedings/interim/2015/01/22/i2rs/proceedings.html



 An outgrowth of the meeting is that the working group will consider adoption
 of

 draft-voit-i2rs-pub-sub-requirements-00 next week.



 The draft-ietf-i2rs-traceability document will be revised, and enter into a
 WG LC call within 3 weeks.



 Please read and consider these documents.



I strongly support adoption of draft-voit-i2rs-pub-sub-requirements-00
and draft-netmod-clemm-datastore-push-00.

However, I do not see anything really I2RS-specific about
most of the requirements or any of the solution.
This is useful for all types of system data modeled in YANG.

We should only need one standard for pub/sub and push
of YANG-defined data within NETCONF-style conceptual datastores.



 Sue Hares and Jeff Haas


Andy


 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Point about writable running

[Andy Bierman]

On Sat, Nov 29, 2014 at 3:41 AM, Juergen Schoenwaelder
j.schoenwael...@jacobs-university.de wrote:
 On Fri, Nov 28, 2014 at 02:39:21PM -0500, Jeffrey Haas wrote:
 Joel,

 On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:
  I don't recall seeing that form of commit in any protocol that has
  been proposed.  I think it would be rather hard to do.

 One of the prior complicating details had been I2RS saying we'd use netconf
 and restconf when we selected our protocol earlier this year.

 As we've since seen, netconf commit and datastore semantics (protocol
 components) significantly complicate our needs.  This has been a detail that
 I believe is pushing netconf off the table and moving us more firmly into
 restconf.

 I like to understand this better. My understanding is that there are
 several implementations underway that use the same backend
 infrastructure for both NETCONF and RESTCONF. So I wonder how RESTCONF
 exposes datastore semantics that are simpler to deal with than NETCONF
 datastore semantics. I personally find the 'unified' datastore defined
 in RESTCONF somewhat handwaving.

Each RESTCONF edit of a datastore resource is saved to non-volatile
storage in an implementation-specific matter by the server.  There is
no guarantee that configuration changes are saved immediately, or
that the saved configuration is always a mirror of the running
configuration.

 This leaves it completely up to the implementation what is made
 persistent and when. While this may be great for implementors, I am
 not sure how this gives you predictable semantics needed to build
 implementations that work with different protocol implementations.


Not what, just when.  The text is intended to allow for implementations
that may NV-save in the background, so a reboot just after an
edit may or may not come back.  I will try to clarify this text in the
-04 version.



 Yes, I this is an issue I should raise on the NETCONF list. But for
 me, a protocol with unclear semantics is even harder to deal with than
 a protocol where it is actually clear in which situations which
 content is made persistent.


IMO the combination of RESTCONF (+ TBD extensions)
and YANG Patch allows the client to clearly specify the intended results,
and the unified datastore lets the server integrate the ephemeral datastore
with the running config and the operational state however it wants.



 /js


Andy


 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Point about writable running

[Andy Bierman]

On Sat, Nov 29, 2014 at 6:42 PM, Joel M. Halpern j...@joelhalpern.com wrote:
 I can not tell from your description Andy who has control and who has
 predictability.  If the device folds the I2RS changes into the permanent
 state, and saves them, it will make a mess with the way the WG has assumed
 things to work.



I am not suggesting the I2RS edits ever change the running or persistent
configuration.  The TBD extensions include some mechanism to
tell RESTCONF to edit the ephemeral config instead of any other datastore.

ephemeral for I2RS:

  PATCH /restconf/edata

running for RESTCONF:

  PATCH /restconf/data



 Yours,
 Joel

Andy



 On 11/29/14, 9:38 PM, Andy Bierman wrote:

 On Sat, Nov 29, 2014 at 3:41 AM, Juergen Schoenwaelder
 j.schoenwael...@jacobs-university.de wrote:

 On Fri, Nov 28, 2014 at 02:39:21PM -0500, Jeffrey Haas wrote:

 Joel,

 On Thu, Nov 13, 2014 at 11:28:04PM -0500, Joel M. Halpern wrote:

 I don't recall seeing that form of commit in any protocol that has
 been proposed.  I think it would be rather hard to do.


 One of the prior complicating details had been I2RS saying we'd use
 netconf
 and restconf when we selected our protocol earlier this year.

 As we've since seen, netconf commit and datastore semantics (protocol
 components) significantly complicate our needs.  This has been a detail
 that
 I believe is pushing netconf off the table and moving us more firmly
 into
 restconf.


 I like to understand this better. My understanding is that there are
 several implementations underway that use the same backend
 infrastructure for both NETCONF and RESTCONF. So I wonder how RESTCONF
 exposes datastore semantics that are simpler to deal with than NETCONF
 datastore semantics. I personally find the 'unified' datastore defined
 in RESTCONF somewhat handwaving.

 Each RESTCONF edit of a datastore resource is saved to non-volatile
 storage in an implementation-specific matter by the server.  There is
 no guarantee that configuration changes are saved immediately, or
 that the saved configuration is always a mirror of the running
 configuration.

 This leaves it completely up to the implementation what is made
 persistent and when. While this may be great for implementors, I am
 not sure how this gives you predictable semantics needed to build
 implementations that work with different protocol implementations.


 Not what, just when.  The text is intended to allow for implementations
 that may NV-save in the background, so a reboot just after an
 edit may or may not come back.  I will try to clarify this text in the
 -04 version.



 Yes, I this is an issue I should raise on the NETCONF list. But for
 me, a protocol with unclear semantics is even harder to deal with than
 a protocol where it is actually clear in which situations which
 content is made persistent.



 IMO the combination of RESTCONF (+ TBD extensions)
 and YANG Patch allows the client to clearly specify the intended results,
 and the unified datastore lets the server integrate the ephemeral
 datastore
 with the running config and the operational state however it wants.



 /js


 Andy


 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs




___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Point about writable running

[Andy Bierman]

On Thu, Nov 13, 2014 at 6:57 PM, Joe Clarke jcla...@cisco.com wrote:
 During today's meeting Dean made a comment that we could use writable
 running as a way to do ephemeral state.  I have a concern about this.  I
 know it may seem like an implementation detail, but I feel that most vendors
 (and operators) assume that things in the running datastore _could_ become
 persistent.

 That is, if I write to the running data store, and my human user sees these
 I2RS ephemeral state in the show running-config (or the like), they might
 think those are persistent.  There is no indication that they are ephemeral.
 On top of that, some NMS systems that use screen-scraping for config archive
 might grab this ephemeral config and later restore state that should not be
 restored.


I think the local-config=persistent assumption is flawed.
In IOS, local config does not persist unless and until the write mem
command is invoked. Persistence is often an operator decision,
not hard-wired into the transaction.


 I just wanted to bring this up as I would rather see more of the panes of
 glass approach rather than try to override an existing datastore for this
 kind of thing.  Or maybe I misunderstood Dean's comment...

I agree.
Tagging the config data as ephemeral does not work if
the local config needs to re-activate once the I2RS state is removed.
(e.g., next-hop example).  A YANG instance-identifier cannot
distinguish between the config and ephemeral versions of each node.


I think Dean meant the I2RS edits take effect right away, like
:writable-running in NETCONF.  There is no commit phase,
like with the candidate datastore.




 Joe

Andy



 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Why do we need a datastore?

[Andy Bierman]

On Mon, Oct 6, 2014 at 8:01 AM, Alia Atlas akat...@gmail.com wrote:

 On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote:
  Now - if we have to decide that the CLI always wins, that is one option.
  I, personally, would be quite opposed to the idea that I2RS would always
  win.  That does not give recovery mechanisms to the operators when and
  if something goes wrong.

 So, what is your proposal to allow CLI/local config to win over ephemeral
 state?  If not something comparable to option 4, what then?


 Jeff,

 It's a good question.  I have been sweeping it under
 implementation-specific
 since it is up to an implementation to decide what collides.  If we were
 talking about
 vendor-specific CLI vs. YANG models for I2RS, how would it work?  At the
 end of
 the day, there has to be understanding of what internally is impacted.


If an I2RS client needs to monitor system state, local config changes,
and also know the proprietary CLI in order to function, it will be too
complicated
to implement. If the CLI or local config has disabled I2RS for some or all
clients,
then the requests will get rejected by the agent. Proprietary data models
and
CLI should be out of scope.


I can picture different abstractions or subsets being exposed for I2RS
 rather than
 CLI or NetConf-for-config.  I do go more towards Russ's idea of I2RS as a
 routing
 protocol that cooperates with the other routing protocols rather than just
 another name
 for a management protocol.


I was surprised at the interim that every config=true schema node could
apply
to running config or ephemeral data, and it is always an operator decision
as to
which instances go in which datastore.  This seems like a vendor decision
first.

I also figured I2RS would ignore local config and just attempt to inject
routing state.
It is up to the agent to resolve local config with ephemeral config to
produce
operational state.  I can see local CLI disabling I2RS, but not competing
with
it to insert data, so I don't understand the CLI wins over I2RS use-case.


 Regards,
 Alia


 -- Jeff



Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Why do we need a datastore?

[Andy Bierman]

On Wed, Oct 1, 2014 at 3:05 PM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote:
 
  I don't agree that multiple ephemeral datastores are needed. Support for
  multiple clients within 1 datastore is needed.
 

 We can punt this but I believe we will be back discussing this again
 in a couple of years. If multiple clients inject state (in an
 uncoordinated way), certain things will go wrong. If we have no way to
 separate multipe uncoordinated I2RS clients (e.g., by controlling the
 priorities of different ephemeral datastores), then we will need hacks
 with metadata to work around this.


There are different priorities for clients.
The collision management and cleanup are basically the same either way,
because the agent is not required to remember state that got bumped.
It that were true, then a separate datastore per client would be a feature
instead of an implementation detail.

Perhaps it is OK to ignore multiple ephemeral datastores now in order
 to make progress. But I believe we are better off if things are
 designed such that there can be multiple ephemeral datastores when
 they are useful, that is we should not do anything to prevent having
 multiple ephemeral datastores.


It's hard enough to agree on 1 ;-)

IMO the ephemeral config always overrides the running config.
That means in order to remove a static entry from the active config
(but not the running config), there needs to be an operation
for creating a data instance deleted entry in the ephemeral datastore.
(Not a way to have I2RS actually delete entries from the running config).




 /js


Andy


 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Two thoughts on an ephemeral data store

[Andy Bierman]

On Fri, Sep 26, 2014 at 8:30 AM, Susan Hares sha...@ndzh.com wrote:

 Alexander:



 To help me understand your proposal, let us move to the previous example:



 Previous example:



   list foo {
 key id;
 leaf id { type int32; }
 leaf a { type int32; }
   }

 local config:

foo 42





So in this foo 42 step, you are assuming that the NETCONF or RESTCONF
client
told the NETCONF or RESTCONF server that the edit to the local config is
supposed
to be copied to the ephemeral datastore?  So modifications to those
protocols
to edit multiple datastores at once will be needed? (Your Q (a) below)
So we are assuming the 2 datastores are in sync so concurrent edits are
feasible?


 In ephemeral config we now do SET /foo[id=42]/a  to 4711.  Thus, in
 ephemeral we now have a single node (a) with value 4711.




You have this only if the previous step copied foo 42.
You cannot create a child node unless the parent exists or is also getting
created.
If you delete a node, the entire subtree (the XPath descendant-or-self
axis) is deleted.
I hope the various plans to couple the running and ephemeral datastores do
not
try to violate these rules.


Andy

Your model:

 a)  The value 4711 - would be a non-golden copy.

 b)  It would not be written through to the the golden copy.



 Questions:

 a)  How would you specify a write-through copy?

 b)  Can I2RS decide later it wants to write-through the golden copy?  Or
 are variables only non-write-through and write-through?

 c)  If we delete foo 42, what happens?



 Thank you,

 Sue Hares




Andy


 *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Alexander
 Clemm (alex)
 *Sent:* Thursday, September 25, 2014 8:57 PM
 *To:* Andy Bierman; Martin Bjorklund
 *Cc:* Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit)
 *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store



 FWIW, I would think the semantics should be kept simple.



 The complexity here comes from the fact that there are dependencies
 between different data stores, and some objects that are part of one data
 store need to be reflected in a different data store.



 It would seem this can be addressed with two fairly simple principles:

 (a)A datastore needs to have a clear way to reference objects in a
 different datastore, really have them incorporated into the same
 namespace.

 (b)   It needs to be clear who owns the golden copy of an object.  I
 needs to be clear which objects are authoritatively owned by a datastore
 vs which ones are reference.  This is the datastore where the object is
 maintained, updated, created; this is where conditions and constraints are
 evaluated, etc.



 Where an ephemeral datastore has dependencies on data in another
 datastore, it should incorporate these other objects by reference.  The
 objects that are authoritatively owned by the ephemeral datastore can refer
 to those objects, have them referred to in conditions and constraints, and
 so on.  (This can also indicate which ephemeral objects are to be removed
 when an object in the other datastore they depend on is deleted, etc)



 Changes to the non-ephemeral objects (e.g. the running datastore) have to
 be made to the golden copy, i.e. the owning datastore.  One way to do
 that involves implementing a write-through operation, in which an update
 to an ephemeral copy of the object is realized by having the server of the
 ephemeral datastore turn around and make a corresponding request at the
 other datastore.



 Very simple semantics.  I think this is preferrable to have different
 copies of the same object in different datastores, requiring logical
 anding (or other inter-datastore arithmetic) of different copies
 representing the same object to figure out what actual value is in effect,
 etc.



 In the netmod WG, we have today posted a draft for what we refer to as
 requirements for a peer mount (
 http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt),
 motivating why a it would be useful to have a capability to mount
 subtrees from a remote datastore into a local datastore, and the
 requirements that such a capability needs to address.  While the original
 use case and motivation described there are somewhat different, it seems
 applicable to the discussion here.



 --- Alex



 *From:* i2rs [mailto:i2rs-boun...@ietf.org i2rs-boun...@ietf.org] *On
 Behalf Of *Andy Bierman
 *Sent:* Thursday, September 25, 2014 8:44 AM
 *To:* Martin Bjorklund
 *Cc:* Jeffrey Haas; i2rs@ietf.org
 *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store







 On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund m...@tail-f.com wrote:

 Jeffrey Haas jh...@pfrc.org wrote:
  On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
   Jeffrey Haas jh...@pfrc.org wrote:
In the proposed overlay model, presume that we have ephemeral data
 from a
model that lives within an augmentation to a local config model.  In
 other
words, the ephemeral nodes

Re: [i2rs] Two thoughts on an ephemeral data store

[Andy Bierman]

On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund m...@tail-f.com wrote:

 Jeffrey Haas jh...@pfrc.org wrote:
  On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
   Jeffrey Haas jh...@pfrc.org wrote:
In the proposed overlay model, presume that we have ephemeral data
 from a
model that lives within an augmentation to a local config model.  In
 other
words, the ephemeral nodes are children of the local config nodes.
   
Presume, per discussion, that the local config lives in the config
 data
store and that the ephemeral config - the augmenting nodes above -
 live in
the ephemeral data store.
   
If we delete the container in the local config that the epehemeral
 config is
augmenting, is there any expectation that such a deletion should
 carry
through to the ephemeral config?
   
Per the netmod interim discussion, probably not.
  
   My interpretation of the interim discussion is that the deletion
   carries through.
 
  To be clear what I meant, consider:
 
  local config:  ephemeral:
  A  A/B - B is introduced as an augmentation of A

 I think there might be a terminology confusion here, so let's do a
 simple example.

   list foo {
 key id;
 leaf id { type int32; }
 leaf a { type int32; }
   }

 local config:

foo 42

 In ephemeral config we now do SET /foo[id=42]/a  to 4711.  Thus, in
 ephemeral we now have a single node (a) with value 4711.

 What happens if we in local config delete foo 42?

 If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now
 presented to the internal apps?



Yes -- and what is presented to a client that retrieves the ephemeral config
in a GET request? IMO, coupling the datastores does not make sense.

Your example is 1 reason I prefer the shadow shapshot approach.
I think the local config and client that added the foo entry in the
ephemeral datastore
are meant to have different priorities.  The entries are not coupled.
One wins and the other loses (main use-case is that ephemeral wins).

Editing foo 42 in the local config just changes what will be installed as
local config
when the device restarts (or the ephemeral state is removed).  It should
not change
the injected I2RS state at all.  IMO it is really important that edits stay
within a single
datastore.




 /martin


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements)

[Andy Bierman]

On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares sha...@ndzh.com wrote:

 Andy:



 The concept on priority and FCFS is if a remote client talks to an agent
 at a priority - then it should not be knocked out by another remote client
 coming later at the same priority.  In my mind this is different that the
 boot/reboot configuration case.   Do you think I am correct?




Sure.

I guess I am assuming each I2RS client has some reconnect-and-reload
strategy.
Normally, the clients will get notified when some data gets bumped or the
agent restarts.
Then there may be a race between the 2+ clients with same priority.

IMO ties are really errors, and the operator is going to need to assign
different priorities
or set some config so all the clients run without data collisions.


Sue




Andy


 *From:* Andy Bierman [mailto:a...@yumaworks.com]
 *Sent:* Monday, September 22, 2014 5:10 PM
 *To:* Jeffrey Haas
 *Cc:* Susan Hares; i2rs@ietf.org; net...@ietf.org
 *Subject:* Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was
 netmod interim and i2rs requirements)







 On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas jh...@pfrc.org wrote:

 Sue,

 On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
  Where does the priority live ??? in I2RS or in config module or in BGP
  routing model?  How does this work with the three datastore proposals: 1)
  separate empheral data store, 2) configuration state in existing
 datastore
  tagged by model as empheral, and 3) whole data stores tagged empheral,
  config, or both.   Is the routing code that sets the priority and handles
  the rollback?

 Priority received quite a bit of discussion during the netmod interim.  The
 reason why it was not explicitly spelled out in my first version of the
 draft is that the implementation would vary considerably depending on which
 answer netmod guided us toward for how we get ephemeral state.



 The rationale for the priority-based first one wins access control model
 is still unclear

 to me.



 A simple NACM extension to add group priority has already been proposed,

 which seems fine to me. So is this how it works?



   #1) NACM data rules can be used to grant or deny access to specific I2RS
 data nodes.

 Steps #2 and #3 assume access is granted here



   #2) the I2RS agent maintains the owner and owner priority of the data
 somehow.

  The priority is configured in each NACM group for enforcement
 purposes.

  This data used to decide if existing data can be overwritten by a
 different client.

  (I think highest priority wins if target data already exists)



   #3) if both writer and current owner have the same priority, then
 current owner wins



 Breaking ties by first-one-wins seems just as arbitrary as last-one-wins.
 It seems to be based on

 the order that the networking devices will boot.  Can somebody explain why
 it is better?



 I am still unclear how the operator know the exact data each client

 will want to use, and how they determine the meaningful overlap

 (e.g. what will break for client B if client A causes 2 of its 7 entries
 to be deleted?)



 This information seems to be required in order to configure the
 tie-breaking priorities properly,

 but I think the intent is that the operator will just know what I2RS
 clients are installed

 and know how to prioritize them, just based on their purpose.







 It turned out they gave us a fourth option.  I'll be summarizing that in my
 meeting minutes.  If you don't believe I've adequately addressed it in that
 writeup (coming shortly), please let me know and we'll resume.

 -- Jeff





 Andy



 ___
 netmod mailing list
 net...@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt

[Andy Bierman]

On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote:
  There is nothing in YANG or RESTCONF to support it (yet).
  For some features the I2RS agent is supposedly simple and mostly
 stateless.
  This template service does not seem to fit with that theme.

 Attempting to summarize discussions with various I2RS WG participants, I
 think it's a matter of perspective - and somewhat of preference.  The
 tension seems to lie roughly along two points of view:

 1. This is a programmatically driven API environment.  As such, there's
 little excuse to not simply send everything needed as a large configuration
 block - templates are extraneous.

 2. By permitting templates, you enable much smaller transactions.  You also
 potentially allow for a stronger security model by locking down stuff
 outside of the template.

 To offer a somewhat concrete example, consider an application for
 provisioning L3VPN customers.  Some minimum required configuration on a
 per-device basis includes:

 VRF name.
 A route-distinguisher.
 A route-target for the VPN.
 Customer PE-CE protocol and endpoint configuration.

 Fully expanded, this is probably a few dozens of lines of configuration in
 YANG.  What's interesting is that the above information is potentially
 generic related to that configuration, which may have per-device variance -
 potentially based upon vendor.

 Thought about perhaps another way, the template inputs are effectively a
 mini-YANG module with much of the back-end abstracted.

  Are these templates ephemeral?  That would be annoying.  They are not
  straight
  config, so a new a configuration data model is needed to manage the
  templates.
  New protocol mechanisms to use templates in addition to payload data will
  be needed.

 All agreed.

   You talk about the priority requirements.  You should probably mention
 the
   multi-headed behavioral requirements there (as I think that the
 resolutions
   will be tightly coupled.)
  
   Section 7.9 of the archtiecture document talks about several
 transactional
   scopes.  The text you have does not seem to deal with all of these.
 Does
   YANG handle them all easily?
  
 
  I would need to review this again -- I don't remember any problems last
  time I read the arch draft.

 Some of this is a matter of where this information lives.

 For tie-breaking of ephemeral vs. static config, is this provisioned
 per-module or per element in the module?  Are there explicit lines of YANG
 in each module for this?

 For tie-breaking user priorities, NACM extensions may make sense.  This
 particular state is effectively meta-data on the ephemeral config.

 Since the epehemeral state is highest priority wins, but there's no
 requirement that the lower priority state is kept in any fashion, how do we
 deal with inconsistent configuration that may result by a higher priority
 user deleting part of their configured state?

  I am confused about some text in the draft about ephemeral config:
 
  In 2.1:
 
 The author wishes to
 prevent any action that would lead to preserving any configuration
 state entered via the I2RS agent across reboots.  If state has to be
 restored, it should be solely by replay actions from I2RS client via
 I2RS agent.
 
 
  Why does the author wish to prevent NV-storage of the I2RS data?
  What is it about the accidental reboot of the router that makes it the
  I2RS data needed before the accidental reboot, but not after?

 I think my point of confusion is why you believe ephemeral configuration
 would ever get NV-stored?


Several people have asked about copy to local config, which is
really NV-save the I2RS state.What if the operator wants the
state to be active until it is explicitly removed?   There may be
significant latency
between the time the client discovers the agent has rebooted and
the state is re-installed.



  If the reason is because I2RS agents are simple and NV-storage is not
  simple,
  then why does the agent need to support templates?

 This is more a clean slate decision.  When the device comes up, it has no
 I2RS state.

 Note that the fully ephemeral nature of I2RS still doesn't feel
 fully-settled in the WG.  See prior thread comments about wanting to do
 copy-config on it. :-)

  This section might mention that the I2RS datastore has its own
  access control model, that is not the same as the running config.
 
 2.  Configuration state in the existing running datastore where the
 module is tagged ephemeral.
 
 3.  Permitting existing configuration to be optionally configured as
 ephemeral.  As an example, the NETCONF server advertises in its
 hello message if it supports the specified YANG module
 persistently and/or ephemerally.
 
 
 
  I thought the I2RS charter said I2RS was not altering the local config.

 Correct.

  Why does I2RS need to change the meaning of YANG configuration nodes

Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt

[Andy Bierman]

On Fri, Sep 12, 2014 at 2:22 PM, Joel M. Halpern j...@joelhalpern.com
wrote:

 Thanks for doing this Jeff.  It is a great start.

 The Object Relationships issue does need more work however.
 Some of the cases are handled...

 YANG's tools for reuse can be used to meet the inheritance requirements.
 I think that the requires and when clauses are probably powerful enough to
 meet the architecture requirements for optionality (arch 6.4.5.2).

 I do not know of anything in YANG that corresponds to agent side
 templating, as was agreed by the working group and captured in arch
 6.4.5.3.  (Since I am one who argued against this, if we need more detailed
 examples I would appreciate some assistance.)


I agree with you that Agent templates do not belong in the I2RS base spec.
There is nothing in YANG or RESTCONF to support it (yet).
For some features the I2RS agent is supposedly simple and mostly stateless.
This template service does not seem to fit with that theme.
Are these templates ephemeral?  That would be annoying.  They are not
straight
config, so a new a configuration data model is needed to manage the
templates.
New protocol mechanisms to use templates in addition to payload data will
be needed.


 The object relationships are three piece.  Arch 6.4.5.4.2 on correlation
 and arch 6.4.5.4.3 on actual references seem to be covered by various parts
 of YANG.  But the initialization reference described in arch 6.4.5.4.1 does
 not correspond to anything I know of in YANG.  Is there a YANG tool for
 that?  This is the case where the definition of an object Foo says that
 whenever a new Foo is created, it takes its initial values from an instance
 of Bar, so as to simplify instantiation.  This is similar too, but not the
 same as the templates material.


Nothing in YANG like that except the description-stmt.
The server can magically create whatever it wants, whenever it wants.




 You talk about the priority requirements.  You should probably mention the
 multi-headed behavioral requirements there (as I think that the resolutions
 will be tightly coupled.)

 Section 7.9 of the archtiecture document talks about several transactional
 scopes.  The text you have does not seem to deal with all of these.  Does
 YANG handle them all easily?


I would need to review this again -- I don't remember any problems last
time I read the arch draft.


I am confused about some text in the draft about ephemeral config:

In 2.1:

   The author wishes to
   prevent any action that would lead to preserving any configuration
   state entered via the I2RS agent across reboots.  If state has to be
   restored, it should be solely by replay actions from I2RS client via
   I2RS agent.


Why does the author wish to prevent NV-storage of the I2RS data?
What is it about the accidental reboot of the router that makes it the
I2RS data needed before the accidental reboot, but not after?

If the reason is because I2RS agents are simple and NV-storage is not
simple,
then why does the agent need to support templates?

This section might mention that the I2RS datastore has its own
access control model, that is not the same as the running config.

   2.  Configuration state in the existing running datastore where the
   module is tagged ephemeral.

   3.  Permitting existing configuration to be optionally configured as
   ephemeral.  As an example, the NETCONF server advertises in its
   hello message if it supports the specified YANG module
   persistently and/or ephemerally.



I thought the I2RS charter said I2RS was not altering the local config.
Why does I2RS need to change the meaning of YANG configuration nodes
in an ad-hoc manner (via tagging)?

This does not really work because YANG validation may fail without some
config data
that has been tagged do not save.  If the router reboots and the startup
config
does not validate, it is probably wedged. It can't really fall back to a
known good config
if I2RS has forced some of the data to be omitted from the saved config.

In sec 2.1.3, if you want a new third choice for the config-stmt for
ephemeral,
then I2RS is gated on the completion of YANG 1.1 (and development of YANG
1.1 tools).
Are you really sure you want that?  That's why a YANG extension was
suggested instead
(or maybe do both).






 Yours,
 Joel



Andy



 On 9/12/14, 4:59 PM, internet-dra...@ietf.org wrote:


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.


  Title   : I2RS requirements for netmod/netconf
  Author  : Jeffrey Haas
 Filename: draft-haas-i2rs-netmod-
 netconf-requirements-00.txt
 Pages   : 10
 Date: 2014-09-12

 Abstract:
 This document covers requests to the netmod and netconf Working
 Groups for functionality to support requirements to implement the
 I2RS architecture.


 The IETF datatracker status page for this draft is:
 

Re: [i2rs] [netmod] netmod interim and i2rs requirements

[Andy Bierman]

On Thu, Sep 4, 2014 at 8:29 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Tue, Sep 02, 2014 at 11:00:05AM -0700, Andy Bierman wrote:
  On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno repe...@cisco.com
 wrote:
   are we taking this approach only for I2RS or this will be our preferred
   solution from now on?
  
   Meaning, every time when a new protocol/WG has certain valid
 requirements
   we will create a new datastore for them?
  
  Good question.
  It is a lot more work to add a new datastore than to tag data as
 ephemeral
  in the existing running datastore -- if the only difference is no
  non-volatile support.
  I think the I2RS WG has to agree on those details first.

 Part of the discussion at the recent netmod session and post-session
 hallway
 discussion provided some suggestion there may be other users desiring
 ephemeral characteristics.  If this is the case, providing for a mechanism
 for tagging ephemeral state seems to be generally useful.

 One of the open questions for the more general mechanism is whether
 ephemeral state should be in a separate data store.  While I think there is
 good cause for I2RS to desire this, from the general standpoint it may also
 simplify implementations to keep ephemeral configuration segregated from
 static configuration.


It makes a big difference to YANG XPath whether there is a separate
datastore.
YANG only supports 1 static context for each document type
(rpc/input, rpc/output, config-data, all-data, notification). A new
datastore might
require many changes to YANG, depending on I2RS requirements.

There are problems mixing local config and I2RS nodes in must or when
expressions.
One important detail is whether I2RS objects are config=true (or false) in
YANG.
This impacts how must, when, and other constructs will behave.

If I2RS is config=false, It should be OK to reference local config from
I2RS must/when stmts,
but a config object must/when statement is not allowed to reference an I2RS
object.
Is this OK? Are there any requirements for YANG integration between the
local config
and the I2RS datastore?


-- Jeff


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [netmod] netmod interim and i2rs requirements

[Andy Bierman]

On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise bcla...@cisco.com wrote:

 Joel,

 On top of what Jürgen wrote, we stressed the need for such a requirement
 document to both I2RS chairs during the last IETF meeting.
 The good news is that some of the requirements were mentioned on the
 microphone during the Sunday YANG editing session and/or the NETMOD meeting
 (my memory fails me).

 Regards, Benoit

  On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote:

 Juergen,
  While I understand the request, I presume that such a request can
 not be met as a working group agreement in the time frame suggested.
 WHile I hope that some of the folks who have been involved in proposing
 the use of YANG for I2RS will write such a draft, I can not see how we
 could even get tot eh point of WG adoption of such a draft, much less WG
 rough consensus on the content, in the time frame you outline.
  Of course, I am not one of the chairs or ADs, but it seems pretty
 clear cut to me.


I agree with Joel that the I2RS does not have consensus on the details.
The slides I presented in London and subsequent discussions suggest this
solution:

   1) define YANG extension to identify I2RS data so typedefs, etc. can be
shared
   in config and state data models
   2) define an I2RS datastore
   3) define or extend a protocol to manage the I2RS datastore

Let's say there is a new datastore added to the RESTCONF architecture for
I2RS.
Explain how this datastore works.  It seems to have the same validation
rules
as YANG running config rules.  The only difference seems to be that the
I2RS datastore
is not NV-saved (or NV-loaded at boot-time) like the running datastore.

YANG 1.1 has some cleanup work planned to make the text less
NETCONF-specific.
I don't think there is much datastore and NV-store specific text that would
need to change.


Andy




 Joel,

 all I need is reasonably agreed upon input. Note that this request for
 input is not coming out of the blue, at least not for those I2RS folks
 who have been at the NETMOD meeting in Toronto.

 As NETMOD chair, I do have a target date to deliver YANG 1.1 and I
 take that milestone serious. My motivation to delay this by N months
 waiting for I2RS to get their input submitted is very small. I recall
 that there were presentations about what is missing bach in London,
 that is March 2014. The regular submission period for YANG 1.1 issues
 was 2014-02-23 until 2014-05-07. The interim meeting is mid September.

 /js


 ___
 netmod mailing list
 net...@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Consensus on I2RS data modeling language and protocol

[Andy Bierman]

Hi,

Sorry I ran out of time to work on I2RS requirements.
I tried to get some others to work on the wiki, but no takers.

I think if you ask an engineer whose job depends how well
they implement I2RS vs. an engineer who has no plans at all
to implement it, you might get different answers. The initial
and ongoing costs of the solution path really matter to vendors.

Even if tools are ignored, there is the problem of I2RS interaction
with the local config. That seems clearly more complicated
with separate solutions for each one.  YANG extensions
are also significant because they allow the language to be customized
instantly, without waiting for NETMOD or FORCES WG to be
rechartered to change their data modeling language.


Andy


On Thu, May 22, 2014 at 8:22 AM, Jamal Hadi Salim h...@mojatatu.com wrote:

 Jeff/Ed,

 First of all I want to thank you both; i think you both tried hard to
 provide the
 opportunity given the constraints.
 Second: I have no qualms with the WG moving forward - I understand
 progress MUST
 be made. Andy, no hard feelings I hope.

 Having said that, I would like to speak my mind. I am disappointed and
 I would like to address
 the two points described as cause for the decision.

 On the more support for netconf/yang:
 
 My view is this boils down to popularity contest as opposed to
 engineering requirements.
 I wouldnt call this a process breakdown in I2RS - just that in general
 the IETF allows the system
 to be very hackable. It is like money in politics. While I empathize with
 folks
 who have implemented netconf/yang and feel that is the path forward -
 i would argue the
 voting system is highly stacked. I know this is how the game has
 been played over the
 years - but for sometime now I feel like we need a new system for
 voting. Things should not be
 judged based on a simple +1 or a hum (I should have advertised
 somewhere for people to
 show up and vote for ForCES which would have been dishonest).
 Voting would  have more more sense if there were clear requirements to
 begin with from which
 a clear checklist could be derived.
 There were no specific requirements. I am sure there was intent but
 assumptions were made
 that netconf/yang is the way to go from the get-go.
 There was not even effort to match against some requirements for
 netconf/restconf/yang
 when I put out a wiki update. There was not even an attempt to
 dis/credit what i listed as requirements.
 From day one at the BOF, netconf and Yang were being presented as the
 answer.
 I remember standing up at the BOF mike and asking why solutions were
 being presented before
 requirements - IIRC the answer was i could present my own favorite
 protocol if i wanted to
 and that process would be  followed. An engineering task requires
 explicit call out of requirements
 first.

 Note: I am not arguing for ForCES here - but it aint
 Netconf/restconf/Yang and neither do i think
 those will require a minor surgery to work (as per my view of the
 requirements). And from that
 perspective I am unhappy - I wish we actually used a matrix of some
 sort to prove me wrong
 but the answer seems like we'll fix it.

 On open source availability
 ===
 The notion that because there is some open source implementation it
 qualifies
 some solution as legit is a red herring. 90% of IETF standards dont
 pass that smell test.
 There is no such requirement anywhere.
 There is *absolutely* no open source implementation of I2RS using
 netconf/restconf/yang.
 I *doubt* there is one in any organization anywhere on the globe. So
 this boils down to be
 a marketing gimmick in an engineering organization. Which is where my
 frustration comes in.
 Perhaps the starting point at IETF is to go back to the old days of
 implementing first as open
 source variant, get cohesion around it and then standardizing.

  I hope my views arent too harsh (I just wanted to feed that elephant
 in the room some peanuts).

 cheers,
 jamal

 On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas jh...@pfrc.org wrote:
  Working Group,
 
  We committed to spend the weeks following last session in London for
 IETF 89
  to look at our proposed data modeling languages and protocols in more
  detail.  While that conversation on the mail list didn't yield an
 explicit
  set of requirements (but thanks to Jamal for taking the first formal try
 at
  it), significant discussion occurred comparing and contrasting the
 benefits
  of FORCES and Netconf/Yang.  Part of that discussion helped clarify gaps
 in
  both proposals that would need to be addressed for use by I2RS.
 
  Each proposed mechanism had a few benefits in contrast to its
 counterpart,
  but none of these were overwhelming in scope.
 
  Our judgment of group consensus is that while both FORCES and
 Netconf/Yang
  could serve I2RS that there is substantially more support for the
  Netconf/Yang proposal.  Part of this consideration includes elements of
  expediency such as 

Re: [i2rs] Update to Wiki (ForCES for I2RS)

[Andy Bierman]

On Wed, May 14, 2014 at 7:28 AM, Joel M. Halpern j...@joelhalpern.comwrote:

 (Alia, correct me if I mis-represent this concept.)

 No, temnplating is not just Default values must be possible to specify.

 An example is that you might have a scheduling structure.  it has a set of
 defaults which create a specific scheduling discipling.
 The Client can create a scheduling instance, and can over-ride any and all
 of those defaults.
 So far, that is just modeling with defaults.

 The idea with templates is that the Client could also say For all the
 values I don't specify, use the WFQ template or the EF template, or ...
  If the client does that, the agent would treat the values from that
 template which are specified in the template and are not specified in the
 request from the controller as if they had been specified by the
 controller, rather than using the base defaults.

 Coupled with this, some mechanism would provide these templates.  The
 power here is that there might be different templates for the EF
 Scheduling template on different boxes to reflect how each box should be
 configured to achieve the policy goal.

 Conversely, clearly, all of this data can be on the client and the client
 can do the inclusion.



A generic template feature would be interesting, and may not be
a lot of work. If a template includes lots of data, then it
could be much faster (CPU, on-the-wire) than inline edits.

Templates are usually just for convenience and consistency,
but consistency (even across clients) is important.

In the generic sense, a YANG template would be a sub-tree
without keys. Whatever nodes were missing from the client request
would get merged in by the server. (Some NETCONF servers are designed
to do this merge very quickly).  The protocol operation would say
edit that data with this patch and template X.


 Yours,
 Joel



Andy



 On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote:

 On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern j...@joelhalpern.com
 wrote:

 Templating is described in the archtiecture document.
 However, as I said when i presented the material, this is a topic on
 which
 the authors disagree.
 I personally do not think it should be a protocol behavior, and
 therefore do
 not see it as something the model needs to represent.

 The basic idea of templating is to allow the I2RS client to say to the
 I2RS
 agent I want to set this instance to these values, but for all the
 things I
 don't specify, use this template over here to determine what values to
 set.
 This clearly has power.  Equally clearly, it can be done at the client
 rather than at the agent.


 Seems like i abused the term template. I.e it seems to me that would
 fall under
  Default values MUST be possible to specify - which is described in the
 wiki.
 Shouldnt this be a model problem?
 I will fix the wiki entry and remove it from that sub-section.

 On the OO class/instances:
 The motivation is to be able to describe set blah to RIB instance foo.
 The
 concept for abstracting a factory which is essentially a class vs
 an instance of
 that class seems to belong to the model.


 cheers,
 jamal


___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] edit-data substatement Re: Operational State

[Andy Bierman]

On Wed, May 7, 2014 at 3:56 AM, Susan Hares sha...@ndzh.com wrote:

 Andy:



 Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau:



 snip

 I imagine I2RS will be completely separate from NETCONF and it should have
 its own datastore -- so i2rs-config is appropriate because I2RS is the only
 protocol using that datastore. The combined operational state is not
 editable.



 Yes, that makes sense. Then if at some point in time you want to save  the
 running config (i2rs), the system has to explicitly copy it over. But until
 then, its separate.  The only question is: what is the complete running
 config represented as? And what if Netconf wants to modify the running
 config (i.e.: and the RIB in particular)?



 That copy-to-local-config feature would be extra, outside the scope of the
 i2rs-config.

 /snip

 -



 Why only is the copy-to-local-config feature out of scope for the
 I2rs-config?   How can the work be interoperable if this feature (required
 or optional) does not work the same in different vendor's boxes?  If the
 implementations are different, this is great (differentiated products =
 good); but IMHO this feature actions has to be interoperable... that is give
 the same effective response in the different vendors.



 Can you explain further?




Writing to the local config is the charter of the NETCONF WG, not I2RS.
In order to copy from the I2RS data model to the configuration data model,
a detailed mapping is required.  Since the local-config is out of scope,
the config data corresponding to the I2RS data is not required to exist.
If it does exist, it can be vendor-specific, right? So the mapping is
vendor specific.

I would agree with you if I2RS was planning on standardizing data models
for configuration and RIB editing.  It that were the case, then I would
re-ask
the question Ron Bonica raised in London -- why would we want to write
config data models with 1 language and I2RS data models with a different
language?


 snip



 Right. If we take that approach we need to have a way of the i2rs
 protocol to signal that the config

 needs to be saved soon.  That is, its not done in real time, but rather
 as a background process.

 Its probably. This can either be through a single keyword that is added
 under the i2rs-config section, or

 per element or even per-element, if we decide to be more granular.

 /snip



 IMHO it is important to know when the write to local-config is done even
 if done in background.   Are you indicating there is no
 write-config/ack-complete-write config interaction?





 snip

 You seem to be suggesting that the I2RS behavior of forgetting all
 injected state

 if the router happens to reboot is not that useful, and therefore it needs
 to be

 saved in the background (best-effort).



 I think it is up to all the I2RS clients to always be around to receive
 some

 sort of agent-reboot event, and re-install any required I2RS config.

 I can't imagine any use cases where the operator thinks I only need to

 install this RIB data until that router accidentally reboots.

 /snip



 If you re-install any required I2RS config, are you sure this is what the
 I2RS client wants?


The protocol request would indicate what the client wants (e,g,
copy-to-local config flag set).
Since notifications are unreliable, a client will poll the 'agent-boots'
counter frequently to
see if needs to re-install lost state.  This design does not scale well and
introduces significant
latency.  It is much more convenient to have the agent deal with
reinstall-after-reboot.




 Sue




Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] edit-data substatement Re: Operational State

[Andy Bierman]

On Fri, May 2, 2014 at 2:29 AM, t.petch ie...@btconnect.com wrote:

  Original Message -
 From: Andy Bierman a...@yumaworks.com
 To: Jeffrey Haas jh...@pfrc.org
 Cc: t.petch ie...@btconnect.com; i2rs@ietf.org
 Sent: Thursday, May 01, 2014 7:10 PM
  On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas jh...@pfrc.org wrote:
 
   Andy,
  
   On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote:
This has been done a few times.
Most recently April 22:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html
  
   I should respond there, but this was one of the messages that
 prompted my
   question about data (operational state) vs. ephemeral config.
  
   I don't believe we want to say this is the module for monitoring
 the rib
   and now you can write to it.
  
 
  that is not what the edit-data extension does.
  It is a sub-statement that identifies I2RS editable data no matter
 what
  YANG module is used to define the data.  The YANG config=true
 statement
  identifies a data node as part of the configuration datastore. The
 edit-data
  extension cannot be used on a config=true node, only
 non-configuration.
 
  module foo {
 ...
 import i2rs { prefix i2rs; }
 
 container config-data {
 // NETCONF definitions here
  }
 
  container i2rs-data {
 config false;
 i2rs:edit-data;
  }
 
  container oper-data {
config false;
 // plain read-only data
  }
  }
 
  Nesting is also possible -- up to the data modeler to decide what to
 use:
 
 1) i2rs-data inside config-data
 2) i2rs-data inside oper-data
 3) oper-data inside i2rs-data

 Andy, Jeff

 I wonder if edit-data on its own will be enough.

 'config true' in base YANG allows the data to be written, but it also
 makes it very easy for NETCONF to read what it wants to, with a
 get-config RPC.  Strictly such a function is unnecessary, it could all
 be done with filters, which would be a nightmare and error-prone.  So we
 have get-config that gets the 'config  true' subset of leafs etc.  And,
 with no apparent downside, there is just the one substatement, 'config
 true', the two sets are identical.

 With I2RS, we need writable operational state so we need an edit-data
 substatement added to YANG but what about getting the data that I2RS
 wants to see?  Do we need an i2rs-data substatement so that we can
 readily tag the parts of the model that i2rs wants to get, e.g. with a
 new 'get-i2rs' RPC?


If definitions are combined in the same module(s), then there is
no way to prevent NETCONF from skipping over these special config=false
nodes.  I doubt that is a problem.

I picture the operational state as the mixing bowl for the 2 config sources
and data learned from protocols and system events.  It seems
both NETCONF and I2RS would be able to pick the data is cares about
out of that.

This is a weakness in YANG that may get improved in YANG 1.1.
Since it is officially just for NETCONF, there are no mechanisms
(other than vendor extensions) to tag the data as specific to
some subset of protocols.



 I think that we will, that is the set of YANG leafs etc that I2RS will
 want to edit and the sets of leafs that I2RS will want to get in a
 straightforward manne will not be the same (eg the latter will include
 read-only statistics and 'config true').  And yes, it could all be done
 with filters, which could be a nightmare.


Examples of read-only data that only I2RS would want to get would help.



 Tom Petch



Andy



 p.s. this is one of the issues that I have been wrestling with that I
 alluded to in my response to Tom Narten


   IMO, I think we want multiple data stores for configuration for
 adding
   routes to the rib.
  
 
 
  How many does I2RS need for itself?
 
 
 
  
   (I also thought the notification example was clear and didn't need
 further
   comment.)
  
I don't see how standard I2RS data could use local config data
 unless it
was also standardized.
  
   Basically, we want to make sure there is WG coordination on modules.
   If WG has a module and it makes sense for I2RS to use it/extend it,
 that's
   great when it makes sense.  Similarly, if we find the need to create
 an
   I2RS
   module for work covered by another WG, we want to make sure we leave
   as much re-usable infra for them as we can.
  
   -- Jeff
  
 
  Andy
 

 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] edit-data substatement Re: Operational State

[Andy Bierman]

On Fri, May 2, 2014 at 8:40 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
  I picture the operational state as the mixing bowl for the 2 config
 sources
  and data learned from protocols and system events.  It seems
  both NETCONF and I2RS would be able to pick the data is cares about
  out of that.

 I think this is what I'd like to see personally.

  This is a weakness in YANG that may get improved in YANG 1.1.
  Since it is officially just for NETCONF, there are no mechanisms
  (other than vendor extensions) to tag the data as specific to
  some subset of protocols.

 As I mentioned elsewhere, I'm hoping we don't go down the path of editable
 operational state, instead configuration semantics for our purposes.


I guess I agree, because when trying to figure out some corner-cases,
I changed the datastore name to i2rs-config.

IMO this makes it easier to conceptualize the underlying system as
the result of the priority-based arbitration between local-config and
i2rs-config.
It is easier to see that the system is going to have to re-install an entry
from local-config when an I2RS client removes a higher-priority
entry from i2rs-config (e.g., your BGP peer example).  Both configs
exist in parallel, and the oper-state has the entry that is higher priority.


  I think that we will, that is the set of YANG leafs etc that I2RS will
   want to edit and the sets of leafs that I2RS will want to get in a
   straightforward manne will not be the same (eg the latter will include
   read-only statistics and 'config true').  And yes, it could all be done
   with filters, which could be a nightmare.
  
  
  Examples of read-only data that only I2RS would want to get would help.

 I believe that it would largely overlap config false state desired for
 normal module purposes in many cases.  For example, interface statistics
 would likely be part of the standard interface module.  Where things get
 interesting are specific augmentations that tie different information
 domains together - interface stats correlated against routing, for example.
 (For prefix X, traffic is seen - similar to IPFIX exports.)

 -- Jeff


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] edit-data substatement Re: Operational State

[Andy Bierman]

On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote:
  On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
   I picture the operational state as the mixing bowl for the 2 config
 sources
   and data learned from protocols and system events.  It seems
   both NETCONF and I2RS would be able to pick the data is cares about
   out of that.
 
  I think this is what I'd like to see personally.
 
   This is a weakness in YANG that may get improved in YANG 1.1.
   Since it is officially just for NETCONF, there are no mechanisms
   (other than vendor extensions) to tag the data as specific to
   some subset of protocols.
 
  As I mentioned elsewhere, I'm hoping we don't go down the path of
 editable
  operational state, instead configuration semantics for our purposes.

 At some point in time, we need to get the terminology sorted out. NC
 has well defined configuration datastores and YANG has a well defined
 concept of configuration data (config true). NC kind of assumes that
 data in configuration datastores has an associated concept of
 persistence (e.g., changes to running/ persist unless you have an
 explicit startup/, candidate/ is a temporary scratch pad).

 We are talking about another writable datastore (or potentially
 multiple of them). Some call the data in this writable datastore
 configuration, others prefer to use a different term to avoid a clash
 with what NC and YANG consider configuration. If we could find a good
 name for such writable datastores, I likely make communication much
 simpler.

 And yes, I think the model that the contents of the configuration
 datastore, the writable datastore(s) as well as the information
 learned dynamically from various control plane protocols all lead to
 the final operational state. (In fact, one could consider a model
 where control plane protocols all conceptually come into the system
 via additional control protocol specific writable datastores.)

 So, can we find a name for these 'other writable datastores' and then
 use that term instead of 'writable operational state', 'ephemeral
 config', 'i2rs datastore', etc.?


I imagine I2RS will be completely separate from NETCONF and it should
have its own datastore -- so i2rs-config is appropriate because I2RS is
the
only protocol using that datastore. The combined operational state
is not editable.

It is tempting to generalize the problem so the solution works for any
protocol (not specifically I2RS) and any data (not specifically RIB data).
But that would be out of scope.  Understanding the interaction between
local-config and i2rs-config is certainly in scope. There is lots of work
left to be done there, so if it seems fuzzy to you, that's probably why ;-)




 /js


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] edit-data substatement Re: Operational State

[Andy Bierman]

On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau tnad...@lucidvision.comwrote:


 On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman a...@yumaworks.com
 wrote:




 On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder 
 j.schoenwael...@jacobs-university.de wrote:

 On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote:
  On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
   I picture the operational state as the mixing bowl for the 2 config
 sources
   and data learned from protocols and system events.  It seems
   both NETCONF and I2RS would be able to pick the data is cares about
   out of that.
 
  I think this is what I'd like to see personally.
 
   This is a weakness in YANG that may get improved in YANG 1.1.
   Since it is officially just for NETCONF, there are no mechanisms
   (other than vendor extensions) to tag the data as specific to
   some subset of protocols.
 
  As I mentioned elsewhere, I'm hoping we don't go down the path of
 editable
  operational state, instead configuration semantics for our purposes.

 At some point in time, we need to get the terminology sorted out. NC
 has well defined configuration datastores and YANG has a well defined
 concept of configuration data (config true). NC kind of assumes that
 data in configuration datastores has an associated concept of
 persistence (e.g., changes to running/ persist unless you have an
 explicit startup/, candidate/ is a temporary scratch pad).

 We are talking about another writable datastore (or potentially
 multiple of them). Some call the data in this writable datastore
 configuration, others prefer to use a different term to avoid a clash
 with what NC and YANG consider configuration. If we could find a good
 name for such writable datastores, I likely make communication much
 simpler.

 And yes, I think the model that the contents of the configuration
 datastore, the writable datastore(s) as well as the information
 learned dynamically from various control plane protocols all lead to
 the final operational state. (In fact, one could consider a model
 where control plane protocols all conceptually come into the system
 via additional control protocol specific writable datastores.)

 So, can we find a name for these 'other writable datastores' and then
 use that term instead of 'writable operational state', 'ephemeral
 config', 'i2rs datastore', etc.?


 I imagine I2RS will be completely separate from NETCONF and it should
 have its own datastore -- so i2rs-config is appropriate because I2RS is
 the
 only protocol using that datastore. The combined operational state
 is not editable.


 Yes, that makes sense. Then if at some point in time you want to save
 the running config (i2rs), the system has to explicitly copy it over. But
 until then,
 its separate.  The only question is: what is the complete running config
 represented as?
 And what if Netconf wants to modify the running config (i.e.: and the RIB
 in particular)?


That copy-to-local-config feature would be extra, outside the scope of the
i2rs-config.
IMO, the i2rs-config datastore has these properties:
   - editable with I2RS using the I2RS owner-priority access control model
   - only field validation; YANG datastore validation is ignored,
 except for mandatory=true|false and min/max-elements
   - data is never saved across a reboot; never saved to NV-storage like
NETCONF config
   - data does not time out; The system or external I2RS client must remove
any data
 to cleanup
   - the system uses the priority values to determine if local-config or
i2rs-config
 wins wrt/ operational values; the system must install the correct
config if
 priorities change



--Tom



Andy



 It is tempting to generalize the problem so the solution works for any
 protocol (not specifically I2RS) and any data (not specifically RIB data).
 But that would be out of scope.  Understanding the interaction between
 local-config and i2rs-config is certainly in scope. There is lots of work
 left to be done there, so if it seems fuzzy to you, that's probably why ;-)




 /js


 Andy

 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs



___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Operational State

[Andy Bierman]

On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas jh...@pfrc.org wrote:

 Tom,

 On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote:
  But, Jeff, you then say, in a parallel post
 
  The issues then comes back to the ones noted in
  draft-bjorklund-netmod-operational-00: How do we distinguish
  operational,
  config or ephemeral config states? 
 
  whereas I see operational state, config and read-only statistics, with
  state (unqualified) referring to the first and last collectively!
  'ephemeral' does not appear in Martin's I-D, nor would I expect it to -
  I don't see it as a concept in YANG/NETCONF.

 I agree it is not currently part of Netconf/Yang.  This is part of why I
 raise the question.

  There is a separate issue of persistent and ephemeral in YANG, or,
  arguably, in NETCONF, which is also not documented AFAICS.  This is
  probably of less interest to I2RS at this time.

 I actually think it's one of our bigger sticking points - or at least
 something we need a clear answer on if N/Y is to be considered for i2rs
 use.
 I2RS state is intended to be ephemeral. (See architecture document.)


I think this has been explained several times already,
starting in the IETF 89 slides.

I don't think anybody has said NC/RC/YANG could be used
as the I2RS protocol without a single change.  People has said
it is the best starting point for I2RS.  There seemed to be an overwhelming
consensus in the London meeting and on this mailing list to
use NC or RC + YANG as the I2RS starting point.

IMO, there needs to be a new datastore in the architecture that
contains I2RS data. The I2RS protocol will define how this data is accessed.
It's really not that complicated.

There are many implementations using NC/RC + YANG, and many of
these vendors have stated that they believe this approach can
be made to work for I2RS.


 If there is one running datastore, then, presumably, it is persistent
  (across reboots) - the documents appear not to say.  If there is running
  and startup, presumably startup is persistent and running is not.  But
  if you have running and acme-special datastores, then which is
  persistent?  This is one of several issues, like operational state, that
  have surfaced from time to time and, for me, have not got nailed down as
  well as I would like, and so - surface from time to time.


I2RS does not have any interaction with the local config except maybe
to read it.  The NETCONF configuration datastores (candidate, running,
startup) are
not going to be used by I2RS.  Nothing I2RS does is going to even slightly
alter the definition of any NETCONF configuration procedures.


This covers my point.  Moving this particular bit of discussion to Juergen's
 response to me in another thread.

 -- Jeff


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Operational State

[Andy Bierman]

On Thu, May 1, 2014 at 8:23 AM, Jeffrey Haas jh...@pfrc.org wrote:

 Andy,

 On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote:
  I think this has been explained several times already,
  starting in the IETF 89 slides.
 
  I don't think anybody has said NC/RC/YANG could be used
  as the I2RS protocol without a single change.  People has said
  it is the best starting point for I2RS.  There seemed to be an
 overwhelming
  consensus in the London meeting and on this mailing list to
  use NC or RC + YANG as the I2RS starting point.

 Since we've not been very good about getting requirements explicitly
 listed,
 part of the point of my questions is to tease out those details.

  IMO, there needs to be a new datastore in the architecture that
  contains I2RS data. The I2RS protocol will define how this data is
 accessed.
  It's really not that complicated.

 And thus, we need a new data store.  How it interacts with similarly
 configured objects in other datastores is another detail I'm trying to
 tease
 out as a requirement.


OK -- I hope this ASCII art helps.

   NC/RC I2RS
   | |
  VV
+---+  ++
 |  local config  |   | i2rs-config |
+---+  ++
   | |
  VV
+---+
 |  operational state  |
+---+

The operational state contains a data-model dependent mix
of local and i2rs configuration, + learned data from protocols.
The i2rs-config datastore is like a fastpath config (as Tom described).
The operations on the local-config datastore use different rules and the 2
only
mix in the operational state.


 I2RS does not have any interaction with the local config except maybe
  to read it.  The NETCONF configuration datastores (candidate, running,
  startup) are
  not going to be used by I2RS.  Nothing I2RS does is going to even
 slightly
  alter the definition of any NETCONF configuration procedures.

 Consider my BGP example noted elsewhere.  If I want to say create a BGP
 peer as an I2RS operation and some of that behavior relies on other
 underlying configuration (autonomous system, security policies, etc.) my
 choices appear to be either to have some amount of shadowed configuration
 objects on top of an existing BGP module or have a somewhat parallel module
 (perhaps inheriting configuration objects from the main BGP module).

 Which would you do?


I would start by making sure the management of the local config and
the I2RS config were fully aligned, because it is inevitable (if not
obvious)
that definitions in all 3 boxes above need to share data naming, data types,
and even data nodes.  A YANG grouping would be the starting point for
sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt).



-- Jeff



Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Operational State

[Andy Bierman]

On Thu, May 1, 2014 at 10:14 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Thu, May 01, 2014 at 09:44:35AM -0700, Andy Bierman wrote:
   If within the same module, there is the implication of a requirement
 for
   changes to the language to permit them to do so harmoniously.
  
  
  I prefer 1 module, but it is not that simple. The user-defined typedefs
 and
  identities (for identityref data type) can be shared (e.g. imported from
  a common-types module). Even if the data nodes are separate, the
  definitions can share YANG semantics in various ways.
 
 
  New YANG statements (or extensions) to identify data affected by I2RS
  will allow the data models to be mixed in the same module, augment across
  modules, etc.

 Enumerating those changes would be helpful.


This has been done a few times.
Most recently April 22:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html




   If across different modules, there is the suggestion but not
 requirement
   that as Working Groups provide yang modules for managing their
 components
   that they are structured in such a way to permit I2RS re-use in our
   modules.
  
  
  I think it would be most efficient if a WG considered complete management
  of a new protocol feature, and chartered configuration, I2RS, monitoring,
  and notification support at the same time.

 That was a likely outcome.  Since other WGs aren't (to my knowledge)
 heavily
 focused on building their protocol management in yang yet, this suggests a
 significant amount of coordination with the related WGs if we want to
 define
 I2RS functionality impacting them.  In effect, they might get their yang
 written for free. :-)

 This does, obviously, have charter impact.

  The IETF approach for the last 2 decades has been to leave most
  of the management to the vendor CLI. The problem with this approach
  is that over-laying monitoring systems (vendor + standard)
  is easy, but not true for APIs that change the system.  Once the vendor
 API
  is in
  place, it is very difficult to overlay an incompatible standard API.

 Been there, done that and had it... shape my opinion of SNMP.
 I'll leave it at that.


I don't see how standard I2RS data could use local config data unless it
was also standardized.




 -- Jeff


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Operational State

[Andy Bierman]

On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas jh...@pfrc.org wrote:

 Andy,

 On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote:
  This has been done a few times.
  Most recently April 22:
  http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html

 I should respond there, but this was one of the messages that prompted my
 question about data (operational state) vs. ephemeral config.

 I don't believe we want to say this is the module for monitoring the rib
 and now you can write to it.


that is not what the edit-data extension does.
It is a sub-statement that identifies I2RS editable data no matter what
YANG module is used to define the data.  The YANG config=true statement
identifies a data node as part of the configuration datastore. The edit-data
extension cannot be used on a config=true node, only non-configuration.

module foo {
   ...
   import i2rs { prefix i2rs; }

   container config-data {
   // NETCONF definitions here
}

container i2rs-data {
   config false;
   i2rs:edit-data;
}

container oper-data {
  config false;
   // plain read-only data
}
}


Nesting is also possible -- up to the data modeler to decide what to use:

   1) i2rs-data inside config-data
   2) i2rs-data inside oper-data
   3) oper-data inside i2rs-data


 IMO, I think we want multiple data stores for configuration for adding
 routes to the rib.



How many does I2RS need for itself?




 (I also thought the notification example was clear and didn't need further
 comment.)

  I don't see how standard I2RS data could use local config data unless it
  was also standardized.

 Basically, we want to make sure there is WG coordination on modules.
 If WG has a module and it makes sense for I2RS to use it/extend it, that's
 great when it makes sense.  Similarly, if we find the need to create an
 I2RS
 module for work covered by another WG, we want to make sure we leave
 as much re-usable infra for them as we can.

 -- Jeff


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

[Andy Bierman]

On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern j...@joelhalpern.comwrote:

 I do not think that matches the definition of role we are using.
 An identity has a role.  Several identities may have the same role.
 And a role is defined by a collections if im-tree-portion, access
 permission pairs.

 This is not specific to the RIB model, and should not be in the rib model
 at all as far as I can tell.

 Separate from the definition of role, and again applicable across all
 information models, an agent may itself have access restrictions.  A client
 using an agent is restricted to the access set which is permitted both by
 its role and by what the agent has permission to do.

 Again, if we want to model that, we should model it outside of any
 specific IM.


NETCONF and RESTCONF already have a standard Role-Based Access Control
Model,
called NACM (RFC 6536).  Does the I2RS WG plan to create its own ACM, leave
it
to vendors, or something else?



 Yours,
 Joel


Andy



 On 4/30/14, 7:26 AM, Susan Hares wrote:

 Joel:

 Great!  This is the answer I hoped to get.  Just to make sure,  We are
 defining a role as:  identity + rib tree + access (read or write or
 read-write).
 If I define a tree portion that is read-only does that align with our role
 definitions.

 If this is a common definition, then I'm good to release the next version
 of
 the draft with read/write for the RIB-info.

 Sue

 -Original Message-
 From: Joel M. Halpern [mailto:j...@joelhalpern.com]
 Sent: Tuesday, April 29, 2014 10:20 AM
 To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org
 Cc: draft-ietf-i2rs-rib-info-mo...@tools.ietf.org
 Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

 Remember that an information model is not a grammar.  It is perfectly okay
 in an IM to have two branches that are just different things.
 Discriminators are added in when one goes from teh information model to
 the
 data model.

 Yours,
 Joel

 On 4/29/14, 2:36 AM, Nitin Bahadur wrote:

 Hi Sue,




  4) Would a corrections to the above be useful:
 Given the above you could simplify your match RBNF:

 match:: = route-tag rt-form [ipv4-route | ipv6-route |
 mpls-route
 | mac-route]


 [Nitin] The rt-form is not needed for mpls and mac routesŠ.since
 MPLS has no concept of SRC or DEST. So that simplification will
 actually not help :(

 [Sue]: Yes, not all forms would benefit.  However, MPLS does have the
 stack tags that we may want to save and match on.  Also: the 5-tuples
 may be a part of matching some routes.  By using rt-form, we are
 using the TLV format to set-up these multiple formats.  Each format,
 would have the appropriate expectations for the appropriate address
 families.

 [Sue]:  I think it provides table based code.


 The main issue is that the grammar will not be deterministic. In other
 words, one needs a way to specify that route-tag-1 rt-form-A is
 valid and route-tag-1 rt-form-B is NOT valid.



 The ip-route-type will need to be associated specifically with
 ipv4-route and ipv6-route.

 [Sue]: yes, it could.  With the rt-form and the rib-family type,
 perhaps we can remove the rt-type.
 [snip]


 Rib-family-type and route-type are kind of the same thing. I need to
 think if there is a case where they can be different...



  5) Why did you specify differently?

 multicast-source-ipv4-address ::=IPv4-Address IPV4_PREFIX_LENGTH
 multicast-source-ipv6-address ::=IPv6-AddressIPV6_PREFIX_LENGTH

 Where you trying to express some checking that the node should have
 on these address?


 Thanks for catching this. They have no reference in the -02 version.
 They are a remnant of -00 of the draft. After the grammar was
 modified in -01, they should have been deleted.

 Here's the next question - how were you planning to handle the
 multiple next-hops for the multicast.  Did you have a plan?

 You will have both ECMP (unicast) multiple nexthops,


 Unicast multiple next hops are covered in Section 7.2.3.


  and multicast replication next hops.


 Section 7.3 talks about multicast replication (and refers to Section
 7.2.2).


  A flag might do nicely to differentiate.
 We could put this on the next hop.


 LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to
 indicate ECMP/load-balancing.



 Thanks
 Nitin


 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs



 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

[Andy Bierman]

On Wed, Apr 30, 2014 at 7:13 AM, Joel Halpern Direct 
jmh.dir...@joelhalpern.com wrote:

 There are at least two reasons why I at least find the reasonable quesiton
 you have asked to be difficult to answer.

 First, it is not at all obvious that manipulation of the access control is
 within scope for I2RS.  The permissions may not even be defined and
 manipulated on the same device where the I2RS agent resides.


Agreed.  Vendors and operators would prefer a single ACM that applies
to all protocols. (Even though NACM says it is only for NETCONF, nobody
implements it that way. CLI, WEBui, RESTCONF, etc. all use the same
authorization rules.

Second, we are working on an information model.  RFC 6536 is a data model,
 and specific to the NetConf/YANG data model.


Most of it is YANG-specific, not NETCONF-specific.
The access rules are based on YANG statements.
But only the behavior for the NETCONF protocol is defined in detail.
I doubt NACM could be used without additional text in some I2RS RFC.

Personally, as I have said repeatedly, I do not see any reason for us to
 have an information model for this until we conclude that there is some
 manipulation of it which is within scope.


Agreed.
The info model and the data model are written (mostly) independent
of access control.

Yours,
 Joel


Andy



 On 4/30/14, 10:02 AM, Andy Bierman wrote:




 On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern j...@joelhalpern.com
 mailto:j...@joelhalpern.com wrote:

 I do not think that matches the definition of role we are using.
 An identity has a role.  Several identities may have the same role.
 And a role is defined by a collections if im-tree-portion, access
 permission pairs.

 This is not specific to the RIB model, and should not be in the rib
 model at all as far as I can tell.

 Separate from the definition of role, and again applicable across
 all information models, an agent may itself have access
 restrictions.  A client using an agent is restricted to the access
 set which is permitted both by its role and by what the agent has
 permission to do.

 Again, if we want to model that, we should model it outside of any
 specific IM.


 NETCONF and RESTCONF already have a standard Role-Based Access Control
 Model,
 called NACM (RFC 6536).  Does the I2RS WG plan to create its own ACM,
 leave it
 to vendors, or something else?

 Yours,
 Joel


 Andy


 On 4/30/14, 7:26 AM, Susan Hares wrote:

 Joel:

 Great!  This is the answer I hoped to get.  Just to make sure,
   We are
 defining a role as:  identity + rib tree + access (read or write
 or
 read-write).
 If I define a tree portion that is read-only does that align
 with our role
 definitions.

 If this is a common definition, then I'm good to release the
 next version of
 the draft with read/write for the RIB-info.

 Sue

 -Original Message-
 From: Joel M. Halpern [mailto:j...@joelhalpern.com
 mailto:j...@joelhalpern.com]
 Sent: Tuesday, April 29, 2014 10:20 AM
 To: Nitin Bahadur; Susan Hares; 'Mach Chen'; i2rs@ietf.org
 mailto:i2rs@ietf.org
 Cc: draft-ietf-i2rs-rib-info-__mo...@tools.ietf.org
 mailto:draft-ietf-i2rs-rib-info-mo...@tools.ietf.org
 Subject: Re: [i2rs] Some comments on
 draft-ietf-i2rs-rib-info-__model-01

 Remember that an information model is not a grammar.  It is
 perfectly okay
 in an IM to have two branches that are just different things.
 Discriminators are added in when one goes from teh information
 model to the
 data model.

 Yours,
 Joel

 On 4/29/14, 2:36 AM, Nitin Bahadur wrote:

 Hi Sue,




 4) Would a corrections to the above be useful:
 Given the above you could simplify your match RBNF:

 match:: = route-tag rt-form [ipv4-route |
 ipv6-route |
 mpls-route
 | mac-route]


 [Nitin] The rt-form is not needed for mpls and mac
 routesŠ.since
 MPLS has no concept of SRC or DEST. So that
 simplification will
 actually not help :(

 [Sue]: Yes, not all forms would benefit.  However, MPLS
 does have the
 stack tags that we may want to save and match on.  Also:
 the 5-tuples
 may be a part of matching some routes.  By using
 rt-form, we are
 using the TLV format to set-up these multiple formats.
   Each format,
 would have the appropriate expectations for the
 appropriate address
 families.

 [Sue]:  I think it provides table based

Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

[Andy Bierman]

On Wed, Apr 30, 2014 at 7:56 AM, Susan Hares sha...@ndzh.com wrote:

 Andy:



 My goal is not to invent something new, so as an expert in
  netconf/restconf role-based access control model could you:



 1 - comment if this can be handle by netconf/restconf



 Identity + role  im-tree-portion, access permission pairs



yes.
NACM assigns users to admin-configured groups.
Groups are used to represent roles. Rule-lists are
used to specify policy for various groups. There are several
wildcards and defaults to make rule specification simple.
Rules are processed in order (first match == process and exit)

http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#rule-list.310




 2 - provide me with references to these RFCs that I should pull out to
 reference to identify how this could be expressed?




The access control model is in RFC 6536.

A 'data rule' would be configured to achieve the policy above:

 -  'admin' group has full access the /foo/rib-data subtree
 -  'monitor' group has read access the /foo/rib-data subtree
 -  all others have no access


  rule-list
nameadmin-can-write-rib-data/name
 groupadmin/group
 rule
namefoo-rib-data/name
path/acme:foo/acme:rib-data/path
access-operationscreate read update delete/access-operations
actionpermit/action
 /rule
  rule-list
  rule-list
namemonitor-can-read-rib-data/name
 groupmonitor/group
 rule
namefoo-rib-data/name
path/acme:foo/acme:rib-data/path
access-operationsread/access-operations
actionpermit/action
 /rule
  rule-list
  rule-list
nameno-access-to-rib-data/name
 rule
namefoo-rib-data/name
path/acme:foo/acme:rib-data/path
actiondeny/action
 /rule
  rule-list




 snip



 NETCONF and RESTCONF already have a standard Role-Based Access Control
 Model,

 called NACM (RFC 6536).  Does the I2RS WG plan to create its own ACM,
 leave it

 to vendors, or something else?



 snip

 Sue


Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] consensus on I2RS protocol and model

[Andy Bierman]

On Wed, Apr 23, 2014 at 7:41 AM, Susan Hares sha...@ndzh.com wrote:

 Andy:



 I started using UML to do the information models because Adrian Farrel and
 Alia Atlas encouraged it to replace RBNF.   I think that the yang/netconf
 models are still mining the existing SNMP/Configuration structures. For new
 development, I suspect UML may help us root out redundancy. Why?  Because I
 think I've found lots of redundancy in the RIB_INFO model.  I've attached
 slides that may convince you, and an alternate drafts.





I do not have any objections to using UML.
They are painful to read and write in ASCII art.
Maybe that's why we tend to describe the model in introductory text.
We also try to avoid duplicating normative text, and try to keep as much
normative text in the YANG modules themselves (since they tend to get
extracted and the RFC tossed ;-).

This is an awesome step forwards.  Thanks!
I was going to translate the next info-model draft to YANG so we
can compare YANG and ForCES using the same data definitions.
Looks like you already did that, but I just see the YANG tree diagram in
the draft,
not the YANG module.

It is still enough to see how YANG features would be defined, based on
protocols.
Clearly, not every I2RS router is going to implement the exact same set of
protocols.
Not every conceivable piece of data is going to be mandatory to implement.
Data organization and modularity are really important aspects to get right
the first time.


Andy



 I've assumed in the information model that yang models as defined below

   ++---+---+

   | Prefix | YANG module   | Reference |

   ++---+---+

   | if | ietf-interfaces   | 
 [YANG-IFhttp://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IF]
 |

   ||   |   |

   | ip | ietf-ip   | 
 [YANG-IPhttp://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13#ref-YANG-IP]
 |

   ||   |   |

   | rt | ietf-routing  *| [routing] |*

  ||   |   |

  | v4ur   | ietf-ipv4-unicast-routing *| [routing] |*

   ||   |   |

   | v6ur   | ietf-ipv6-unicast-routing |* [routing * |

   ||   |   |

   | yang   | ietf-yang-types   | 
 [RFC6991http://tools.ietf.org/html/rfc6991]
 |

   ||   |   |

   | inet   | ietf-inet-types   | 
 [RFC6991http://tools.ietf.org/html/rfc6991]
 |

   ++---+---+



 I've attached a revision of the RIB-info-model draft that provides:

 1)  Revised RIB Grammar in RBNF (section 6.1)

 2)  (section 6.2) Spot for the pdf graphic attached as
 draf-thares-i2rs-info-rib-only-v7.pdf

 3)  (section 6.3) Yang tree structure (per yang documents)

 4)  Revised Usage - using simplified grammar



 Basically the complex RBNF grammar boils down to very few simply
 statement.  The Yang Tree does not provide an easy way to design/debug
 redundancy. I think that the use of the UML tools that create the Yang
 modules/Yang Tree structures could speed time to market on the designs.
  For example, all the I2RS RIB is simply 5 power-point slides, that then
 can be generated into Yang module.  This seems the normal progression of
 the process you started with the Yang-modules.



 CAVEATS:

 1)  For all mistakes on the UML and diagrams blame me - this first
 pass at UMLs, and it will need revising

 2)  Some of the redundancies could have been fixed in other ways

 3)  I did Yang modules to demonstrate proof of concept

 4)  I suspect with Jamal and Joel Halpern's help (FoRCES gurus)..
 FoRCES Data model can do the same



 Sue Hares



 *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman
 *Sent:* Tuesday, April 22, 2014 8:46 PM
 *To:* Susan Hares
 *Cc:* i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim; Dean Bogdanovic;
 Russ White; Jan Medved (jmedved); Joel M. Halpern
 *Subject:* Re: [i2rs] consensus on I2RS protocol and model

 ..snip

 1)  Why do you think that only the RIB matters in the long run (Short
 run = RIB + BGP) -

 [Andy] Why do you think I said that I don't see anything special about
 I2RS at all. Editing operational state would probably work the same for
 other data.

 [Sue]: Agree!



 2)  Your modeling questions are important .. so let me ask a
 meta-question and then go a level deeper...

  Why does netmod never really publish an informational model?

  NETMOD publishes YANG modules. I suppose it is perceived an unnecessary.

 [Sue]: Other designers on lists stated they suggested they considered IM
 in their design of YANG.  I think the graphical finds redundancies

 snip)



 *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Andy Bierman

Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model

[Andy Bierman]

On Thu, Apr 24, 2014 at 3:27 AM, Jamal Hadi Salim h...@mojatatu.com wrote:

 Forgot to change the topic.
 I would like to follow up and build on this - but i wanted to make sure
 there was some sanity first.


Which drafts shows 1 I2RS client performing a network-wide edit
across N locked I2RS agents?

The agents do not coordinate with each other.
The clients do not coordinate with each other.
This is currently out of scope for the I2RS protocol.

cheers,
 jamal


Andy



 -- Forwarded message --
 From: Jamal Hadi Salim h...@mojatatu.com
 Date: Thu, Apr 24, 2014 at 6:24 AM
 Subject: Re: [i2rs] consensus on I2RS protocol and model
 To: Dean Bogdanovic de...@juniper.net
 Cc: Andy Bierman a...@yumaworks.com, i2rs@ietf.org
 i2rs@ietf.org, Martin Bjorklund m...@tail-f.com, e...@google.com
 e...@google.com, ie...@btconnect.com ie...@btconnect.com


 On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic de...@juniper.net
 wrote:
 
  On Apr 23, 2014, at 3:54 PM, Andy Bierman a...@yumaworks.com wrote:
 

  I thought I2RS is starting out focusing on 1 client and 1 agent.

 Dont think so.

  Network locking across devices is out of scope.
 
 
 
  I have same opinion as you on this one, just wanted to spell it out one
 more
  time explicitly, as I heard some discussions where network locking was
  coming up.
 

 Either I am misunderstanding both of you or both of you misunderstood the
 requirement.
 The idea is to allow a single writer per object as a starting point.
 OTOH, if you really mean what you say then I violently disagree.

 cheers,
 jamal

 PS:- Changing the topic so this is not lost in the noise because i think
 that
 the many clients-single agent brings needs for other protocol requirements.

 ___
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/listinfo/i2rs

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs