ADSL MIB (adslmib)

headers Randy Presuhn | 2 Sep 2004 18:32

Hi -

There are some dangling references (e.g. RFC 3417) left after the edits,
but the changes look otherwise ok to me.

Randy

Mmm.. I finally started to review this one.

I find: 
    vdslLineSCMConfProfileBandId OBJECT-TYPE
        SYNTAX      Unsigned32 {        optionalBand (1),
                                        firstDownstreamBand (2),
                                        firstUpstreamBand (3),
                                        secondDownstreamBand (4),
                                        secondUpstreamBand (5),
                                        thirdDownstreamBand (6),
                                        thirdUpstreamBand (7) }
to cause a SYNTAX error with SMICng.
The reason is that enumerations should use INTEGER as base datatype.
See RFC2578 sect 7.1.1 2nd para:

   The INTEGER type (but not the Integer32 type) may also be used to
   represent integer-valued information as named-number enumerations.
   In this case, only those named-numbers so enumerated may be present
   as a value.  Note that although it is recommended that enumerated
   values start at 1 and be numbered contiguously, any valid value for
   Integer32 is allowed for an enumerated value and, further, enumerated
   values needn't be contiguously assigned.

When I fix that I run into the next one vdslLineSCMPhysBandId

Maybe the SCMBandId should be a TC ??

THen when I fix that, I run into syntax error
   vdslLineSCMConfProfileBandUsage OBJECT-TYPE
        SYNTAX       unsigned32

OK, while review mcm and scm MIB documents, I see

- RFC3728 has:
    vdslMIB MODULE-IDENTITY
       ... snip ...
       ::= { transmission 97 }

    vdslLineMib    OBJECT IDENTIFIER ::= { vdslMIB 1 }

- mcm mib document has:
       ::= { vdslMIB XX }   -- To be assigned by IANA
    -- RFC Ed.: we suggest to put it under { vdslMIB 3 } because
    --          vdslMIB 1 is the VDSL-LINE-MIB, vdslMIB 2 is the SCM
    --          extension MIB, while vdslMIB 3 is this MCM extension MIB.

- scm mib document has:
       ::= { vdslMIB XX }   -- To be assigned by IANA
    -- RFC Ed.: we suggest to put it under { vdslMIB 2 } because
    --          vdslMIB 1 is the VDSL-LINE-MIB, vdslMIB 2 is this SCM
    --          extension MIB, while vdslMIB 3 is the MCM extension MIB.

So I have a few questions:

- the latest mib review guidelines (I know they were published
  at same time as your MIB document, so I understand you might not
  have seen this) as in draft-ietf-ops-mib-review-guidelines-03.txt
  state on page 13, sect 4.5, 3rd bullet:

   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the

OK here are my other review comments:

Serious issues

1. The SMICng compilation/syntax issues I reported earlier.
   - must use INTEGER for enumartions, not Unsigned32.
   - must use Unsigned32, not unsigned32
   - index item "vdslLineSCMConfProfileBandId" must be not-accessible

2. I see:
   vdslLineSCMConfProfileBandUsage OBJECT-TYPE
        SYNTAX       Unsigned32 
        MAX-ACCESS  read-create
        STATUS  current 
        DESCRIPTION 
          "Indicates whether this band is in use.
           Specified as an Unsigned32, the two
           possible values are:
           Unused(1),
           InUse(2)"
        ::= { vdslLineSCMConfProfileBandEntry 2 }
   Seems to me you would rather do that as an enumeration, using INTEGER
   don't you think so?

3. I see:
    vdslLineSCMConfProfileBandRowStatus OBJECT-TYPE
        SYNTAX       RowStatus
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION

1. In your sect 2.4 you speak about the expected persistency behaviour.
   That is goodness. You need to say something about thet in all the
   vdslXxxEntry DESCRIPTION clauses of any read-create or read-write 
   tables.

2. RowStatus objects.
   - I see them speak aboput "ouOfService", but such a value does not
     exists, it is "notInService".
   - You need to say if (which) any object can or cannot be changed
     when a row is active.

