[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



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

Inline...

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
> Sent: Wednesday, March 31, 2004 13:26
> To: netconf@ops.ietf.org
> Subject: Re: Proposal to do away with netconf attributes in data model
> payloads
>
> Hi -
>
> > From: "Glenn Waters" <gww@nortelnetworks.com>
> > To: <j.schoenwaelder@iu-bremen.de>; "Andy Bierman" <abierman@cisco.com>
> > Cc: "Gilbert Gagnon" <gagnong@nortelnetworks.com>;
> <netconf@ops.ietf.org>
> > Sent: Tuesday, March 30, 2004 2:05 PM
> > Subject: RE: Proposal to do away with netconf attributes in data model
> payloads
> >
>
> > I believe that naming is comprised of two pieces:
> > - the path to the object
> > - one or attributes of the object
> >
> > Also, if I understand correctly and if we decide to follow the xpath
> > specification then the following is also true:
> > - the path is not necessarily part of the data model; that is, the head
> of
> > the path is where the object sits in the hierarchy (not part of the
> model)
> > and the tail of the path can be within the object (part of the model);
> > - the attributes that can be used for naming an object can be any
> attribute
> > of the object
>
> 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.

 
> > So all the above says that naming that we need to make some decisions
> about
> > naming however I think that naming is just part of the model and not
> part of
> > the protocol. Naming must be transported in the protocol.
> >
> > The above all assumes that we are following an xpath model.
> ...
>
> 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.
 
> Randy

Regards, /gww