Re: netconf WG charter proposal

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> Message-Id: <4.3.2.7.2.20030404103632.023b97b8@fedex.cisco.com>
> Date: Fri, 04 Apr 2003 10:43:22 -0800
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> From: Andy Bierman <abierman@cisco.com>
> Subject: Re: netconf WG charter proposal
> Cc: <xmlconf@ops.ietf.org>
> In-Reply-To: <004801c2fad7$b8de8a60$7f1afea9@oemcomputer>
> References: <4.3.2.7.2.20030403171423.0238a208@fedex.cisco.com>
>  <4.3.2.7.2.20030403225334.06ff4df0@fedex.cisco.com>
>  <4.3.2.7.2.20030403234922.023a6bb0@fedex.cisco.com>
...
> >> >As a property of the protocol per se?  It might be better to consider
> >> >it a property of the information model that should be represented
> >> >in the data model so that configuration management applications
> >> >can focus on the right bits.
> >>
> >> Actually, I think this is cleaner as a protocol feature
> >> than an artifact of the data organization.  We never had
> >> much luck writing MIBs that kept all state info in a separate
> >> sub-tree from config info.
> >...
> >
> >Please don't put words in my mouth.  I'm not suggesting
> >using OID tree structure.  We all know it doesn't work.
> >There's more to data models than sub-tree structures.
>
> I'm not putting words in your mouth.  I was making
> a reference to the NM data structures the IETF has the
> most experience with -- MIBs.  Please be specific -- what
> data structures are you suggesting we use?

Data Models encompass a lot more than mere data structures.
As an example, the distinction between read-write and
read-create, though very important from a model and
implementation perspective, is not reflected in any way
OID tree structures.  It doesn't even really show up in
SNMP protocol.  An application needs to know about the
object definition in order to do the right thing.

...
> >>                                                 It's better
> >> to tag the data with meta-attributes, and have the device
> >> return config or state data, depending on the protocol
> >> operation.
> >...
> >
> >Those "meta-attributes" should be assigned in the data model.
> >If they're not in the data model, either as properties of the object
> >attribute definitions (qualifiers in CIM-speak), or in the form of
> >additional attributes (as in your example) how does a managed
> >element or configuration management system know what bits to use?
>
> I understand these meta-attributes are part of the data model.

Good, we're in violent agreement on this point.  That's why
I'm worried about how this proposed WG is going to accomplish
its goals without addressing how one specifies this in models.

> I am only suggesting that it is a feature (not a bug) in
> the protocol to be able to ask a device "give me this
> blob of configuration data" instead of (the SNMP way)
> the NMS needing to know every attribute of every object,
> down to the instance level, and extract only those data
> elements with multiple (or complex) retrieval operations.

It's reasonable to be able to ask for a named chunk of
configuration data.  However, it's also reasonable to
want to be able to provision systems.  In order to do
so, an application (developer) needs to be able to
figure out what bits to put into the proposed configuration.

> >If the config/state distinction only shows up at the protocol level,
> >then we'll end up with the "device is configuration of record", and
> >provisioning/configuration management applications will be no
> >better off than today.
>
> It shows up in the protocol and the data model.

Good, I think we're in agreement.
However, I think this exchange illustrates the dangers of
trying to build a protocol without looking at what the assumptions
about the data model(s) are.

Randy



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