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

[Alia Atlas <[e-mail]>]

On Wed, Jun 3, 2015 at 1:15 PM, Andy Bierman <[e-mail]> wrote:

> On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas <[e-mail]> wrote:
> > Andy,
> >
> > On Fri, May 29, 2015 at 8:41 PM, Andy Bierman <[e-mail]>
> wrote:
> >>
> >> 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.
> >
> >
> > 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?
> >
>
>
> 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.
>

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

Alia



>
> > Regards,
> > Alia
> >
> >
>
> Andy
>
> >>
> >>
> >> 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
> >
> >
>