Hello Veena and Naren,
Thank you for insisting on the second issue (minor comment #2).
You're right and the mistake will be corrected.
For the first issue. I think the problem is that RFC2662 does not
reference any ITU-T standard and is based on DSL Forum
TRs that did not refer to ITU-T at that time.
For new DSL technologies the DSL Forum decided to change
the management model and follow ITU-T G.997.1.
If we experience hard-times (as you noticed) in stating the right
references near each MIB object, think about putting a PM
counter such as LOL which (to the best of my knowledge)
has no reference in any DSL standard.
Regards,
Moti Morgenstern
<narendranath.nai
[email protected]>
To
07/06/2006 09:00 <[email protected]>,
<[email protected]>
cc
<[email protected]>
Subject
RE: [Adslmib] Comments on ADSL2
internet draft
Hello Moti and Scott,
Many thanks for the clarifications. Basically, we do get it that at this
point of time you accept only errors. Here we are summarizing our
responses to only those points for which we felt we were not clear
enough initially.
Ref.: comment nr. 5
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.
V & N: I will rephrase our question: G992.1 (ADSL) uses G997.1 for
modeling performance counters; so does G992.3, G992.4 and G992.5.
Basically, the different flavours of DSL refer to the same standard for
modeling PM counters.
In ADSL MIB RFC2662, the above mentioned counters were modeled. This we
had found to be useful. Our question is why did you decide not to model
these for ADSL2 MIB? Anyway even for ADSL (G992.1) too ITU-T mentioned
nothing about these counters.
Ref.: minor comments nr. 2
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.
V & N: The object 'adsl2SCStatusActAtp' stands for Actual Aggr. Transmit
Power. In the REFERENCE section for this object, you refer to PSD. As I
understand PSD is different from Aggr. Transmit Power. The correct
sections of G997.1 you should be referring to are:
7.5.1.16 & 7.5.1.17
Regards
Veena, Naren
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Monday, June 05, 2006 8:35 PM
To: Veena Naidu (WT01 - Broadband Networks)
Cc: [email protected]; Narendranath Nair (WT01 - Broadband Networks)
Subject: Re: [Adslmib] Comments on ADSL2 internet draft
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
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.
www.wipro.com
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.