[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stopping notifications
Sharon Chisholm wrote:
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."
The last 2 sentences are unacceptable.
Multiple people (including myself) have requested that
this text be removed.
Note that in Montreal it was agreed that processing messages just to
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.
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."
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.
Sharon
Andy
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, July 05, 2007 10:40 PM
To: Martin Bjorklund
Cc: netconf@ops.ietf.org
Subject: Re: stopping notifications
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
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.
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...
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).
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 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.
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).
/martin
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/>
--
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/>
--
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/>