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
