Re: NGDSL-LINE MIB Thoughts

[email protected]
Newsgroups gmane.ietf.adslmib
Message-ID <OF0BDA1CFA.A582A8E4-ONC2257084.004FA613-C2257084.00543852@ecitele.com>



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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.