Subject: event classes (sec. 3.5)

From: Andy Bierman <[email-masked]>
Date: Fri, 05 May 2006 09:15:24 -0700

Hi,

This section is very under-specified.

IMO, it is impossible for independent developers
to select classifications in an interoperable manner.

It is really not at all clear why we need audit, data,
maintenance, metrics, information, and syslog classes at all.

Most of these are totally redundant.

Metrics is out of scope.

Syslog is not a proper member of this classification set.
In XML, we use namespaces to identify content format,
such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
The notification <data> section will be just like
the <config> or <data> elements already defined in
the protocol.

Andy

--
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: Balazs Lengyel <[email-masked]>
Date: Tue, 16 May 2006 16:22:18 +0200

Hello
- FAULT event - OK, but could specify the details somewhat even if they are optional e.g. 
eventsource, probable cause,  severity, specific problem
- CONFIGURATION - OK
- STATE - OK
- AUDIT event seems a bit overkill. I think event classes should mainly speak about
	why/on what occasion do  we send that specific event class
	what information does an event class carry
	what handling is expected of the specific event class
Here we only have part of the third point. You could have an audit trail of state changes 
or a trail of configuration changes etc. I don't see this as a separate event class. It 
should be merged with something or removed.
- DATA DUMP event should me merged with configuration event. The main difference is that 
it can also carry state information. But thats already included in State event, so kill 
data dump.
- Ericsson needs MAINTENANCE events. See Jurgens requirement page: "notify about delayed 
results of long running RPCs [BL]". I am not totally happy with the name of the event 
class, but I like the idea behind it. If the draft misses this Ericsson will have to do 
some dirty workaround.
- METRICS is certainly out of scope although I don't see any real problem with it. We must 
note however that Netconf events are probably unsuitable for HIGH volume performance data 
transfer.
- HEART BEAT - OK
- INFORMATION event is really an extension mechanism. OK.
- SYSLOG: We spoke a lot about transferring syslog via events, but please could someone 
say who really has a requirement to do this! If we really have the requirement Jurgen 
please add it to your page!
- SECURITY - mentioned in the initial list, but not described later. As I see it security 
related notifications can be carried as fault or state events, so I don't see a need for 
this event class.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 May 2006 08:07:43 -0700

Balazs Lengyel wrote:

IMO, the only thing that matters here is that the
classifications are clearly defined so that any
2 independent implementors will pick the same
classification for the same new notification message.

There is no way that can happen given the current text.
The descriptions of some of them are too vague, and there
is too much overlap.

Andy

> Hello
> - FAULT event - OK, but could specify the details somewhat even if they 
> are optional e.g. eventsource, probable cause,  severity, specific problem
> - CONFIGURATION - OK
> - STATE - OK
> Here we only have part of the third point. You could have an audit trail 
> of state changes or a trail of configuration changes etc. I don't see 
> this as a separate event class. It should be merged with something or 
> removed.
> - DATA DUMP event should me merged with configuration event. The main 
> difference is that it can also carry state information. But thats 
> already included in State event, so kill data dump.
> - Ericsson needs MAINTENANCE events. See Jurgens requirement page: 
> "notify about delayed results of long running RPCs [BL]". I am not 
> totally happy with the name of the event class, but I like the idea 
> behind it. If the draft misses this Ericsson will have to do some dirty 
> workaround.
> - METRICS is certainly out of scope although I don't see any real 
> problem with it. We must note however that Netconf events are probably 
> unsuitable for HIGH volume performance data transfer.
> - HEART BEAT - OK
> - SYSLOG: We spoke a lot about transferring syslog via events, but 
> please could someone say who really has a requirement to do this! If we 
> really have the requirement Jurgen please add it to your page!
> - SECURITY - mentioned in the initial list, but not described later. As 
> I see it security related notifications can be carried as fault or state 
> events, so I don't see a need for this event class.
> 
> Balazs
> 
> Andy Bierman wrote:
>> Hi,
>>

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 16 May 2006 17:18:29 +0200

Hello,
If we provided the following set of data for each notification(why event?) class would 
that be enough ?
- Definition
- Events that trigger the notification
- Expected data, might contain optional parts
- expected handling/usage

Or do we need more ? What ?

Balazs

