Subject: Re: [Netconf] comments on netconf-monitoring-03 draft

From: Martin Bjorklund <[email-masked]>
Date: Sun, 01 Mar 2009 21:07:33 +0100 (CET)

Hi,

Andy Bierman <[email-masked]> wrote:
> 3 more comments on counters:
> 
> 14) The counter conditions are specific -- that's good,
>      except inBadRpcs.  The words 'parsed correctly'
>      implies well-formed XML.  If so, then another
>      counter should be added for invalid XML messages received.

There is one - inXMLParseErrors.

> 15) Is inRpcs == outRpcReplies always true?
>      If not, why not?  (If yes, why do both counters exist?)

Good question... I think that if these counters do not have the same
value, then that indicates some bug in the agent which made it close
the session or something.  Should one of them be removed?

> 16) Is inBadRpcs == outRpcErrors always true?
>      If not, why not?  (If yes, why do both counters exist?)

If you receive a non well-formed XML message, but you did get the
<rpc> element, should you reply with an <rpc-error>?  If so, then
these counters do not have to be the same.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 01 Mar 2009 12:24:15 -0800

> There is one - inXMLParseErrors.

I mixed up 2 comments from my notes on this issue.
I meant to say there is no catch-all like resources-denied.
Is this worth a separate counter, or is inBadRpcs good enough?

> the session or something.  Should one of them be removed?

Actually (in my code) when you read the counters,
the inRpcs is always 1 more than outRpcReplies,
because the <get> for the counters has already been added
to inRpcs.

> these counters do not have to be the same.

If you cannot send an <rpc-reply> then
the session should be dropped.

We should not waste counter memory on redundant or
easily derivable statistics.  That seems to be the case here.

> /martin

Andy

---

From: WashamFan <[email-masked]>
Date: Mon, 02 Mar 2009 10:37:11 +0800

>  because the <get> for the counters has already been added

If <rpc> requests sent in a row, before all the corresponding <rpc-reply>
responds returned, the inPpcs may be more than 1 greater than outRpcReplies.
So if inRpcs is greater than outRpcReplies, we can assume a number of
requests is being handled when we retrieve the counters.

>  >>      If not, why not?  (If yes, why do both counters exist?)

Or inBadRpcs + inNotSupportedRpcs == outRpcErrors ?

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Mar 2009 08:14:32 +0100 (CET)

> Or inBadRpcs + inNotSupportedRpcs == outRpcErrors ?

No, for example a perfectly legal <validate> will not increment
inBadRpcs or inNotSupportedRpcs, but it might still generate an
rpc-error if the source config is not valid.

Hmm.  Re-reading the description of outRpcErrors, it seems the text is
not as precise as it could be.  E.g. will the counter be incremented
if <data> AND <rpc-error> is sent?  Will it be incremented if inline
rpc-errors are sent?

I think the conclusion is that this counter probably is not very
useful as it is defined.  Separate counters for each error-type might
be interesting, or at least for error-type transport, rpc, and
protocol.

/martin