Subject: [Adslmib] Draft VDSL MIB

From: [email-masked]
Date: Mon, 22 Apr 2002 14:09:18 +0300

There was a little confusion regarding to my email address. If you get the
mail twice please forgive me!
----- Forwarded by Moti Morgenstern/ECI Telecom on 22/04/02 14:07 -----
                                                                                                                                       
                      Moti Morgenstern                                                                                                 
                                               To:      [email-masked]                                                               
                      22/04/02 13:41           cc:                                                                                     
                                               Subject: Draft VDSL MIB                                                                 

Hi,

I was absent for some time from my office (Mid-East problems...)

After a first look I have the following comments :
(1) The MIB refers only to ANSI standards and it should also follow the
work in ETSI and ITU. We already know that there are several differences
between the various specs for ADSL (e.g., The Vendor ID in ANSI is 2 bytes
while in G.992.1 it's 8 bytes) and a similar situation is possible in VDSL.
The IETF MIB should be as much as possible relevant for all standard VDSL
applications.
(2) A mistake. In 4.3 the VdslLineMCMConfProfileTable is listed twice.
(3) A mistake: The description of vendor ID and version number refer to
"Phy[10]", which is a leftover text from RFC 2662.
(4) Why doesn't the MIB include a support for 24 hours counters, as
mentioned in 4.4 and as defined for ADSL and SDSL?
(5) I think that LOF defect is also a source for ES, not only LOS. It
should be corrected in all ES objects of the VdslPerfDataTable.
(6) Isn't it required to count severely errored seconds (SES) and
unavailable seconds (UAS) too as in ADSL and SDSL?
(7) When a LOF or a "lighter" failure is encountered it is certain that the
VTU-R is physically connected and "still there". It makes sense to count
the number of initializations experienced with that specific VTU-R.
However, when a LOS failure is cleared it is probable that the peer VTU-R
is different than the one that was physically connected before. What's the
meaning of counting the number of initializations with such a scenario?
(8) As the VdslLineConfProfileEntry is currently structured you use two
entries in order to configure the line. But, since the TxSpeed of one modem
is the RxSpeed of the peer one, what do you gain from breaking the profile
into two?
(9) Do you really need a row status object per each MCM and SCM related
tables? I think that it also may lead to problems e.g., when part of the
row status objects for any profile are still not in Active state while
other row status objects are already in Active state. (Similarily when
deactivating a profile)  If you had only a single row status, (e.g., for
the "common" table), then it could serve as a common control mechanism
(i.e., a "semaphore") for creating, activating and deleting entries in all
tables that construct the whole "picture" (i.e., profile). How do you make
sure that rows in all tables are "synchronized"?
(10) In 4.6 the reader may, by mistake, understand that there is a
threshold crossing event for the LOL defect (which is not a formal VDSL
defect). The paragraph should be modified to reflect the actual PM counters
tables and the notifications section.

Kind regards,
Moti Morgenstern

Senior System Engineer
Inovia Telecoms Ltd.
Member of the ECI Telecom group
30 Hasivim St.
Petach Tikva, Israel 49133
Tel.: +972-3-9266258 Fax: +972-3-9268182
e-mail: [email-masked]

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib