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

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

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:[e-mail]] On Behalf Of Andy Bierman
Sent: Friday, May 29, 2015 11:13 PM
To: Joel M. Halpern
Cc: [e-mail]; Jeff Haas; [e-mail]; 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 <[e-mail]> wrote:
> Some of the discussions in the working group earlier (not formally 
> captured in the archtiecture, and not clarified in discussion) were of 
> the form "If the operator wants to shoot himself in the foot, I2RS' 
> job is to let him."
> If that is the model that the working group is assuming, then I am not 
> sure that consistency / validity enforcement is desired.
>
> I don't have a strong opinion one way or another.  I believe at least 
> some people saw the omission of such checks as a path to improvd 
> transaction rates.
>
> My only concern is to avoid accidentally chaning a working group agreement.
>


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

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

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

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

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

This is my understanding of the 3 options.



> yours,
> Joel

Andy

>
> On 5/29/15 9:59 PM, Susan Hares wrote:
>>
>> Andy:
>>
>> See one question below.  If alter to not store invalid values in the 
>> datastore - is my addition to Jeff's 2.4 addition acceptable?
>>
>> Sue
>>
>> -----Original Message-----
>> From: i2rs [mailto:[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
>>
>>
>

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