Re: NGDSL-LINE MIB Thoughts
"Clay Sikes" <[email protected]>
| Newsgroups | gmane.ietf.adslmib |
|---|---|
| Message-ID | <[email protected]> |
Hi Menachem, My primary objective was to provoke some thought as to how to achieve flexibility should the module be applied to VDSL2 or Quad-Spectrum ADSL in the future. I think that objective was achieved. I agree the third option is way out there and may not be the right thing to do. It does put more of a burden on the instrumentation effort to ensure values entered are legal. Should the ranges or limits on objects need to be extended in the future, the important thing is to select a mechanism that would facilitate that process quickly and pass the SMI rules. We don't want to get backed into a corner. I'm certain that you will make an excellent choice. You guys are doing some awesome work! Best Regards, Clay Sikes Zhone Technologies, Inc On 9/22/2005 11:19 AM, [email protected] wrote: > > >Hi Clay, > > The answer to your question regarding using the NGDSL-LINE MIB to >manage VDSL2 lies in Moti's email of the 20/9, he wrote: >"It sounds like the majority in the (DSL FORUM)Operation >and Network Management WG is in favor of having a shared management model >that covers ADSL/2/2plus and VDSL2. This is also the opinion of the ITU-T >G.997.1 editor." Therefore I see the NGDSL-LINE MIB should in the future be >part of the shared management MIB that can >handle all lines ADSL/2/2plus and VDSL2. > > > Regarding the three proposals that you set forward: > The third option is not clear to me. If all restrictions are >removed then while the MIB is future proof, however there is no checking >done on the values entered; which, in my humble opinion, is not really an >acceptable option. Do you agree? > > I would like to confer with the other editors on this issue and >then come back to the Working Group, by Monday, with a date by which option >2, >namely splitting the TC into a separate module, could be completed. If this >delay is short enough I hope that the Working Group Chairs would give >their approval. From the discussion on the list my understanding is that >this is the preferred option (not withstanding the time issue). > >Best Regards, > >Menachem. > > > > > > "Clay Sikes" > <csikes@paradyne To: [email protected], ADSL MIB List <[email protected]> > .com> cc: Clay Sikes <[email protected]> > Sent by: Subject: [Adslmib] NGDSL-LINE MIB Thoughts > adslmib-bounces@ > ietf.org > > > 21/09/2005 20:18 > > > > > >Hi Menachem, > >Are you considering the possibility of using the NGDSL-LINE MIB to manage >VDSL2? That would really be cool. Also, it sounds like there is some work >going on for quad-spectrum ADSL. It sounds like you guys are plugged into >what is happening in the ITU and DSL Forum which is awesome. > >One thing that's interesting is the effect on the ranges for various >objects the different flavors of DSL will have. I mentioned in an earlier >Email, that it might be better to pull out the TCs in a separate module. >Given the choice between having them in the NGDSL-LINE MIB verses a >separate module, the separate module may be a better choice. I think the >whole issue of how to make the NGDSL-LINE MIB as adaptable as possible >should be carefully considered. In fact, it may warrant a discussion with >Bert, Randy, and perhaps a MIB doctor such as C.M. Heard ([email protected]). >It also will have an impact on compliance statements. Some thoughts are >(there may be others that are better): > Keep everything in the NGDSL-LINE MIB and if something needs to be > updated, get a draft out as soon as possible. > I think there is a tendency to frown on implementing drafts, but in > this case, it may be the only thing to do. > Create TCs for all the objects that have ranges such as maximum > nominal aggregate transmit PSD and move all the TC into a > stand-a-lone document. There may be issues with this solution. > Objects that have range restrictions take on the full limit of their > syntax and there could be an informational type of document that IDs > valid ranges for the respective technology. >Basically I'm just trying to provoke some thought that may or may not have >already taken place regarding changes that may require the MIB module to be >updated and how they can occur quickly as the process of updating an RFC is >significant and usually requires and enterprise solution. I worry about >this. May be more than I should. ;-) > >Does this make sense? > >What are your thoughts? > >Regards, > >Clay Sikes >Zhone Technologies, Inc. > > >On 9/20/2005 11:07 AM, [email protected] wrote: > > > > Hi Clay, > > Thanks very much for this email and your other email with > comments on > the Adsl2 draft. Moti is currently at the ATM forum as > he has written to you. Sounds like we will need to add a Vdsl2 > addition to > the Adsl2 MIB once the work on the Adsl2 MIB is completed. > > I will review the Adsl2 draft in light of your comments. > > Thanks again, for your valuable review of the draft, so far. > > Regards, > > Menachem Dodge > ECI Telecom Ltd. > Broadband Access Division > > Tel: +972-3-9268421 > Mobile: +972-54-5788421 > Fax: +972-3-9287342 > > > >-- Paradyne Mail -- > > >_______________________________________________ >Adslmib mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/adslmib > > > > > -- Paradyne Mail --