Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-vdsl-01.txt

From: [email-masked]
Date: Thu, 04 Apr 2002 07:01:47 -0500

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 VDSL Lines
	Author(s)	: R. Abbi, B. Ray
	Filename	: draft-ietf-adslmib-vdsl-01.txt
	Pages		: 52
	Date		: 03-Apr-02
	
This document defines a portion of the Management Information Base 
(MIB) module for use with network management protocols in the 
Internet community.  In particular, it describes objects used for 
managing Very high speed Digital Subscriber Line (VDSL) interfaces
[18, 19, 20].
This document specifies a MIB module in a manner that is compliant 
to the SMIv2 (STD 58 [5, 6, 7]).

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
	"get draft-ietf-adslmib-vdsl-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-adslmib-vdsl-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "David Horton" <[email-masked]>
Date: Mon, 8 Apr 2002 15:08:08 +1000

I am concerned with the use of the IMPLIED clause in the INDEXing for many
of the tables.

Quoting from RFC2578 page 28:

   Note that the IMPLIED keyword can only be present for an object
   having a variable-length syntax (e.g., variable-length strings or
   object identifier-valued objects), Further, the IMPLIED keyword can
   only be associated with the last object in the INDEX clause.
   Finally, the IMPLIED keyword may not be used on a variable-length
   string object if that string might have a value of zero-length.

In the draft, it is used as the first attribute in the INDEX clause, e.g.

   vdslLineConfProfileEntry OBJECT-TYPE
        SYNTAX         VdslLineConfProfileEntry
        MAX-ACCESS     not-accessible
        STATUS         current
        DESCRIPTION
            "Each entry consists of a list of parameters that
            represents the configuration of a VDSL modem.  A
            default profile will always exist.  This profile's
            name will be set to `DEFVAL' and its parameters will
            be set to vendor specific values, unless otherwise
            specified in this document."
        INDEX { IMPLIED vdslLineConfProfileName,
                        vdslPhysSide }
        ::= { vdslLineConfProfileTable 1 }

   vdslLineMCMConfProfileEntry OBJECT-TYPE
        SYNTAX       VdslLineMCMConfProfileEntry
        MAX-ACCESS   not-accessible
        STATUS       current
        DESCRIPTION
            "Each entry consists of a list of parameters that
            represents the configuration of a multiple carrier
            modulation VDSL modem.  A default profile will always
            exist.  This profile's name will be set to `DEFVAL'
            and its parameters will be set to vendor specific values,
            unless otherwise specified in this document."
        INDEX { IMPLIED vdslLineConfProfileName,
                        vdslPhysSide }
        ::= { vdslLineMCMConfProfileTable 1 }

I would suggest a couple of alternatives:

1) simply drop the IMPLIED. (Thus the ASN.1 will use a counted string,
rather than implying the length from the remaining length of the OID.)
[preferred]
2) reorder the attributes e.g.
        INDEX { vdslPhysSide ,
                IMPLIED vdslLineConfProfileName
              }
  Thus the vdslPhysSide attribute can be extracted from the OID without
ambiguity.

