[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: notification charter proposal
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: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/>