[Netconf] #15: <rpc> interleaving during notification delivery mode

["Netconf" <trac@tools.ietf.org>]

#15: <rpc> interleaving during notification delivery mode
---------------------------------------------+------------------------------
 Reporter:  ietf@andybierman.com             |       Owner:     
     Type:  defect                           |      Status:  new
 Priority:  major                            |   Milestone:     
Component:  draft-ietf-netconf-notification  |     Version:     
 Keywords:  notification-08                  |  
---------------------------------------------+------------------------------
 There are some interoperability issues related
 to interleaving of <rpc> requests.  This means
 that the agent has already processed the <create-subscription>
 operation, and is delivering notifications.

 This notification delivery mode continues until
 either a stopTime is reached or the session is terminated.
 If the stopTime is reached, the session reverts back to
 the normal mode (accepting <rpc> requests).

 Issue a) what MUST, SHOULD, MAY an agent do with input
 received on the session, after the <create-subscription> RPC,
 when it transitions back to normal mode?

 ------

 The current proposal is that the text will say
 the manager SHOULD NOT send <rpc> after requesting
 notifications, and the agent MAY NOT process <rpc>
 after it starts sending notifications.

 ------

 comments:

 First, what are the choices?

   1) require interleaving MUST be supported by the agent
   2) allow interleaving to be supported by the agent,
      but just warn that the manager SHOULD NOT interleave
      and the agent MAY NOT accept interleaved requests.
   3) allow interleaving to be supported by the agent,
      based on the '#interleave' capability,
      and also warn that the manager SHOULD NOT interleave
      and the agent MAY NOT accept interleaved requests.
   4) require interleaving MUST NOT be supported by the agent
      - what happens when the manager sends an <rpc> anyway?
        a) close session
        b) ignore request
        c) send operation-failed response

 What are the benefits?

 There obvious benefit from allowing interleaving,
 if you believe sessions are expensive -- it saves an extra session
 on both the manager and the agent.

 The real benefit is that <close-session> is a the cleanest way
 to terminate sessions, and it should be used in all modes.
 The <kill-session> and drop connection methods are both bad ideas.

 It would also be a HUGE CLR to forbid interleaving completely.
 In the future, some new feature will come up that will make it
 clear the agent should never be in a mode it MUST stop listening
 to all input from the client.  It will be clear then (if not now)
 that this is a really bad idea.

 So what are the benefits of forbidding interleaving completely,
 and what happens if the manager sends an <rpc> anyway?

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/netconf/trac/ticket/15>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Group�������zǧu���Ơz�z�����l���0����ۧ����z)ڲ)�b�欶�z����w&�r�zm����������w