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

From: Alia Atlas <[email-masked]>
Date: Wed, 3 Jun 2015 13:02:54 -0400

Andy,

On Fri, May 29, 2015 at 8:41 PM, Andy Bierman <[email-masked]> wrote:

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

I agree.  For the stop-on-error, when one operation in the message causes
an error,
that operation is not done (can't b/c of error) AND no operations after
that  in the
message are done.  For recording errors, all operations in the message are
attempted in order and any errors are recorded to send back to the client.
If an operation caused an error, then the operation isn't completed.

Does that make sense?

Regards,
Alia

>
> 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:[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:
> >
> >
> >
> > 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 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 {
> >
> >          description "The client name";
> >
> >          type i2rs:client-name;
> >
> >       }
> >
> >       leaf priority {
> >
> >         description "The priority value assigned to this client.";
> >
> >         type i2rs:client-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
> >
> >    to the user stating the nodes where the user had insufficient
> >
> >    priority to override the state.
> >
> >
> >
> > 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
> >
> >
> >
> > On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[email-masked]> 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.
> >
> >>
> >
> >
> >
> > That is an optional mode.
> >
> > There is also a local users table that can 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
> >
> >>    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.
> >
> >>
> >
> >
> >
> >
> >
> > 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
> >
> >
> >
> >>
> >
> >>
> >
> >> -----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
> >
> >>
> >
> >> On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[email-masked]> 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:[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:
> >
> >>>> 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
> >
> >>> [email-masked]
> >
> >>> https://www.ietf.org/mailman/listinfo/i2rs
> >
> >>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Jun 2015 10:15:43 -0700

On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas <[email-masked]> wrote:
> I agree.  For the stop-on-error, when one operation in the message causes an
> error,
> that operation is not done (can't b/c of error) AND no operations after that
> in the

I think so. This is a sharp knife. Developers using anything
except 'all-or-none' will need to be very knowledgeable about the
data models in use in order for partial edits to be practical.
But I think the draft makes this clear.

Andy

---

From: Alia Atlas <[email-masked]>
Date: Wed, 3 Jun 2015 13:18:55 -0400

> But I think the draft makes this clear.

I should have read further in the thread before responding. I saw that you
gave exactly this with good clear examples.

Alia

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 15:32:06 -0400

Andy:

Just to check - are these acceptable to add as 2.4 to Jeff's document. [I added in perform all or none] to Alia's list: 

For perform all or none, when one operations in the message causes an error, 
all previous operations are rolled back to the pre-operation state. 

For the stop-on-error, when one operation in the message 
 causes an error, that operation is not done (can't b/c of error) AND 
 no operations after that in the message are done.  

For recording errors, all operations in the message are attempted in order and any 
errors are recorded to send back to the client.
 If an operation caused an error, then the operation isn't completed.

Sue 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 1:16 PM
To: Alia Atlas
Cc: Susan Hares; [email-masked]; Jeff Haas; [email-masked]; Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas <[email-masked]> wrote:
>> > 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 state.  Most YANG validation errors can be pruned from the datastore.
> I agree.  For the stop-on-error, when one operation in the message 
> causes an error, that operation is not done (can't b/c of error) AND 
> no operations after that in the message are done.  For recording 
> errors, all operations in the message are attempted in order and any 
> errors are recorded to send back to the client.

I think so. This is a sharp knife. Developers using anything except 'all-or-none' will need to be very knowledgeable about the data models in use in order for partial edits to be practical.
But I think the draft makes this clear.

Andy

>> > occurring in a single message, but it does not require 
>> > multi-message atomicity and rollback. Three types of error handling 
>> > should be supported:
>> >
>> >
>> >
>> > Will this cover the architecture document 7.9 transactions impact 
>> > on ephemeral state?
>> >
>> >
>> >
>> > Sue Hares
>> >
>> >
>> >
>> > (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.
>> >
>> > 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
>> > 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.
>> > These two model documents show why atomic state may be on a very 
>> > small section of the whole change.
>> >
>> >
>> >
>> > 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 {
>> >
>> > 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
>> >
>> > on config=false data. It is possible some edits to NACM are needed 
>> > “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
>> >
>> > needed even if no objects are added to the data structure."
>> >
>> >
>> >
>> > Sue
>> >
>> >
>> >
>> >> attribute that is stored in the NACM list on the agent (see 
>> >> Section 5.2 as described
>> >> 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.
>> >
>> >>
>> >
>> >> 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
>> >
>> >>
>> >
>> > The last paragraph sounds like some nodes will be accepted and 
>> > others rejected.
>> >
>> >>> 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
>> >
>> >>> ------------------------
>> >
>> >>>         Application 1:  TCP session 3 -  priority 20, opaque 
>> >>> "Weekly config"
>> >
>> >>>         Application 1:  TCP session 4 -  priority 55, opaque 
>> >>> "Emergency config"
>> >
>> >>>
>> >
>> >>>>> should be mandatory for I2RS or required to configure I2RS 
>> >>>>> client priority.
>> >
>> >>>>>
>> >
>> >>>>>    list i2rs-client {
>> >
>> >>>>>       key name;
>> >
>> >>>>>       leaf name {
>> >
>> >>> 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.
>> >
>> >>>
>> >
>> >>> 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
>> >
>> >>>
>> >
>> >>>> --
>> >

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Jun 2015 12:45:01 -0700

> all previous operations are rolled back to the pre-operation state.

Yes, but rollback is an implementation detail.
Typically, the server will attempt to validate
the edits before applying any of them.
This is required by YANG Patch.

It is possible for everything to validate and the internal
commit of an edit to still fail.  Then a real rollback happens
on the server.

>From the client POV, all-or-none does not change the
resource unless all edits are applied successfully.
Whether nodes were temporarily applied and then removed
is not visible to the client.

Andy

>>> >> nodes

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 15:55:56 -0400

Andy: 

I would take a set of sample language on the perform all or none.  Any suggestions or edits?  Other answers below.

Here's what I think we have 
=======================

For the stop-on-error, when one operation in the message  causes an 
error, that operation is not done (can't b/c of error) AND  no 
operations after that in the message are done.

For recording errors, all operations in the message are attempted in 
order and any errors are recorded to send back to the client.
If an operation caused an error, then the operation isn't completed.

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

On Thu, Jun 4, 2015 at 12:32 PM, Susan Hares <[email-masked]> wrote:
> For perform all or none, when one operations in the message causes an 
> error, all previous operations are rolled back to the pre-operation state.
>

Yes, but rollback is an implementation detail.
Typically, the server will attempt to validate the edits before applying any of them.
This is required by YANG Patch.

It is possible for everything to validate and the internal commit of an edit to still fail.  Then a real rollback happens on the server.

[OK.  It is obvious I step on the text here.  Please provide alternative. ] 

resource unless all edits are applied successfully.
Whether nodes were temporarily applied and then removed is not visible to the client.

> For the stop-on-error, when one operation in the message  causes an 
> error, that operation is not done (can't b/c of error) AND  no 
> operations after that in the message are done.
>
> For recording errors, all operations in the message are attempted in 
> order and any errors are recorded to send back to the client.
> Cc: Susan Hares; [email-masked]; Jeff Haas; [email-masked]; 
> Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern
>>> > multi-message atomicity and rollback. Three types of error 
>>> > handling should be supported:
>>> >
>>> >
>>> >
>>> > 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:
>>> >
>>> >
>>> >
>>> > 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
>>> > “Ephemeral configuration state nodes that are created or altered 
>>> > by users that match a rule carrying i2rs-priority will have those 
>>> > 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
>>> >
>>> >
>>> >
>>> >> out-of-band from the I2RS protocol these values.  Into the 
>>> >> Client, the Agent's ID is loaded.
>>> >> 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 
>>> >> 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."
>>> >
>>> >>
>>> >
>>> >>> 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
>>> >

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Jun 2015 20:09:47 -0400

[I am massively behind in my mail again. My apologies.]

On Fri, May 29, 2015 at 08:10:24AM +0200, Juergen Schoenwaelder wrote:
> 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.

As discussed at the most recent interim, the priority should be made a
property of the group rather than a rule.  I have no issue with this.

To answer other comments regarding "why put this in NACM at all", this is an
attempt to show binding of user to priority.  In the case that NACM is in
use, I believe this would be required by I2RS.  In the absence of NACM, it
would be a similar property of a local user database.

-- Jeff