RE: netconf WG charter proposal

[Andy Bierman <abierman@cisco.com>]

At 04:56 PM 4/5/2003 -0700, John Strassner wrote:

>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.

We will identify data model requirements that affect the protocol
in the netconf WG.  We will not be ignoring the data model.  (BTW,
I don't want to rathole on the info model vs. data model debate
in the netconf WG ;-)


>regards, 
>John 
>  

Andy


>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>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/>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/>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/>