Re: [BEHAVE] nat-mib-06 abbreviations

[Simon Perreault <[e-mail]>]

Le 2013-06-24 16:40, ietfdbh a écrit :
> That's pretty much impossible given that NAT is underspecified and various
> NAT implementations do various things. What we can do is eliminate any
> ambiguity, while remaining generic.
> [dbh>] But you're NOT eliminating the ambiguity.

Right. I did not propose a way to eliminate the ambiguity. I was only 
suggesting that that is what we should do (as opposed to eliminating 
generality).

> I have a background in NMS development, and know that it is frustrating to
> have the same counter name used to count different things on different
> implementations. The counter simply  becomes useless. Having a "standard" is
> pretty useless if I have to code my application to know that the xyzCounter
> counts one thing on Cisco NATs, but Juniper NATs count something else, and
> Acme NATs some other implementation-dependent stuff, while Foobar NATs
> include their implementation-dependent things. And if the standard is
> ambiguous, then different models from the same vendors can choose to count
> different things as well, making it REALLY useless.
>
> The problem is that an NMS cannot compare the value of this counter across
> different implementations because the meaning of the counter differs across
> implementations. I recommend standardizing what can be agreed upon, and let
> those things that are implementation-specific (i.e., not agreed upon) be
> documented in implementation-specific MIB modules; maybe at some time in the
> future, agreement can be reached to extend the standard.
>
> if the counter goes into an IETF standard MIB, then it should standardize
> what gets counted in that counter.

That's a fair point.

Unless the WG disagrees, the state mismatches counters will be removed 
from the next revision.

>> natCntQuota => natQuotaErrors? natQuotaRejects? natQuotaRefusedPkts?
>> Does this only apply to incoming packets?
>
> The whole MIB assumes that 1 packet in = 1 packet out. If an incoming packet
> gets dropped because an outbound quota is reached, then that still
> increments the counter. Is that what you meant?
> [dbh>] well, yes, that is what I meant, at least to a degree.
> Remember that under SMI rules, you cannot go back and change the semantics
> of this description later.
> As long as there is a 1:1 mapping, it probably doesn't matter whether you
> count this as an incoming packets of an outgoing packet issue. However,
> given the variety of NAT implementations, as you've mentioned, and I'm not
> sure that variability will go away anytime soon, somebody might choose to
> implement different quotas for incoming and outgoing. Hence, it could be
> better to specify that this counts "the number of incoming packets that did
> not get translated ..."; that way if ever implementations allow for a
> not-1:1 mapping, they still know which packets to count in this counter. And
> if the 1:1 assumption always holds true, it makes no difference.

Will do.

> I think the naming should change to reflect that this is a drop counter - I
> suggest natQuotaDrops.

Ok.

> In general, counters count behaviors/actions such as drops, rather than
> things like quotas, so the behavior/action being counted should be part of
> the name. If I am an operator looking at a counter named natCntResource, is
> this counting the resources? Or is it counting the drops caused by
> inadequate resources? Ideally an operator should not need to go read the MIB
> description clause to figure this out, while trying to debug why the
> company's shopping cart network connection suddenly isn't working. It helps
> a lot to use meaningful object names.

Makes total sense. Thanks for the help!

Simon