[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>