[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Textual Conventions for Internet Network Addresses to Proposed Standard
Mike, thanmks for your carefull analysis and also for
the proposed text changes. I believe that this topic was
(at least parially) mentioned by another commenter too
(not sure if it was done on the public mailing list).
Anyway... I am sure that the MIB authors/ediotrs will
consider your comment. Let us see what answer they come
up with to address your concerns/comments. Hopefully
that will happen early this week, so that I can take
that input into the IESG meeting.
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Saturday, November 24, 2001 10:21 PM
> To: mibs@ops.ietf.org
> Cc: iesg@ietf.org
> Subject: Re: Last Call: Textual Conventions for Internet Network
> Addresses to Proposed Standard
>
>
> [ 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-upd
> ate-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
>
>