Subject: Re: [MIB-DOCTORS] Proposed renaming of MIB objects (Issue 009)

From: David Harrington <[email-masked]>
Date: Fri, 7 Nov 2014 14:20:01 -0500

Hi Tom,

I finally reviewed your proposed renamings.
You still have some naming that isn’t consistent with RFC4181 naming conventions.
I am copying this to the mib-doctors list, since there are few things that are as much art as science ;-)
That will hopefully also get you more review, since the behave WG has closed.

Do you have a new draft for the natv2 mib? I’m having to mentally apply your emails to -11, and I could easily misunderstand what you intend. 
An updated draft would be helpful.

TEXUAL-CONVENTIONS:

  - Names of TCs that are specific to the MIB module and names of
     SEQUENCE types that are used in conceptual table definitions should
     start with a prefix Xxx that is the same as xxx but with the
     initial letter changed to uppercase.  OPT-IF-MIB uses the prefix
     OptIf on the names of TCs and SEQUENCE types.
My impression is that the new MIB module’s ProtocolNumber T-C utilizes existing standard protocols numbers from the IANA registry.
Therefore, this doesn’t have to be a MIB module-specific textual convention, it could be used by any module referring to that registry.
So you could simply use ProtocolNumbers without the prefix.
Check with Benoit to see if he agrees. If so, the common textual conventions on the ops wiki should be updated (pending draft approval).

VlanIndexorZero might also be applied for non-nat usage. 
This is the same as VlanIndex, but allows for zero to indicate no Vlan. 
I suggest a REFERENCE clause pointing to the VlanID and VlanIndex T-Cs in rfc4363.
The description doesn’t make that “zero” distinction clearly.
I recommend putting the description of the zero value at the end of the description, in a separate paragraph.
(You could just eliminate all the description text except a reference to VlanIndex and add the extra zero part, but having the description cover the values makes it easier for an operator to see semantics without having to hunt through multiple documents.
Check with Benoit to see if he agrees. If so, the common textual conventions on the ops wiki should be updated (pending draft approval).

natBehaviorType:
I’m not sure why you changed natBehaviorType T-C to Natv2AddressPortMappingAndFilteringBehavior
I notice that there are only two objects that use the behavior type T-C, and they are actually for different purposes (4.1 address mapping and 5.0 port filtering).
Since there are only two, and they actually represent different behaviors, you could eliminate the T-C and just add the appropriate description to each object.
The real potential benefit for this is the possibility of new address/port mapping behaviors or filtering behaviors, where it wouldn’t necessarily be useful to combine them into a single T-C.

TABLES:

Within a table, the descriptors should all start with the same prefix; This helps to identify which table the object is in.
   - The descriptor associated with a conceptual table should be of the
     form xxxZzzTable; the descriptor associated with the corresponding
     conceptual row should be of the form xxxZzzEntry; the name of the
     associated SEQUENCE type should be of the form XxxZzzEntry; and the
     descriptors associated with the subordinate columnar objects should
     be of the form xxxZzzSomeotherName.  An example from the OPT-IF-MIB
     is the OTMn table.  The descriptor of the table object is
     optIfOTMnTable, the descriptor of the row object is optIfOTMnEntry,
     the name of the associated SEQUENCE type is OptIfOTMnEntry, and the
     descriptors of the columnar objects are optIfOTMnOrder,
     optIfOTMnReduced, optIfOTMnBitRates, optIfOTMnInterfaceType,
     optIfOTMnTcmMax, and optIfOTMnOpticalReach.

Within natv2Limits, you have natv2ThresholdAddressPortMapActivesHigh; that isn’t prefixed with natv2Limits.
A threshold is a limit, and High implies the thresholdness of the limit, so why not natv2LimitsAddressPortMapActivesHigh?
ditto natv2ThresholdAddressMapActivesHigh.

A real nit:
Counters traditionally end with an ’s’, so ActiveHighs rather than ActivesHigh.

natv2Counters
If you are going to ut these counters into a table, then their names should reflect they are in the table:
natv2Translations => natv2CountersTranslations, etc.

I wondered why you had a table for counters, rather than putting them directly under natv2Counters, but then realized the table gave you the instance index.
natv2InstanceTranslations would be more meaningful than natv2CountersTranslations, since these are instance=specific, but you’re already using natv2InstanceXXX.
The counters table is indexed by instanceIndex, as is the instance table.
Is there a reason you don’t just add these counters to the natInstanceEntry?

Keeping these in the same table would avoid fate-sharing addition/deletion anomalies across tables.
If you keep the instance-specific counters in a different table, then you need to improve the documentation for the counters table, to indicate that if an instance is deleted from the instance table, you need to make sure to delete the associated counters as well.
And you need to improve documentation about whether adding an instance to the instance table implies that a corresponding row MUST be added to the counters table.
And you need tp document whether creating a row in the counters table MUST only occur if there is a corresponding instance in the instances table (can I just choose an unused instanceIndex and create a row of counters, which has no corresponding alias object (not even a zero-length string)?
Imagine creating instance #3, plus associated #3counters, then deleting instance#3 but not #3counters, and then creating a new #3 instance. Now the counters are incorrectly associated.

The same issues occur with the natLimits table versus the instance table. Why not simply combine them into one table?

Sometimes, you want to keep slowly-changing operational state separated from fast-changing counters, especially if you used some type of “row changed” indicator.
This can be important when, for example, you wanted to change the limits occasionally, and had a huge table of instances.
Trying to detect when a row’s limits changed might require reading through all the rows and comparing the whole thing to a previous read of the whole table.
Keeping a “dirty” flag per row could work, but if changed are infrequent but important to detect, you can have a table-dirty flag to indicate that something int he table changed.
But this wouldn’t work if the table also contains counters, since counters almost always change.
I don’t think that’s important here, but it’s something the WG/authors should discuss.
see entLastChangeTime and entConfigChange n RFC2037 for an example of this.

natv2L4ProtocolTable - are all of the protocols L4?
This T-C really needs a reference to the specific registry you are referring to. There are lots of protocol numbers maintained by IANA, so this description is ambiguous.
Is this meant to refer to "http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml” mapping of services to ports?
If so,, then I’ll note that the natv1 mib included icmp in the protocols, but that is not in the service.port mapping.
icmp is in the http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1 registry. “Assigned Internet Protocol Numbers”
Is this the one you mean?

natPoolWatermarkLow was correctly prefixed as an object in the natPool table.
Changing it to natv2ThresholdPoolUsageLow would make it inconsistent with the tangle naming.

you could shorten natv2AddressPortMapTable to natc2PortMapTable et. al.
Then you’d have a parallel of AdressMap and PortMap.

Subscriber information is spread across multiple tables.
Make sure the table descriptions include detailed information about fate-sharing across the tables to avoid delete/addition anomalies.
When creating a series of tables related to a subscriber, is there a proper order for creation of the tables?
MUST associated rows in other tables be deleted when the “base” table entry is deleted?

Longer than you probably wanted, but hopefully this helps,
David Harrington
[email-masked]

On Oct 29, 2014, at 9:34 PM, Tom Taylor <[email-masked]> wrote:

> Attached find a table of proposed new names, in PDF and Open/LibreDocument format. Comments? This is in response to Issue 009, "Review all names taking account of criteria in Tickets: #17, RFC 4181, and details of DBH review".
> 
> http://trac.tools.ietf.org/wg/behave/trac/wiki/MibIss009
> 
> You'll note that I have anticipated responses to other issues at various points.
> 
> Tom
> 
> <MIB name mapping.pdf><MIB name mapping.odt>