Further, the use of this pair as a parent for a sub-table is problematic,
e.g.

 vdslLineMCMConfProfileTxBandEntry OBJECT-TYPE
        SYNTAX       VdslLineMCMConfProfileTxBandEntry
        MAX-ACCESS   not-accessible
        STATUS       current
        DESCRIPTION
            "Each entry consists of a transmit band descriptor, which
            defines the start and stop bands and the power spectral
            density (PSD) for that band.

            A default profile will always exist.  This profile's name
            will be set to `DEFVAL' and its parameters will be set to
            vendor specific values, unless otherwise specified in this
            document."
        INDEX { IMPLIED vdslLineConfProfileName,
                        vdslPhysSide,
                        vdslMCMConfProfileTxBandNumber }

The vdslMCMConfProfileTxBandNumber needs to be the last attribute of the
INDEX clause for correct definition for existence relationships and
dependence relationships. Thus this requirement is at odds with the
requirement on the IMPLIED attribute being the rightmost.
[Reference: Dependent Expansion Relationship from "Inter-Table Indexing in
SNMP MIBs" by Dave Perkins.

On a more pedantic note, I think the re-use of vdslPhysSide attribute in the
profiles is incorrect. The initial definition of vdslPhysSide is on a
particular line, associated with a particular ifIndex in vdslPhysEntry. Thus
this defines the object instance for vdslPhysSide. If my understanding is
correct, the use of vdslPhysSide in the profiles is as a 'role'. i.e. "When
this device is acting as a VTU-C, use this set of profiles; When acting as a
VTU-R, use that set of profiles." I am considering the case where a device
capable of acting as CPE or Central Office side roles is shipped with
'DEFAULT' profiles for acting in either role. In a particular deployment,
the role in use is simply enabled.

I believe that we should be introducing a new attribute into the
vdslLineConfProfileTable -:

vdslLineConfProfilePhysSideRole  OBJECT-TYPE
        SYNTAX       VdslLineEntity
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
            "Identifies whether the modem is the Vtuc or Vtur."
        ::= { vdslLineConfProfileEntry  1 }

This attribute would used instead of vdslPhysSide in the profile tables.

In summary, I would recommend
1. dropping the use of IMPLIED with any profile names.
2. consider adding an additional attribute to represent a role that a modem
may play for profile configurations, rather than the specific physical
interfaces currently deployed.

regards,
David

David Horton
CiTR Pty Ltd
Level 2 John Oxley Centre
339 Coronation Drive
Milton, Queensland, 4064

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

---

From: "Bob Ray" <[email-masked]>
Date: Mon, 8 Apr 2002 09:07:08 -0500

>I am concerned with the use of the IMPLIED clause in the INDEXing for many

You are correct - the indexing is just plain wrong and must be corrected.
I, too, would prefer not using IMPLIED at all.  I had used integer indices
in the first drafts of the HDSL2/G.SHDSL MIB but was roundly chastised for
doing so when I presented it to the DSL Forum.  The consensus was that the
DSLAM and management station code base was built around the IMPLIED clause;
to do otherwise would break many things.

The general consensus among IETF SNMP cognoscenti, however, seems to be that
the IMPLIED convention was a mistake.  I would welcome consensus to remove
this.

>If my understanding is

You are correct - such as device would require TWO default profiles, one
for CPE and another for CO deployment  As a background note, my desire was
to simplify the MIB (in comparison to the ADSL MIB) by not having near
duplicate tables for each side, hopefully halving the number of object
definitions.

There may be another way to simplify the link between the band descriptor
profile tables and the line profile table.  In the current draft, the
band descriptor tables are indexed by profile name, side, and row entry,
with distinct tx and rx tables (for MCM).  As cpe-transmit == co-receive
and co-transmit == cpe-receive, inverting this indexing relationship by
placing partial indices of the band tables into the line profile table
(with all the appropriate band table index changes) might work as well.
This would involve adding two attributes to the profile table:

     vdslLineConfProfileVtucTxProfile -- identifies entries in the
              line code specific profile tables
     vdslLineConfProfileVturTxProfile -- identifies entries in the
              line code specific profile tables

Thus a device would require but one line profile entry and would
interpret the line-code specific profiles as receive or transmit
depending upon its role (vtuc or vtur).

So, as an alternative to your alternatives, I would propose changing the
index of the profile entry to something along the lines of:

   vdslLineConfProfileEntry OBJECT-TYPE
        SYNTAX         VdslLineConfProfileEntry
        MAX-ACCESS     not-accessible
        STATUS         current
        DESCRIPTION
            "Each entry consists of a list of parameters that
            represents the configuration of a VDSL modem.  A
            default profile will always exist with an index value
            of 1 and its parameters will be set to vendor specific
            values, unless otherwise specified in this document."
        INDEX { vdslLineConfProfileIndex }
        ::= { vdslLineConfProfileTable 1 }

    where

    VdslLineConfProfileEntry ::=
        SEQUENCE
            {
            vdslLineConfProfileIndex               INTEGER,
            vdslLineConfProfileName                SnmpAdminString,
            vdslLineConfTargetSnrMgn               INTEGER,
            vdslLineConfTxSpeed                    INTEGER,
            vdslLineConfRxSpeed                    INTEGER,
            vdslLineConfProfileVtucTxProfile       INTEGER,
            vdslLineConfProfileVturTxProfile       INTEGER,
            vdslLineConfProfileRowStatus           RowStatus
            }

    vdslLineConfProfileIndex OBJECT-TYPE
        SYNTAX         INTEGER(1..255)
        MAX-ACCESS     not-accessible
        STATUS         current
        DESCRIPTION
            "This object is used by the line configuration table
            in order to identify a row in that table.  A default
            profile will always exist with an index value of 1.
            Its parameters will be set to vendor specific values,
            unless otherwise specified in this document."
        ::= { vdslLineConfProfileTable 1 }

    vdslLineConfProfileName OBJECT-TYPE
        SYNTAX       SnmpAdminString (SIZE (1..32))
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "A name for this profile."
        ::= { vdslLineConfProfileEntry 2 }

     etc.

Thoughts, criticism, further clarifications are all very welcome.
Personally, I just very glad SOMEONE is reading this stuff!!!!!!

Regards,
Bob Ray