RE: GMPLS MIB I-D updates

["Thomas D. Nadeau" <[e-mail]>]

At 05:18 PM 1/25/2002 +0100, Wijnen, Bert (Bert) wrote:
>Inline
> > -----Original Message-----
> > From: Cheenu Srinivasan [mailto:[e-mail]]
> > Sent: Friday, January 25, 2002 4:22 PM
> > To: Thomas D. Nadeau; Wijnen, Bert (Bert)
> > Cc: Joan Cucchiara; [e-mail]; Kireeti Kompella; Vijay Gill;
> > [e-mail]
> > 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.

         That wasn't the idea, sorry if it sounded that way. The point
was that we will change the name to whatever is necessary to get
this work moving forward.   We will use the v2 approach as you
suggested. The only question now is which WG to put these into:
CCAMP or MPLS (see below).

> > 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).

         --Tom



>Bert, again speaking as AD
>
> > 3. We request that these be adopted as WG documents; shortly
> >    thereafter we will reissue them under the correct MIB and document
> >    names.
> >
> > Thanks,
> > Cheenu
> >
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:[e-mail]]
> > > Sent: Friday, January 25, 2002 9:50 AM
> > > To: Wijnen, Bert (Bert)
> > > Cc: Joan Cucchiara; Cheenu Srinivasan; [e-mail]; Kireeti
> > > Kompella; Vijay Gill; [e-mail]
> > > Subject: RE: GMPLS MIB I-D updates
> > >
> > >
> > >
> > >          Hi,
> > >
> > > >Thanks for the posting.
> > > >I have not yet looked at these new MIBs.
> > > >If they are indeed updates or enhancements to the MPLS versions,
> > > >then they should follow the rules/guidelines that we have for
> > > >updating MIB Modules as outlined in RFC2578.
> > >
> > >          The question of what to name the documents is up
> > > to the WG; the co-authors are indifferent on this issue.
> > > Just some background.  The state of the GMPLS MIBs is that they
> > > do indeed extend existing  MPLS MIBs  to facilitate new GMPLS
> > > functions. Specifically, they have been modified to
> > > accommodate longer labels, and a few other things.
> > > However, in the future, additional modifications, features
> > > and functions
> > > may be added that are GMPLS-specific.
> > >
> > > >That is independent of the question of which WG does the work.
> > >
> > >          As I recall, the question of where this work is to be done
> > > was already discussed and decided that it would happen in
> > > CCAMP. However, the ADs, George and Kareeti might want to
> > > verify this for us all. The co-authors are agnostic as to
> > > where the work
> > > gets done; however, the point raised above about the MIBs
> > potentially
> > > changing more for GMPLS-specifics might bias the work to be done
> > > in CCAMP. This is also why we chose the naming of the documents.
> > >
> > >          --Tom
> > >
> > >
> > >
> > > >Bert
> > > >
> > > > > -----Original Message-----
> > > > > From: Joan Cucchiara [mailto:[e-mail]]
> > > > > Sent: Friday, January 25, 2002 1:43 AM
> > > > > To: Cheenu Srinivasan
> > > > > Cc: [e-mail]; Kireeti Kompella; Vijay Gill
> > > > > Subject: Re: GMPLS MIB I-D updates
> > > > >
> > > > >
> > > > >
> > > > > Hi Folks,
> > > > >
> > > > > I would like to raise 2 concerns with having this working
> > > > > group adopt draft-nadeau-ccamp-gmpls-lsr-mib-01.txt (aka
> > > > > GMPLS-LSR-MIB)
> > > > > and draft-nadeau-ccamp-gmpls-te-mib-01.txt (aka GMPLS-TE-MIB):
> > > > >
> > > > > 1) Since these 2 proposed MIBs (GMPLS-LSR-MIB and GMPLS-TE-MIB)
> > > > > are updates to 2 of the MIBs in the MPLS working group,
> > > > > namely the MPLS-LSR-MIB and the MPLS-TE-MIB, I think these MIBs
> > > > > should be proposed in the MPLS working group which is
> > where folks
> > > > > have experience in implementing and using them.  In my
> > opinion the
> > > > > additions for GMPLS to these MIBs is minor and it would
> > be better
> > > > > to stick with the MPLS working group for these MIBs.
> > > > >
> > > > > 2) The choice of names for these MIBs, i.e. GMPLS-LSR-MIB and
> > > > > GMPLS-TE-MIB,
> > > > > does not follow how the IETF names a new version of a MIB.
> > > > > The current trend in the IETF is to use the same name for
> > > > > the draft versions of an existing MIB and differentiate this
> > > > > with the draft title (and eventually a new RFC number).
> > > As examples:
> > > > >
> > > > > draft-ietf-atommib-rfc2558bis-00.txt with MIB name: SONET-MIB
> > > > > draft-ietf-atommib-rfc2496bis-00.txt with MIB name: DS3-MIB
> > > > > draft-ietf-hubmib-etherif-mib-v3-00.txt with MIB name:
> > > EtherLike-MIB
> > > > > draft-ietf-hubmib-mau-mib-v3-00.txt with MIB name: MAU-MIB
> > > > > draft-ietf-snmpv3-update-mib-07.txt with MIB name: SNMPv2-MIB
> > > > > and many others...
> > > > >
> > > > > My biggest concern is that the names of GMPLS-LSR-MIB and
> > > GMPLS-TE-MIB
> > > > > will be confusing and misleading to customers.  Could these be
> > > > > renamed MPLS-LSR-MIB and MPLS-TE-MIB, and thus,
> > accurately reflect
> > > > > what they are?
> > > > >
> > > > > thanks,
> > > > >  -Joan
> > > > >
> > > > > Cheenu Srinivasan wrote:
> > > > > >
> > > > > > We would like to request that these four I-Ds be
> > > adopted as CCAMP
> > > > > > working group documents.
> > > > > >
> > > > > > Thanks,
> > > > > > Tom, Cheenu, Adrian, Tim, Ed
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Cheenu Srinivasan
> > > > > > > Sent: Thursday, January 24, 2002 12:48 PM
> > > > > > > To: [e-mail]
> > > > > > > Cc: Thomas Nadeau (E-mail); Adrian Farrel (E-mail); Tim
> > > > > Hall (E-mail);
> > > > > > > Ed Harrison (E-mail)
> > > > > > > Subject: GMPLS MIB I-D updates
> > > > > > >
> > > > > > >
> > > > > > > The following I-D updates have been posted:
> > > > > > >
> > > > > > >   draft-nadeau-ccamp-gmpls-tc-mib-01.txt
> > > > > > >   draft-nadeau-ccamp-gmpls-lsr-mib-01.txt
> > > > > > >   draft-nadeau-ccamp-gmpls-te-mib-01.txt
> > > > > > >   draft-nadeau-ccamp-gmpls-label-mib-01.txt
> > > > > > >
> > > > > > > They are aligned with each other and have been verified to
> > > > > > > compile cleanly with smilint.
> > > > > > >
> > > > > > > They should appear on the IETF's site shortly. Copies are
> > > > > > > attached for your reference.
> > > > > > >
> > > > > > > Cheenu
> > > > > > >
> > > > >
> > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------
> > > Mathematics is the supreme nostalgia of our time.
> > >
> > >
> >



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.