Subject: RE: [Adslmib] Comments on ADSL2 internet draft

From: <[email-masked]>
Date: Wed, 7 Jun 2006 11:30:16 +0530

Hello Moti and Scott,

Many thanks for the clarifications. Basically, we do get it that at this
point of time you accept only errors. Here we are summarizing our
responses to only those points for which we felt we were not clear
enough initially. 

Ref.: comment nr. 5
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) .
M.M. & S.B. : The performance counters in the ADSL2 Line MIB are per
                     G997.1. The counters you mention from RFC2662 are
not
                      part of ITU-T model. Use RFC 2662 if you want to
just
                      manage ADSL lines.

V & N: I will rephrase our question: G992.1 (ADSL) uses G997.1 for
modeling performance counters; so does G992.3, G992.4 and G992.5.
Basically, the different flavours of DSL refer to the same standard for
modeling PM counters. 
In ADSL MIB RFC2662, the above mentioned counters were modeled. This we
had found to be useful. Our question is why did you decide not to model
these for ADSL2 MIB? Anyway even for ADSL (G992.1) too ITU-T mentioned
nothing about these counters.

Ref.: minor comments nr. 2
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)"
  M.M. & S.B. : The references to ACTATPDs/Us are correct. ActPsdDs/Us
                       also use the correct references in G.997.1 so the
comment is unclear.

V & N: The object 'adsl2SCStatusActAtp' stands for Actual Aggr. Transmit
Power. In the REFERENCE section for this object, you refer to PSD. As I
understand PSD is different from Aggr. Transmit Power. The correct
sections of G997.1 you should be referring to are:
7.5.1.16 & 7.5.1.17

Regards
Veena, Naren

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]

Sent: Monday, June 05, 2006 8:35 PM
To: Veena Naidu (WT01 - Broadband Networks)
Cc: [email-masked]; Narendranath Nair (WT01 - Broadband Networks)
Subject: Re: [Adslmib] Comments on ADSL2 internet draft

Hello Veena and Naren,

Thank you for your comments.

Some of the comments lead to changes in the MIB that will be published
under revision -08.

Embedded please find the MIB editors' references to your comments.

Regards,
Moti and Scott

             <veena.naidu@wipr

             o.com>

To 
             01/06/2006 15:10          <[email-masked]>

cc 
                                       [email-masked]

Subject 
                                       [Adslmib] 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.
 M.M. & S.B. : The MIB authors did considered separating the
configuration
                      and status objects but agreed to combine them in
order to
                      reduce table count. Note that DSL Forum TR-090
(5.1.1)
                      combines them in a single line table and also all
previous
                      DSL line MIBs did the same.

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.
M.M. & S.B. : Theoretically this could be a single status parameter
                     but, as the ATM and PTM are different L2
technologies
                     with different alarm definitions, the MIB editors
preferred
                     to allow the agent be familiar with ATM (or PTM)
failures
                     only if ATM (PTM) technology is being used. A
special
case
                     is ADSL lines in which PTM is completely
irrelevant.
Should
                     the channel status parameter in ADSL refer to PTM?
                     In addition, both attributes do not appear in the
mandatory
                     section of the module compliance section and hence
any
of
                     them can be omitted.

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'."
M.M. & S.B. : Correct

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.
M.M. & S.B. : In ADSL there were 5 possible setups where in ADSL2 there
                     are from 1 to 4 channels, each with its own
interleaving setup.
                     The interleave delay can be set to a low value in
order to
                     approximate a fast channel.
                     If working in ADSL mode, The fast and interleaved
channels
                     can be identified by examining the
adsl2ChStatusActDelay
                     attribute. Also that the operator can still put the
                     values Interleave (124) or fast (125) as the ifType
of
a channel.

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) .
M.M. & S.B. : The performance counters in the ADSL2 Line MIB are per
                     G997.1. The counters you mention from RFC2662 are
not
                      part of ITU-T model. Use RFC 2662 if you want to
just
                      manage ADSL lines.

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.
 M.M. & S.B. : The sub carrier status table has a set of scalars to
indicate
                       its size because it has some very large
attributes
and the
                       indexing of the table suggests that there should
be
rows in
                       this table for every line, which probably is a
requirement far
                       beyond most embedded systems capability. The
profile
                       tables do not require any special consideration
and
hence
                       do not require a scalar to specify the maximum
number of
                       entries.

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 management application to name the provision provided.
     (Line index is also unique but not user friendly to display ) .
 M.M. & S.B. : You may add such an attribute if you like as a
