Re: [BEHAVE] nat-mib-06 abbreviations

[Simon Perreault <[e-mail]>]

Le 2013-06-22 15:59, ietfdbh a écrit :
> My experience is that operators find abbreviations irritating.
> "Let's see, was that spelled out as counter, or abbreviated as Cnt, or Cntr,
> ...?"
>
> Counter names have often historically ended with an "s", which helps
> identify it as a counter.
>
> I'm not convinced you need the extra hierarchy of natCounters and natLimits
> and natPoolObjects, but I can live with it.
>
> Meaningful descriptors are preferred.
> Some NMS applications display the object name without a corresponding
> description, so  meaningful object names help operators.
> Let's see, I wonder what natCntOOP means? The number of object-oriented
> programming counters?
> How about using natCntNoPorts instead?
>
> Do you really need the "Cnt" in the names? Wouldn't natNoPorts suffice?
> natCntTranslates => natTranslations?
> natCntResource => natResourceErrors?
>
> natCntStateMismatch => natStateMismatches?

That makes sense, and I don't see a big problem with changing names now.

I remember that when naming some objects I hit the length limit and had 
to use abbreviations instead of full names. I'll see what I can do while 
staying under the limit.

> I also have concerns that this definition is ambiguous. You give an example
> rather than a clear description of what MUST and MUST NOT be counted in this
> counter.

Could this be due to the underspecified nature of NAT itself?

> If the only thing that gets counted is incompatible flags, then name it
> natIncompatibleFlags.

It's not just flags. Various NAT implementations expect various things 
from packets so that they match state entries. One example of something 
that is not a flag would be TCP sequence number mismatches. Some NATs 
track TCP sequence numbers. When a packet is outside an acceptable 
window, this counter would get incremented.

> If other things are supposed to be counted, be explicit about WHAT gets
> counted in this counter.

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.

> Ambiguity leads to differing interpretations, which hurts interoperability.
> I think this description needs tightening (and possibly a reference to a
> discussion of state mismatch)
>
> 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?

> I'm a bit uncomfortable with "The number of packets to which NAT could not
> be applied because ..."
> Does this mean "The number of packets not translated because ..."

Agreed. Fixed in my local copy.

> natCntMappings - it is generally considered bad practice to define objects
> that are easily derived from existing objects.
> These objects are instantiated on devices that should be focused on
> forwarding packets, not running formula calculations.
> Forwarding devices often have very limited resources, so having the nat
> device use its CPU to do unnecessary calculations and store the results in
> scarce memory is not a good idea.
> Let the NM application get Creations and Removals and let it do the
> calculations.
> Complexity should be pushed to the SNMP manager, not the SNMP agent.

Makes sense. Fixed in my local copy.

> Here are the guidelines used in the BRIDGE-MIB:
> " To be consistent with IAB directives and good engineering practices,
>     an explicit attempt was made to keep this MIB module as simple as
>     possible.  This was accomplished by applying the following criteria
>     to objects proposed for inclusion:
>
>     1. Start with a small set of essential objects and add only as
>        further objects are needed.
>
>     2. Require that objects be essential for either fault or
>        configuration management.
>
>     3. Consider evidence of current use and/or utility.
>
>     4. Limit the total number of objects.
>
>     5. Exclude objects that are simply derivable from others in this or
>        other MIB modules.
>
>     6. Avoid causing critical sections to be heavily instrumented.  The
>        guideline that was followed is one counter per critical section
>        per layer.
> "
>
> natCntMappings - Can Creations exceed Removals? That would seem reasonable
> to me.
> If so, then Mappings = removals - creations would generate negative numbers,
> right?
> Shouldn't this be creations - removals?

You're absolutely right! Fixed in my local copy.

Thanks a lot!

Simon