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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> On Thu, Oct 02, 2003 at 09:03:50AM -0700, C. M. Heard wrote:
> > > 
> > > 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...
> > 

Another way to side step it is to rename the TCs in my document
I can name them
  VlanIdentifier
  VlanIdentifierOrAny
  VlanIdentifierOrNone

A quick check seems to indicate they have not yet been used in
IETF MIB modules.

comments?
 
> > 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.
> 
> So what is your suggestion how RFC 2674 should pick up the new TCs? Or
> is your suggestion to leave RFC 2674 alone?
> 
And with my suggested approach above we can leave 2674 alone till
it needs to be opened for other reasons.

Bert
> /js