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

From: "Susan Hares" <[email-masked]>
Date: Wed, 27 May 2015 14:52:39 -0400

Ran

I appreciate you taking the time to present your draft at the i2RS interim.
Your draft suggests: 

When the I2RS session is opened, An I2RS Client should advertise to

   an I2RS Agent that the I2RS Client's identifier and priority.  The

   I2RS Client's identifier and priority should be managed by the I2RS

   Agent, and associated with its I2RS session.

It was an important contrast to the existing assumption which Joel pointed
out - that I2RS authentication is done outside of the I2RS protocol.  This
is the agreed upon position in the I2RS architecture document. 

The I2RS architecture has proposed that the other authentication protocols
(For Example AAA's Radius or Diameter) would establish the identity outside
the I2RS protocol.  Most routing people have AAA protocols to establish
identity for other purposes.  The priority would be associated with the
client identity and stored by the I2RS agent per client. 

Your draft provides another alternative the WG should hear during its
deliberation process.  It could be done outside the I2RS protocol as a
simple authentication scheme.  As a WG chair, I appreciate your willingness
to bring an alternate proposal to our current thoughts to help us keep
nimble in our thinking.   During the next 2 weeks, I hope you will continue
to actively participate in the authentication and identity discussion. 

Joel's comments were: 

.         We already have an identity establishing mechanism between the
client-agent. It is the AAA authentication. If we introduce into the I2RS
protocol any in-protocol portion fo identity, we make our lives harder

.         [Ran]: Could you expand upon the question and concepts? 

.         [joel]: If you look at the I2RS mutual authentication in AAA, it
is a identity that other people understand. The client -agent authentication
in the out-protocol use is what people understand. 

.         [Ran]: netconf/restconf have authentication, but it only includes
identity. It does not include the priority.  We can also modify priority.

.         [Joel]: Let me step back into your draft for a moment.  You have a
constraint on the format of Identity and the mappings between identity to
implementation format.  We had that debate, and decided these implementation
mappings are an implementation format. 

.         [Joel]: Let me return to priority, the NACM (as defined in Jeff's
draft) will give us priority associated with a client.  We do not need new
mechanism. 

.         [Ran]: Is this a requirement in the architecture or a restatement
from the WG discussion? 

.         [Sue]: Restatement of the WG discussion on NACM.   The
implementation mapping should be implied in the architecture document.
However we are grateful for your question that makes this clearer. 

.         [Alia]: We choose this direction to maximize re-use of existing
protocols and mechanism for the first release of the I2RS protocol.

.         [Sue]: Is Client priority store in the agent per node? How does it
occur? 

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

 People may respond to this post with other discussion points on the
identity and secondary identity. 

Sue

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 May 2015 00:09:01 +0200

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

[discussion about priority]
 
>          +--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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 May 2015 19:35:07 -0400

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

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 May 2015 18:04:58 -0700

On Wed, May 27, 2015 at 4:35 PM, Joel M. Halpern <[email-masked]> wrote:
> When a client performs an operation, the client identity and priority are
> recorded both for traceability and for future comparison.
> (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?

> Joel

Andy

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 May 2015 08:05:02 +0200

>         type i2rs:client-priority;

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

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?

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.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 May 2015 05:19:50 -0400

Joel and Juergen: 

This is my understanding as well.   When a client performs an operation, the
client identity (primary and secondary) and priority are recorded on the
object (E.g. Route for traceability and for future comparison).  If later
actions change the attempt to change the object, only clients identities
(primary and secondary) with greater priority can change it.   You are
correct that this means the first write wins in I2RS architecture.  Alia
remembers this was discussed on the list and in I2RS sessions.  

Jeff's proposal is that all actions by a client identity have the same
priority, and that a client identity in a Transport connection cannot change
priority.  This is a good starting point.  

However, in the discussion in the interim session - Alia indicated that the
client with multiple Transport connections might have different priorities
for the different sessions.  Alia - did I understand you correctly? 

Sue Hares 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, May 27, 2015 7:35 PM
To: Susan Hares; [email-masked]; 'Jeffrey Haas'; [email-masked]; 'Alia
Atlas'
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2015 06:19:48 -0400

I believe the point of Alia's comment was that something that is 
actually one client could behave as if it is multiple clients.  It could 
have multiple identities it can authenticate.  Each of those could be 
used with different connections.  From the point of view of I2RS this is 
multiple clients. From the point of view of the software, it is a single 
client with multiple prioritieis.  This is a fairly typical 
implementation tchnique that keeps protocol simple, while allowing 
flexible operation.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 May 2015 08:17:16 -0700

> NETCONF/RESTCONF username?

Is is probably not different.

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

> tools I2RS needs? This is probably a question the NETCONF WG has to

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.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 May 2015 19:22:22 -0400

Andy: 

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

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?

Sue 
===============

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 {

   +--rw rule-list [name]
      +--rw name     string
      +--rw group*   union
      +--rw rule [name]
         +--rw name string
         +--rw module-name?  union
         +--rw (rule-type)?

Are you proposing something different than Jeff's proposal? 

Sue 

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

On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder <[email-masked]> 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 {

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

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.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 May 2015 19:34:15 -0400

Juergen:

In my opinion, the i2rs:client-name is not different than the
NETCONF/RESTCONF user name.   If you have a proposal on how to link the i2rs
priority to different than Jeff's proposal for NACM rules, we would be glad
to hear it.   Jeff is trying to provide workable I2RS requirements to the
netconf/netmod WGs 

The architecture document indicates that the I2RS Client will obtain the
client identity and priority out-side of the protocol.  Our intent was to
re-use the AAA mechanisms to spread client-identity, priority, and secondary
opaque id (if necessary).   Early proof-of-concept implementations suggest
this easily linked to. 

NETCONF/NETMOD will indeed need to determine how the NETCONF protocol WG
will meet (or not meet) the I2RS requirements.  

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 2:05 AM
To: Andy Bierman
Cc: Joel M. Halpern; Jeffrey Haas; [email-masked]; [email-masked]; Alia
Atlas; Susan Hares

>         type i2rs:client-priority;

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

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?

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.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 May 2015 16:39:45 -0700

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

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 28 May 2015 20:09:23 -0400

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.  

I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will be annotated with meta-data with the client-id, priority, and secondary ID.  

The only proposed change to section 5.2 requirements is to the sentence 
"Additionally, during commit processing, if
   nodes are found where i2rs-priority is already present, and the
   priority is better than the transaction's user's priority for that
   node, the commit SHALL fail.

" Additionally, during commit processing" is incorrect because there is not commit processing.   Jeff stated we are still working with both NETCONF and RESTCONF - so we must allow for a commit process.  In the meeting I noted that the architecture indicates a change is possible only if the priority is greater than (>) existing priority.  (First rather than last).  Therefore this text should read:  "Additionally, during the operation (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where i2rs-priority is already present, and the priority is equal to or better than the transaction's user's priority for the node, the operation/commit SHALL fail." 

Do you have any suggestions for modifications to section 5 of Jeff's document? 

Sue 

============================
Jeff's document 5.2 states: 

  To support Multi-Headed Control, I2RS requires that there be a
   decidable means of arbitrating the correct state of data when
   multiple clients attempt to manipulate the same piece of data.  This
   is done via a priority mechanism with the highest priority winning.
   This priority may vary on a per-node or sub-tree basis based for a
   given identity.

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

   Ephemeral configuration state nodes that are created or altered by
   users that match a rule carrying i2rs-priority will have those nodes
   annotated with metadata.  Additionally, during commit processing, if
   nodes are found where i2rs-priority is already present, and the
   priority is better than the transaction's user's priority for that
   node, the commit SHALL fail.  An appropriate error should be returned
   to the user stating the nodes where the user had insufficient
   priority to override the state.

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 7:40 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; [email-masked]; [email-masked]; Alia Atlas
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

Not sure what you mean.

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

Andy

> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey 
> Haas; [email-masked]; [email-masked]; Alia Atlas; Susan Hares
>> 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?
>>
>
>> 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.
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 28 May 2015 17:22:36 -0700

> 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 (…

That is an optional mode.
There is also a local users table that can be used.

> Do you have any suggestions for modifications to section 5 of Jeff's document?

The last paragraph sounds like some nodes will be accepted and others rejected.
If any nodes are rejected, the entire edit should be rejected.

I don;t think the rule-list should store the client priority.
It should be in the 'group' list, or outside NACM completely.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 May 2015 08:10:24 +0200

> 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 (…

So I will ask again: If the priority is a property of the I2RS client
(this is how I understand the I2RS architecture document), why would
it be configured as part of a NACM rule as suggestd in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the
priority a property of the scope of a NACM group.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 May 2015 08:15:14 +0200

> to hear it.   Jeff is trying to provide workable I2RS requirements to the

Andy already made a proposal.

> opaque id (if necessary).   Early proof-of-concept implementations suggest

I do not care where the I2RS client obtains its identity from. My
concern is the server and I like to get an answer whether the priority
is a property of a client, a property of a NACM group (of clients), or
whether the priority is a property of a NACM access control rule.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 12:03:18 -0400

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:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, May 29, 2015 2:10 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Andy Bierman'; 'Alia Atlas';
'Jeffrey Haas'; 'Joel M. Halpern'
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

> 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 the I2RS architecture document), why would it be
configured as part of a NACM rule as suggestd in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a
property of the scope of a NACM group.

/js

-- 

Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 May 2015 18:25:08 +0200

Thanks for all the details but I am missing an answer to my question.
Shall I repeat it once more?

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 May 2015 12:32:02 -0400

I think that the problem answering your question is that as long as the 
priority gets associated with the client, I2RS does not care where the 
information is.  So we are open to the various alternatives that have 
been suggested in this regard.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 12:40:37 -0400

Andy: 

Just to clarify is this an a

  "That is an optional mode [of NACM]. There is also a local users table
that can be used."   Can you provide an example?  Is this an alternate
proposal to Jeff's proposal on NACM? 

 Sue Hares

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, May 28, 2015 8:23 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]; Juergen Schoenwaelder; Alia Atlas;
Jeffrey Haas; Joel M. Halpern
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Sue]: You mean this is an optional mode of NACM?  Can you give me a
reference for the local users table?  Is it RFC6536 in section 2.5 where a
configurable set of users can be defined, and linked to a NACM (section
3.1.1)?  Can you provide an example  how the local users table could be
used? 

> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will
be annotated with meta-data with the client-id, priority, and secondary ID.
>
> The only proposed change to section 5.2 requirements is to the 
> sentence "Additionally, during commit processing, if
> " Additionally, during commit processing" is incorrect because there is
not commit processing.   Jeff stated we are still working with both NETCONF
and RESTCONF - so we must allow for a commit process.  In the meeting I
noted that the architecture indicates a change is possible only if the
priority is greater than (>) existing priority.  (First rather than last).
Therefore this text should read:  "Additionally, during the operation
(RESTCONF)/Commit (NETCONF) processing, if the nodes are found where
i2rs-priority is already present, and the priority is equal to or better
than the transaction's user's priority for the node, the operation/commit
SHALL fail."
> Do you have any suggestions for modifications to section 5 of Jeff's
document?

The last paragraph sounds like some nodes will be accepted and others
rejected.
If any nodes are rejected, the entire edit should be rejected.

Andy

> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; 
> [email-masked]; [email-masked]; Alia Atlas
>> Yes - the client with priority and secondary identity are inherently
simple additions.   Can you confirm my understanding below based on Jeff's
document?
>> 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?
>> 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
<[email-masked]> wrote:
>> My point showing the 2 item list is that the information needed to
implement I2RS client priority is rather trivial.
>> 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.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 May 2015 09:47:18 -0700

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

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 May 2015 09:58:12 -0700

> proposal to Jeff's proposal on NACM?

Actually the local user table is in ietf-system.yang:
http://www.netconfcentral.org/modules/ietf-system/2014-08-06#user.659

The 'user-name' leaf-list in the NACM 'group' list is populated by
the administrator.  The actual values are irrelevant to NACM.
They can be local users, Radius, or anything else.  Adding a user-name
to this list does not in any way enable the server to accept sessions
from that user.  This is outside the scope of NACM.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 13:44:03 -0400

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 <https://tools.ietf.org/html/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 change.  

> I don’t think the rule-list should store the client priority.

> It should be in the 'group' list, or outside NACM completely."

Your alternate proposal are: 

1)            Moving i2rs-priority to group list 

2)            Adding a i2rs-client [unspecified location] 

This mail deals with #1.  If you have more details on proposal #2, please suggest them on the list.  

list i2rs-client {

      key name;

      leaf name {

         type i2rs:client-name;

      }

      leaf priority {

     }

  }

Question: Is this i2rs-list to be included in the group list for NACM (as listed below from RFC6536) as a leaf list below? 

       container groups {

         description

           "NETCONF Access Control Groups.";

         list group {

          key name;

           description

             "One NACM Group Entry.  This list will only contain

              configured entries, not any entries learned from

              any transport protocols.";

           leaf name {

             type group-name-type;

             description

               "Group name associated with this entry.";

           }

           leaf-list user-name {

             type user-name-type;

             description

               "Each entry identifies the username of

                a member of the group associated with

                this entry.";

           }

          # add leaf-list I2rs-client here 

         }

       }

Your message: http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html

States:  "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."

Do you have a proposal for changing the text in section 5.2 of draft-haas-i2rs-ephemeral-state-reqs-00?  

Is it sufficient to state:   “NACM implementations for I2RS will need to check write request on config=false, ephemeral = true. “

before the paragraph: 

“Ephemeral configuration state nodes that are created or altered by users that match a rule carrying i2rs-priority will have those nodes annotated with metadata.  Additionally, during commit processing, if nodes are found where i2rs-priority is already present, and the  priority is better than the transaction's user's priority for that node, the commit SHALL fail. An appropriate error should be returned

I’m unclear what this means: “It is possible some edits to NACM are needed even if no objects are added to the data structure."

Sue 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 8:23 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; [email-masked]; [email-masked]; Alia Atlas
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

 

 

 

Andy

> From: Andy Bierman [ <mailto:[email-masked]> mailto:[email-masked]]

>  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Alia Atlas

> On Thu, May 28, 2015 at 4:22 PM, Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

>>   <foo xmlns:i2rs=" <https://ietf.example.com/i2rs> https://ietf.example.com/i2rs"

>>         I2rs:i2rs-secondary-identity="pub-sub montior"

>> i2rs:i2rs-priority="1">

>> From: Andy Bierman [ <mailto:[email-masked]> mailto:[email-masked]]

>> Haas;  <mailto:[email-masked]> [email-masked];  <mailto:[email-masked]> [email-masked]; Alia Atlas; Susan Hares

>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder < <mailto:[email-masked]> [email-masked]> wrote:

>>> Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/> http://www.jacobs-university.de/>

>>  <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 14:18:42 -0400

Andy: 

I agree that priority in draft-haas-i2rs-ephemeral-state-reqs  links to each NACM rule.  Jeff states in section 5.2  "this priority may vary on a per-node or sub-tree basis based for a  given identity".  

Joel states http://www.ietf.org/mail-archive/web/i2rs/current/msg02522.html states 

"Priority is associated with a client. A client does not get to change its priority (although administrators clearly can)." 

Alia also stated that if an application wants to use an I2RS client to connect with multiple TCP sessions with different priorities, the client should utilize a different identity for each different priority.  With this restriction, each client has 1 priority setting whether or not it utilizes the multiple TCP sessions. 

If we can reach consensus on this point, then we can suggest change to Jeff's document in section 5.2 based on that consensus. If you agree,  my next step is to call for consensus on this point, so we can change Jeff's document based on this consensus.  
 
Sue 
-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, May 29, 2015 12:47 PM
To: Juergen Schoenwaelder; Susan Hares; [email-masked]; [email-masked]; Andy Bierman; Alia Atlas; Jeffrey Haas; Joel M. Halpern
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

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.

Andy

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 15:10:03 -0400

Juergen: 

I appreciate your patience as I attempt to answer your question in these
three emails: 

http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html

If the priority is a property of the I2RS client

http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html

"My concern is the server and I like to get an answer whether the priority

whether the priority is a property of a NACM access control rule."

http://www.ietf.org/mail-archive/web/i2rs/current/msg02536.html

 

Short Answer:   I agree with Andy's message that priority is an
property/attribute of a client.  Alia and Joel state that 1 client has 1 and
only 1 priority.  Only an administrator can change the priority associated
with a client.  No one has specified what occurs when the administrator
changes priority.  Andy's 3 proposals below do not provide a complete
alternate proposal to Jeff proposal.  

Recommendation: I recommend we call for consensus for a client having 1 and
only 1 priority, and determine what happens when the administrator can
change the priority.   After we agree, we can focus on suggesting a change
to section 5.2 of draft-haas-i2rs-ephemeral-state-req.  Jeff's statement
"This priority may vary on a per-node or sub-tree basis based for a given
identity" does not seem to have consensus with the I2RS WG.    

Longer Answer:    Section 5.2 draft-haas-i2rs-ephemeral-state-reqs  links
this to a NACM that is arbitrating the correct state of data when multiple
clients attempt to manipulate the same piece of data.  This is done via a
priority mechanism with the highest priority winning.
Draft-haas-i2rs-ephemeral-state-req states "this priority may vary on a
per-node or sub-tree basis based for a given identity."  Jeff's  proposal
arises out of section 4.2 in the I2RS architecture document.  This section
states: 

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 this section, but he makes
the assumption that: "This priority may vary on a per-node or sub-tree basis
based for a given identity." (section 5.2) 

A consensus call will be issue to check to agree that: 

"A client identity have only 1 priority for all nodes or sub-trees.  If a
client uses multiple TCP sessions each with a different priority, the client
must use multiple identities where each identity is linked to 1 and only 1
priority." 

 ============

Andy's Proposals:  Andy's Bierman's suggestion in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html  has been
responded to in other email asking for clarification of the proposal.   

Proposal 1: Moving i2rs-priority to client user 

  This is a Is a change section 5.2 of draft-haas-i2rs-ephemeral-state-reqs
to move from NACM

Andy states jeff's change is  optional mode of NACM
(http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) . Andy
first indicates Jeff thought the the priority can be on the group-list
(http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html), but later
he revises his opinion (
http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html) to state
this must be associated with the client.  He notes Martin mentioned this
first. This placement of priority on client aligns with Joel and Alia's
comments. 

Issue regarding this options:  Why are we not using NACM rule list to
protect against multiple write access by lower priority clients? 

1)      If we agree that a client can be linked to a single priority - it
doesn't matter where it is located.  It can be configured by AAA and stored
in a location in the I2RS Agent and the I2RS client. 

