RE: Comments on draft-ietf-adslmib-vdsl2-01

Hi Clay,

Thanks for your comments which should be considered for the next
revision.
However, the first comment deserves a separate explanation with multiple
points.
1) You say: I'm confused as to when I should use this module
------------------------------------------------------------------------
-----------------
There are two MIBs we develop for equipment that supports ADSL/ADSL2
and ADSL2+ only. Both are based on G.997.1
One MIB, however, supports ONLY those 3 families and not the VDSL2.

So, when "I should use this module"? The decision is very obvious!

The "new" MIB will be selected by an operator that has VDSL2 lines in
the network (or plan to add that technology) and wishes to manage all 
kinds of DSL lines by a single MIB. If he selects this MIB then all
lines
will be classified with the same ifType=VDSL2 (which is TBD) 

The MIB defined in draft-ietf-adslmib-adsl2-08.txt will be selected by
an
operator that does not implement VDSL2 technology in his network. If 
he selects this MIB then all lines will be classified with the same 
ifType=ADSL2 (230). 

By using draft-ietf-adslmib-adsl2-08.txt the operator that does not need
VDSL2 at all can get rid of many MIB objects that their syntax in the 
newer MIB is adapted to support BOTH the ADSL/2/+ and the VDSL2
families. 

Few examples: 
The 4 sub-carriers group objects are introduced in the newer MIB to 
serve for VDSL2 only. But, even if you implement the MIB for ADSL/2/+
only you cannot omit them. The draft-ietf-adslmib-adsl2-08.txt MIB 
does not mention sub-carriers groups at all. 
In the draft-ietf-adslmib-adsl2-08.txt MIB MIB objects that deal with 
sub-carriers are shorter and can be contained in a single table (rather
than two in the new MIB). It has shorter PSD masks, shorter sub-carriers
masks, etc.

2) "Could this ID and the adsl2 ID be combined"?
----------------------------------------------------------------------
The editors considered this issue when started the work. As described
above the problem is not with objects that are technology specific but 
mainly with textual conventions and objects that are adapted to support
ALSO VDSL2 and the operator is forced to implement them even if he
does not have VDSL2 lines. Few examples were provided above. 

Regards,
Moti Morgenstern
 
 

-----Original Message-----
From: Clay Sikes [mailto:[email protected]] 
Sent: Saturday, October 14, 2006 10:19 PM
To: IETF ADSL MIB Working Group
Subject: [Adslmib] Comments on draft-ietf-adslmib-vdsl2-01

Hi,

I have taken a first pass through the ID and have the following
comments:

   1. It looks like this MIB module can also be used for managing ADSL, 
ADSL2, and ADSL2+ lines.  I'm confused as to when I should use this 
module verses that which is defined in draft-ietf-adslmib-adsl2-08.txt.

The second to the last paragraph on page 4 indicates that I must use 
both draft-ietf-adslmib-adsl2-08.txt and this ID.  Page 51 states that 
this document provides a more comprehensive management model, but I 
wander what is more comprehensive about it vs. adsl2-08 ID (I haven't 
looked at adsl2 ID in quite a while).  There is some discussion in page 
169, Implementation Analysis.

      If I was in a position to implement a MIB module to manage 
ADSL2/ADSL2+, it is not obvious which module I need to implement.  Do we

really need separate MIB modules, or could this ID and the adsl2 ID be 
combined with technology-unique objects separated in their own tables?  
Or could there be something written to provide additional clarification?
   2. May want to add something like <vspace blankLines="xx" /> in page 
5 to get all the figure stuff on the same page.
   3. If this module can be used to ADSL/ADSL2/ADSL2+, shouldn't their 
ifType be listed on page 6?
   4. May want to indicate on page 11, that US0 is band Upstream 0 (010 
to 138khz).
   5. Section 2.7.1 pages 20 and 21: Should the text be indented after 
the bullet like previous pages?
   6. Section 2.7.3, page 21.  Excellent idea on suggesting that it's ok

to align intervals with the wall clock.  Why not take it one step 
further and add an optional DateAndTime object to tables that store 
15-minute and 1-day buckets indicating when the interval was stored?
   7. Section 2.8.2, page 24, bullet 1: Do you really mean to reference 
