[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to do away with netconf attributes in data model payloads
At 02:43 PM 3/31/2004, Randy Presuhn wrote:
>Hi -
>
>> From: "Gilbert Gagnon" <gagnong@nortelnetworks.com>
>> To: "'Andy Bierman'" <abierman@cisco.com>; "Randy Presuhn" <randy_presuhn@mindspring.com>
>> Cc: <netconf@ops.ietf.org>
>> Sent: Wednesday, March 31, 2004 1:17 PM
>> Subject: RE: Proposal to do away with netconf attributes in data model payloads
>>
>
>> Hello,
>>
>> Seems to me that XPath is just another way of specifying a component name
>> (edit-path)
>> [and a not so simple one at that].
>...
>
>I think a distinction from an ancient management protocol is worth keeping
>in mind:
> - how one specifies the starting point (name) of a tree to be operated on
> XPATH is total overkill for this
> - how one (optionally) further qualifies the set of instances of interest
> within that that tree. XPATH fits this nicely.
I agree. Thanks for stating it so well.
Here's an example <config> payload, shown with attributes
and then with the verbs as containers, with Xpath expressions.
I assuming attribute-based naming so the Xpath is simpler
('cause that's all I know ;-)
The containment tree is:
- chassis
- slots
- slot N
- ports
- port M
- duplex mode
- filters
- ip-filters
- ip-filter X
Protocol operations:
- modify the duplex mode on slot 3, port 7
- create ip-filter 1 on slot 3, port 7
1) <config> payload with attribute approach
<config>
<chassis>
<slots>
<slot instance-id="3">
<ports>
<port instance-id="7">
<duplex-mode operation="modify">auto</duplex-mode>
<filters>
<ip-filters>
<ip-filter instance-id="1" operation="create">
<action>permit</action>
<direction>both</direction>
<address>
<addr-type>ipv4</addr-type>
<addr>192.168.1.1</addr>
</address>
</ip-filter>
</ip-filters>
<filters>
</port>
</ports>
<slot>
<slots>
</chassis>
</config>
2) <config> payload with element container approach, using
Juergen's optimization of removing the (redundant) <config> layer
<modify
start-path="//chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/duplex-mode">
<chassis>
<slots>
<slot instance-id="3">
<ports>
<port instance-id="7">
<duplex-mode>auto</duplex-mode>
</port>
</ports>
<slot>
<slots>
</chassis>
</modify>
<create
start-path="//chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/filters/ip-filters/ip-filter[@instance-id='1']">
<chassis>
<slots>
<slot instance-id="3">
<ports>
<port instance-id="7">
<filters>
<ip-filters>
<ip-filter instance-id="1">
<action>permit</action>
<direction>both</direction>
<address>
<addr-type>ipv4</addr-type>
<addr>192.168.1.1</addr>
</address>
</ip-filter>
</ip-filters>
<filters>
</port>
</ports>
<slot>
<slots>
</chassis>
</create>
---------------------------------------------------------
Method 2 looks like a lot more work for both the agent
and the application -- and its almost twice as verbose.
Look at this encoding:
<modify>
<target xmlns="http://example.com/xsd/foo.1";>
/chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/duplex-mode
</target>
<value>auto</value>
</modify>
<create>
<target xmlns="http://example.com/xsd/foo.1";>
/chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/filters/ip-filters/ip-filter[@instance-id='1']
</target>
<value>
<action>permit</action>
<direction>both</direction>
<address>
<addr-type>ipv4</addr-type>
<addr>192.168.1.1</addr>
</address>
</value>
</create>
I think this was suggested already on the mailing list.
IMO, if Xpath is supported, it's a much more efficient encoding
than what we have now. But I don't want to make Xpath mandatory.
Andy
>The first is the question of having a "canonical" name for an instance;
>the latter is the question of scoping / filtering.
>
>> If the data model of the payload is to be deferred to the implementation,
>> wouldn't
>> it be logical to do the same for the edit-path specification, for example;
>
>Perhaps, as long as the normalization issue is resolved, since that is a question
>of how the protocol encodes things, rather that one of what the data model
>represents.
>
>...
>> This way, one could use an XPath expression, a component name, whatever...
>> Maybe we need to define a type element or attribute to make that clear;
>
>Agreed.
>
>...
>> Conceptually, the "where" above does not identify an "element" within the
>> payload but the element in the target object model where the operation is to
>> occur.
>...
>
>Yup.
>
>Randy
>
>
>
>--
>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/>
--
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/>