Andy:
Yes - the client with priority and secondary identity are inherently simple
additions. Can you confirm my understanding below based on Jeff's document?
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?
Sue
===============
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
