Andy says:
> I guess we're going to be choosing the lesser of two evils.
>
> Now you've slid completely down the slope such that full
> XPath support would be required for every netconf agent
> implementation, and we have to fully specify the naming
> scheme of the TBD data modeling language before we can
> finish the protocol.
I don't think that supporting XPath requires us to specify any of the naming scheme. At least I can't think of a reason why that that would be true. Can you explain why you think the naming is tied to XPath.
> I would rather have option (D) -- leave the operation
> attribute in the spec -- than go this route. From
> an implementation POV, having the operation attribute within
> the element whose callback function needs to know the
> operation is easy to implement on the agent. It may
> be easier on the application than Xpath as well.
I don't understand why XPath is viewed as so difficult to implement. We must specify some path and filtering technology as part of the NetConf protocol. XPath is already defined. Let's just use it (and maybe specify a subset of XPath if some parts of it give us real heartburn).
> For a real world example, it would be nice if someone
> wants to model a simple chassis -- a container with N
> slots. Each slot has a 'ports' container with M physical ports,
> where M can be different for each value of N.
> The homework assignment is to show the assumed data model
> and Xpath _expression_ for selecting the start-point
> of an edit operation. (E.g., set the duplex-mode on
> slot 3, port 7.)
I think that's a great idea. I have been thinking about a simple model we can use as an example. I will try to get something to the list in the next couple of days.
> Andy
Regards, /gww