Re: Proposed changes to draft ADSL2 MIB

This file contains follow up comments by Scott Baillie and Umberto
Bonollo regarding our proposed changes to the ADSL2 MIB.



Change 1
--------
Suggested change:
  Moved the 4 channel profile pointers from the adsl2LineConfTemplateTable table
  to the adsl2LineConfProfTable.
Response:
  We suggest that this change be rejected for the following reasons:
Reasons:
  The problem with the configuration profiles as specified in RFC2662, 
  VDSL-LINE-MIB and SHDSL-LINE-MIB is the coupling between the spectrum 
  configuration and the service layer (channels) configuration.
  The rational for changing the model was introduced by Rajesh Abbi 
  (co-editor of VDSL-LINE-MIB and SDSL-LINE-MIB) and is explained in 
  the DSL Forum TR-90.
  Breaking the configuration into line level and channel level profiles, 
  and the creation of a higher level profile (called template) is more 
  adequate for new generation xDSL where the number of channels/service 
  may be up to 4 and the number of service combinations is higher as well. 
  This method allows different service-packages to be configured without 
  requiring profiles to be duplicated in the MIB.
Follow Up Comments from S.B. and U.B.:
  O.K., we understand the new profile model is based on ADSLF TR-090.
  So we can accept your reasons and don't require this change anymore.



Change 2
--------
Description of change:
  Moved the us & ds rate adaption ratio attributes from the
  adsl2LineConfTemplateTable table to the adsl2ChConfProfileTable.
Response:
  We suggest that this change be rejected for the following reasons:
Reasons:
  The rate adaptation ratios do NOT belong to the channel level at all. 
  These ratios apply to the channel COMBINATION. That is, a package with
  one channel can obviously allocate 100% of the excess rate to that 
  channel, while if the same channel/service is defined in another package 
  that allows a second channel/service then part of the excess rate may 
  be allocated to the second channel. It's not a good idea to specify a
  separate full channel profile per each collection of services, or per
  each possible distribution of the excess bandwidth.
  Moreover, if you put these rates in the line configuration 
  profile you then need to duplicate the line configuration profile 
  for each ratio combination. The least "effect" is when the ratio values
  is part of the template that you anyway need to allocate per each 
  service-package.
Follow Up Comments from S.B. and U.B.:
  O.K., we understand the new profile model is based on ADSLF TR-090.
  So we can accept your reasons and don't require this change anymore.


   
Change 3
--------
Description of change:
  Removed the adsl2LineConfTemplateTable table.
Response:
  We suggest that this change be rejected for the following reasons:
Reasons:
  If we do not adopt changes 1 and 2 then adsl2LineConfTemplateTable 
  table has a key-role in the management model.
Follow Up Comments from S.B. and U.B.:
  O.K., we understand the new profile model is based on ADSLF TR-090.
  So we can accept your reasons and don't require this change anymore.



Change 4
--------
Description of change:
  Changed comments for the attributes :
  adsl2LConfProfChan1ConfProfile,
  adsl2LConfProfChan2ConfProfile,
  adsl2LConfProfChan3ConfProfile,
  adsl2LConfProfChan4ConfProfile,
Response:
  We accept the suggested description/comments for those attributes.
  However the attributes should be left as part of the line 
  configuration template.
Follow Up Comments from S.B. and U.B.:
  Agreed - We accept your response in detail.



Change 5
--------
Description of change:
  Merge the contents of the tables :
  adsl2LineStatusTable,
  adsl2LineCommandTable,
  adsl2LineConfigTable
  into one single table ( adsl2LineTable ).
Response:
  The reason we separated the configuration parameters from the status
  parameters and the commands is for clarity of the management model. 
  It's not that a single table cannot include a mixture of read-write 
  and read-only objects, as long as they refer to the same category 
  (e.g., Obviously one expects to see the command result located 
  at the same table where the command resides.) 
  At first glance the proposed merge seems harmless. Initially the 
  status parameters are located in the beginning of the table. Then come
  the command related parameters and finally the configuration parameters. 
  However, assume we need to update the MIB with a new status parameter. 
  This parameter would need to be appended at the end of the table (for
  backward compatibility reason) and that greatly reduces the clarity of
  the MIB. 
  Also we failed to understand why is it important that "some of the old 
  tables were really quite small".
Follow Up Comments from S.B. and U.B.:
  We agree that is unfortunate when MIB attributes are separated within
  the same table but we believe that it is not a strong enough reason
  to introduce 3 tables when only one is needed.
  

