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

Re: Notification Requirements Consensus Points

Sharon Chisholm wrote:

hi

I still don't agree with the first bullet, but if I am the only one who
worries about the ramifications of this layer compression, I can yield
in the effort to move forward.


Good.

It isn't a matter of layer compression.
It may very well be useful for somebody to
have the agent make an actual RPC call to the manager.
In this case, the current RPC model works, with
access control going in the right direction
(agent getting permission to do something on the manager).

A notification (from agent to manager) is an entirely
different mechanism.  The access control is granted
to the manager to view specific data from the agent.
A notification carries no 'responsibilities'
or side effects on the manager whatsoever (unlike an
RPC request from agent to manager).  The agent is
just responsible for delivering the data and the manager
can simply drop the notification if it wants.

IMO, this makes it very different than a reverse-RPC.




What we (the editor's) would like to do is create an update to the
document based on the consensus points for next week or, if the long
weekend here delays us, very early the next.


Great



Sharon


Andy



-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, April 12, 2006 8:16 PM
To: Netconf (E-mail)
Subject: Notification Requirements Consensus Points


Hi,

It is difficult to measure WG consensus.
It seems like no matter what the issue is,
there are about equal numbers of opinions on either side.

There seems to be consensus on these points:
 - Top level message is <notification> (rpc-one-way is out)
 - Separation of header and content-independent data is needed
 - Both the manager subscription model and traditional agent-configured
   notification generator model should be supported
 - The header should include some type of classification
(e.g., event-class). - The ability to filter (i.e., drop) notifications at the source based on event class and notification data content is needed. Access control is impacted by this feature. 
 - Named profiles (if kept) need to be fully specified in a
   standard read-create data model.
 - There is no limit on the length of the notification data
   (same as for RPC data)

There does not seem to be consensus on these points:
 - The specific role of notifications in the netconf protocol
   or whether a specific role is even needed
 - The use of a read-only instead of a read-create data model
   for notification generation parameters
 - The use of specialized RPCs instead of a standard data model
   to configure notification generation parameters
 - The need for named profiles (issue is irrelevant if read-create
   data model approach is used)
 - Multiple subscriptions per session are needed
 - RPC operations and notifications should be mixed on the same session
 - The specific list of event classes, or
   whether this document or IANA maintains the list, or
   whether we even need a list at all (i.e., just a string match).
 - The need for a modify-subscription feature
   (Note that this is implicitly supported by edit-config if a
   read-create data model is used)
 - The use of an endless-RPC model (which is only relevant if
   the WG decides mixed-mode sessions are not required)
 - The specific standard notifications (if any) that an agent
   must support



Andy







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