2)      Andy states in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html

"I don't think the client should provide the priority in request messages.
This is configured on the agent, not requested by the client." IMHO Jeff's
proposal suggests it is passed in out-of-band mechanism from netconf or i2RS
additions to netconf. 

3) Mixing client and groups is problematic: 

http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html states: 

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

Proposal 2) Adding a i2rs-client to local users table 

(from http://www.ietf.org/mail-archive/web/i2rs/current/msg02541.html) 

Issues with this proposal: 

1)      This proposal does not use NACM to enforce the I2RS priority
mechanism.  It requires the I2RS agent to create additional mechanisms to
enforce use of priority to resolve multi-headed control writes. 

2)      Andy states in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html

"I don't think the client should provide the priority in request messages.
This is configured on the agent, not requested by the client."  Does this
propose it is passed in an unsecure way? 
 
Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs - implies this is stored
in a NACM rule list on the agent.  How the NACM rule is generated is not
specified IMHO. 

Proposal 3: Andy states in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html

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

Comment:  Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs only applies
to config=false.  Is there some wording that

needs to be added to make sure Andy's concern is addressed. 

Let me know if you have more questions. 
 
Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, May 29, 2015 2:10 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; 'Andy Bierman'; 'Alia Atlas';

/js

-- 

i2rs mailing list

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 17:55:42 -0400

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: 

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:[email-masked]] 
Sent: Friday, May 29, 2015 1:44 PM
To: 'Andy Bierman'
Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; [email-masked]'; [email-masked]'; 'Alia Atlas'
Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00

