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

[Andy Bierman <abierman@cisco.com>]

At 06:50 AM 4/2/2004, Glenn Waters wrote:

>Andy says: 
>
>> This requires Xpath in every box, which is going to be 
>> a deal-breaker for some vendors. 
>> 
>> I'd like to hear from operators who are thinking of using 
>
>There are operators on this list?? Seriously, we keep pointing questions to the operators when in reality I think that for the most part they have done their bit -- they gave us the requirements and we need to come back with a solution.
>
>> NETCONF in scripting applications.  Which is easier 
>> for you to implement? 
>>   a - the Xpath expression plus a data model element tree, 
>>   b - the Xpath expression plus just the <value> data to change (like 
>>      the example above) 
>>   c - the operation attribute inside the data model element tree? 
>
>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.


>> 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/>