Change 6
--------
Description of change:
  Add adsl2LineAlarmConfProfileTable table for performance
  thresholds and data rate change thresholds.
Response:
  Please Clarify this Change:
  We do know that the performance thresholds are currently missing.
  However, to the best of our knowledge the data rate change thresholds
  are already implemented by:
  adsl2ChConfProfUsDataRateDs,
  adsl2ChConfProfDsDataRateDs, 
  adsl2ChConfProfUsDataRateUs, and 
  adsl2ChConfProfDsDataRateUs
Follow Up Comments from S.B. and U.B.:
  We agree that the attributes that you mention in your response
  do represent the data rate change thresholds.
  With our better understanding of the role of TR-090 we no longer
  require the table mentioned above ( adsl2LineAlarmConfProfileTable ).
  As specified in TR-090, the performance thresholds will
  use the new line threshold template table and associated
  line threshold profile and channel threshold profile.
  We are currently designing the new TR-090 based threshold tables
  and will release these shortly.


Change 7
--------
Description of change:
  Add threshold and data rate traps.
Response:
  Accepted as long as we keep traps optional.
Follow Up Comments from S.B. and U.B.:
  We accept that the traps should be optional.


Change 8
--------
Description of change:
  Use standard Textual conventions such as TruthValue instead
  of re-inventing these Textual conventions.
Response:
  Accepted



Change 9   
--------
Description of change:
  Use a OCTET STRING instead of a huge BITS type for the
  sub carrier mask attributes.
Response:
  We understand the argument but still believe this change is 
  unjustified. 
Reasons:
  The sub carrier mask is an entity that has a per-bit meaning. I.e.
  Each bit position refers to a frequency slot, a bin. So, this is 
  more similar to the Adsl2TransmissionModeType (where each bit 
  refers to a mode) rather than to octet strings in which the meaning
  is per an octet, a word or the string as a whole. The naming issue 
  may be resolved by changing the bit names from "bit***" to "bin***".
  If you have an alternative way to express the "per-bit meaning" will
  be glad to adopt a prettier solution.
Follow Up Comments from S.B. and U.B.:
  Using an OCTET STRING instead of a very large BITS type, provides
  a better economy of description.
  If our suggestion is adopted the comments field would need to
  indicate that each bit in the OCTET STRING represents bin-i
  where i increases sequentially from 1 to 512.
  We don't insist on this change but do think it is a prettier
  solution.


Change 10  
---------
Description of change:
  Use the standard index ifIndex rather than defining a
  index of type Unsigned32.
  In the comments, specify the ifType of the interface
  where ifIndex is used.
Response:
  Accepted




Change 11   
---------
Description of change:
  Add an extra index to the subcarrier table adsl2SCStatusTable.
Response:
  This change is not as simple as it seems.
Reasons:
  The ADSL technology is asymmetric. I.e., the string size of most
  attributes in the table is different for downstream and upstream 
  directions. The main issue here is that the upstream related objects 
  should be size limited and you lose this inherent protection regarding 
  the object range as part of performing this change.
  A minor issue (i.e., even if we solved the main problem), is that 
  there is a need to provide a clear description in each object
  for each flow direction. Currently the description provided is only 
  for the downstream direction.
Follow Up Comments from S.B. and U.B.:
  We agree that the inherent protection regarding the object range
  is desirable. However, the size of the OCTET STRINGs already varies
  depending on whether the operating mode is ADSL2 or ADSL2plus.
  In the case of ADSL2, there are 256 downstream sub carriers whereas
  in the case of ADSL2plus, there are 512 downstream sub carriers.
  In light of this, we think that our proposed change is reasonable.


Change 12
---------
Description of change:
  Removed attributes from from adsl2SCStatusTable 
  adsl2SCStatusLnAttenUs
  adsl2SCStatusLnAttenDs
  adsl2SCStatusSigAttenUs
  adsl2SCStatusSigAttenDs
  adsl2SCStatusSnrMarginUs
  adsl2SCStatusSnrMarginDs
  adsl2SCStatusAttainableRateUs
  adsl2SCStatusAttainableRateDs
  adsl2SCStatusActAtpUs
  adsl2SCStatusActAtpDs
Response:
  We suggest that this change be rejected for the following reasons:
