RE: GMPLS MIB I-D updates

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

> >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?
> 
>          I don't see the new MIBs as obsoleting the v1 MIBs.
> The existing MPLS MIBs will continue to be perfectly
> valid for existing implementations, as well as future ones that do not
> want to have anything to do with GMPLS. These MIBs have been around
> for over 3 years now, and are fully cooked for "classic" MPLS. There
> are many implementations that support them. Disregarding them now so
> that we can wait for GMPLS-related functions will delay them 
> for several more years. The vendors and operators that I work and 
> interact with want the existing MPLS MIBs to become RFCs ASAP.
> 
>          The new v2 MIBs need to support the new GMPLS functions
> as well as existing MPLS functions (since GMPLS is based on MPLS),
> and I think there is sufficient reason for to stand on their own
> while leaving the first versions of these MIBs as RFCs.
> 
OK, that sounds plausible. 

BUT......

Then I think you should try and duplicate as few objects from the old
MPLS MIBs as possible. So only new stuff that is needed should be in
the GMPLS MIBs. If Someone needs both MPLS and GMPLS MIB funcrtionality,
they then implement both the MPLS MIBs and the GMPLS MIBs.

I think that that means that you should not consider them as version2 
of the MPLS MIBs, but as MIBs that provide GMPLS function only.

Bert
>          --tom
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------
> Mathematics is the supreme nostalgia of our time. 
> 
>