Subject: RE: notification charter proposal

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

hi

How does a management agent send out a Notification without an event
system triggering it to do so? I think it is a part of all
architectures, whether it is a well-defined entity or implicit within
the rest of the system.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, November 21, 2005 3:31 PM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: [email-masked]
Subject: Re: notification charter proposal

Sharon Chisholm wrote:

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

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.

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

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.

>Sharon

Andy

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

--
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: Mon, 21 Nov 2005 14:22:12 -0800

>architectures, whether it is a well-defined entity or implicit within

Maybe I'm worrying about it too much, but it seems like you are
creating yet another CLR here.   Can 1 NC peer send another NC peer
the message "No activity has occurred in the last hour"? Or does
the message have to be "designed" as an Inactivity Event in the one-and-only
Official NETCONF Agent Architecture? And Event Messages only go
from Agents to Managers, etc.

I would rather focus on the operational features that must be agreed upon,
without trying to specify too much architecture.  IMO, it's too early in
the technology cycle to standardize that.  Let's work on
stuff that has "proven operational value" and spend our debate-energy
trying to agree what that means.

For starters, should there be a minimum max-message size in NETCONF?
If so, what should it be? 1500 bytes? 65535 bytes? More?  I wonder if
there is any consensus on this very specific detail.

Andy

---

From: Vincent Cridlig <[email-masked]>
Date: Tue, 22 Nov 2005 10:05:11 +0100

> there is any consensus on this very specific detail.

In our implementation, we experiment such sizes:
- around 1600 bytes for a single physical network interface config 
(ipv4, v6, mac, mtu, netmask, ...) *without* the stats. This number 
grows proportionally with the number of network interfaces.
- around 3400 bytes for a single physical network interface config 
(ipv4, v6, mac, mtu, netmask, ...) *with* the stats.
- around 10000 bytes for a simple BGP config.
- around 25000 bytes for a installed RPM package list (this example is 
more specific to system config than network config but well...)

So, for the copy-config operation and a large data model, I would say at 
least 65535 bytes for a minimum max-message size.

Vincent