Hello Veena and Naren,
Thank you for your comments.
Some of the comments lead to changes in the MIB that will be published
under revision -08.
Embedded please find the MIB editors' references to your comments.
Regards,
Moti and Scott
<veena.naidu@wipr
o.com>
To
01/06/2006 15:10 <[email protected]>
cc
[email protected]
Subject
[Adslmib] Comments on ADSL2
internet draft
Hi,
Following are the comments, questions and suggestions we have on the
draft-ietf-adslmib-adsl2-07.txt. Please ignore the disclaimer attached
automatically at the end of this email.
regards
Veena, Naren
Comments:
1.It would be good idea to model Configuration parameters and
operational(current status parameters) separately.
Observation:adsl2LineTable,page no.42
Reason: Say ,Manager wants to get only operation data of all links,if
there is a separate table for operstatus of the line
then he can use GET BULK to all values.So for operations like these it
will be very difficult from Manager perspective.
M.M. & S.B. : The MIB authors did considered separating the configuration
and status objects but agreed to combine them in
order to
reduce table count. Note that DSL Forum TR-090
(5.1.1)
combines them in a single line table and also all
previous
DSL line MIBs did the same.
2. In table adsl2ChannelStatusTable page no 51.
What is the motivation behind modeling two mib objects viz.
Adsl2ChAtmStatus, Adsl2ChPtmStatus
for the data path status? What prevents us from having one parameter
for the dataPathStatus
(the enum values can be different). Having one parameter makes sense,
as a line cannot be
configured in PTM and ATM mode simultaneously.
M.M. & S.B. : Theoretically this could be a single status parameter
but, as the ATM and PTM are different L2 technologies
with different alarm definitions, the MIB editors
preferred
to allow the agent be familiar with ATM (or PTM)
failures
only if ATM (PTM) technology is being used. A special
case
is ADSL lines in which PTM is completely irrelevant.
Should
the channel status parameter in ADSL refer to PTM?
In addition, both attributes do not appear in the
mandatory
section of the module compliance section and hence any
of
them can be omitted.
3. adsl2LConfProfScMaskDs page no 74:
In the description of the parameter, the last line is not correct.
It should be
corrected to ,
"Also note that if NSCds < 512, all bits
i (NSCds < i <= 512) should be set to '1'."
M.M. & S.B. : Correct
4. Why isn't adslType modeled (as in RFC 2662 adslLineTable ,page no 21.)
It would be good (from a management application perspective) to have
an attribute
to indicate whether the line is in fast or interleaved mode.
M.M. & S.B. : In ADSL there were 5 possible setups where in ADSL2 there
are from 1 to 4 channels, each with its own
interleaving setup.
The interleave delay can be set to a low value in
order to
approximate a fast channel.
If working in ADSL mode, The fast and interleaved
channels
can be identified by examining the
adsl2ChStatusActDelay
attribute. Also that the operator can still put the
values Interleave (124) or fast (125) as the ifType of
a channel.
5. I feel we should model 15min and 24hr performance counters for
Loss of Link (LOL)
Loss of Power(LPR)
Loss of Frame(LOF)
Loss of Signal(LOS)
Severely Error Frame(SEF) .
M.M. & S.B. : The performance counters in the ADSL2 Line MIB are per
G997.1. The counters you mention from RFC2662 are not
part of ITU-T model. Use RFC 2662 if you want to just
manage ADSL lines.
6. For Alarmthreshold and profiles tables, it would be good to have a
scalar attribute
that indicates the maximum size of the table like we have
adsl2ScalarSCMaxInterfaces and
adsl2ScalarSCAvailInterfaces.
M.M. & S.B. : The sub carrier status table has a set of scalars to
indicate
its size because it has some very large attributes
and the
indexing of the table suggests that there should be
rows in
this table for every line, which probably is a
requirement far
beyond most embedded systems capability. The profile
tables do not require any special consideration and
hence
do not require a scalar to specify the maximum
number of
entries.
8. It would be better idea to model the "circuit id" attribute, an ASCII
String ,
while provisioning the line.This attribute could be used by the
a network management application to name the provision provided.
(Line index is also unique but not user friendly to display ) .
M.M. & S.B. : You may add such an attribute if you like as a proprietary
attribute. The MIB editors however tried to minimize
such
nonstandard attributes.
In addition, if the DSL line is a virtual bridge
port
it may anyhow need to support such a circuit/remote
id
for DHCP option 82.
9. Was there any reason for not making the "Rate Adaptation Ratio"
attribute
part of adsl2ChConfProfileTable instead of adsl2LineConfTemplateTable.
As actually these are configurable attributes of channel,
so I guess they could be channel profile ?
Reference :Page no 68,90.
M.M. & S.B. : The MIB editors considered the idea and decided that the
attribute should be external to the channel profile
if we
want the channel profile to be reusable.
If you put the attribute as part of the profile then
you need
many identical profiles in which only the RA ratio is
different.
Question
Why dont we model Static and Dynamic profiles any more (as was done in RFC
2662)?
M.M. & S.B. : RFC2662 allows static profiles, one profile per each DSL
line.
All DSL line MIBs afterwards do not support such a
model,
which doesn't make much sense (I.e., Typically
multiple DSL
lines share the same setup)
Minor comments:
1. adsl2LineCmndAutomodeColdStart ,Page no 45
The reference should be "ITU-T G.997.1 Amendment 1, paragraph
7.3.1.1.10"
M.M. & S.B. : Note that though amendment 1 defines the object, the
7.3.1.1.10 is
a paragraph number in G.997.1 (!). So will put there
"ITU-T G.997.1, (amendment 1) paragraph 7.3.1.1.10"
2. adsl2SCStatusActAtp ,page no 65
The reference should have been "ITU-T G.997.1, paragraph 7.5.1.16
(ACTATPds)
and paragraph 7.5.1.17 (ACTATPus)" ,Instead of
ITU-T G.997.1, paragraph 7.5.1.14 (ACTPSDds)
and paragraph 7.5.1.15 (ACTPSDus)"
M.M. & S.B. : The references to ACTATPDs/Us are correct. ActPsdDs/Us
also use the correct references in G.997.1 so the
comment
is unclear.
3. Page no 83: Description of adsl2LConfProfAtuTransSysEna :
According to ITU-T(page no 32),this parameter is only
for near-end ATU .But the decription in draft is depicting both ATUs.
M.M. & S.B. : The object is instanciated per line, as required, and not
per ATU.
4 The Description of adsl2LineStatusLastStateUs/adsl2LineStatusLastStateDs
page no 46 is in complete .
The ITU-U says that "This parameter is available only when,
after a failed full initialization, the line diagnostics
procedures are activated on the line. Line diagnostics procedures
can be activated by the operator of the system
(through the Line State Forced line configuration parameter)
or autonomously by the ATU-C or ATU-R."
This additional info gives developer of Agent ,
who refers this MIB a different perspective.
M.M. & S.B. : We could add the suggested information but at this
phase we only correct errors. Remember that we
still give the reference to the paragraph where
the
suggested text appear.
5 Page no 86: adsl2LConfProfMaxNomPsdDs
The range according to ITU-t is -60 to -40 dBm/hz
instead of -60 to -30 dBm/hz
M.M. & S.B. : Though you are basically right (revision 2 uses the
a different range) we noticed that ITU-T decided
recently to correct the range to -60 to -30. So,
we
thought it is reasonable to use that information
even
if it contradicts the formal text at this moment.
6 Page no 87:adsl2LConfProfMaxNomPsdUs
The range according to ITU-t is -60 to -38 dBm/hz
instead of -60 to -30 dBm/hz
M.M. & S.B. : Same as previous comment.
7 In page no 89 adsl2LConfProfPsdMaskSelectUs
The reference should be "ITU-T G.997.1 (amendment 1),
7.3.1.2.10 instead of 7.3.1.10
M.M. & S.B. : Correct.
Suggestions:
1. It would be better if this draft
has a "System reference model" present in ITU_T
G.997.1.Page no 10. This will give readers of the MIB a clear
idea of the interfaces this MIB is taking about
while describing some of the modeled parameters.
M.M. & S.B. : At this phase we got a permission only to correct errors.
Anyhow, the figure in G.997.1 is not very easy
translated
into the textual format of RFCs.
2. I think we should have the definition of NSC as it is used
extensively in MIB .
NSC - The highest sub carriers index which can be transmitted (i.e.,
sub carrier
index corresponding to Nyquist frequency, see 8.8.1.4). The
parameter can
be different for the ATU-C (NSCds) and the ATU-R (NSCus). Its
value is fixed
by the Recommendation and depends upon the underlying service
(i.e., POTS or
ISDN). Reference from Table 8-4/G.992.3 page no 74)
M.M. & S.B. : We will consider more Naming Conventions in
the VDSL2 MIB.
3. It would be good if we could have in the beginning an object diagram
describing the
modeling.
M.M. & S.B. : We will consider adding such a diagram or a
reference to another document which includes
the diagram as part of the VDSL2 MIB.
_______________________________________________
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.