Re: draft-ietf-ops-mib-review-guidelines-01.txt is now available

[Bob Natale <Bob.Natale@AppliedSNMP.com>]

Hi Mike,

>> >2.) No consensus was reached on making it RECOMMENDED to put
>> >external items used by MCs and ACs in the IMPORTS statement, so
>> >(for now) Section 4.4 retains the neutral "MAY" language.
>>
>> It should be a MUST...or an explanation as to why
>> *these* external references are exempt from the
>> otherwise clear requirement (citation given earlier
>> in this thread) that *all* external references MUST
>> be included in the IMPORTs statement.
>
>Specifying it as a 'MUST' would be contrary to the rules of RFC 2580 (see
>below).

If you are referring to this part of 2580:

"5.4.3.  Mapping of the OBJECT clause
...
   By definition, each object specified in an OBJECT clause follows a
   MODULE clause which names the information module in which that object
   is defined.  Therefore, the use of an IMPORTS statement, to specify
   from where such objects are imported, is redundant and is not
   required in an information module."

That is fine...it says that the MODULE clause is effectively an
IMPORTS statement.  No problem at all with that and it does not
at all obviate or diminish the more general and prior guidance
of 2578:

"3.2. IMPORTing Symbols
To reference an external object, the IMPORTS statement must be used to
identify both the descriptor and the module in which the descriptor is
defined, where the module is identified by its ASN.1 module name."

For the record, at least from my perspective, this has nothing to
do with "limitations of specific products" (honestly, I could not
care less from a business perspective)...it has to do with having
clear rules and following them, and where we don't have clear rules
then agreeing to implementing things in an interoperable way that
is consistent with the rules that we do have.

Cheers,

BobN