Re: Proposed changes to draft ADSL2 MIB

This file contains references to a list of the changes suggested by 
Scott Baillie and Umberto Bonollo to the draft MIB 
draft-morgenstern-ngadsl-mib-00.txt.


Change 1
--------
Suggested change:
  Moved the 4 channel profile pointers from the adsl2LineConfTemplateTable table
  to the adsl2LineConfProfTable.

Our 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-edtior 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.

  Example: 
    A short example may help:
    Assume you have a "Bronze" service-package with one channel. 
    According to the suggested "Change 1" the operator creates a line 
    configuration profile for the "Bronze" package and utilizes one of 
    the channel profile "pointers" in it.
    Assume there is a need for a "Silver" service-package with 2 channels:
    the same channel as already in the "Bronze" package and an additional 
    channel.

    "Change 1" Approach:
      In this case the operator has to create for the "Silver" package a 
      new line configuration profile (dozens of objects that contain 
      exactly the same values as in the "Bronze" package). He probably 
      need to create not one but two new channel profiles, as explained 
      later on.
      The two line profiles consume much more memory than in the templates 
      approach which is in version "-00' of the draft MIB. 

    "Template" Approach:
      What happens in the template approach? 
      In the templates approach, adopted by the DSL Forum, the operator 
      creates a line configuration profile for the "Bronze" package.
      The "Bronze" template "points" to the line configuration profile
      and to a channel profile. 
      When the operator configures the "Silver" package he uses exactly 
      the same line configuration profile and exactly the same (unless 
      "Change 2" is accepted) channel profile he used for the "Bronze" 
      package. The "delta" is: a second channel profile and a specific 
      template (which is basically a collection of up to 5 pointers).
      This is much more optimal from memory consumption point-of-view.

Change 2
--------
Description of change:
  Moved the us & ds rate adaption ratio attributes from the
  adsl2LineConfTemplateTable table to the adsl2ChConfProfileTable.

Our 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.
   
Change 3
--------
Description of change:
  Removed the adsl2LineConfTemplateTable table.

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


Change 4
--------
Description of change:
  Changed comments for the attributes :
  adsl2LConfProfChan1ConfProfile,
  adsl2LConfProfChan2ConfProfile,
  adsl2LConfProfChan3ConfProfile,
  adsl2LConfProfChan4ConfProfile,

Our Response:
  We accept the suggested description/comments for those attributes.
  However the attributes should be left as part of the line 
  configuration template.


Change 5
--------
Description of change:
  Merge the contents of the tables :
  adsl2LineStatusTable,
  adsl2LineCommandTable,
  adsl2LineConfigTable
  into one single table ( adsl2LineTable ).

Our 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".


Change 6
--------
Description of change:
  Add adsl2LineAlarmConfProfileTable table for performance
  thresholds and data rate change thresholds.

Our 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


Change 7
--------
Description of change:
  Add threshold and data rate traps.

Our Response:
  Accepted as long as we keep traps optional.


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

Our Response:
  Accepted


Change 9   
--------
Description of change:
  Use a OCTET STRING instead of a huge BITS type for the
  sub carrier mask attributes.

Our 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 gald to adopt 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.

Our Response:
  Accepted



Change 11   
---------
Description of change:
  Add an extra index to the subcarrier table adsl2SCStatusTable.

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


Change 12
---------
Description of change:
  Removed attributes from from adsl2SCStatusTable 
  adsl2SCStatusLnAttenUs
  adsl2SCStatusLnAttenDs
  adsl2SCStatusSigAttenUs
  adsl2SCStatusSigAttenDs
  adsl2SCStatusSnrMarginUs
  adsl2SCStatusSnrMarginDs
  adsl2SCStatusAttainableRateUs
  adsl2SCStatusAttainableRateDs
  adsl2SCStatusActAtpUs
  adsl2SCStatusActAtpDs

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

Change 13   
---------
Description of change:
  Add a row status attribute to the adsl2SCStatusTable table.

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

Change 14
---------
Description of change:
  Added TEXTUAL CONVENTIONS :
  Adsl2Direction
  Adsl2LastTransmittedState
  Adsl2LineLdsf
  Adsl2LineStatus
  Adsl2ChAtmStatus
  Adsl2LConfProfPmMode

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

Our Response:
   Correct.