Subject: notification charter proposal

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Nov 2005 18:27:20 -0800

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/>

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 21 Nov 2005 15:02:44 +0100

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:-(

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Nov 2005 07:42:11 -0800

>I get a slight sense of you and Sharon determinedly heading in different
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".

Andy

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 22 Nov 2005 10:50:56 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 21, 2005 4:42 PM
Subject: Re: notification charter proposal

> wants this sort of "notification feature".
Yes, I can see that and it makes me think that there needs to be something about
that in the charter, clarifying what a notification is; otherwise, by
simultaneously adopting 'draft-chisholm-netconf-event-01.txt', I think we are
implicitly taking on board whatever that says.  I always associate the term
notification with SNMPv3 - I don't see it used elsewhere - which does not appear
to define it but implies it is asynchronous, an unsolicited transmission, an
event notification; and there is an implicit size limit because of UDP,
something NETCONF lacks.

The original charter did have asynchronous in it, which seems right to me, but I
would like something about limiting the size as well, to stop people including a
storage dump with the restart notification, but I don't have a good wording for
it - perhaps
'a notification is a brief, asynchronous message indicating that an event has
occurred'.

---

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

On Tue, Nov 22, 2005 at 10:50:56AM +0100, Tom Petch wrote:

> I always associate the term notification with SNMPv3 - I don't see
> it used elsewhere - which does not appear to define it but implies
> it is asynchronous, an unsolicited transmission, an event
> notification; and there is an implicit size limit because of UDP,
> something NETCONF lacks.

I think the term notification is not that unusual - even Corba has a
"notification service". 
 
> The original charter did have asynchronous in it, which seems right
> to me, but I would like something about limiting the size as well,
> to stop people including a storage dump with the restart
> notification, but I don't have a good wording for it - perhaps 'a
> notification is a brief, asynchronous message indicating that an
> event has occurred'.

I believe it is not a good approach to try to prevent people from
mis-using a protocol by means of rules or definitions (basically this
is the source of CLRs).

I favour an approach where a document spells out why it is a really
bad idea to use a certain protocol feature in a certain way.

I think the current netconf protocol spec does not define minimum
required message sizes for the RPC or operations layer. Introducing
such constraints for notifications to prevent their misuse I think is
not helpful. In fact, it might be more helpful if during the greeting
boxes could just advertise the message sizes they support, much like
ESMTP does it.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Nov 2005 07:41:28 -0800

>boxes could just advertise the message sizes they support, much like

That would be fine with me.
I brought up the issue because the problem is obviously worse
for notifications than RPCs, because the lack of an application
layer ACK (which <rpc-reply> effectively is). 

The reason for setting a minimum is to allow NMS developers
to code to some reasonable minimum.  The market will help
keep things somewhat reasonable, but we could see a range
from 1500 to 64K as the minimum.  Is that OK? 

Andy

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 22 Nov 2005 22:27:02 +0100

<inline>
Tom Petch
----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: <[email-masked]>
Cc: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 22, 2005 4:41 PM
Subject: Re: notification charter proposal
<snip>> >
> from 1500 to 64K as the minimum.  Is that OK?

I raised size because there are references appearing on the list calling for
something syslog-like and size has been an issue with syslog that has not been
satisfactorily resolved.  syslog unearthed two contrasting viewpoints, one that
messages should not exceed 2k or even 1k, the other that 64k should be supported
(for at least one application).

Netconf is more virgin territory than syslog is but I do believe is setting a
Maximum size, at least to start with; but I do not see this as anything to do
with the charter:-).

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Nov 2005 15:01:15 -0800

>Maximum size, at least to start with; but I do not see this as anything to do

This is part of protocol syntax and semantics.

IMO, the best approach is to have the NC peer advertise its
max-message-size.  The number should be an PositiveInteger,
so that would set a theoretical max-message-size of 4G-1 bytes.

A separate issue is whether there is a minimum an NC peer
can set this parameter to, somewhat higher than zero.  I don't see
any consensus yet on how much higher to set the minimum.

Another  important issue:  Can an NC peer (optionally?)
send its max-message-size in the <hello> exchange?  This doesn't
mean the other NC peer has to do anything with the value, it just
provides a good guess at the number instead of trying
various message sizes to see what breaks.   Advertising a
max-message-size doesn't mean you won't get messages greater
than that size. 

Andy