[BEHAVE] [behave] #17: nat-mib-06 abbreviations

["behave issue tracker" <[e-mail]>]

#17: nat-mib-06 abbreviations

 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?
 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.
 If the only thing that gets counted is incompatible flags, then name it
 natIncompatibleFlags.
 If other things are supposed to be counted, be explicit about WHAT gets
 counted in this counter.
 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?

 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 ..."

 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.

 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?

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-
  [e-mail]    |  [e-mail]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  64-analysis  |    Version:
 Severity:  In WG Last   |   Keywords:
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/behave/trac/ticket/17>
behave <http://tools.ietf.org/wg/behave/>