3. I see
    vdslLineMCMConfProfileTxBandNumber OBJECT-TYPE
        SYNTAX       Unsigned32
   and wonder if a value of zero is valid? In principle we do not like
   index objects to allow for a zero value. If there are good reasons 
   to still allow a zero value, then we prefer to see that explained
   in the DESCRIPTION clause. This comes back a number of times and
   causes these errors/warnings with SMICng:
      C:\bwijnen\smicng\work>smicng vdslmcm.inc
      E: f(vdslmcm.mi2), (185,17) Index item "vdslLineMCMConfProfileTxBandNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (277,17) Index item "vdslLineMCMConfProfileRxBandNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (368,17) Index item "vdslLineMCMConfProfileTxPSDNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (456,17) Index item "vdslLineMCMConfProfileMaxTxPSDNumber"
         must be defined with syntax that includes a range
      E: f(vdslmcm.mi2), (549,17) Index item "vdslLineMCMConfProfileMaxRxPSDNumber"
         must be defined with syntax that includes a range

Hello,

    I would like to thank Bert for his thorough review of the SCM and MCM
documents. I am working through each of the points raised and will make the
necessary changes before submitting the drafts again. I will list these
changes
in another email.

    There are however some clarifications that I need:

   1.  Regarding the OID, the approach taken was to place the two extension
MIBs
(SCM and MCM) under the VDSL MIB as these MIBS are seen as optional
extensions to the that MIB. I did not follow why this approach is not
logical, however,
I don't have any objections to changing this approach.
Bert, do you suggest, then, placing them directly under the transmission MIB
as
 ::= { transmission 98 } and ::= { transmission 99 }

If this is done in this way, are the SCM and MCM MIBs still seen as
extensions to the VDSL MIB ?

    2. Please explain further your point that "the MODULE-COMPLIANCE
statement defined mandates
that everyone MUST implement the first table as read-create table."

    Yours Sincerely,

    Menachem.

> 
> Hello,
> 
>     I would like to thank Bert for his thorough review of the SCM and MCM
> documents. I am working through each of the points raised and will make the
> necessary changes before submitting the drafts again. I will list these
> changes in another email.
> 
>     There are however some clarifications that I need:
> 
>    1.  Regarding the OID, the approach taken was to place the two extension
> MIBs (SCM and MCM) under the VDSL MIB as these MIBS are seen as optional
> extensions to the that MIB. I did not follow why this approach is not
> logical, 

The thing abvout "not logical" was as follows and has to do with the OID 
structure underneath vdslMIB

    OID tree
->  1.3.6.1.2.1.10.97  vdslMIB  [VDSL-LINE-MIB]: module-identity
->  1.3.6.1.2.1.10.97.1  vdslLineMib  [VDSL-LINE-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.1.0  vdslNotifications  [VDSL-LINE-MIB]: oid-value-assignmentOID tree
    1.3.6.1.2.1.10.97.1.1  vdslMibObjects  [VDSL-LINE-MIB]: oid-value-assignment
->  1.3.6.1.2.1.10.97.2  vdslExtSCMMIB  [VDSL-LINE-EXT-SCM-MIB]: module-identity
->  1.3.6.1.2.1.10.97.2.1  vdslLineExtSCMMib  [VDSL-LINE-EXT-SCM-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.2.1.1  vdslLineExtSCMMibObjects  [VDSL-LINE-EXT-SCM-MIB]: oid-value-assignment
->  1.3.6.1.2.1.10.97.3  vdslExtMCMMIB  [VDSL-LINE-EXT-MCM-MIB]: module-identity
->  1.3.6.1.2.1.10.97.3.1  vdslLineExtMCMMib  [VDSL-LINE-EXT-MCM-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.3.1.1  vdslLineExtMCMMibObjects  [VDSL-LINE-EXT-MCM-MIB]: oid-value-assignment

Bert,

    Thanks for these clarifications.

    Regards,
    Menachem

----- Original Message -----
From: Wijnen, Bert (Bert) <bwijnen <at> lucent.com>
To: Menachem Dodge <mhdo <at> zahav.net.il>; Adslmib (E-mail) <adslmib <at> ietf.org>
Sent: Wednesday, September 08, 2004 10:57 AM
Subject: RE: áòðééï: [Adslmib] AD review of:
draft-ietf-adslmib-vdsl-ext-scm-05.txt

> >
> > Hello,
> >
> >     I would like to thank Bert for his thorough review of the SCM and
MCM
> > documents. I am working through each of the points raised and will make
the
> > necessary changes before submitting the drafts again. I will list these
> > changes in another email.
> >
> >     There are however some clarifications that I need:
> >
> >    1.  Regarding the OID, the approach taken was to place the two
extension
> > MIBs (SCM and MCM) under the VDSL MIB as these MIBS are seen as optional
> > extensions to the that MIB. I did not follow why this approach is not

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the ADSL MIB Working Group of the IETF.

	Title		: Definitions of Managed Objects for G.SHDSL.BIS Lines
	Author(s)	: C. Sikes, et al. 
	Filename	: draft-ietf-adslmib-gshdslbis-05.txt
	Pages		: 73
	Date		: 2004-9-10

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 High Bit-Rate
   Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and
   Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.
   This document introduces extensions to several objects and textual
   conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276).  The MIB
   module described in this document will obsolete the MIB module
   described in RFC 3276.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gshdslbis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then

_______________________________________________
Adslmib mailing list
Adslmib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

1	June 2013
5	April 2013
8	February 2013
1	December 2012
1	November 2012
1	October 2012
13	July 2012
2	June 2012
1	May 2012
10	April 2012
11	March 2012
13	February 2012
5	January 2012
3	November 2011
1	October 2011
1	September 2011
1	August 2011
1	July 2011
3	June 2011
4	May 2011
5	March 2011
1	January 2011
8	December 2010
12	November 2010
1	September 2010
3	June 2010
4	May 2010
3	March 2010
2	February 2010
5	January 2010
15	December 2009
18	November 2009
9	October 2009
2	September 2009
5	August 2009
5	July 2009
19	June 2009
18	May 2009
6	April 2009
28	February 2009
3	January 2009
2	November 2008
1	October 2008
10	September 2008
1	August 2008
3	July 2008
10	June 2008
4	March 2008
1	February 2008
3	January 2008
1	December 2007
6	November 2007
6	October 2007
10	August 2007
10	July 2007
2	June 2007
2	May 2007
1	April 2007
21	March 2007
5	February 2007
3	January 2007
2	December 2006
3	November 2006
18	October 2006
14	September 2006
30	August 2006
9	July 2006
13	June 2006
6	May 2006
6	April 2006
12	March 2006
19	February 2006
13	January 2006
17	December 2005
13	November 2005
13	October 2005
30	September 2005
8	August 2005
18	July 2005
10	June 2005
13	May 2005
15	April 2005
11	March 2005
12	February 2005
23	January 2005
3	December 2004
3	November 2004
19	October 2004
20	September 2004
4	August 2004
1	July 2004
8	June 2004
4	May 2004
17	April 2004
43	March 2004
16	February 2004
3	January 2004
3	December 2003
9	November 2003
9	October 2003
21	September 2003
8	August 2003
2	July 2003
45	June 2003
46	May 2003
29	April 2003
15	March 2003
7	February 2003
9	January 2003
3	December 2002
40	November 2002
23	October 2002
16	September 2002
5	August 2002
1	July 2002
23	June 2002
12	May 2002
23	April 2002
1	March 2002

comments on gshdslbis-04

AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt

vdslMIB OID tree

AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt

AD review of: draft-ietf-adslmib-vdsl-ext-mcm-04.txt

áòðééï: [Adslmib] AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt

RE: áòðééï: [Adslmib] AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt

áòðééï: áòðééï: [Adslmib] AD review of: draft-ietf-adslmib-vdsl-ext-scm-05.txt

I-D ACTION:draft-ietf-adslmib-gshdslbis-05.txt

ADSL2/2+ MIB