|
|
Hello All,
Does anyone have any comments regarding the issues that Naren
has put forward and Moti's responses?
In particular please look at item #1 as Moti has requested some more
opinions on this issue.
Are there any other comments on the Vdsl2 draft?
Thank you kindly.
Best Regards,
Menachem
-----Original Message-----
From: Moti Morgenstern [mailto:Moti.Morgenstern@xxxxxxxxxxx]
Sent: Tuesday, September 26, 2006 10:25 AM
To: narendranath.nair@xxxxxxxxx; adslmib@xxxxxxxx
Subject: RE: [Adslmib] Comments on draft-ietf-adslmib-vdsl2-01
Hi Naren,
Thank you for your comments.
Here are my answers:
(1) Organization of xdsl2ProfileLine group
------------------------------------------------------------
I understand that you actually refer to the object identifiers, i.e.,
the MIB branches.
The xdsl2ProfileLine branch currently has 3 configuration tables which
all are on the line level
(i) The line configuration template,
(ii) The line configuration profile, and
(iii) The line configuration template
If I understand you correctly you propose to separate the templates from
the other two line tables.
I don't have any objection to this, but I would be happy to hear more
opinions (especially from
the other editors)
2) RaRatios could be part of the channel conf profile
------------------------------------------------------------------------
--
At first glance it seems correct, and we had the same debate when
started the ADSL2 MIB.
We understood that the ratio is an attribute that belongs to the
relationships among a given
set of profiles and it is not part of the profile itself.
For example, in case channel profile X represents a service, then
profile X can be used
in a single channel configuration (its ratio will be set on the template
level to 100%), or
together with another channel Y (the two ratio values for X and Y will
be set on the template
level so that they sum to 100%), etc.
(3) Actual INP and INP reporting mode
-------------------------------------------------------
Correct
(4) consistent abbreviations
---------------------------------------
>From my p.o.v. it's a minor issue but ... OK, let's correct that.
(5) INPMIN for 8.625kHz
-----------------------------------
We need to add separate INPMIN8 (d/s and u/s) attributes to the table.
In that occasion, it seems reasonable to add a separate textual
convention for those (i.e.,
without the 1/2 symbol)
(6) Per band measurements
----------------------------------------
My proposal is having a table for the measurements with a row per band
and also with a row for the line level (u/s and d/s). See below.
(7) SNR mode
--------------------
(8) Add WT-129
------------------------
Correct
(references)
-----------------
The -01 revision was released before G.997.1 was consented. So, we
sure need to review all references.
(Question on line and signal atten)
--------------------------------------------------
My proposal is having a table for the measurements with a row per band
and also with a row for the line level (u/s and d/s).
We can then move there the parameters that currently are listed under
the status table and under the SC status table.
(Minor comments)
--------------------------------------------------
Both are correct
Moti Morgenstern
Senior Systems Engineer
ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
Tel.: +972-3-9266258
Fax.: +972-3-9287342
Cell.: +972-54-5786258
e-mail: Moti.Morgenstern@xxxxxxxxxxx
-----Original Message-----
From: narendranath.nair@xxxxxxxxx [mailto:narendranath.nair@xxxxxxxxx]
Sent: Wednesday, September 20, 2006 4:59 PM
To: adslmib@xxxxxxxx
Subject: [Adslmib] Comments on draft-ietf-adslmib-vdsl2-01
Hi,
Please find my comments attached. I have used the following documents as
reference during my review:
WT-129
G.997.1 (06/2006)
Regards
Naren
Comments on draft-ietf-adslmib-vdsl2-01
---------------------------------------
1) Organization of xdsl2ProfileLine group looks strange:
xdsl2LineConfTemplateTable has pointers to both line and channel
profile, so in my opinion it is best to keep this outside
xdsl2ProfileLine group.
Proposed structure:
xdsl2Profile
+
|
+--xdsl2ProfileTemplate
| +--xdsl2ProfileConfTemplateTable
|
+--xdsl2LineProfile
| +--xdsl2LineProfileTable
| |
| +--xdsl2LineProfSpecModeTable
|
+--xdsl2ChannelProfile
| +--xdsl2ChannelProfileTable
|
+--xdsl2AlarmConfProfile
| +--xdsl2AlarmConfProfileTable
|
2) xdsl2LConfTemplateTable:
a) RaRatios can be put under channel conf profile itself, any reason
why it is put separately?
3) xdsl2ChannelStatusTable : MIB objects for Actual INP and INP
reporting mode are not modelled.
4) Use consistent abbreviations (as described in RFC4181) - Change
xdsl2LineCnfgTemplate to xdsl2LineConfTemplate; similarly,
xdsl2LineAlarmCnfgTemplate to xdsl2LineAlarmConfTemplate;
5) This is regarding MIN INP for systems using 8.625kHz subcarrier
spacing. In the description of xdsl2ChConfProfMinProtectionXs mention
that for systems using 8.625kHz subcarrier, 1/2 symbol is not valid.
6) Per band Line Attenuation and Per band Signal attenuation are not
modelled.
7)Actual Down/Upstream Signal-To-Noise Ratio mode (sec. 7.5.1.15 and
7.5.1.18 of G.997.1) are not modelled
8) TR-129 (actually WT-129 now, but in letter ballot) can be included in
the reference section.
I know that references are to be re-visited, however, some pointers from
my side:
*) REFERENCE section for xdsl2ChConfProfMaxBerDs,
xdsl2ChConfProfMaxBerUs is not correct. The correct section in G.997.1
is paragraph 7.3.2.6.
*) In the DESCRIPTION section of xdsl2LineCnfgTemplate &
xdsl2LineAlarmCnfgTemplate, the reference to TR-129 is incorrect, there
is no 5.1.1 section in TR-129.
*) REFERENCE section for xdsl2LineStatusPwrMngState refers to 7.5.1.2 of
G.997.1, this is incorrect, the right section is 7.5.1.5
*) REFERENCE section for xdsl2SCStatusSigAtten is not correct. Sec.
7.5.1.9 of G.997.1 refers to per band line attenuation (LATNds)
*) REFERENCE section for xdsl2LineStatusLnAttenDs and
xdsl2LineStatusLnAttenUs are not correct.
Question: Line Attenuation and Signal Attenuation parameters are defined
in G.997 & TR-129 only on a per-band basis. I am of the opinion that
signal and line attenuation should be modelled at the live level too.
How do we handle this?
Minor / Cosmetic comments
-------------------------
In the description of xdsl2LInvSystemVendorId, change 'The ATU System
Vendor ID ...' to 'The XTU system Vendor ID ...'
Page 51, capitalize reference to standard in para 3 -> change '... per
[g.992.5] ...' to '... per [G.992.5] ...'
--
Narendranath Nair
Lead Architect, Network Management,
Wipro Technologies, Keonics Electronics City,
Bangalore - 560 100, India
Tel: +91-80-28520408 Ext. 85338
_______________________________________________
Adslmib mailing list
Adslmib@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/adslmib
_______________________________________________
Adslmib mailing list
Adslmib@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/adslmib
_______________________________________________
Adslmib mailing list
Adslmib@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/adslmib
|
|