Re: Please review and comment: draft-ietf-ops-vlanid-tc-mib-00.tx t

["C. M. Heard" <heard@pobox.com>]

On Thu, 2 Oct 2003, Juergen Schoenwaelder wrote:
> On Thu, Oct 02, 2003 at 04:55:55PM +0200, Wijnen, Bert (Bert) wrote:
> > 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...

This approach would solve the "legal" problems but it does
have some significant drawbacks:

- It's necessary to re-spin RFC 2674.  Bert has suggested an
incremental update as one way to get around this.

- It causes any module that imports VlanID and kin to depend
normatively on the P-BRIDGE-MIB.  The upshot would be that absent a
variance of some kind, no module importing VlanID and kin could
advance on the standards track faster than P-BRIDGE-MIB.  That's not
desirable, because changes to things that are unrelated to  VlanID
and kin could hold back advancement.

Unless we decide to reform the standards process I think this second
disadvantage is a good reason to have VlanID and kin in a separate
stand-alone MIB module.  We would recognize that in this case we are
breaking our rule on uniqueness of descriptors for a good reason.

In any case, it should be noted that while it would be legal from an
SMIv2 point of view to replace Integer32 (1..4094) by VlanID in the
SYNTAX clause RFC 2613's definition of smonVlanIdStatsId, doing
would prevent that RFC from advancing faster than the module from
which VlanID was imported.  My understanding is that RFC 2613 was
recently submitted for advancement to DS without revision.

Mike