Re: stopping notifications

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

Andy Bierman <ietf@andybierman.com> wrote:
> Juergen Schoenwaelder wrote:
> > On Sun, Jul 08, 2007 at 07:55:55AM -0700, Andy Bierman wrote:
> > 
> >>> 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.
> > 
> > I do.
> > 
> >> 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.
> > 
> > Does it say that requests have to be processed within a given time
> > interval? A single threaded implementation might just postpone
> > processing requests...
> 
> 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.

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


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