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

Re: Notification Requirements Consensus Points

Eduardo Cardona wrote:
Hi, I am not a WG contributor, but I follow with interest the discussions. 

"There does not seem to be consensus on these points:
...
- RPC operations and notifications should be mixed on the same session"


I can see pros and cons for the implementation as already stated by the
WG. One thing is what the architecture should be, one is what works,
scale, is deployed and sold. Where the line is set? 
My question is more Where IETF is moving on session/applications from
the transport protocol perspective? And plug the applications protocols
right there.
For example : BEEP offers channels; SCTP ( not a protocol required for Net-Conf) offers streams within an association (session). What about Netconf for wireless/Satellite/slow/far networks where mixed RPCs and large RPCs maybe a problem? 
A compromised solution could be to define for BEEP the notification
channel and the configuration channel. SSH/SOAP (TCP) a negotiable
feature:
- Require for the Managed element to support both (in session and
different session notifications) - Require for the Manager ( the TCP session resources constrained device) to support either one or the other, or both. 
In this way the specialization is performed at the manager based on the
needs, and not at the network element


We already have plenty of options (i.e., capabilities).
None of them are specific to any transport layer -- by design.
The WG already rejected the idea of different notifications
(and control channels, etc.) for each transport.

The netconf architecture only works if each layer hides the
layer underneath it.  Is this feature important enough
to incur the complexity it would cost to support it
on all transports, mandatory in all agent implementations?

IMO, we are close to deciding that mixed-mode (what I call
sharing 1 NETCONF session for notifications and operations)
is not important to enough people to support.

Your proposal sounds like you don't want to mix notifications
and operations together, but if other people to, then here is
a way to do that.  Is that correct?

I would like to see emails that clearly state
"we have this requirement in our product/service/network"
for specific features", or "we do not plan to use feature X".

The only example of mixed mode that has been given is
the ability for current CLI implementations to be configured to
send spurious system console messages to the terminal.
I don't see how that really applies to a programmatic
interface like NETCONF.  The messages can be much larger,
and the interactions more complicated in NETCONF.





Although my preference is separate sessions (e.g BEEP channels, TCP
sessions) -> SCTP streams !  - solve the architecture paradigm (is there
any?) 
Thanks

Eduardo


Andy



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] Sent: Wednesday, April 12, 2006 6: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/>