On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern <[email protected]> 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:[email protected]] On Behalf Of Andy Bierman
>> Sent: Friday, May 29, 2015 8:42 PM
>> To: Susan Hares
>> Cc: [email protected]; Jeff Haas; [email protected]; 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 <[email protected]> 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:[email protected]]
>>> Sent: Friday, May 29, 2015 1:44 PM
>>> To: 'Andy Bierman'
>>> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
>>> '[email protected]'; '[email protected]'; '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 protected]]
>>> Sent: Thursday, May 28, 2015 8:23 PM
>>> To: Susan Hares
>>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;
>>> [email protected]; [email protected]; Alia Atlas
>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>>>
>>>
>>>
>>> On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[email protected]> 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 protected]]
>>>
>>>
>>>> Sent: Thursday, May 28, 2015 7:40 PM
>>>
>>>
>>>> To: Susan Hares
>>>
>>>
>>>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;
>>>
>>>
>>>> [email protected]; [email protected]; Alia Atlas
>>>
>>>
>>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>>>
>>>
>>>>
>>>
>>>> On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[email protected]> 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 protected]]
>>>
>>>
>>>>> Sent: Thursday, May 28, 2015 11:17 AM
>>>
>>>
>>>>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey
>>>
>>>
>>>>> Haas; [email protected]; [email protected]; 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 protected]> 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 protected]
>>>
>>>
>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>>
>>>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
