Subject: stopping notifications

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jul 2007 07:58:56 -0700

Hi,

If an agent was to keep track of dropped sessions, and perhaps even
generate a notification, or take other action, then the design of
the notification feature will be a concern.

The only way to stop getting notifications is to drop the session.
Unlike normal RPC mode (i.e., <close-session>), the agent has no
indication that this is intentional and not a network problem.

Would it be a feature or a hack to allow the agent to accept a <close-session>
request during 'notification delivery mode'?  If a feature, should this
be the mandatory mechanism to get out of notification mode and exit?
(The tail -f command this is modeled after has the manager send 'control-c'
in this case -- <close-session> is our closest matching operation.)

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jul 2007 19:33:40 +0200 (CEST)

> The only way to stop getting notifications is to drop the session.

Or just open a new channel (netconf session) and send a <kill-session>
for the notification session.

> in this case -- <close-session> is our closest matching operation.)

This means that the agent has to poll for and parse incoming requests
while sending notifications.  If the request is something else, should
an error be generated or should the session be terminated?  If the
agent has logic for this, it could very well handle any request, IMO.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jul 2007 10:46:19 -0700

> for the notification session.

true, although a little more work for the manager

> agent has logic for this, it could very well handle any request, IMO.

The agent has to send something if a manager sends an RPC request
during notification mode, even if it is a quick 'operation-failed' reply.
Just letting the manager hang until it times out seems wrong.
IMO, there is already code to close down the session in case
it is dropped, and this is not nearly as hard to support as
allowing any RPC method.

However, the <kill-session> workaround could be good enough,
and it won't require any changes.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jul 2007 20:03:52 +0200 (CEST)

> during notification mode, even if it is a quick 'operation-failed' reply.

There's nothing in the draft that specifies this behaviour.

> Just letting the manager hang until it times out seems wrong.

Well it's wrong to try to send anything in notification mode...

> it is dropped, and this is not nearly as hard to support as

This is obviously implementation dependent.  In my implementation, I
would have to add code to detect this case and send an
'operation-failed' error instead of handling the request.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jul 2007 19:40:26 -0700

> Well it's wrong to try to send anything in notification mode...

The agent cannot assume the manager will always send the correct PDU.
The agent must always respond appropriately to an <rpc> request.
RFC 4741 says so.

The immediate issue is whether or not the draft needs to say
anything about this situation.

I think it is better to just say the agent MAY allow RPC requests
to be processed after <create-subscription>, but if not, the
agent MUST respond with an appropriate <rpc-error>.
(Define an error-app-tag like 'notification-exclusive-mode' for
an operation-failed error-tag).

> 'operation-failed' error instead of handling the request.

This argument washes out.
You would need special code to know you are in notification mode
so you should ignore the subsequent <rpc> requests.

I think my solution above allows the 'normal' code path
to be utilized, allows an implementer to easily reject requests
in notification mode, and allows a manager to easily tell
if interlaced RPCs are supported (without needing yet another capability).

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 8 Jul 2007 10:23:04 -0400

Hi

On this topic, the draft currently says:

"A NETCONF server is not required to process RPC requests on the
   session associated with the subscription until the notification
   subscription is done and may silently discard these requests.  A
   capability may be advertised to announce that a server is able to
   process RPCs while a notification stream is active on a session.  The
   behaviour of such a capability is outside the scope of this
document."

Note that in Montreal it was agreed that processing messages just to
produce error messages just did not make sense. 

In some offline discussions, we have proposed the following improvement
to the paragraph

"A NETCONF server is will not read RPC requests, by default, on the
   session associated with the subscription until the notification
   subscription is done.  A capability may be advertised to announce 
   that a server is able to process RPCs while a notification stream 
   is active on a session.  The behaviour of such a capability is 
   outside the scope of this document." 

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Thursday, July 05, 2007 10:40 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: stopping notifications

The immediate issue is whether or not the draft needs to say anything
about this situation.

I think it is better to just say the agent MAY allow RPC requests to be
processed after <create-subscription>, but if not, the agent MUST
respond with an appropriate <rpc-error>.
(Define an error-app-tag like 'notification-exclusive-mode' for an
operation-failed error-tag).

> 
>> IMO, there is already code to close down the session in case it is 
>> dropped, and this is not nearly as hard to support as allowing any 
>> RPC method.
> 

This argument washes out.
You would need special code to know you are in notification mode so you
should ignore the subsequent <rpc> requests.

I think my solution above allows the 'normal' code path to be utilized,
allows an implementer to easily reject requests in notification mode,
and allows a manager to easily tell if interlaced RPCs are supported
(without needing yet another capability).

