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

Randy Presuhn <[email protected]> Tue, 7 Jan 2003 14:26:40 -0800 (PST)
Newsgroups gmane.ietf.snmpv3
Message-ID <[email protected]>
Hi -

> Date: Tue, 7 Jan 2003 13:18:18 -0800 (PST)
> From: "C. M. Heard" <[email protected]>
> To: [email protected]
> Subject: Re: coex draft last call -- review of Section 2
> In-Reply-To: <[email protected]>
> Message-ID: <[email protected]>
...
> The first paragraph says that the Integer32 and INTEGER types are
> indistinguishable, so I would expect that INTEGER could be used
> wherever Integer32 could be used, unless a subsequent provision of
> the specification said otherwise.  The second paragraph indeed makes
> such an exception, which is that one is allowed to use enumerations
> with INTEGER but not Integer32.  But I could find is no language in
> RFC 2578 that prohibits using an unconstrained INTEGER.  On that basis
> I concluded that it's legal.
> 
> Now, can you explain to me why that reading is wrong?
...

*I* can't, but 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.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email protected]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------