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. ------------------------------------------------------