On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas <[email protected]> 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. > > This approach would mean that the I2RS client acting as a broker would need a different session for each secondary client. It seems more useful to allow the client to use 1 session, and just require that each edit be from a specific secondary identity. (e.g., add a secondary-identity parameter to the edit operation). The proposed solution of an XML attribute allows every node in an edit to be from a different secondary identity. > 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. > I thought the client priority is configured in advance by the administrator. It makes no sense to have each client state their own priority. This is useless for resolving conflicts between clients. > > > 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. > IMO, priority 0 is the highest, and can only be used by the system itself. Priority 1 is the next highest. > > > 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 > Andy > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
