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