the adsl2LineAlarmConfProfileTable?  I would expect the reference to be 
to a table in this module such as xdsl2LineAlarmConfProfileTable.
   8. Section 2.8.2, page 24, bullet 2: Couldn't find the 
xdsl2ChAlarmConfProfTable in this module.
   9. Section 2.8.3, page 24 second paragraph and page 25 second 
paragraph: Couldn't find xdsl2LCnfgLineTemplate.  Perhaps these should 
be xdsl2LineConfTemplateTable on page 80.
  10. Section 2.9, page 27, last paragraph: States that counters are 
reset at the beginning of the next interval.  I think some or all of 
these counters are of TC Counter32.  May want to consider making those 
counters of TC Gauge32 such as in the PerfHist-TC-MIB.
  11. Page 52, OID {vdsl2 7} seems to be missing.  Goes from {vdsl2 6} 
to {vdsl2 8}.
  12. Page 52, description for xdsl2LineTable: Description includes 
ADSL/ADSL2/ADSL2+. However, there seem to be a contradiction in that the

same description text restricts the ifType to vdsl2.
  13. Object xdsl2LineCmndAutomodeColdStart, page 56, 2 paragraph: 
Couldn't find xdsl2LConfProfAtuTransSysEna.  Perhaps this is 
xdsl2LConfProfXtuTransSysEna, page 96.
  14. Object xdsl2ChStatusPtmStatus, page 64: I think PTM is Packet 
Transfer Mode.  Should PTM be spelled out on first use, e.g. Packet 
Transfer Mode (PTM)?
  15. Description for the object xdsl2ScalarSCMaxInterfaces, page 65: 
It's not clear what the significance of  wording, "two times the number 
of entries of this attribute."  Perhaps this needs to be reworded.  Is 
it trying to state that the object xdsl2ScalarSCMaxInterfaces specifies 
the maximum numbers in the xdsl2SCStatusTable  along with the maximum 
number of entries in the xdsl2SCStatusMainTable.  That is if the 
xdsl2ScalarSCMaxInterfaces is 20, then the maximum number of entries in 
the xdsl2SCStatusTable is 20 and the maximum number of entries in the 
xdsl2SCStatusMainTable is 20?

      Likewise, the object xdsl2ScalarSCAvailInterfaces, page 64: May 
have the same wording issue.
  16. Object xdsl2SCStatusMainEntry, pages 65 and 66: Seems to have a 
contradiction in the desciption. Lists ADSL/ADSL2/ADSL2+, yet seems to 
restrict entries to those which have an ifType vdsl2.  Some objects in 
this table specify ADSL.
  17. Object xdsl2SCStatusEntry, page 72: Couldn't find the 
Hfxdsl2SCStatusEntry specified.  Could this be referring to 
xdslSCStatusEntry?

      Also, there seems to be contradiction in the description. Lists 
ADSL/ADSL2/ADSL2+, yet seems to restrict entries to those which have an 
ifType of vdsl2.
  18. Object xdsl2SCStatusSegment, page 73: Could there be reference to 
where the range of the syntax is derived from?
  19. Object xdsl2SCStatusLinReal, page 73: This seems to be the firs 
place where NS is used.  I wonder of some text should be added to spell 
out that NS refers to the Number of Subcarriers?
  20. Object xdsl2SCStatusLog, page 74: Should UNITS "dB" be added?
  21. Object xdsl2SCStatusSnr, page 75 and 76: Should UNITS "dB" be
added?
  22. Object xdsl2SCStatusTssi, page 77: Should UNITS "-0.5dB" be added?
  23.  Objects xdsl2LineInventoryTable and xdsl2LineInventoryEntry, page

78: Should "inventory of DSL"  be changed to "inventory of the DSL?"
  24. Object xdsl2LineInventoryEntry,  page 78: The entry object 
restricts entries to ifType vdsl2.  Is that what is desired?
  25. Object xdsl2LInvG994VendorId, page 78: References T.35, but it is 
not listed in the references section.
  26. Object xdsl2LineConfTemplateEntry, page 81: Why not prefix the 
