Subject: [Adslmib] Phase 2 Comments on draft-ietf-adslmib-adsl2-01.txt

From: Clay Sikes <[email-masked]>
Date: Tue, 20 Sep 2005 08:54:04 -0400

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.

Would it be possible to add a reference to all the TCs?

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)'"

G.997.1, May 2003, exists as a Normative Reference.  Shouldn't
G.997.1, Amendment 1, December 2003, also be listed?

The DSL Forum TR-90, May 2004 is referenced, but the latest on
the DSL Forum is December 2004.

Some descriptions have ATU-C and ATU-R while some have ATU?C and
ATU?R.  For example, adsl2LineStatusActAtpdDs.

Some references have a space after the beginning quote.  Not sure
if that was desired.

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.

adsl2LineCmndConfLdsf references G.997.1 paragraph 7.3.1.8.3
which I couldn't find.  Should this be 7.3.1.1.8?

adsl2LineCmndAutomodeColdStart references paragraph 7.3.1.1.10
which is in Amendment 1.  Not sure if that should be noted.

adsl2LineStatusSigAttenUs references G.997.1 paragraph 7.5.1.7.
Should this be 7.5.1.9?

adsl2LineStatusAttainableRateDs references G.997.1 paragraph
7.5.1.  Should this be 7.5.1.12?

Some descriptions are indented differently.  First noticed in the
adsl2ScalarSC group with other following.

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)'"

adsl2LConfTempChan2RaRatioDs seems to be missing a "R" as the
first character in the description text.

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.

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.

adsl2LConfProfL2Atpr and adsl2LConfProfL2Atprt have the same
description.  I think adsl2LConfProfL2Atprt should be 7.3.1.1.9 in
G.997.1, Amendment 1.

FecSeconds have "Seconds" spelled out, while the others have just
"s".  Not sure that's what is desired.

What does the "r" represent in adsl2PMrLineCurrInitTable and
adsl2PMrLineCurrInitEntry?  It almost seems out of place.

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.

The lower case "f" in adsl2PMLCurrInit15MfullInits and
adsl2PMLCurrInit15MfailedFullInits caught my attention when compared to
ShortInits and FailedShortInits.

The comment "MP line init history 15 Minutes doesn't have a
pretty "---" box around it like the others.

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.

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?

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.

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.

Please forgive the nits.  I hope this helps.

Best Regards,

Clay

-- Paradyne Mail --

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

---

From: [email-masked]
Date: Wed, 21 Sep 2005 14:54:05 +0300

Hello Clay,

      Thanks very much for your comments. I hope to have these items fixed
in the next draft.

Best Regards,

Menachem Dodge

                      Clay Sikes                                                                                                       
                      <[email-masked]         To:      ADSL MIB List <[email-masked]>                                               
                      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,

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?
   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)'"
   3. G.997.1, May 2003, exists as a Normative Reference.  Shouldn't
      G.997.1, Amendment 1, December 2003, also be listed?
   4. The DSL Forum TR-90, May 2004 is referenced, but the latest on the
      DSL Forum is December 2004.
   5. Some descriptions have ATU-C and ATU-R while some have ATU?C and
      ATU?R.  For example, adsl2LineStatusActAtpdDs.
   6. Some references have a space after the beginning quote.  Not sure if
      that was desired.
   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.
   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?
   9. adsl2LineCmndAutomodeColdStart references paragraph 7.3.1.1.10 which
      is in Amendment 1.  Not sure if that should be noted.
   10.      adsl2LineStatusSigAttenUs references G.997.1 paragraph 7.5.1.7.
      Should this be 7.5.1.9?
   11.      adsl2LineStatusAttainableRateDs references G.997.1 paragraph
      7.5.1.  Should this be 7.5.1.12?
   12.      Some descriptions are indented differently.  First noticed in
      the adsl2ScalarSC group with other following.
   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)'"
   14.      adsl2LConfTempChan2RaRatioDs seems to be missing a "R" as the
      first character in the description text.
   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.
   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.
   17.      adsl2LConfProfL2Atpr and adsl2LConfProfL2Atprt have the same
      description.  I think adsl2LConfProfL2Atprt should be 7.3.1.1.9 in
      G.997.1, Amendment 1.
   18.      FecSeconds have "Seconds" spelled out, while the others have
      just "s".  Not sure that's what is desired.
   19.      What does the "r" represent in adsl2PMrLineCurrInitTable and
      adsl2PMrLineCurrInitEntry?  It almost seems out of place.
   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.
   21.      The lower case "f" in adsl2PMLCurrInit15MfullInits and
      adsl2PMLCurrInit15MfailedFullInits caught my attention when compared
      to ShortInits and FailedShortInits.
   22.      The comment "MP line init history 15 Minutes doesn't have a
      pretty "---" box around it like the others.
   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.
   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?
   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.
   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.
Please forgive the nits.  I hope this helps.

Best Regards,
Clay

-- Paradyne Mail --

---

From: [email-masked]
Date: Mon, 26 Sep 2005 14:28:28 +0300

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                                                                                                       

                      20/09/2005 15:54                                                                                                 

Hi,

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 --