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

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

Hello,
As I remember Phil also complained about that now we have two "modes" of the Netconf session: normal mode and notification mode, when something special happens with incoming requests (e.g. discard them).
A big benefit of an interleaving-only solution would be that we do not have this modality. The manager application can still dedicate the session to notifications simply by not sending any RPC. 
Balazs

PS. I wanted interleaving in Montreal.

Martin Bjorklund wrote:

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


--
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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