[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: netconf WG charter proposal



Andy,

The statistics information is frequently configured to be sent to the
NMS at intervals from the network device.  Why do you need to
<get-state> on counters to verify configuration, by the way?  

-faye  

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