Re: Last Call: Textual Conventions for Internet Network Addresses to Proposed Standard

["C. M. Heard" <heard@pobox.com>]

[ Apologies for the length.  Follow-up to mibs@ops.ietf.org, please. ]

On Fri, 2 Nov 2001, The IESG wrote:

> The IESG has received a request from the Operations & Management Open
> Area Working Group to consider Textual Conventions for Internet Network
> Addresses <draft-ietf-ops-rfc2851-update-05.txt> as a Proposed
> Standard.  This action will obsolete RFC 2851.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by November 28, 2001.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ops-rfc2851-update-05.txt

While conducting a review of a MIB module that uses the textual
conventions in this draft I have found some problems with the
text describing the ordering constraints between the registration
OIDs of InetAddress and InetAddressPrefixLength objects and the
registration OID of the InetAddressType object which serves as
their type discriminator.  I have also come to the conclusion
that these OID registration constraints can lead to some awkward
MIB designs, and so I question whether they are a good idea.

First let me describe the problem with the text describing the
registration OID ordering constraints.  I'll start by quoting the
relevant text.  The InetAddress DESCRIPTION clause says that

   An InetAddress value is always interpreted within the
   context of an InetAddressType value. The InetAddressType
   object which defines the format of the InetAddress
   value MUST be registered before the object(s) which use
   the InetAddress textual convention. If multiple
   InetAddressType objects are registered before the
   InetAddress object(s), the closest one applies.

and the InetAddressPrefixLength DESCRIPTION clause says that

   An InetAddressPrefixLength value is always interpreted
   within the context of an InetAddressType value. The
   InetAddressType object must be registered before the
   object which uses the InetAddressPrefixLength textual
   convention.

The meaning of "registered before" is defined in Section 4, "Usage Hints":

   The InetAddressType object must be registered before the InetAddress
   object(s) or InetAddressPrefixLength object(s).  In other words, the
   object identifiers for the InetAddressType object and the InetAddress
   object MUST have the same length and the last sub-identifier of the
   InetAddressType object MUST be less than the last sub-identifier of
   the InetAddress object.  This rule allows programs such as MIB
   compilers to identify the InetAddressType of a given InetAddress or
   InetAddressPrefixLength object by searching for the InetAddressType
   object which precedes InetAddress or InetAddressPrefixLength
   registration.

I do not believe that this text captures the intent of the authors,
because it does not constrain the relation between the OID
sub-indentifiers other than the last one.  As written, it would
permit an InetAddressType object registered (for example) as
xyzMIB.1.1.2.1.1, to serve as the type discriminator for an
InetAddressObject registered as xyzMIB.1.1.4.1.2.  Such
objects could reside in different tables with unrelated indices,
or one could be a scalar and one could be a columnar object.

If I correctly understood the discussions that took place some
time ago on the mibs@ops.ietf.org list, I believe that it was
intended that the InetAddressType and the corresponding
InetAddress/InetAddressPrefixLength should have the same initial
sub-identifiers, which would automatically require that they all
be scalars or all reside in the same table.  If that is the case,
then the first sentence of the text from Section 4 should be
modified along the following lines:

   The InetAddressType object must be registered before the InetAddress
   object(s) or InetAddressPrefixLength object(s).  In other words, the
   object identifiers for the InetAddressType object and the
   corresponding InetAddress object(s) and/or InetAddressPrefixLength
   object(s) MUST have the same length, all of the sub-identifiers
   except for the last MUST be identical, and the last sub-identifier of
   the InetAddressType object MUST be less than the last sub-identifier
   of the InetAddress and/or InetAddressPrefixLength object(s).

It would also be useful to make it explicit that the words "closest
one" mean.  That could be done by adding another sentence like this:

   If multiple InetAddressType objects are registered before an
   InetAddress or InetAddressPrefixLength object, then the one whose
   registration OID has the largest trailing subidentifier applies.

There is still one small problem.  If a MIB designer leaves a gap
between the InetAddressType registration OID and the corresponding
InetAddress and/or InetAddressPrefixLength objects, and a new
InetAddressType object is inserted in that gap in a subsequent revision
of the MIB, then the existing InetAddress and/or InetAddressPrefixLength
objects will be associated with a different type discriminator than
before.  This would be an illegal (non-backward-compatible) change of
semantics, and should be forbidden.  That could be done by additional
words along the following lines:

   Note:  MIB module maintenance activities MUST NOT cause a different
   InetAddressType object to be associated with existing InetAddress
   and/or InetAddressPrefixLength objects (for example, by registering
   a new InetAddressType object after an existing InetAddressType and
   before existing InetAddress and/or InetAddressPrefixLength objects).

The InetAddress and InetAddressPrefixLength DESCRIPTION clauses should
then be modified to refer to the Usage Hints in Section 4.  Or better
still, the text could be put right in the DESCRIPTION clauses (where
an implementor is sure to read it).

                                ==0==

The comments above are simply to ask that the text describing the
registration ordering constraints be clarified (assuming that the
proposed clarifications are consistent with the intent of the authors).
However, I would also like to question whether these constraints are
a good idea in the first place.

My motivation for looking at <draft-ietf-ops-rfc2851-update-05.txt> was
that I was asked to review a MIB module that uses the textual conventions
therein.  That MIB module has one table indexed by an InetAddressType and
an InetAddress object, and two subordinate tables (with these indices as
well as others) that contain additional InetAddress objects.  In each
case the InetAddress objects in a given row of a subordinate table are
necessarily of the same type as the objects in the corresponding
row of the main table, and so no additional InetAddressType objects
were supplied.  However, this usage is not legal under the rules in
<draft-ietf-ops-rfc2851-update-05.txt>, either with or without the
clarifications proposed above [without the proposed clarifications
the legality depends on some accidents of OID assignments].  Fixing
this would require adding auxiliary objects to the subordinate
tables that correspond to (and have the same values as) the main
table indices -- much as was done in many early SMIv1 MIBs.  This seems
like a step backward to me.  Do the registration constraints really
add enough value to make up for stuff like this?  Frankly, I think
it would be better if the registration constraints were eliminated
(or were turned from MUSTs into SHOULDs) and designers were required
to specify in the DESCRIPTION clauses of InetAddress and
InetAddressPrefixLength objects which InetAddressType object serves
as the type discriminator.

Mike