Andy Bierman wrote:
>> - FAULT event - OK, but could specify the details somewhat even if 
>> they are optional e.g. eventsource, probable cause,  severity, 
>> specific problem
>> - CONFIGURATION - OK
>> - STATE - OK
>> Here we only have part of the third point. You could have an audit 
>> trail of state changes or a trail of configuration changes etc. I 
>> don't see this as a separate event class. It should be merged with 
>> something or removed.
>> behind it. If the draft misses this Ericsson will have to do some 
>> dirty workaround.
>> please could someone say who really has a requirement to do this! If 
>> we really have the requirement Jurgen please add it to your page!
>> - SECURITY - mentioned in the initial list, but not described later. 
>> As I see it security related notifications can be carried as fault or 
>> state events, so I don't see a need for this event class.
>>
>> Balazs
>>
>> Andy Bierman wrote:
>>> Hi,
>>>

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 May 2006 08:42:36 -0700

Balazs Lengyel wrote:
> Hello,
> If we provided the following set of data for each notification(why 
> event?) class would that be enough ?

I like the term notification classification better.

> Or do we need more ? What ?

We don't have any notification definition template for
XSD, RelaxNG or whatever.  If one were to define such
a template, there would be a field for the event-class.

We need a classification set that is complete and
also easy to decide which classification to choose.
Otherwise, standard filters based on event-type will be mostly worthless
because no 2 agents classify notifications the same way.

Since this entire solution scales so poorly, without useful
filtering for session-based manager ease-of-use, it is
totally pointless.

Andy

>>> problem with it. We must note however that Netconf events are 
>>> probably unsuitable for HIGH volume performance data transfer.
>>> - HEART BEAT - OK

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 16 May 2006 17:59:45 +0200

I don't see the connection between scaling and notification classes. Also if we manage to 
filter notifications that just improves scalability.

We need a notification template I agree but even if we just say
- we have event class filters
- xpath or subtree filters are applied to the data in the notification starting from a 
standard base point e.g. <data>

and leave the data model below this base point up to each implementation we still have 
produced something useful. Based on this you could build a model agnostic tool where 
filters can be configured on a GUI.

Still I feel the notification content should be defined in more detail. The notification 
draft does contain a very basic XSD for notifications (mainly page 23). Would you like a 
more detailed more specific XSD separately for each notification class or how would you 
start defining the event classes. I am willing to put in some work on this, but after 
understanding that you feel that the current version is insufficient I would like to 
understand what you would like to see in the draft.

regards Balazs

Andy Bierman wrote:
>>>> - DATA DUMP event should me merged with configuration event. The 
>>>> main difference is that it can also carry state information. But 
>>>> thats already included in State event, so kill data dump.
>>>> As I see it security related notifications can be carried as fault 
>>>> or state events, so I don't see a need for this event class.
>>>>
>>>> Balazs
>>>>
>>>> Andy Bierman wrote:
>>>>> Hi,
>>>>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 May 2006 09:21:36 -0700

Balazs Lengyel wrote:
> I don't see the connection between scaling and notification classes. 
> Also if we manage to filter notifications that just improves scalability.

They are not.
I don't think this solution is suitable for replacing
any existing non-session based notification system.
Therefore (IMO) the only use it has is to copy and deliver netconf
specific notifications (over a session) while a manager is connected
for operations.

Even if one really wanted notifications over sessions, why not just
run syslog over ssh somehow?  It is not at all clear to me
why reinvented-syslog over netconf over ssh is important.

> - xpath or subtree filters are applied to the data in the notification 
> starting from a standard base point e.g. <data>
> 
> and leave the data model below this base point up to each implementation 
> we still have produced something useful. Based on this you could build a 
> model agnostic tool where filters can be configured on a GUI.
> 
> Still I feel the notification content should be defined in more detail. 
> The notification draft does contain a very basic XSD for notifications 
> (mainly page 23). Would you like a more detailed more specific XSD 
> separately for each notification class or how would you start defining 
> the event classes. I am willing to put in some work on this, but after 
> understanding that you feel that the current version is insufficient I 
> would like to understand what you would like to see in the draft.

Look at an IANA classification system like interface type (ifType).
Without specific documentation to determine which classification
to choose, there is no point to standardizing the classification
system.

I already pointed out that this document does not actually need
to define the classification system.  At the protocol level,
the <event-class> could be a Name string.  But if it does
include a classification system, it must be complete, meet
IETF documentation standards, and show WG consensus for each
enumerated choice.

Andy

>>>>> please could someone say who really has a requirement to do this! 
>>>>> If we really have the requirement Jurgen please add it to your page!
>>>>> - SECURITY - mentioned in the initial list, but not described 
>>>>> later. As I see it security related notifications can be carried as 
>>>>> fault or state events, so I don't see a need for this event class.
>>>>>
>>>>> Balazs
>>>>>
>>>>> Andy Bierman wrote:
>>>>>> Hi,
>>>>>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 May 2006 15:11:55 -0700

Balazs Lengyel wrote:
>....

