Subject: [Adslmib] AD review: draft-ietf-adslmib-adsl2-04.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 2 Jan 2006 18:12:11 +0100

Sorry that it took so long to review.

Here is what I get from SMICng: 

   E: f(adsl2.mi2), (3689,16) Index item "adsl2PMLHist15MInterval"
      must be defined with syntax that includes a range
   E: f(adsl2.mi2), (3833,16) Index item "adsl2PMLHist1DInterval"
      must be defined with syntax that includes a range
   E: f(adsl2.mi2), (3977,16) Index item "adsl2PMLHistInit15MInterval"
      must be defined with syntax that includes a range
   E: f(adsl2.mi2), (4083,16) Index item "adsl2PMLHistinit1DInterval"
      must be defined with syntax that includes a range
   E: f(adsl2.mi2), (4348,16) Index item "adsl2PMChHist15MInterval"
      must be defined with syntax that includes a range
   E: f(adsl2.mi2), (4451,16) Index item "adsl2PMChHist1DInterval"
      must be defined with syntax that includes a range

Not sure I understand why you did not inlcude such a range?

I see:
   ngdslTCMIB MODULE-IDENTITY
         ::= { transmission xxx }
   -- RFC Ed.: we suggest to put it under { transmission 230 } because
   --          this is the first available number.
and I also see:
   ngdslMIB MODULE-IDENTITY
         ::= { transmission xxx }
   -- RFC Ed.: we suggest to put it under { transmission 231 } because
   --          this is the first available number.

Now if you go to http://www.iana.org/assignments/ianaiftype-mib
then you will see that 231 and 232 have been taken by now.
So asking for 231 does not make sense (anymore).
But besides, I see that you have gotten 230 assigned for adsl2.
So it seems weird to me to then askl it to be used for the TC MIB module.

For RFC2662, I see that we also had a TC and that we had 
   adsltcmib MODULE-IDENTITY
      ::= { transmission 94 2 } -- adslMIB 2
And 
   adslMIB MODULE-IDENTITY
   ::= { transmission 94 }

   adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 }

So we could follow a similar approach here.

Then (I do not recall if you answered this earlier) I wonder that
the IfType is adsl2, but we root the ngdslMIB underneath it.
I understand (from wg mail discussion) that this new MIB module is
also to address the ngdsl and vdsl2 in the future.
Is the plan to have a vdsl2 ifType in the future? If so, how does that
fit with this MIB document?

We then use ngdls as the MIB module name and adsl2 as prefix for 
all objects. Not very consistent is it?

The reason I get a bot confused is this:
- abstract says:
   This document defines a Management Information Base (MIB) module for
   use with network management protocols in the Internet community.  In
   particular, it describes objects used for managing parameters of the
   "Asymmetric Digital Subscriber Line" family of interface types,
   especially including ADSL, ADSL2, and ADSL2+.
- And then the first table DESCRIPTION states:
   adsl2LineTable  OBJECT-TYPE
      SYNTAX      SEQUENCE  OF  Adsl2LineEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
         "The table adsl2LineTable contains configuration,
          command and status parameters of the ADSL2 line.
          The index of this table is an interface index where the
          interface has an ifType of adsl2(230)."
- So will ifTypes with ifType adsl also be in this table?
  Can they be in this table? MUST they be in this table?

I see read-create table(s) like adsl2LineConfTemplateTable and
adsl2LineConfProfTable but nowhere can I find what the persistency
behaviour is of the rows in these tables. Pls check all writable
objects and tables and make sure you describe the expected persistency
behaviour and/or use StorageType objects (RFC2579) for tables.

In your RowStatus object DESCRIPTION clauses I see:

         Before a profile can be deleted or taken out of service
         (by setting this object to 'destroy' or 'outOfService'),
         it must be first unreferenced from all associated
         lines."

I think you mean notInService instead of outOfService, see RFC2579.

You must also state whihc objects if any can or cannot be changed
if a row is active.

I need to study this more and better before I can complete my review.

Bert

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

---

From: [email-masked]
Date: Sun, 8 Jan 2006 16:14:37 +0200

Hi Bert,

See the embedded (intermediate) response.

Best Regards,
Moti Morgenstern

Senior Systems Engineer
ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
Tel.: +972-3-9266258
Fax: +972-3-9287342
Cell: +972-54-5786258
e-mail: [email-masked]
www.ecitele.com

             "Wijnen, Bert                                                 
             (Bert)"                                                       
             <[email-masked]                                          To 
             om>                       "'Ray, Robert'"                     
             Sent by:                  <[email-masked]>                
             adslmib-bounces@i                                          cc 
             etf.org                   "Adslmib \(E-mail\)"                
                                       <[email-masked]>                  
                                                                   Subject 
             02/01/2006 19:12          [Adslmib] AD review:                
                                       draft-ietf-adslmib-adsl2-04.txt     

                                                                           

<<<<Moti: I've fixed this problem. The value ranges have been added
according
<<<<        to what we describe in the introduction (section 2.6.1 and
2.6.2)

I see:

<<<<Moti: The reference quoted concerns the ifType. We actually do need
<<<<        more than the value (ifType=230) already allocated for adsl2.

<<<<Moti: Yes. We'll adopt the same approach for this MIB.

<<<<Moti: In the beginning of the work we assumed that this MIB will serve
<<<<        for all new DSL technologies. As a result of recent changes in
ITU-T
<<<<        management  model we understand that for VDSL2 there will be a
need for
<<<<        revising existing management tables/attributes as well as
adding few new
<<<<        ones.
<<<<        Some of those changes (e.g., use of subcarrier groups, using
band number
<<<<        as a table index) will unnecessarily complicate the use of the
VDSL2
<<<<        line MIB for operators that prefer to deploy ADSL2 "only".
<<<<        So now we understand that the existing MIB should be called
ADSL2 line MIB.
<<<<        It will support, as designed, the ADSL2, ADSL2+, RE-ADSL2 and
"old" ADSL
<<<<        lines. Another MIB will be required for VDSL2. It will also
support backward
<<<<        compatibility to ADSL2/ADSL2+, RE-ADSL2 and ADSL, at the cost
of using
<<<<      the more complicated approach of VDSL2 line management.

<<<<Moti: This is a complicated situation. What we understand is that
<<<<         in case the SNMP agent supports only RFC2662 then any ADSL
<<<<         line will be given the ifType=adsl and accordingly the EMS
will
<<<<         manage it with RFC2662.
<<<<         However, NE that supports (also) ADSL2 will prefer to manage
all
<<<<         lines using the ADSL2 Line MIB. So, all ADSL/ADSL2/ADSL2+
<<<<         and RE-ADSL interfaces will be given ifType=adsl2 (230) and
will be
<<<<         managed with the same line MIB. The NE will still be able to
indicate
<<<<         that a specific interface is ADSL "only" using an attribute
within the
<<<<         inventory table (adsl2LInvTransmissionCapabilities).
<<<<         Similarly an NE that will support VDSL2 lines will naturally
be in
<<<<         favor of using the same ifType=vdsl2 (???) for all xDSL
technologies.
<<<<         The specific capabilities of each xDSL interface will be
reflected by
<<<<         the same kind of attribute in the VDSL Line MIB.

<<<<Moti: We'll add references to the persistency aspect of tables/objects.

<<<<Moti: Will be corrected

<<<<Moti: Will be corrected

Bert