[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposal to do away with netconf attributes in data model pay loads



> >Hmmm. I can barely figure out which one to pick and I have 
> been very actively following this list. I think I pick (a) 
> but that is only because I know I don't want (c) and option 
> (b) I don't fully understand the implementation ramifications 
> (and besides you already state a problem with it and I'll go 
> with that for lack of a better reason :)
> 
> Do you any technical reasons why (a) is bettern than
> the current solution (c) for vendors and operators?
> Juergen wants us to use Xpath to key off of a magic 'uri'
> attribute instead of a magic 'operation' attribute.
> 
> Here are the problems with (a):
> 
>   - specifying a NETCONF-only subset of XPath is not an
>     option.  It's all-or-nothing for XML standards like this
>   - image footprint, memory/CPU requirements, coding and
>     testing complexity are all negatively impacted by 
>     the XPath implementation requirement.  The smaller
>     the device, the more this matters
>   - instance naming impacts the complexity and form of the
>     Xpath expressions. What is the canonical representation?
>     These data modeling issues won't be decided until after
>     the protocol is finished. 
>   - The Xpath expressions are not going to be interoperable,
>     since there are no guidelines at all how to use it.
>     Any attempt to impose order will require some netconf-specific
>     elements or attributes be encoded in the data model
>     (like Juergen's 'uri' attribute).  But this is the exact
>     problem the Xpath approach is supposed to solve.
> 
> IMO, option (c) is the easiest to implement (for agent and
> manager), the most readable, and the most interoperable
> choice we have.
> 

I agree.

Branislav
> 
> >> One problem with the approach 'b' above is that it doesn't 
> meet the 
> >> operator requirement that the output from a <get-config> 
> >> operation should be usable as input back into an <edit-config> 
> >> command.  The config representation has to be identical 
> >> for edit and get. 
> >
> >Regards, /gww 
> 
> Andy




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>