Re: Notification Message Processing Model

[Andy Bierman <ietf@andybierman.com>]

Phil Shafer wrote:
> Balazs Lengyel writes:
> > I feel that using a never ending rpc-reply is a much bigger deviation from the original 
>
> But it's not a deviation; it's completely within the spec.  For
> example, JUNOScript has a <ping> RPC.  When you perform this RPC,
> the ping operation continue until the connection is terminated or
> the <abort/> operation is sent.  There's another RPC called
> <get-accounting-record-information> which will feed you accounting
> records with the same unending paradigm.  The endless reply is
> really quite useful.  Yes, it requires your client to understand
> that it cannot buffer data endlessly before passing it up to
> interested parties, but a <get-route-information> RPC on a box
> with a million routes will do this too.

We already have unbounded strings in NETCONF
(not that I didn't try to get rid of all of them).
Unbounded == infinite length.  I'm not exactly sure
why XSD and the WG think this is so important,
but it's in there, so Phil's proposal wouldn't be a new
implementation burden.  For event-driven parsers,
it is not a problem at all.

Here is yet another solution variant:

---------------------------------------------------

2 New capabilities:

  :notification

OR

  :notification-mixed

Make mixed-mode (RPCs and notifications on the same channel)
a capability.  That means:

 - if the :notification capability is advertised the
    agent will process <rpc> messages (while sending <notification>
    messages) by immediately returning an <rpc-error>

 - if the :notification-mixed capability is advertised instead, the
   agent will process <rpc> messages (while sending <notification>
   messages) in the normal manner.

Neither capability is mandatory-to-implement.

Message flow:

     Manager                 Agent

     rpc/start-notif.   --->
     rpc-reply/ok       <---
     notification       <---
     notification       <---
     rpc/*              --->
     notification       <---
     rpc-reply/*        <---

This is essentially the same as the the current draft,
except the manager has to check for 2 variants of
the notification capability instead of 1, and use
that data to know if it needs 1 session or 2 sessions.

If people find the mixed mode so useful, it will
get implemented and deployed.

This gets rid of never-ending element with capabilities
instead of runtime modes, and lets implementors decide
whether they think mixing notifications and operations
on the same channel is something they want to do.


> Thanks,
>  Phil

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