RE: GMPLS MIB I-D updates

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

> > > 2. We believe CCAMP is the appropriate place to continue this
> > >    work since the extensions are completely GMPLS related. This was
> > >    discussed in Salt Lake City and (we thought) agreed upon but
> > >    we would like to hear the chairs'/AD's word on this.
> > >
> >If the MIBs are GMPLS specific, in which case they would
> >probably conatin a set of AUGMENTing tables to the MPLS MIBs,
> >then they may belong in CCAMP. If they are changing (i.e.
> >just repeating and adding new objects) the base tables in the
> >MPLS MIBs, then it seems to me that they may also belong in the
> >MPLS WG. I'd like to hear from author how they want to approach
> >adding GMPLS management objects to the MPLS MIBs. Then I want
> >to hear from WG chairs how they are reading consensus on what
> >to do and where to do it.
> 
>          The AUGMENTS approach was originally thought though
> (I think that we sent you email on this, but maybe not). The
> conclusion was to not AUGMENT the existing MIBs because the
> indexing of many of the existing tables used the MPLS label. Since
> GMPLS allows for labels of much greater length, we could not
> use this approach, and thus decided to write new tables that
> were as close as the old ones as possible so as to preserve existing
> implementations, but to also facilitate GMPLS functions (existing and
> future).
> 
So that to means you will obsolete the MPLS MIBs at that time.
And tat means you recycle at Proposed Standard.
So maybe you are to quick trying to get the current set of MPLS
MIBs approved as PS?

Bert