With all due respect, you are mixing implementation with specification (of the protocol and of the data model). While your MIB example may be correct, it is also undoubtedly an artifact of the SMI. This is why I worry that marching ahead and building Yet Another Protocol (great acronym, by the way ;-) without first addressing some of the underlying information management issues is probably NOT the best way to proceed.
regards,
John
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
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Friday, April 04, 2003 12:55 AM
To: Randy Presuhn
Cc: xmlconf@ops.ietf.org
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. And what about objects that are used for both (e.g. the ipRoutingTable uses the same objects for static and learned routes)? It's better to tag the data with meta-attributes, and have the device return config or state data, depending on the protocol operation.
>Randy (the other one)
Andy
>--
>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/>
--
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/>