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