Re: Proposal to do away with netconf attributes in data model payloads

[Andy Bierman <abierman@cisco.com>]

At 11:08 AM 3/31/2004, Randy Presuhn wrote:
>Hi -
>
>> From: "Glenn Waters" <gww@nortelnetworks.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>; <netconf@ops.ietf.org>
>> Sent: Wednesday, March 31, 2004 10:46 AM
>> Subject: RE: Proposal to do away with netconf attributes in data model payloads
>...
>> > We need to be *very* careful here.  If it is possible to construct
>> > multiple
>> > names for a single object instance, the handling of relationships (and
>> > comparing
>> > configurations to determine whether they are equivalent) gets ugly fast.
>>
>> I agree. XML Schema does not have the concept of unique key or such. As part
>> of the data modeling discussion we need to discuss how or if we mark
>> attributes as keys (and they must be retrievable, unlike SNMP!)
>>
>> The way XPath is defined there is no requirement to have unique keys. You
>> specify one or more attributes to search on and you get back the set of
>> matching objects (it's actually a bit more complex than what I just
>> described but conceptually what I described is somewhat accurate).
>>
>> So if we choose XPath then we may have to subset the features we support to
>> fit the network management requirements that we have.
>
>I don't think subsetting XPath would be necessary.  We just need to be
>sure that there is a way to determine a "canonical" name of an object instance.
>There will be a multitude of XPATH expressions that might find that
>object instance (perhaps even independent of its name), but, regardless of
>how we've found it, we need to be able to determine what its name is.

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

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.)

Andy



>...
>> > and still begs the question about which normalization form is in use.  I
>> > think
>> > this has to be nailed down at the protocol level.
>>
>> I don't know what normalization form means in the context of this work. Can
>> you explain.
>...
>
>See the big NOTE in the XPATH specification section 3.6.
>(http://www.w3.org/TR/xpath#strings) for a good explanation.
>
>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/>