Andy

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 08 Jul 2007 07:55:55 -0700

>    behaviour of such a capability is outside the scope of this

The last 2 sentences are unacceptable.
Multiple people (including myself) have requested that
this text be removed.

> produce error messages just did not make sense. 

I do not remember this at all.
RFC 4741, sec. 4.2 does not agree with this statement.
The <rpc-reply> is expected if the <rpc> is received
by the agent.  It does not say anything in RFC 4741 about
the agent ignoring <rpc> requests for any reason.

So how does the manager know the difference between a wedged agent
and one that is simply ignoring the <rpc> request?
Doesn't the Postel Principle require the agent to respond,
even if the manager should not have sent a request at all?
It seems the choices are respond or drop the session, but
not ignore the request.

>    outside the scope of this document." 

This is not an improvement.
If the entire feature is outside the scope of this document,
then why/how does this document know the feature is controlled
with a capability?

We care first about multi-vendor interoperability.
Support for unspecified proprietary features is not a high priority
at all.  Leaving the documentation vague and confusing (in the hope
of leaving vendors more wiggle room) is not going
to help in the AD review or IETF review phases.
Fix it now or have it throw back at us later.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 8 Jul 2007 20:51:49 +0200

> I do not remember this at all.

I do.

> the agent ignoring <rpc> requests for any reason.

Does it say that requests have to be processed within a given time
interval? A single threaded implementation might just postpone
processing requests...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 08 Jul 2007 12:11:34 -0700

> interval? A single threaded implementation might just postpone

No, there are no time limits for any NETCONF PDU exchanges.
I suppose an implementation can be compliant by never
processing the message and claiming no time limit has
been exceeded.

IMO, it would be a huge CLR to forbid an agent from responding
to new <rpc> requests, but the document should not specify that this
feature is supported with some unidentified capability.

In this case, if the agent drops the <rpc> request,
then the manager should eventually time out and drop the session
(the only thing it was allowed to do in the first place).
So the text does not need to say anything except perhaps
that the agent is not required to respond to subsequent <rpc>
requests after <create-subscription> is completed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 08 Jul 2007 12:26:45 -0700

> interval? A single threaded implementation might just postpone

So remind me why we can't just define this 'interleave' capability,
instead of saying how it works, but punting it to the vendor?

I don't really care that much one way or the other about any
feature in this document.  I only care about getting the document
published quickly (i.e., IESG and IETF LC find the draft clear,
complete, and believe independent interoperable
implementations could be created from it).

IMO, it would be better to put a stake in the ground and
add the extra capability to this document, than ignore
the issue completely.

But the current middle ground is not interoperable.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 08 Jul 2007 22:43:51 +0200 (CEST)

> feature is supported with some unidentified capability.

I think that the agent's behaviour must be clearly specified.  We have
seen two different interpretations of the words "not required to
process RPC requests".  One interpretation is that the agent does not
read from the socket at all, and the other is that the agent reads,
parses, and replies with an error.  So obviously the current words are
not clear enough.  I think/hope Sharon's new words are better.

> In this case, if the agent drops the <rpc> request,

It doesn't drop the request, it never reads it.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Sun, 08 Jul 2007 18:26:58 -0400

>   outside the scope of this document." 

Isn't this just a vague reference to a non-existent capability?  Do
specs normally do this sort of thing?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 08 Jul 2007 18:24:56 -0400

>feature is supported with some unidentified capability.

But isn't it a bug to allow some agents to respond by not spelling
out in the spec was is and isn't allowed?

This is fall-out from turning the netconf session into this bi-modal
thing.  It gets even worse if the boundary conditions between the
modes are not well defined.

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 12 Jul 2007 21:03:14 +0200

Hello,
I think the previous text from draft-07 is quite good:

"A NETCONF server is not required to process RPC requests on the
    session associated with the subscription until the notification
    subscription is done and may silently discard these requests."

I also remember that in Montreal we sad we don't process requests just to report errors even 
though this slightly violates the base RFC.

Two additional aspects:
1) We should preferably not mention capabilities that are not defined properly. If we do not 
forbid a specific behavior a vendor might have optional capabilities implementing it, so why 
speak about it?

2) I completely agree with Phil that we should very explicitly define the Netconf session being 
in Command-Response mode or in Notification mode.
Notification mode starts at create-subscription and its response.
Notification mode ends at replayComplete or session termination.

replayComplete MUST only be sent if a stop-time was used in the create-subscription. This is 
ambiguous even in the draft-08.

Balazs