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.
 
 
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.
 
   
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'." 
 
 
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.
    
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) .
 
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.
 
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 managemetn application to name the provision provided.
     (Line index is also unique but not user friendly to display ) .
 
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.
 
 
Question
Why dont we model Static and Dynamic profiles any more (as was done in
RFC 2662)?
 

         
Minor comments:
1.  adsl2LineCmndAutomodeColdStart  ,Page no  45
    The reference should be "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)" 
 
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.

 
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.   
 
5 Page no 86:  adsl2LConfProfMaxNomPsdDs  
    The range according to ITU-t is -60 to -40 dBm/hz 
    instead of -60 to -30 dBm/hz
 
6 Page no 87:adsl2LConfProfMaxNomPsdUs  
    The range according to ITU-t is -60 to -38 dBm/hz 
    instead of -60 to -30 dBm/hz
 
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
 
 
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.
 
 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) 
 
3. It would be good if we could have in the beginning an object diagram
describing the 
   modeling.

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