netconf notification transport issues

[Andy Bierman <ietf@andybierman.com>]

Hi,

Phil brought up some transport issues again, that I think we should
find out some opinions, one way or the other.

1) Multi-use session

  Is it important that a manager be able to issue <rpc> calls and
  receive <notification> messages within the same session?

  The other option (Single-use session) implies that the manager
  will establish multiple single purpose sessions instead.

  As Phil pointed out, if single-use is okay, then the manager can
  simply make a 'start-receiving-notifications' RPC call that
  never finishes (usually until the manager shuts down the session).


2) Multiple channels and Multiple Connections

  Should we try to bring back this concept?
  Wasn't this the main reason we picked BEEP in the first place?
  Is the BEEP mapping that relevant without it?
  This issue is only relevant if multi-use sessions are required.


3) Application Acks and Reverse RPCs

  As Phil and I pointed out in emails, a notification with an
  application-ack is really just another <rpc> method, but
  from the agent to the manager.  It might be simpler to define
  how to reverse the flow for notification purposes, rather
  than redefining the <rpc> and <rpc-reply> elements.

  Should this feature be dropped, capability-based, or mandatory?
  If kept, how should it be done?


4) Any More Transport Issues??

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