Re: GMPLS MIB I-D updates

["Adrian Farrel" <afarrel@movaz.com>]

Thanks Bert,
I don't think Cheenu meant to suggest that the authors would decide, rather that
we would like to be guided by ADs/chairs and act accordingly.  You have now
guided us!

With regard to new/overlapping material.  We did go through the
augments/extends/replaces issue at the last couple of IETFs, but would be
pleased to revisit it.

In summary, there is a lot of material in the GMPLS MIBs that is "identical" to
that in the MPLS MIBs.  The intention so far has been to produce a 'version 2'
of the MPLS MIBs that can support MPLS on its own,  GMPLS on its own, or both at
once.  This v2 MIB would replace the existing MIB in implementations that were
interested in GMPLS and would be the base MIB for new implementations of MPLS or
GMPLS.  At the same time, a lot of thought has gone into easing the migration
path for existing implementations.

As always, we look for guidance and opinions.

Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com
> > -----Original Message-----
> > From: Cheenu Srinivasan [mailto:cheenu@paramanet.com]
> > Sent: Friday, January 25, 2002 4:22 PM
> > To: Thomas D. Nadeau; Wijnen, Bert (Bert)
> > Cc: Joan Cucchiara; ccamp@ops.ietf.org; Kireeti Kompella; Vijay Gill;
> > swallow@cisco.com
> > Subject: RE: GMPLS MIB I-D updates
> >
> > Just to reiterate the authors' view:
> >
> > 1. We can change the MIB/doc name to whatever the WG/chairs/ADs think
> >    is appropriate.
> >
> You can change the docname to whatever you want.
> You can even change the MIB name to whatever you want.
> But if you want this document to be a ever considered for standards
> track, then you better follow the rules as outlined in RFC2578 on
> how you can extend MIB Modules.
>
> And even if you claim that this is just a GMPLS MIB and then
> when I find a lot of duplictae/overlapping information, even then
> it will not go on the standards track. I am quite convinced that I
> can convince my IESG collegues to not approve.
>
> Sorry of this sounds too managerial... but your remark above seems
> to sound as if you have all the authority to decide on this.
>
> Bert, speaking as AD.
>
> > 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.
>
> Bert, again speaking as AD