RE: netconf WG charter proposal - data model or not?

["Faye Ly" <faye@pedestalnetworks.com>]

Andy,

It is a bit hard to define what is 'lightweight operation'?  Is this
simply status of the if interface or counters?  Or audit trail?  (Has
anybody thought of this?)  If the current script used by the operator
requires status retrieval embedded inside of a transaction, this ought
to be built into the protocol and not having a loosely defined
monitoring BEEP channel for it.

Unless you are thinking about using this channel for other purpose as
well and not just for status retrieval?

-faye

-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com] 
Sent: Sunday, April 06, 2003 3:47 PM
To: Faye Ly
Cc: Randy Bush; Romascanu, Dan (Dan); xmlconf@ops.ietf.org
Subject: RE: netconf WG charter proposal - data model or not?

At 12:31 PM 4/6/2003 -0700, Faye Ly wrote:
>Randy,
>
>I really don't think setting and retrieving of the state data is a big
>hole that is not being addressed by both network device and NMS.  SNMP
>serves the purpose quite nicely with the exception for 'accounting'
type
>of data.  But I don't see a lot of screaming and yelling for this type
>of support anyway.

I think it is useful to be able to retrieve state data with 
the same protocol that is used to edit configuration. Several
people at the BOF said the same thing. I think the data retrieval 
will be used for lightweight operations, like checking interface status.
I don't think SNMP developers that have already written comprehensive 
monitoring applications will rewrtie their code to use netconf instead.
Router vendors are not going to pull out SNMP monitoring support because
of netconf.

>(Do you?)
>
>Your statement 'overly describing something we don't do' is a very
sharp
>observation!  We are suffering from lacking a very clear vision on how
>this configuration protocol is going to turn out without using any data
>model.  I think of the data model as the use case that needs to be feed
>into the design as the requirement. 

I disagree that we don't know what an XML data model might
look like.  Look at the XMLCONF examples. Look at the Junoscript
draft.  Several vendors are already creating XML data models
on their own.

> But I am also seeing quite a few NM
>veterans willing to put in their time to get the working group and
>protocol going.  Note that each brings with him/her experience that
will
>help sanity check the protocol once we get it going.  As I said before,
>we all bring certain data model in our minds to examine how the
protocol
>fit anyway.  I actually don't see it as a big issue anymore.  But
please
>correct me if I have interpreted your comment wrong.  
>
>Best,
>
>-faye

Andy






>-----Original Message-----
>From: Randy Bush [mailto:randy@psg.com] 
>Sent: Sunday, April 06, 2003 6:55 AM
>To: Romascanu, Dan (Dan)
>Cc: xmlconf@ops.ietf.org
>Subject: RE: netconf WG charter proposal
>
></ad-hat>
>
>> If I understand well what you are saying, separation between the
>> configuration and non-configuration data is something that needs
>> to be realized both at the level of the retrieval mechanisms in
>> the protocol, as well as in the data model. I suggest that the
>> later be specifically added to the 'requirements for standard
>> data models in order to fully support the Netconf protocol' in
>> the netconf charter proposal.
>
>something keeps bothering me here.  i am not sure i can fully put
>my finger on it.  but it's something like worrying that we are
>trying to overly describe what we *don't* do.  can we just talk
>about configuration, and not get into characterizing what other
>types of data there might be?
>
>or are we seriously considering that the wg should also cover
>setting and retrieval of other data, e.g., state data such as
>interface counters etc.?
>
>or maybe my discomfort is due to lack of clue.
>
>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/>
>
>--
>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/>