[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: netconf WG charter proposal
Hi -
> 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 suggesting
using 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 data
model, and when the information source
matters, as in this
case, 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 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?
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.
Randy