I think this delayed <rpc-reply> should have its own event class
and fully defined syntax (because it's already done in the prot-spec).

This could turn out to be an important feature.
IMO, a specialized RPC to provide 'ping' type of exec
features is a good use of session-specific config.
and netconf-specific session-based notifications.

E.g.:

  <rpc message-id="101">
    <ping>
      <source>
      <target>
      <frequency>60</frequency>
      <rest-of-ping-params ...>
    </ping>
   </rpc>

   <rpc-reply  message-id="101">
     <ok/>
   </rpc-reply>

   ... 60 seconds later

   <notification>
     <event-class>rpc-reply</event-class>
     <sequence-id>42</sequence-id>
     <data>
       <rpc-reply message-id="101">
         ...  ping result # 1
       </rpc-reply>
     </data>
   </notification>

  ... 60 seconds later

   <notification>
     <event-class>rpc-reply</event-class>
     <sequence-id>43</sequence-id>
     <data>
       <rpc-reply message-id="101">
         ...  ping result # 2
       </rpc-reply>
     </data>
   </notification>

> unsuitable for HIGH volume performance data transfer.

The problem with it is that netconf is chartered
for a completely different purpose.  The ipfix protocol
is designed much more appropriately for streaming metrics
data from source to sink.  They made very different design
choices than netconf because they are solving a different
problem.  Streaming metrics data encoded in XML over a session
over TCP seems rather inefficient to me.

> - INFORMATION event is really an extension mechanism. OK.

why not call it 'other' then?

> really have the requirement Jurgen please add it to your page!

IMO syslog is not an event classification at all
and does not belong in the set, unless it indicates
the exact content of the payload (like my rpc-reply event class.)
Is is syslog/RAW or syslog/COOKED or something else?
If I need to depend on the namespace URIs in the data anyway,
then what value is this classification?

I agree with you that it doesn't make a lot of sense
to tunnel syslog over netconf, but from a dev-cost POV,
it would be easy to implement syslog/RAW over netconf.
It would provide no additional value whatsoever from a modeling
perspective, but maybe it does from a transport and
security perspective.

> events, so I don't see a need for this event class.

agreed

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 18 May 2006 14:19:21 +0200

Hello,
In Ericsson every managed object (conceptually similar to an XML element) can have both 
data (children) and associated actions. These are commands whose primary aim is NOT to set 
data but to do something like your ping. The possible actions are part of the data model 
so we only need one extra operation like <execute-action with parameters>.

As netconf is missing this feature we intended to do a workaround but I would be much more 
happy to see this in netconf itself. I just didn't bring it up as yet as there were so 
many other topics to discuss.

I wonder how Juniper solved this? They had Junos-script and operational mode commands like 
ping for a long time.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 May 2006 05:50:24 -0700

Balazs Lengyel wrote:
> I was extremely glad to read you mail !!!!
> - By the way we have a similar multiple reply feature called 
> "one-to-many exchange" in BEEP as well so the concept is not new.
> - On the other hand Sharon's definition includes automatic maintenance 
> action. Let's say we have a daily automatic backup and I want a 
> notification that it succeeded. Which event class would you choose for 
> this ?

MAINTENANCE

(I never said take this classification away.)

I think delayed rpc-reply messages are a more valid
reason for supporting mixed-mode (operations and notifications)
than saving 1 session overhead worth of memory in the NMS.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 May 2006 05:57:41 -0700

Balazs Lengyel wrote:
> Hello,
> In Ericsson every managed object (conceptually similar to an XML 
> element) can have both data (children) and associated actions. These are 
> commands whose primary aim is NOT to set data but to do something like 
> your ping. The possible actions are part of the data model so we only 
> need one extra operation like <execute-action with parameters>.
> 
> As netconf is missing this feature we intended to do a workaround but I 
> would be much more happy to see this in netconf itself. I just didn't 
> bring it up as yet as there were so many other topics to discuss.

Actually netconf already has this feature.
You can define your own <rpc> requests in your own namespace.
The WG debated whether or not to have an explicit <exec>
operation, but decided it was redundant.

This is also an area where snmp/cli/netconf unification
comes into play (in my research anyway) -- i.e., a netconf API
to the REMOPS-MIB in this case.

> 
> I wonder how Juniper solved this? They had Junos-script and operational 
> mode commands like ping for a long time.
> 
> Balazs

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 18 May 2006 14:07:10 +0200

I was extremely glad to read you mail !!!!
- By the way we have a similar multiple reply feature called "one-to-many exchange" in 
BEEP as well so the concept is not new.
- On the other hand Sharon's definition includes automatic maintenance action. Let's say 
we have a daily automatic backup and I want a notification that it succeeded. Which event 
class would you choose for this ?

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Mon, 22 May 2006 15:40:20 -0400

>I wonder how Juniper solved this? They had Junos-script and operational mode commands like 

We do operational commands as simple RPCs, like:

  <ping>
    <host>10.1.2.3</host>
    <count>5</count>
    <no-resolve/>
    <interval>4</interval>
    <wait>10</wait>
  </ping>

We avoid putting actions as attributes of data.  This was done
primarily as the Junoscript API (and our netconf implementation)
leverages the existing plumbing of the UI.  The above RPC is
the equivalent of the CLI command:

    ping 10.1.2.3 count 5 no-resolve interval 4 wait 10

I continue to believe that netconf will fail if it becomes the
"third way" (where first=cli and second=snmp).  This was discussed
at length in the prelude to netconf's creation.  One of our goals
was allowing the vendor to reuse their cli implementation to the
greatest extent possible.

Given the overwhelming use of syslog and snmp to handle notifications
in the current service provider world, the idea of netconf rolling
its own notification mechanism seems to swim against this logic.

We started this notification discussion with the idea of just
carrying syslog messages over a beep channel using an existing
standard.  Have we wandered to far from this idea of reusing something
that's already there?  Will folks really revisit their entire source
code tree and code every syslog call or snmp trap creation to
generate netconf events?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 22 May 2006 17:41:44 -0400

Andy Bierman writes:
>How do you distinguish delayed responses for this ping
>vs. other delayed responses. vs other RPCs?

It's a long-lived RPC.  The rpc-reply contains the entire results.

>If not that, then how do you distinguish multiple responses to
>1 request?

We don't have 'em.  It's a one-to-one mapping.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 May 2006 14:19:54 -0700

How do you distinguish delayed responses for this ping
vs. other delayed responses. vs other RPCs?
Just keep sending more <rpc-reply> messages for
the same message-id?  If so, the standard doesn't
seem to support that.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 23 May 2006 12:09:06 +0200

Does this mean that for each operational command you have a separate RPC/operation ? How 
will you translate that to netconf ? Is the below example the complete XML doc or is there 
still some RPC wrapper around it ? Could you please send the complete XML as well.
Thanks Balazs

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 May 2006 09:08:28 -0400

Balazs Lengyel writes:
>Does this mean that for each operational command you have a separate RPC/operation ?

Yup, under junoscript and netconf, each junos command is available
as a distinct RPC.

>Is the below example the complete XML doc or is there 
>still some RPC wrapper around it ?

What I sent was the complete RPC, as it would appear inside the
netconf <rpc> element.  Here's another example:

        <get-interface-information>
          <terse/>
          <interface-name>ge-0/1/2</interface-name>
        </get-interface-information>

All our RPCs are documented under www.juniper.net/support/junoscript/.
All these RPCs are available under netconf as well, since we drive
the command, file, patch, xml, junoscript, and netconf parsing off
the same meta-data.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 May 2006 08:15:23 -0700

>         </get-interface-information>

I like special RPCs for this kind of thing.
IMO this is a different sort of RPC than the type in the
Notifications draft.   My biggest concern is not a 1000
little APIs to deal with, but rather multiple APIs that
deal with the "netconf write model" or data models
in inconsistent ways.

We have a "write model" based on 3 standard conceptual data-stores
(i.e., <candidate>, <running>, <startup>) and a set of operations
to deal with various complexities with the native devices.
IMO, defining new RPCs which modify NV-saved config data is wrong,
if they ignore or contradict this model.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 May 2006 12:07:59 -0400

>if they ignore or contradict this model.

Yup.  The win of netconf is having a common mechanism
for dealing with configuration data.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 May 2006 09:12:17 -0700

> It's a long-lived RPC.  The rpc-reply contains the entire results.

Are you willing to help write an Informational RFC so those who
like it can all do long-lived RPC in the same way?

It seems to me this can make the parsing easier on the NMS, not harder.
Consider an iterator operation that get-nexts its way through really
big tables.  This is not an endless RPC, just a really long RPC
where perhaps an <ok> (to ACK the initial request) is followed by N <data>
nodes.   If the RPC is intended to end (or <abort/> is received),
the </rpc-reply> element will be sent and the PDU ended.

The difference is that instead of a really big XML tree, the NMS
can consume multiple "rows" in sequence, where each <data>
element is well-formed XML and represents a conceptually
coherent container of data. (or like, notification data even ;-)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 23 May 2006 18:33:07 -0400

>like it can all do long-lived RPC in the same way?

I've started it, but am fighting to find time to finish it.

>It seems to me this can make the parsing easier on the NMS, not harder.

Amen.  It's a simpler mechanism and reuses the existing RPC
construct.

Thanks,
 Phil