Subject: RE: Why are we doing netconf?

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 29 Mar 2006 12:17:05 -0500

hi

<Juergen>

On Wed, Mar 29, 2006 at 10:08:33AM -0500, Sharon Chisholm wrote:
> Here are some of the requirements .
> 
> - Netconf content (without mapping )
> - Filtering
> - Subscription
> - Event classification

What are the classes you have in mind? Can you elaborate a bit more?
</Juergen>

This is like the event class concept in the draft. The idea that we
define a set of big buckets that both allow intelligent filtering as
well serve as a predictor of the content of the notification. So,
examples are configuration, audit, security, etc.

<Juergen>
> - Structured content
> - Predictable content

What is predictable content?
</Juergen>

Predictable is that the consumer of the message based only on the
protocol definition and a definition of the data model associated with
the notification (XML Schema, for example) are able to predict what
information will be in the notification and how it will be formatted.

<Juergen>
> - reliable delivery (or ability to detect when things go wrong)
> - event replay

Why is that a requirement? What is this good for in operational
environments?
</Juergen>

I should mention that I consider event replay something we can add
later. We did not include it in the draft. Event replay is a mechanism
that allows you when you first start talking to a device to learn about
interesting events that have happened to it within the immediate past.
Ideally, this information will be in the same format as it would have
been if you had actually been there it hear it.

<Juergen>
> - Ability to support different types of events (alarms, logs, 
> configuration snippets, etc)

Is "configuration snippets" and event type? Is logs == syslog messages?
</Juergen>

A configuration snippet would be part of a configuration either as part
of an audit trial or a configuration mirroring thing. I think
configuration might be the actual event class. Logs could be the same
sort of information that is currently done in syslog, yes. 

<Juergen>
> - XML encoding (not a big driver, but certainly a major industry
> direction)

If XML encoding is a requirement, is then not structured content
superfluous? Since netconf content is XML, is even the XML requirement
superfluous?
</Juergen>

Well, it is a way to do structured data, so perhaps it is a
sub-requirement? I listed them separately as a nod to that fact that
there are other ways to structure data but also to acknowledge the fact
that there are people who very much want XML explicitly.

Sharon

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Mar 2006 00:29:22 +0200

> information will be in the notification and how it will be formatted.

I assume that any reasonable data modeling language should have the
property that notifications defined with the data modeling language
are predictable.

I fail to see a requirement here for the development of a NETCONF
_protocol_ extension. If I am wrong, can you please help me phrase
this as a protocol requirement?

> been if you had actually been there it hear it.

Thanks for the clarification. So then I will not list event "event
replay" as a requirement.
 
> sort of information that is currently done in syslog, yes. 

So what is the distinction between an event class and an event type?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 30 Mar 2006 11:58:57 +0200

For me this also means that the content of the notifications should be defined as well. A 
full definition is not possible but at least a set of basic data (notification type, 
category?, sender, timestamp, human readable info string ?, alarmID etc.) could be defined 
by the protocol. (Like sender, notification type and timestamp is included in SNMP as I 
remember.)

So even if the NMS doesn't know the specific data model he can do some useful things with 
it e.g. present it, search for specific string values etc.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Mar 2006 15:25:26 +0200

On Thu, Mar 30, 2006 at 11:58:57AM +0200, Balazs Lengyel wrote:

> For me this also means that the content of the notifications should
> be defined as well. A full definition is not possible but at least a
> set of basic data (notification type, category?, sender, timestamp,
> human readable info string ?, alarmID etc.) could be defined by the
> protocol. (Like sender, notification type and timestamp is included
> in SNMP as I remember.)

SNMPv1 indeed did this but the idea was weakened with the introduction
of SNMPv2 PDU formats some 12+ years ago since only the notification
name (its OID) and the sysUpTime timestamp is required to be shipped
in the varbind list (and note that sysUpTime is the time since the
network management portion of the system was last re-initialized).
The identification of the sender got reintroduced in SNMPv3 by means
of the (context-engine-id, context-name) pair, in particular to handle
proxy situations (but I hope NETCONF avoids dealing with proxies).
 
> So even if the NMS doesn't know the specific data model he can do
> some useful things with it e.g. present it, search for specific
> string values etc.

You are proposing to hard-wire a portion of a data model into the
protocol. So far, NETCONF tried to avoid this and the question would
be where to stop.

/js

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 30 Mar 2006 09:27:10 -0800 (PST)

HI,

I think you accidentialy used an incorrect characterization
of SNMPv3's the  (context-engine-id, context-name) pair.
It is not the identity of the "sender". It is the
source of the notification. An observer can send
a NOTIFICATION reporting that an event occured on
another system, and when so would use the that
system's identifier as the source.

A proxy also uses the identification of the source
system and not it's identity.

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Mar 2006 19:46:55 +0200

> system and not it's identity.

Correct.

I simply assumed that when Balazs Lengyel wrote "sender" that he
actually meant the source of the notification in the sense of the
(context-engine-id, context-name) pair.

/js