index object with IMPLIED so ordering is not based on length?
  27. Object xdsl2LConfTempLineProfile, page 81: Couldn't find 
Xdsl2LineConfProfileTable.  Could this be xdsl2LineConfProfTable on page
87?
  28. Objects xdsl2LConfTempChan1ConfProfile, page 82, 
xdsl2LConfTempChan2ConfProfile, page 83, xdsl2LConfTempChan3ConfProfile,

page 84, xdsl2LConfTempChan4ConfProfile, page 85: Couldn't find 
Xdsl2ChanConfProfileTable.  Could this be xdsl2ChConfProfileTable on 
page 107.
  29. Object xdsl2LConfTempChan1RaRatioDs, page 82: Couldn't find 
Xdsl2ConfTemplateChan1RaRatioDs.
  30. Object xdsl2LConfTempChan1RaRatioUs, page 82: Couldn't find 
Xdsl2ConfTemplateChan1RaRatioUs.
  31. Object xdsl2LConfTempChan2RaRatioDs, page 83: Couldn't find 
Xdsl2ConfTemplateChan2RaRatioDs.
  32. Object xdsl2LConfTempChan2RaRatioUs, page 84: Couldn't find 
Xdsl2ConfTemplateChan2RaRatioUs.
  33. Object xdsl2LConfTempChan3RaRatioDs, page 84 Couldn't find 
Xdsl2ConfTemplateChan3RaRatioDs.
  34. Object xdsl2LConfTempChan3RaRatioUs, page 84: Couldn't find 
Xdsl2ConfTemplateChan3RaRatioUs.
  35. Object xdsl2LConfTempChan4RaRatioDs, page 85: Couldn't find 
Xdsl2ConfTemplateChan4RaRatioDs.
  36. Object xdsl2LConfTempChan4RaRatioUs, page 86: Couldn't find 
Xdsl2ConfTemplateChan4RaRatioUs.
  37. Object xdsl2LineCnfProfEntry, page 87: Why not prefix the index 
object with IMPLIED so ordeing is not based on length?
  38. Object xdsl2LCnfProfRaUsNrmDs, page 90: Couldn't find 
Xdsl2LineConfRaModeDs.  Could this be xdsl2LConfProfRaModeDs on page 90?
      Couldn't find Xdsl2LineConfRaUsTimeDs. Could this be 
xdsl2LConfProfRaUsTimeDs on page 91?
  39. Object xdsl2LConfProfRaUsNrmUs, page 91: Couldn't find 
Xdsl2LineConfRaModeUs.  Could this be xdsl2LCofProfRaModeUs on page 90?
      Couldn't find Xdsl2LineConfRaUsTimeUs.  Could this be 
xdsl2LConfProfRaUsTimeUs on page 91?
  40. Object xdsl2LConfProfRaUsTimeDs, page 91: Couldn't find 
Xdsl2LineCofRaModeDs.  Could this be xdsl2LineConfProfRaModeDs on page
90?
  41. Object xdsl2LConfProfRaUsTimeUs, page 91: Couldn't find 
Xdsl2LineConfRaModeUs.  Could this be xdsl2LConfProfRaModeUs on page 90?
  42. Object xdsl2LCnfProfRaDsNrmsDs, page 92: Couldn't find 
Xdsl2LineConfRaModeDs.   Could this be xdsl2LConfProfRaModeDs, on page
90?
      Couldn't find Xdsl2LineConfRaDsTimeDs.  Could this be 
xdsl2LConfProfRaDsTimeDs on page 92.
  43. Object xdsl2ConfProfRaDsNrmUs, page 92: Couldn't find 
Xdsl2ineConfRaModeUs.  Could this be xdsl2LConfProfRaModeUs on page 90?
      Couldn't find Xdsl2LineConfRaDsTimeUs.  Could this be 
xdsl2LConfProfRaDsTimeUs on page 93.
  44. Object xdsl2LConfProfRaDsTimeDs, page 92: Couldn't find 
Xdsl2LineConfRaModeDs.  Could this be xdsl2LConfProfRaModeDs on page 90?
  45. Object xdsl2LConfProfRaDsTimeUs, page 93: Couldn't find 