Andy: 

list i2rs-client {

      key name;

      leaf name {

         type i2rs:client-name;

      }

      leaf priority {

     }

  }

       container groups {

         description

         list group {

          key name;

           description

           leaf name {

             type group-name-type;

             description

           }

           leaf-list user-name {

             type user-name-type;

             description

                this entry.";

           }

         }

       }

before the paragraph: 

Sue 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 8:23 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; [email-masked]; [email-masked]; Alia Atlas
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

 

 

 

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 May 2015 17:41:34 -0700

On Fri, May 29, 2015 at 2:55 PM, Susan Hares <[email-masked]> 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

> 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:
>
>
>
> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
> [email-masked]'; [email-masked]'; 'Alia Atlas'
> I missed the second part of the email
> (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in my
> earlier message:
>
>
>
> 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)).
>
>
>
> Question: Is this i2rs-list to be included in the group list for NACM (as
> listed below from RFC6536) as a leaf list below?
>
>
>
>        container groups {
>
>          description
>
> Your message:
> http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html
>
> States:  "I think I2RS interaction with NACM needs to be clearly defined.
> on config=false data. It is possible some edits to NACM are needed even if
> no objects are added to the data structure."
>
>
>
> Is it sufficient to state:   “NACM implementations for I2RS will need to
> check write request on config=false, ephemeral = true. “
>
> before the paragraph:
>
>
>
> “Ephemeral configuration state nodes that are created or altered by users
> that match a rule carrying i2rs-priority will have those nodes annotated
> with metadata.  Additionally, during commit processing, if nodes are found
> where i2rs-priority is already present, and the  priority is better than the
> transaction's user's priority for that node, the commit SHALL fail. An
> appropriate error should be returned
>
> I’m unclear what this means: “It is possible some edits to NACM are needed
> even if no objects are added to the data structure."
>
>
>
> Sue
>
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 29 May 2015 21:59:59 -0400

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:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, May 29, 2015 8:42 PM
To: Susan Hares
Cc: [email-masked]; Jeff Haas; [email-masked]; Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

>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.
>The must/min-elements/unique statements can cause validation errors on nodes outside the edit list.
>

[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

> 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:
>
>
>
> (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in 
> my earlier message:
>
>
>
> 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
> 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.
> Question: Is this i2rs-list to be included in the group list for NACM 
> (as listed below from RFC6536) as a leaf list below?
>
>
>
>        container groups {
>
>          description
>
> “Ephemeral configuration state nodes that are created or altered by 
> I’m unclear what this means: “It is possible some edits to NACM are 
> needed even if no objects are added to the data structure."
>
>
>
> Sue
>
>
>
>> 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
>> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent 
>> will be annotated with meta-data with the client-id, priority, and secondary ID.
>
>>
>
>> and RESTCONF - so we must allow for a commit process.  In the meeting 
>> I noted that the architecture indicates a change is possible only if 
>> the priority is greater than (>) existing priority.  (First rather than last).
>> i2rs-priority is already present, and the priority is equal to or 
>> better than the transaction's user's priority for the node, the 
>> operation/commit SHALL fail."
>
>>
>
>>> RESTCONF to use client priority?"  What are you proposing that you 
>>> do not want to add the NACM list the priority?
>
>>
>
>>> 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
>
>>>
>
>>>> --
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 May 2015 22:02:57 -0400

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.

yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 May 2015 20:13:29 -0700

On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern <[email-masked]> 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 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.
>

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.

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
>>
>> Cc: [email-masked]; Jeff Haas; [email-masked]; Juergen Schoenwaelder;
>> Alia Atlas; Jeffrey Haas; Joel M. Halpern
>> [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
>>
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 May 2015 23:34:11 -0400

Your examples match my understanding of the intent of the draft.

The assumption is that
if there is mutual dependence, the client will use all-or-none
if there is an ordering constraint, the client will use until-error
if there is no ordering coupling, but just a bundling for convenience, 
the client can use all storing errors.

The text does not specify what consistency checks are applied in cases 2 
and 3.  Classic network management would lead one to expect full 
consistency checks.  Modeling as individual api operations (and some 
people's view of cli) would lead to no consistency checks.

Yours,
Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 30 May 2015 09:11:20 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> "If the operator wants to shoot himself in the foot, I2RS' job is to
> let him."

Yes, semantic constraints means additional processing on the server.
How much is implementation dependent, and obviously dependent on the
constraint (must ../foo; is cheaper than must //*[contains(., "a")]).

If the WG is moving towards a solution where the ephemeral I2RS data
is explicitly modelled, you can simply choose to not put semantic
constraints into the model in most cases (and explain what the
implementation is supposed to do with seemingly invalid data).

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 30 May 2015 10:46:45 -0400

Andy and Joel:

Andy's examples seem reasonable to me.  Let me try to put together text for Jeff's document that represents Andy's examples.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, May 29, 2015 11:13 PM
To: Joel M. Halpern
Cc: [email-masked]; Jeff Haas; [email-masked]; Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Susan Hares
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern <[email-masked]> wrote:
> the form "If the operator wants to shoot himself in the foot, I2RS' 
> job is to let him."

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.

Andy

>> Cc: [email-masked]; Jeff Haas; [email-masked]; Juergen 
>> Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern
>>>> 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
>>> 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
>> [sue]:  On case: or if perform and until error / or perform and 
>> record error - you are assuming these are a validation error?
>>> 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
>>> 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.
>>> Question: Is this i2rs-list to be included in the group list for 
>>> NACM (as listed below from RFC6536) as a leaf list below?
>>>
>>>
>>>
>>>         container groups {
>>>
>>>           description
>>>
>>>> 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 
>>>> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an 
>>>> Agent will be annotated with meta-data with the client-id, 
>>>> priority, and secondary ID.
>>>
>>>
>>>>
>>>
>>>> and RESTCONF - so we must allow for a commit process.  In the 
>>>> meeting I noted that the architecture indicates a change is 
>>>> possible only if the priority is greater than (>) existing 
>>>> priority.  (First rather than last).
>>>> Therefore this text should read:  "Additionally, during the 
>>>> operation (RESTCONF)/Commit (NETCONF) processing, if the nodes are 
>>>> found where i2rs-priority is already present, and the priority is 
>>>> equal to or better than the transaction's user's priority for the 
>>>> node, the operation/commit SHALL fail."
>>>
>>>
>>>>
>>>
>>>>> 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?
>>>
>>>
>>>>
>>>
>>>>> change by the administrator will be to select which clients should 
>>>>> continue working and which should be broken.
>>>
>>>
>>>>>
>>>
>>>>>
>>>
>>>>>>
>>>
>>>>>> /js
>>>
>>>
>>>>>>
>>>
>>>>>
>>>
>>>>> Andy
>>>
>>>
>>>>>
>>>
>>>>>> --
>>>
>>>