RE: netconf WG charter proposal

[Andy Bierman <abierman@cisco.com>]

At 04:07 PM 4/13/2003 -0700, Faye Ly wrote:
>Andy,
>
>The statistics information is frequently configured to be sent to the
>NMS at intervals from the network device.  

The <get-state> operation is a simple 'pull' command,
like an SNMP 'get' PDU.  Additional features to push 
counter values to the NMS have nothing to do with this
command.  

>Why do you need to
><get-state> on counters to verify configuration, by the way?  

Who said anything about verifying configuration.  You sometimes
need to know the state of a device (status, error counters, etc.)
in order to make provisioning decisions.


>-faye  

Andy



>-----Original Message-----
>From: Andy Bierman [mailto:abierman@cisco.com] 
>Sent: Sunday, April 13, 2003 3:20 PM
>To: Faye Ly
>Cc: Harrington, David; xmlconf@ops.ietf.org
>Subject: RE: netconf WG charter proposal
>
>At 02:49 PM 4/13/2003 -0700, Faye Ly wrote:
>>Andy,
>>
>>Can you please clarify the state information?  Is this the status (such
>>as ifOperStatus) or statistics (such as ifIn unicast packets)?  I think
>>the netconf protocol should cover the former but not the later.  
>
>I think both represent state information.  Both are just more
>XML payload from the protocol POV.  Why do you think we should
>outlaw certain data model payloads in the <get-state> operation?
>Please provide some technical rationale for your opinion.
>
>
>>-faye
>
>Andy
>
>
>
>>-----Original Message-----
>>From: Andy Bierman [mailto:abierman@cisco.com] 
>>Sent: Saturday, April 12, 2003 9:15 AM
>>To: Harrington, David
>>Cc: xmlconf@ops.ietf.org
>>Subject: RE: netconf WG charter proposal
>>
>>At 11:09 AM 4/12/2003 -0400, Harrington, David wrote:
>>>Hi,
>>> 
>>>I suggest that netconf should not address these additional usages, but
>>should consider them in its design so as to not preclude addressing
>them
>>later by reusing the netconf protocol solution.
>>
>>There have been several people (at the BOF and in email)
>>that have stated that it is very important to retrieve
>>some state data with the same protocol as they use send
>>and receive configuration data.  
>>
>>The people against this capability cannot explain (even a little)
>>why retrieving ifOperStatus is somehow different than retrieving
>>ifAdminStatus.  The evidence I have seen so far (i.e., proprietary
>>XML solutions such as JunoScript) suggest that no special mechanisms
>>are needed to retrieve state data vs. retrieve config data. What
>>evidence do you have to suggest otherwise?
>>
>>> 
>>>my $.02
>>>dbh
>>
>>Andy
>>
>>>-----Original Message----- 
>>>From: Randy Bush [mailto:randy@psg.com] 
>>>Sent: Friday, April 11, 2003 3:45 PM 
>>>To: mrm 
>>>Cc: Allen, Keith; xmlconf@ops.ietf.org 
>>>Subject: RE: netconf WG charter proposal
>>>
>>>>> We would prefer to use one protocol for both configuration and
>>monitoring 
>>>>> both to limit the number of interfaces we have to support and to
>>eliminate 
>>>>> the problems that crop up with trying to use multiple protocols to
>>manage 
>>>>> one box. 
>>>> I would suggest debug in addition to config and monitoring 
>>>> be a first class consideration.
>>>
>>>andy, if we are going to cater to such mission creep, it's probably 
>>>appropriate move the millstones one or two years later in the charter.
>
>>>or maybe separate xmlconf and xml-b-arc into two separate efforts?
>>>
>>>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/>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/> 
>
>
>--
>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/>