Randy Presuhn | 2 Sep 18:32 2004
Picon

comments on gshdslbis-04

Hi -

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

Randy
Wijnen, Bert (Bert | 3 Sep 16:33 2004
Picon

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

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
(Continue reading)

Wijnen, Bert (Bert | 3 Sep 18:01 2004
Picon

vdslMIB OID tree

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
(Continue reading)

Wijnen, Bert (Bert | 3 Sep 22:46 2004
Picon

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

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
(Continue reading)

Wijnen, Bert (Bert | 4 Sep 16:15 2004
Picon

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

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
(Continue reading)

Menachem Dodge | 8 Sep 00:55 2004
Picon

áòðééï: [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
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.
(Continue reading)

Wijnen, Bert (Bert | 8 Sep 10:57 2004
Picon

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

(Continue reading)

Menachem Dodge | 8 Sep 22:54 2004
Picon

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

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
(Continue reading)

Internet-Drafts | 10 Sep 21:54 2004
Picon

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

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
(Continue reading)

Howon Choe | 17 Sep 23:03 2004

ADSL2/2+ MIB

Hi,

Could you tell me where I can get MIB supporting ADSL2 and ADSL2+?

Thanks in advance.

Howon Choe

972-761-7815

 

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

Gmane