proprietary
                       attribute. The MIB editors however tried to
minimize
such
                       nonstandard attributes.
                       In addition, if the DSL line is a virtual bridge
port
                       it may anyhow need to support such a
circuit/remote
id
                       for DHCP option 82.

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.
M.M. & S.B. : The MIB editors considered the idea and decided that the
                      attribute should be external to the channel
profile
if we
                      want the channel profile to be reusable.
                      If you put the attribute as part of the profile
then
you need
                      many identical profiles in which only the RA ratio
is
different.

Question
Why dont we model Static and Dynamic profiles any more (as was done in
RFC
2662)?
 M.M. & S.B. : RFC2662 allows static profiles, one profile per each DSL
line.
                      All DSL line MIBs afterwards do not support such a
model,
                      which doesn't make much sense (I.e., Typically
multiple DSL
                      lines share the same setup)

Minor comments:
1.  adsl2LineCmndAutomodeColdStart  ,Page no  45
    The reference should be "ITU-T G.997.1 Amendment 1, paragraph
7.3.1.1.10"
 M.M. & S.B. : Note that though amendment 1 defines the object, the
7.3.1.1.10 is
                      a paragraph number in G.997.1 (!). So will put
there
                      "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)"
  M.M. & S.B. : The references to ACTATPDs/Us are correct. ActPsdDs/Us
                       also use the correct references in G.997.1 so the
comment
                       is unclear.

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.
  M.M. & S.B. : The object is instanciated per line, as required, and
not
                        per ATU.

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.
   M.M. & S.B. : We could add the suggested information but at this
                         phase we only correct errors. Remember that we
                         still give the reference to the paragraph where
the
                         suggested text appear.

5 Page no 86:  adsl2LConfProfMaxNomPsdDs
    The range according to ITU-t is -60 to -40 dBm/hz
    instead of -60 to -30 dBm/hz
   M.M. & S.B. : Though you are basically right (revision 2 uses the
                         a different range) we noticed that ITU-T
decided
                         recently to correct the range to -60 to -30.
So,
we
                         thought it is reasonable to use that
information
even
                         if it contradicts the formal text at this
moment.

6 Page no 87:adsl2LConfProfMaxNomPsdUs
    The range according to ITU-t is -60 to -38 dBm/hz
    instead of -60 to -30 dBm/hz
   M.M. & S.B. : Same as previous comment.

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
   M.M. & S.B. : Correct.

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.
    M.M. & S.B. : At this phase we got a permission only to correct
errors.
                         Anyhow, the figure in G.997.1 is not very easy
translated
                         into the  textual format of RFCs.

 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)
     M.M. & S.B. : We will consider more Naming Conventions in
                           the VDSL2 MIB.

3. It would be good if we could have in the beginning an object diagram
describing the
   modeling.
    M.M. & S.B. : We will consider adding such a diagram or a
                          reference to another document which includes
                          the diagram as part of  the VDSL2 MIB.

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

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

---

From: [email-masked]
Date: Wed, 7 Jun 2006 14:16:12 +0300

Hello Veena and Naren,

Thank you for insisting on the second issue (minor comment #2).
You're right and the mistake will be corrected.

For the first issue. I think the problem is that RFC2662 does not
reference any ITU-T standard and is based on DSL Forum
TRs that did not refer to ITU-T at that time.
For new DSL technologies the DSL Forum decided to change
the management model and follow ITU-T G.997.1.
If we experience hard-times (as you noticed) in stating the right
references near each MIB object, think about putting a PM
counter such as LOL which (to the best of my knowledge)
has no reference in any DSL standard.

Regards,
Moti Morgenstern

             <narendranath.nai                                             
             [email-masked]>                                                  
                                                                        To 
             07/06/2006 09:00          <[email-masked]>,     
                                       <[email-masked]>             
                                                                        cc 
                                       <[email-masked]>                  
                                                                   Subject 
                                       RE: [Adslmib] Comments on ADSL2     
                                       internet draft                      

                                                                           

Hello Moti and Scott,

Ref.: comment nr. 5

Regards
Veena, Naren

-----Original Message-----

Hello Veena and Naren,

Regards,
Moti and Scott

             <veena.naidu@wipr

             o.com>

To

cc

Subject

                                       internet draft

Hi,

regards
Veena, Naren

Comments:

Question

Minor comments:

4 The Description of

Suggestions:

The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.

www.wipro.com