Hi,
Thank you for your comments. We (the editors) reviewed them in a conference
call and our response is in-line.
Best Regards,
Moti Morgenstern
Clay Sikes
<[email protected] To: ADSL MIB List <[email protected]>
m> cc:
Sent by: Subject: [Adslmib] Phase 2 Comments on draft-ietf-adslmib-adsl2-01.txt
adslmib-bounces@
ietf.org
20/09/2005 15:54
Hi,
I sent this out last night, but it bounced. Hope it works this time.
Here is another round of comments on the ID. As I continue to look deeper,
I may generate more.
One of the things I really love about this module is the use of the
reference clause. It really goes a long way to eliminate confusion.
Mostly in this phase of review I looked at references.
1. Would it be possible to add a reference to all the TCs?
***
We will add the reference section wherever there is a distinct
reference.
***
2. Where references are used, is it possible to add the title of the
paragraph for both the ITU and the DSL Forum documents?
For example on adsl2LineCmndConfPmsf, "ITU-T G.9971., Paragraph
7..3.1.1.3, `Power management state forced (PMSF)'"
***
As you said the reference section purpose is "to eliminate
confusion". We believe that once you put the paragraph numbers there
is no confusion.
***
3. G.997.1, May 2003, exists as a Normative Reference. Shouldn't
G.997.1, Amendment 1, December 2003, also be listed?
***
We'll add amendment 1 and 2 references and an explanation that
paragraphs may be found in either the G.997.1 or its amendments. This
will also be useful when G.997.1 rev 2 is published and all
paragraphs will be in a single document.
***
4. The DSL Forum TR-90, May 2004 is referenced, but the latest on the
DSL Forum is December 2004.
***
Will be corrected
***
5. Some descriptions have ATU-C and ATU-R while some have ATU?C and
ATU?R. For example, adsl2LineStatusActAtpdDs.
***
Will be corrected
***
6. Some references have a space after the beginning quote. Not sure if
that was desired.
***
Will be corrected
***
7. Data rates through out top out at 50,000,000 bps. Having seen us get
burned on the SHDSL MIB module, I would hate to see is have the same
potential issue here. What if this is reused in some way for VDSL2?
It seems like 0..4294967295 would prevent any potential future issue.
***
To be future proof for VDSL2 we can change it to 200M.
***
8. adsl2LineCmndConfLdsf references G.997.1 paragraph 7.3.1.8.3 which I
couldn't find. Should this be 7.3.1.1.8?
***
Will be corrected
***
9. adsl2LineCmndAutomodeColdStart references paragraph 7.3.1.1.10 which
is in Amendment 1. Not sure if that should be noted.
***
See our answer to #3
***
10. adsl2LineStatusSigAttenUs references G.997.1 paragraph 7.5.1.7.
Should this be 7.5.1.9?
***
Will be corrected
***
11. adsl2LineStatusAttainableRateDs references G.997.1 paragraph
7.5.1. Should this be 7.5.1.12?
***
Will be corrected
***
12. Some descriptions are indented differently. First noticed in
the adsl2ScalarSC group with other following.
***
Will be corrected
***
13. Several references don't take you to a specific section for the
object in the ITU document. It seems like the specific section
should be referenced to remove any ambiguity. For example on
adsl2SCStatusMtime, the reference could be:
REFERENCE "ITU-T G.997.1, paragraph 7.5.1.20.1, `Downstream SNR
Measurement Time (SNRMTds)'
ITU-T G.997.1, paragraph 7.5.1.20.3,
`Upstream SNR Measurement Time (SNRMTus)'"
***
We will put both paragraph numbers, but we do not see the
additional contribution of quoting the exact paragraph title.
***
14. adsl2LConfTempChan2RaRatioDs seems to be missing a "R" as the
first character in the description text.
***
Actually it's channel 3. Will be corrected
***
15. Most objects are in the sequence as Ds followed by Us. In the
adsl2LConfProfTable,adsl2LConfProfMsgMin lists Us followed by Ds.
Not that it hurts anything, it was just unexpected.
***
Actually that's the objects order in G.997.1
***
16. When object have a syntax of come TC, I would consider not
listing the values in the object's description. Keep that
information over at the TC. I suppose this would only be important
if the TCs get put in a separate ID.
***
We are against separating the TCs from the current document. In
such a case we agree that the redundant values list should be
omitted.
***
17. adsl2LConfProfL2Atpr and adsl2LConfProfL2Atprt have the same
description. I think adsl2LConfProfL2Atprt should be 7.3.1.1.9 in
G.997.1, Amendment 1.
***
ATPRT will be corrected
***
18. FecSeconds have "Seconds" spelled out, while the others have
just "s". Not sure that's what is desired.
***
FecSeconds will be changed to Fecs
***
19. What does the "r" represent in adsl2PMrLineCurrInitTable and
adsl2PMrLineCurrInitEntry? It almost seems out of place.
***
Will be corrected
***
20. The description for adsl2PMLHist15MValidInterval asks a
question. Seems like it ought to make an authoritative statement
like, "Indicate whether or not the interval contains valid
information." Ditto on other ValidInterval objects.
***
Will be revised
***
21. The lower case "f" in adsl2PMLCurrInit15MfullInits and
adsl2PMLCurrInit15MfailedFullInits caught my attention when compared
to ShortInits and FailedShortInits.
***
Will be corrected
***
22. The comment "MP line init history 15 Minutes doesn't have a
pretty "---" box around it like the others.
***
Will be corrected
***
23. I didn't see any mention of RFC 3440, in the ID. Seems like
its relationship to the NGDSL-LINE MIB ought to be discussed.
***
We do not refer to RFC3440 which only extends RFC2662.
***
24. There are objects for ATM Data Path Failure objects, but none
for ATM Data Path performance monitoring from G.997.1 paragraph
7.2.4.1.2. Is that what is desired?
***
We decided against including the data path parameters in the MIB
as the ATM management is mainly in RFC2515. However the reason for
including the status attribute in the MIB is for reflecting the NCD (
noCellDelineation ) failure which is not covered by RFC2515.
***
25. I didn't see an object in the MIB for G.997.1, paragraph
7.3.1.1.2. Perhaps the intent is to use ifAdminStatus. I haven't
looked at the discussion text to see if this is discussed.
***
This parameter is relevant only on the T/S-interface. It is not
required on the Q-interface.
***
26. I didn't see any objects in the MIB for G.997.1, paragraph
7.5.1.21.5 and 7.5.1.21.6. Not sure if they are needed or discussed.
***
Will be added
***
Please forgive the nits. I hope this helps.
Best Regards,
Clay
-- 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.