Xdsl2LineConfRaModeUs.  Could this be xdsl2LConfProfRaModeUs on page 90?
  46. Object xdsl2LConfProfDpboEsEL, page 99: First use of DPBO (or may 
be xdsl2LConfProfDpboEPsd).  I think this is Downstream Power Back-Off.

Perhaps this should be spelled out on first use.
  47. Object xdsl2LconfProfXdslMode, page 101: Begins with xdsl2Lconf, 
while all the others objects in the table begin with xdsl2LConf.
  48. Object xdsl2LConfProfMaxAggRxPwrUs, page 103: refers to "upstream 
power cutback."  Should the actual object be named?
  49. Object xdsl2ChConfProfileEntry, page 107: Why not prefix the index

object with IMPLIED so ordering is not based on length?
  50. Object xdsl2ChConfProfMinResDataRateDs, page 108: Couldn't find 
Xdsl2LineConfRaModeDs.  Could this be xdsl2LConfProfRaModeDs on page 90.
  51. Object xdsl2ChCnfProfMinResDataRateUs, page 109: Couldn't find 
Xdsl2LineConfRaModeUs.  Could this be xdsl2LConfProfRaModeUs on page 90.
  52. Object xdsl2ChConfProfMaxDelayDs, page 110:  Couldn't find 
Xdsl2ChanStatusActDelay.  Could this be xdsl2ChStatusActDelay on page
63?
      Couldn't find Xdsl2ChanConfMaxDelayDs.  Could this be 
xdsl2ChConfProfMaxDelayDs on page 116?
  53. Object xdsl2ChConfProfMaxDelayUs, page 110: Couldn't find 
Xdsl2ChanStatusActDelay.  Could this be xdsl2ChStatusActDelay on page
63?
      Couldn't find Xdsl2ChanConfMaxDelayUs.  Could this be 
xdsl2ChanProfMaxDelayUs on page 110?
  54. Object xdsl2LineAlarmConfTempEntry, page 114: Why not prefix the 
index object with IMPLIED so ordering is not based on length?
  55. Object xdsl2LineAlarmConfProfileEntry, page 117: Why not prefix 
the index object with IMPLIED so ordering is not based on length?
  56. Object xdsl2ChAlarmConfProfileEntry , page 122: Why not prefix the

index object with IMPLIED so ordering is not based on length?
  57. xdsl2PMLineCurrEntry, page 124:  Restricts entries to only those 
with ifType of vdsl2.  Is this what is desired?
  58. Seems like there ought to be a set of counters somewhere that are 
of type Counter32 that count since reset (e.g. running counters).
  59. Object xdsl2PMLCurrValidIntervals and 
xdsl2PMLCurrInvalidIntervals, page 125: Seems like these are referring 
to 15-minute intervals.  If this is true, it would seem like they should

have something like "15M" as part of their name.
  60. Seem like many of the couners in the xdsl2PMLineCurrTable reset to

0 when they are moved to the interval when it is completed.  If so, 
shouldn't they be of type Gauge32 such as say PerfCurrentCount or others

in the PerfHist-TC-MIB?
  61. xdsl2PMLineCurrInitEntry, page 130: Restricts entries to only 
those with ifType of vdsl2.  Is this what is desired?
  62. xdsl2PMLineHist15MinEntry, page 132: Restricts entries to only 
those with ifType of vdsl2.  Is this what is desired?
  63. xdsdl2PMLineHist1DayEntry, page 135: Restricts  entries to only 
those with ifType of vdsl2. Is this what is desired?
  64. xdsl2PmLineInitHIst15MinEntry, page 139: Restricts entries to only

those with ifType of vdsl2.  Is this what is desired?
  65. xdsl2PmLineInitHist1DayEntry, page 141: Restricts entries to only 
those with ifType of vdsl2.  Is this what is desired?
  66. Most of the objects are xdsl2 implying VDSL2, ADSL, ADSL2, and 
ADSL2+, yet the confirmance is vdsl2.  This seems confusing.

That's it for a first pass.

Best Regards,
Clay Sikes


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