[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please review and comment: draft-ietf-ops-vlanid-tc-mib-00.tx t
On Thu, Oct 02, 2003 at 04:55:55PM +0200, Wijnen, Bert (Bert) wrote:
>
> > 2. Probably a pointless nit, but why use Integer32 rather
> > than Unsigned32 for types that have explicitly non-negative
> > ranges?
> >
> Aha... a few reasons:
>
> - left over from earlier on where we were thinking to use -1
> a a wild card
> - To potentially allow RFC2613 and RFC2674 to pick up this
> common definition when they revise or advance the documents.
>
> This brings out the fact that RFC2674 already defines a TC
> with a descriptor of VlanId, and so probably we should not do
> that (in fact our guidelines say we cannot). One (we) could
> wonder/discuss if however this time it does make sense to
> keep the duplicate.
The real interesting question is how RFC 2674 should pick up this
definition. Is the idea that they import form the new TC MIB and
just remove their definition? That might break other imports. If
they import and keep the original definition in RFC 2674, you will
have to distinguish the two TCs with the same name, which is likely
to test the quality of MIB parsers.
So perhaps the new TCs should in fact go into an update of RFC 2674
rather than introducing a new module? This would at least side-step
this interesting problem...
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany