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

["Susan Hares" <[e-mail]>]

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

On Fri, May 29, 2015 at 2:55 PM, Susan Hares <[e-mail]> wrote:
>> Andy:
>>
>>
>>
>> On all actions working or not – you should look at section 7.9 of the 
>> architecture.  It allows “perform all or none”, “perform until error”, and
>> “perform all storing errors.”    I will propose an addition to section 2.4
>> to Jeff’s document:
>>
>>

>>OK -- I remember these options now.

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

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

Andy

>
> 2.4 ) Transaction to ephemeral state:
>
>
>
> The ephemeral state should support a multiple parts of a operation 
> occurring in a single message, but it does not require multi-message 
> atomicity and rollback. Three types of error handling should be supported:
>
>
>
>    Perform all or none:   This traditional SNMP semantic indicates that
>
>       other I2RS agent will keep enough state when handling a single
>
>       message to roll back the operations within that message.  Either
>
>       all the operations will succeed, or none of them will be applied
>
>       and an error message will report the single failure which caused
>
>       them not to be applied.  This is useful when there are, for
>
>       example, mutual dependencies across operations in the message.
>
>
>
>    Perform until error:   In this case, the operations in the message
>
>       are applied in the specified order.  When an error occurs, no
>
>       further operations are applied, and an error is returned
>
>       indicating the failure.  This is useful if there are 
> dependencies
>
>       among the operations and they can be topologically sorted.
>
>
>
>    Perform all storing errors:   In this case, the I2RS Agent will
>
>       attempt to perform all the operations in the message, and will
>
>       return error indications for each one that fails.  This is 
> useful
>
>       when there is no dependency across the operation, or where the
>
>       client would prefer to sort out the effect of errors on its own.
>
>
>
>    In the interest of robustness and clarity of protocol state, the
>
>    protocol will include an explicit reply to modification or write
>
>    operations even when they fully succeed.
>
>
>
>
>
> Will this cover the architecture document 7.9 transactions impact on 
> ephemeral state?
>
>
>
> Sue Hares
>
>
>
> From: Susan Hares [mailto:[e-mail]]
> Sent: Friday, May 29, 2015 1:44 PM
> To: 'Andy Bierman'
> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; 
> '[e-mail]'; '[e-mail]'; '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:[e-mail]]
> Sent: Thursday, May 28, 2015 8:23 PM
> To: Susan Hares
> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; 
> [e-mail]; [e-mail]; Alia Atlas
> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>
>
>
> On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[e-mail]> 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:[e-mail]]
>
>> Sent: Thursday, May 28, 2015 7:40 PM
>
>> To: Susan Hares
>
>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;
>
>> [e-mail]; [e-mail]; Alia Atlas
>
>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>
>>
>
>> On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[e-mail]> 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:[e-mail]]
>
>>> Sent: Thursday, May 28, 2015 11:17 AM
>
>>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey
>
>>> Haas; [e-mail]; [e-mail]; Alia Atlas; Susan Hares
>
>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>
>>>
>
>>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder 
>>> <[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>
>>>> Fax:   [phone]         <http://www.jacobs-university.de/>
>
>>>
>
>>> _______________________________________________
>
>>> i2rs mailing list
>
>>> [e-mail]
>
>>> https://www.ietf.org/mailman/listinfo/i2rs
>
>>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs