Subject: RE: notification charter proposal

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 21 Nov 2005 13:58:09 -0500

hi

Introducing the one-way-rpc mechanism is consistent with the Netconf
architecture. It also allows the possibility of someday people adding
other asynchronous operations with different behaviour.

We should absolutely prioritize on what problems we want to solve via
this sort of mechanism, but I don't see the value in precluding what
sorts of information can be set in event messages. The only way we could
really do it would be to explicitly state that people can't use the
protocol to perform these functions or to put restrictions on the
solution that make it unsuitable for use by these.  The former is odd
and the latter is just as likely to cause problems for your 'legitimate'
uses as those you wish to discourage.

Event Message is a much better term in my books. The system generates an
event and an event message gets sent. Notification brings up
connotations of SNMP Traps, which never could have been used to send
security audit logs or to mirror configuration. I'm not adamant that the
term shouldn't be used, but it isn't obviously the right one either.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Monday, November 21, 2005 10:42 AM
To: Tom Petch
Cc: [email-masked]
Subject: Re: notification charter proposal

Tom Petch wrote:

>Andy
>
>Notifications or events, or asynchronous messages?
>
>As Sharon says
>"an asynchronous message, sometimes referred to as a
>   notification or event message"
>
>I get a slight sense of you and Sharon determinedly heading in 
>different directions:-(
>  
>
Notifications.

I want to design features with a specific purpose.
NETCONF is not a transport for arbitrary asynch messages.  We will not
have super-loose definitions of protocol elements, so that (for example)
NETCONF notifications could be used to carry IPFIX reports or SW
downloads or 
whatever.
I think there is something in the draft called a "one-way RPC" that I 
really disagree with.
Once you start down the slippery slope (e.g., declaring a notification 
can be a 4 billion
byte octet stream) then all implementations get more difficult, even 
though hardly anyone
wants this sort of "notification feature".

>Tom Petch

Andy

>----- Original Message -----
>From: "Andy Bierman" <[email-masked]>
>To: <[email-masked]>
>Sent: Thursday, November 17, 2005 3:27 AM
>Subject: notification charter proposal
>
>
>  
>
>>Hi,
>>
>>Please comment on the following charter text before it goes to the ADs

>>for approval.
>>
>>thanks,
>>Andy and Simon
>>
>>============================================================
>>
>>NETCONF WG Charter Clarification proposal:
>>
>>The original NETCONF WG charter contains the following line item, 
>>describing the characteristics that the protocol should have:
>>
>>   - Provides support for asynchronous notifications
>>
>>This support was removed from the protocol for several reasons, 
>>including:
>>
>> - Removal of multiple channels (or connections) per session
>> - Inconsistent notification support capabilities for each application

>>mapping
>> - Lack of a configurable notification type selection (filtering) 
>>mechanism
>> - Lack of consensus on feature importance
>> - Lack of time to reach consensus on all these issues
>>
>>Some time has passed, and there is now WG consensus to finish this 
>>work item, however the single line in the original charter needs to be

>>expanded and this work scoped in much more detail.
>>
>>The NETCONF Notification work shall consist of the following:
>>
>> - Specify the <hello> message (capability exchange) details to
>>    support notifications.
>> - Specify the application mapping details to support notifications.
>> - Specify the protocol syntax and semantics of a notification 
>>message.
>> - Specify a mechanism for controlling the delivery (turn on/off)
>>   of notifications during a session.
>> - Specify a mechanism for selectively receiving a configurable subset
>>of all
>>   possible notification types.
>>
>>An individual submission Internet Draft has been proposed to the WG as

>>the starting point for this work.  Unless there are any strong 
>>objections or alternate proposals, the WG shall adopt the document 
>>identified as 'draft-chisholm-netconf-event-01.txt' as the starting 
>>point for this work.
>>
>>Goals and Milestones
>>
>>  Dec 05   Update charter
>>  Jan 06   Submit first version of NETCONF Notifications document
>>  Sep 06   Begin WGLC of NETCONF Notifications document
>>  Dec 06   Submit final version of NETCONF Notifications document to
>>IESG for
>>           consideration
>>
>>
>>
>>
>>--
>>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/>

--
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: Eliot Lear <[email-masked]>
Date: Mon, 21 Nov 2005 20:20:31 +0100

Sharon,

I tend to agree with you that "event message" is a better term.
However, I also wonder if this is architecturally severable from the
netconf base.  If so, I don't know that you even need one way RPCs.  You
just do your own schema.  I think it's fine to have a netconf capability
to indicate that one end can send such notifications, and provide a
means to map it accordingly with mapping updates.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Nov 2005 12:30:50 -0800

>uses as those you wish to discourage.

I disagree.
I like to clearly define functionality as clearly as possible up front,
so later on in WGLC, nobody can claim this feature is broken
because it can't do some new thing they just thought of.

We don't list all the things the protocol doesn't have.
We specify in detail the things it does have.

>term shouldn't be used, but it isn't obviously the right one either.

I don't confuse SNMP Notification with SNMP Trap, but many people do.
IMO, the term Event Message implies some sort of Event occurred, which
is being reported.  This of course implies an Event Model, and perhaps more.
The term Notification simply means one peer is notifying the other peer
of something. 

I don't want to reinvent the concept of an SNMP Notification.
Why is a NETCONF notification so different?  I don't mean
silly details like snmpContextEngineID, but the purpose of a notification.

I don't care if you want to include a REALLY BIG varbind list, but at
some point, we have to face reality and at least advertise a max-msg-size.
Right now we have the lame discover-by-error max-msg-size.
That's what it comes down to really.  If you advertise a max-msg-size
of 4 billion, then go ahead and receive your giant notifications and 
have fun.
But don't expect everyone to set max-msg-size that high.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Nov 2005 09:21:32 +0100

> term shouldn't be used, but it isn't obviously the right one either.

I prefer the term "notification" over other terms such as "event
message" or "event report" which have been used in other places.

I recall that we had a short discussion about this terminology with
Dave Sidor (ITU) at the NMRG meeting in Austin since ITU/ISO folks
have some slightly different terminology but we finally agreed that
the IETF terminology is actually not a bad one. Some of you might
remember that discussion (which by the way led to the information
model vs. data model RFC - perhaps we should have also produced a
document defining terms such events, notifications, alarms, etc).

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Nov 2005 09:46:40 +0100

> other asynchronous operations with different behaviour.

I think the question to asked is whether a notification message needs
an application layer acknowledgement and if so what the semantics are
or whether we can get away without such an application layer
acknowledgement. Some options are:

a) The notification sender sends a notification and hopes that it
   will be understood by the receiver.

b) The notification sender sends a notification and gets a confirmation
   that the notification was understood to the extend that it could be
   handed over to an entity dealing with notifications. (This is what
   SNMP notifications actually do.)

c) The notification sender sends a notification and gets a confirmation
   that an entity dealing with notifications actually understood the
   semantics associated with the notification.

Once we understand and agree on the semantics we want to have (at the
moment a) seems to be on the table), we know whether we need a
response or if we can get away with a one-way message (in which case I
agree that the so called RPC layer should be extended to support
this).

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 22 Nov 2005 10:42:17 -0500

>   semantics associated with the notification.

Dumb question:  what does one do with a system that supports you
option (c)?  If I sent a notification, the receiver tells me my
semantics are off, then what happens?  I resend?  I resend to another
target?  I auto-correct my semantics?  Are there realistic options
that I have as a non-intelligent notification sender?

Thanks,
 Phil

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 22 Nov 2005 11:16:40 -0500

Hi Phil,

My impression is that option c) is similar to error codes in an SNMPv3
Response message that explains the problem, so the sender can try to
correct the problem, such as by shortening a TooBig message by
removing the largest varbind. I agree there are limited cases where a
non-intelligent notification sender could auto-correct the semantics,
and the TooBig issue could be handled via capabilities.

One response might be to NOT resend, and to not send future
notifications of a specific type, if the sender is made aware that
specific notifications can not be handled due to a semantics problem. 

Another response might be to drop back to a different version or
different protocol to get a message through. Some SNMP-based NMSs drop
back to lesser  versions and protocols when the default stops working,
such as dropping from SNMPv3 to SNMPv1 to ping.

It might also be useful if another notification was generated, either
in netconf or syslog or snmp, that alerted the administrator that
there is an interoperability problem related to a specific
notification from managed device A to management application B.

Dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Tuesday, November 22, 2005 10:42 AM
> To: [email-masked]
> Cc: Sharon Chisholm; [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Nov 2005 17:20:13 +0100

> that I have as a non-intelligent notification sender?

If you talk to a person, you can get back either

a) nothing
b) "I heard you"
c) "I understood what you were saying"

It of course depends on the smartness of the whole system how you
react. Some humans are fine when they achieve b), some other
implementations feel better if they know they have achieved c).

Sure, implementation complexity goes up from a) to c) and the added
value of c) might not be worth the extra effort it causes. So perhaps
the decision is between a) and b).

/js