Secondary identity can (and in fact is expected to) change during the
session an I2RS client has with an I2RS Agent. Specifically, if the
client is acting as a broker, it will need to associated different
operations with different secondary identities.
Priority is, as I understand it, per session. I tend to think of
priority as coming from AAA, not from the Client, but that is something
we can discuss.
Yours,
Joel
On 7/13/15 6:46 PM, Jeffrey Haas wrote:
On Sat, Jul 04, 2015 at 11:25:29AM +0800, [email protected] wrote:
I have some doubt about "draft-ietf-i2rs-ephemeral-state-00".
1.Chapter 6 Requirements regarding Identity, Secondary-Identity and
Priority
I2RS permits RPC operation to carry priority and a secondary identity as
attribute parameters.
In this draft, it describes that "This secondary identity meta-data MUST
be read-only. operations attempting to alter it MUST be silently ignored.
"
Since identity attribute cannot be changed until the session terminates,
why don't we permit client to send hello message with such infos during
session establishment.
e.g,
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.0
</capability>
<capability>
urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1&priority=10
</capability>
</capabilities>
</hello>
It means in this session, the secondary-identity is named "user1", the
default priority is 10
This would be an acceptable means of encoding the secondary-identity. Does
anyone working on a netconf implementation have any opinions about this form
vs. what is in the draft?
Note that the priority MUST not be user-supplied. It should be derived from
the credentials. Letting the user set the priority may be inappropriate
security.
then,if the session wants to change its priority while RPC operation,as
follows
<foo xmlns:i2rs="https://ietf.example.com/i2rs";
i2rs:i2rs-priority="47">
...
</foo>
It means now in this session, the secondary-identity is named "user1", the
priority is 47
furthermore, we can define <set-i2rs-priority> to change current session's
priority,such as
<set-i2rs-priority
xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0">
<priority>20</priority>
</set-i2rs-priority>
I believe having the priority set per-session likely matches our use case.
In the event a different priority is expected, the user would use a
different session with different credentials.
2.In this draft, Priority is defined as a numeric value,how about its
range statements? Is "i2rs-priority = 255" is the highest?
At the moment, I think we're a bit early on this specific detail. Once we
have further clarification from the netconf working group, we can clarify
this point.
3.config ephemeral
In this draft,The YANG "config" keyword is extended,like "config
true/false/ephemeral" ,and the basic netconf operation should be extended,
like "get-config" "edit-config" and so on.
why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"?
There has been some level of feedback from the netmod/netconf Working Group
participants that this might be the way to go. Consider the prior
proposal draft-bjorklund-netmod-operational.
The specific details of this will resolve once the underlying concepts of
how we'll represent the ephemeral configuration state have been better
defined. The proposals in the current draft are merely discussion points to
try to start a conversation as to what the mechanism could look like.
We're looking forward to that discussion within netconf.
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
