RE: MIB Doctor Review of draft-ietf-hubmib-rfc3636bis-05 .txt

On Tue, 17 Oct 2006, Wijnen, Bert (Bert) wrote:
> I personally prefer it if we add OBJECT clauses to the MODULE-COMPLIANCE
> to list the old enumerations as minimal requirement (i.e. the newly
> added labels will not yet be supported by earlier implementations
> who claimed compliance with current MODULE-COMPLIANCE statements.
> 
> I know that Mike believes such is not needed for read-only objects.
> I agree that it is not a fatal flaw if we do not add them for the
> read-only objects. The WG has seen this document several times now,
> so I assume WG consensus is to leave MODULE-COMPLIANCE as is.

Since Bert has fairly and accurately stated my position, I'll leave
it to other folks to comment on whether they do or do not wish to
see the MODULE-COMPLIANCE statements updated.  There are a couple of
points that I think should be considered, however.

The first point is that the new named bits and/or enumerated integer
values are in TCs that are housed in an IANA-maintained module.
Those TCs are expected to have more new stuff added in the future
without making any changes to the base module -- in particular
without changing the compliance statements.  The expectation, I
think, is that an implementation will support the subset of values
appropriate to the MAU types it actually supports.  If a need is
seen to make this more explicit, OBJECT clauses that say this in
their descriptions might be a better way to go than putting in
SYNTAX refinements that just capture the values that were defined at
the time RFC 3636 was published.

The second point is that one of the objects that now has an
opened-ended set of values is ifMauAutoNegCapAdvertisedBits, since
it's now covered by an IANA-maintained TC.  In the review I said
this (buried deep in the fine print :)

| NOTE: although no new autonegotiation capabilities were instroduced
| in this draft, the comments made above for IANAifMauTypeListBits
| stating that new bit positions need not start on a new byte applies
| also to IANAifMauAutoNegCapBits.  There is never an ambiguity for
| the read-only objects ifMauAutoNegCapabilityBits and
| ifMauAutoNegCapReceivedBits, and a management station can always
| update ifMauAutoNegCapAdvertisedBits by retrieving the value of
| ifMauAutoNegCapabilityBits, resetting bits in the returned value
| that correspond to capabilities that should not be advertised, and
| then writing the result to ifMauAutoNegCapAdvertisedBits.

I think it's clear from the above that I think the document as it now
stands provides implementors with sufficient information to "do the
right thing";  but other folks might not see it that way.

Thanks

Mike