Subject: RE: Questions on the Events draft ?

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Tue, 13 Dec 2005 10:23:42 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
> Sent: Monday, December 12, 2005 9:39 AM
> To: [email-masked]
> Subject: Questions on the Events draft ?
> 
> - Will it be allowed to transfer multiple events in one 
> message ? What is the reasoning pro and contra ?

HT: Right now the doc doesn't state whether or not this is allowed.
However, the assumption has been
one event/message. With that said, I've gotten requests from people at
Cisco to allow multiple events/msg
so this needs to be discussed further.

The primary reason for doing this is efficiency. 

> - The sequence number belongs to the event or the event 
> message ? What happens with it during node restart ?

HT: The sequenceNumber is in the header. So, it is per msg. 

The what happens part is being put back (it got lost in the edits)
The value of sequence number may be reset (i.e. value is not preserved
across reboots) following a device reload/reboot. 

> - Do we want anything like the active alarm list in RFC3877 ?

HT: Eventually yes. But this would fall under the "modeling" work rather
than extensions to support events.

> - Can an event be resent by the node with changed content 
> e.g. a stronger severity critical instead of major ?

HT: This is outside the scope of the document. Your implementation could
do this. 

> - Chapter 3.5 Event classes: I would like to see how I can 
> transfer the ITU X.733/736 event/alarm classes 
> (processingErrorAlarm, QualityofServiceAlarm, 
> CommunicationsAlarm, EnviromentalAlarm, etc.) in the netconf event

HT: Right now there is no discussion on message encapsulation/transport
other than syslog which is discussed in one of the
appendices. Do you have a need/use for this (i.e. would u use it)?  
> 
> regards Balazs
> 
> --
> 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/>
> 

--
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: Andy Bierman <[email-masked]>
Date: Tue, 13 Dec 2005 11:04:28 -0800

>The primary reason for doing this is efficiency. 

Seems reasonable -- IMO this is way different than multiple RPC requests 
per msg,
which keeps coming up for some reason.   The entire notification PDU should
be <= the max-message-size of the receiver BTW.

>than extensions to support events.

Thank you Hector for this answer!
We need to separate the content layer from the rest of the PDU,
just like every other NETCONF operation. 

I have a feeling there will not be agreement on a one-and-only content model
for notifications.  By NETCONF design, this is not a critical problem, 
but from
an operational POV, the less variants the better.  

>appendices. Do you have a need/use for this (i.e. would u use it)?  

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 16 Dec 2005 12:08:39 +0100

In the long run Ericsson might want to send all alarms via Netconf.
When we do that we will definitely need the alarm class information. Also as
Percieved Severity and Probable cause are already included in the Annex A this is the last 
bit of ITU alarm information that is missing.
Balazs

Hector Trevino (htrevino) wrote:

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager & AXD Operational Suite (AOS) OPM
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]