Reasons:
  The same attributes list already exists in another table. That's true.
  However, they serve for different functions (which we failed to 
  explain in the first draft). 
  Basically same attributes should be updated either after full 
  initialization or after a DELT. However, we believe that an operator 
  would be happy to preserve the values of the attributes as were after last 
  full initialization, even if another operator executed a DELT. So, we 
  find it worthwhile to have one set of attributes as part of the line status
  table and a separate set of attributes for the DELT. That's why the second
  set is located together with the DELT results. 
  The two sets of attributes do not reflect the same values. I.e., The first 
  set is unaffected by the DELT. We probably need to document this issue 
  inside the MIB.
Follow Up Comments from S.B. and U.B.:
  Accepted. We agree that this issue should be documented inside the MIB.


Change 13   
---------
Description of change:
  Add a row status attribute to the adsl2SCStatusTable table.
Response:
  We suggest reviewing all aspects of the problem and then deciding.
Reasons:
  We fully agree that it is not probable to expect a system to 
  keep all DELT-specific results for all lines all the time.
  Only do see some questions:
  1. Who creates the row? Is it the operator, before issuing the
     command, or the system, as part of processing it?
  2. Who is responsible for deleting the lines:
     a. The operator who originated the DELT? What happens if he
        didn't delete the entry?
     b. Any operator that encounters a memory problem? How does he
        know which entry to destroy?
     c. The embedded system (based on what criteria?)
  3. Must we actually remove the entry or can we provide the user 
     other means
     a. A timeout object optionally configured with the DELT command. 
        If being used then Upon exhausting releases the internal memory
        allocation. Further references to the table with the associated
        link would result in error.
     b. A counter object that provides the age of the results. The 
        operator may decide accordingly if the entry is a "zombie" or
        may still be important for someone.
Follow Up Comments from S.B. and U.B.:
  1. If the row does not already exist at the time the DELT test
     completes, the SNMP agent will create the row automatically.
     However, if the row already exists then the existing row will
     be used. Assuming that a RowStatus variable has been added,
     it would be acceptable for the manager process to 
     create the row before the DELT test.
     The rule that we have just described allows the maximum flexibility.
  2. Key point: Assuming that a RowStatus variable has been added, the manager
     process is responsible for deleting the rows according to any
     application-specific scheme. 
     We propose to use a scalar attribute called adsl2MaxSCStatusEntries.0
     which defines the maximum number of rows in adsl2SCStatusTable.
     If the current number of rows is equal to adsl2MaxSCStatusEntries.0 
     then any attempt to start a new DELT test will fail and the reason
     for the failure will be indicated using a new value called
     tableFull(10) for the adsl2LCmndConfLdsfFailReason variable.
     a. Rows will accumulate if they are not deleted by the manager process.
        If the maximum number of entries has been reached then a new
        DELT test cannot be started due to tableFull(10) as explained above.
     b. The manager process is responsible for deleting the rows according to any
        application-specific scheme. For example, when the DELT test user
        interface screen is closed, the manager process deletes the row.
     c. The embedded system should not be responsible for deleting rows.
        However, rows are volatile and would not persist across an
        agent cold start / reboot.
  3. We don't think any of these suggestions should be implemented
     since we have ruled out any automatic agent deletion of rows.
  4. So far we have assumed that the manager process must somehow
     keep track of which rows to delete. Nevertheless, we could
     add a variable called adsl2SCStatusOwner of type SnmpAdminString
     which could be used as a lock variable that contains values
     such as "Locked", "OwnerName" and where a zero length string
     indicates unlocked and hence OK to delete the row.
  5. Also if you agree, a timestamp attribute (of type TimeTicks) could also be added to
     the row to record the time at which the DELT results were obtained.
     In addition, the time stamp optionally could be used to help select
     which rows to delete.


Change 14
---------
Description of change:
  Added TEXTUAL CONVENTIONS :
  Adsl2Direction
  Adsl2LastTransmittedState
  Adsl2LineLdsf
  Adsl2LineStatus
  Adsl2ChAtmStatus
  Adsl2LConfProfPmMode
Response:
  Basically accepted the change. We also foresee a need to update few 
  of those TCs (e.g., we consider adding the Loss Of Signal Quality
  [LOSQ] to the status).
  


Comment 1
---------
   In general, the wording for DESCRIPTION fields of attributes
   should be cut and pasted and edited from G.997.1
Response:
   G.997.1 is not always a good source for the attribute description.
   So we accept the comment but it should be considered per each 
   attribute.



Comment 2
---------
   Need to add extra clauses to most MIB attributes.
   Clauses needed are :
   UNITS
   REFERENCE
   DEFVAL
Response:
   Correct.