Re: coex draft last call -- review of Section 2

"C. M. Heard" <[email protected]> Wed, 8 Jan 2003 10:38:11 -0800 (PST)
Newsgroups gmane.ietf.snmpv3
Message-ID <[email protected]>
On Tue, 7 Jan 2003, Randy Presuhn wrote:
> [ ... ] I don't think the real issue here is
> whether naked INTEGER is permitted in an SMIv2 MIB module.
> (Though I happen to believe it is.)
> The context of discussion is the algorithm for translating
> between the languages.  Even if more than one translation
> would be theoretically possible, we should *pick one*,
> ideally the one with the least room for misunderstanding.
> Unconstrained INTEGER -> Integer32 seems to be a very
> reasonable translation rule.

I agree that it would be appropriate for the coex doc to say that
people SHOULD follow the rule unconstrained INTEGER -> Integer32
or unconstrained INTEGER -> INTEGER ( -2147483648 .. 2147483647 )
when converting an SMIv1 information module into SMIv2.

However, I don't think it is appropriate to say that people MUST
do so, because that is not absolutely required to make a valid
SMIv2 information module.  And I think that RFC 2119 backs me up
on this:

 6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with
   care and sparingly.  In particular, they MUST only be used
   where it is actually required for interoperation or to limit
   behavior which has potential for causing harm (e.g., limiting
   retransmisssions)  For example, they must not be used to try to
   impose a particular method on implementors where the method is
   not required for interoperability.

It seems to me that it's in line with this guideline to RECOMMEND
certain translation rules over others in order to minimize confusion,
which is harmful, and which as we've seen in previous messages on
this thread really does happen.  On the other hand, it seems to me
that it is an abuse of the imperative MUST to say unconstrained
INTEGER MUST NOT be used in an SMIv2 module that's translated from
SMIv1 when we don't put the same restriction on a newly-created SMIv2
information modules.

So I still say that right thing to do is to change "MUST" to "SHOULD"
in paragraph (3) of the first numbered list in Section 2.1.1 and to
move this paragraph into the 2nd list in Section 2.1.1 (which is the
list of changes that are desirable but not absolutely required).

//cmh