[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: GMPLS MIB I-D updates



Bert, Please see comments inline.

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

You misread - I said we would change it to whatever the WG/chairs/ADs
think is appropriate, not what we (the authors) decide. We'll go
through 2578 and get bck to the list about this.

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

We tried the former approach (AUGMENTing the existing tables) but
this turned out to be really messy since there was a need to change
indexing and reorganize information. So, we took the latter approach.