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

[Andy Bierman <[e-mail]>]

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