John Strassner
Chief Strategy Officer
Intelliden
Corporation
90 South Cascade Avenue
Colorado Springs, CO 80903
USA
phone: +1.719.785.0648
FAX: +1.719.785.0644
email:
john.strassner@intelliden.com
Hi -> From: "Andy Bierman" <abierman@cisco.com>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>> Cc: <xmlconf@ops.ietf.org>> Sent: Thursday, April 03, 2003 11:54 PM> Subject: Re: netconf WG charter proposal>> At 11:41 PM 4/3/2003 -0800, Randy Presuhn wrote:
> >Hi -
> >
> >> From: "Andy Bierman" <abierman@cisco.com>
> >> To: "Randy Bush" <randy@psg.com>
> >> Cc: <xmlconf@ops.ietf.org>
> >> Sent: Thursday, April 03, 2003 11:04 PM
> >> Subject: Re: netconf WG charter proposal
> >...
> >> >> The Netconf Working Group is chartered to produce a protocol
> >> >> suitable for network configuration, with the following
> >> >> characteristics:
> >> >>
> >> >> - Provides a clear separation of configuration data
> >> >> from non-configuration data
> >> >
> >> >is this necessary to the task? clearly universally achievable?
> >>
> >> It was listed as an operator requirement at the NM workshop.
> >> It could be easy to achieve. It was never realized with SNMP.
> >...
> >
> >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 suggestingusing OID tree structure. We all know it doesn't work.There's more to data models than sub-tree structures.> And what about objects that
> are used for both (e.g. the ipRoutingTable uses the
> same objects for static and learned routes)?Such things need to be identified as "dual use" in the datamodel, and when the information source matters, as in thiscase, that bit of data also needs to be in the model.> 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 objectattribute definitions (qualifiers in CIM-speak), or in the form ofadditional attributes (as in your example) how does a managedelement or configuration management system know what bits to use?If the config/state distinction only shows up at the protocol level,then we'll end up with the "device is configuration of record", andprovisioning/configuration management applications will be nobetter off than today.Randy