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

[Martin Bjorklund <mbj@tail-f.com>]

"Netconf" <trac@tools.ietf.org> wrote:
> #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.

I agree to this.  And another benefit is that we would have one single
way all agents will behave, no extra capabilities or anything.  A
manager will know how things work.

So, if I recall correctly, it was Andy and Phil that were most vocal
against interleaving in Monteral.  But I might remember wrong.  Andy
now seems to think interleaving is ok.  We also know that there are at
least two implementations that support interleaving currently.  So can
the WG agree to make interleaving the only option?


/martin

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