[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: notification charter proposal

Sharon Chisholm wrote:


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.


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.



Sharon


Andy


-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Monday, November 21, 2005 3:31 PM 
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: netconf@ops.ietf.org
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: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On



Behalf Of Andy Bierman
Sent: Monday, November 21, 2005 10:42 AM
To: Tom Petch
Cc: netconf@ops.ietf.org
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" <ietf@andybierman.com>
To: <netconf@ops.ietf.org>
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 netconf-request@ops.ietf.org 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 netconf-request@ops.ietf.org 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 netconf-request@ops.ietf.org 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 netconf-request@ops.ietf.org 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 netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>