Subject: [Adslmib] VDSL Line Extension MIB

From: Flemisch Felix <[email-masked]>
Date: Mon, 2 Jun 2003 13:37:38 +0200

Hi all,

I wrote

> The announced email on "VDSL Line Extension MIB" will be sent out
> tomorrow.

And here it is.

I first give a rationale for what I'm proposing about LCS extensions
in "draft-ietf-adslmib-vdsl-09a.txt", sent out on 30th May, and answer
the related comment by Randy (711c753,759; see his email of 31st May)
and the one by Moti (711c753,759; see his email of 1st June).

I then formalize the MUST requirement for VDSL-LINE-EXT-MIB, at
least regarding LCS line configuration profile tables, through the
introduction of the new parameter "vdslLineConfProfileLCSExt"
within vdslLineEntry.  It identifies the row (maybe none) in the
LCS Line Configuration Profile Extension Table, which applies
for this VDSL line and its channels (if applicable).

0. Rationale and Answers to Comments

   In a major editorial step between vdsl-07 and vdsl-08 the VDSL
   MIB was fully aligned with TR-057 and thereby became line-code
   independent.  In particular, the eight (!) LCS configuration
   profile tables were removed without trace (but keeping a trace
   would be useful, see "4. Proposal" below).  These tables were
   organized to use the object vdslLineConfProfileName as a common
   index for all tables (including vdslLineConfProfileTable).

   In a further step some flaws of TR-057 were resolved by adding
   the configuration parameters slow burst protection and fast FEC
   overhead for both downstream and upstream direction.

   Subsequently it turned out that the agreed core parameter set
   covers completely the PMS-TC sublayer but not completely enough the
   PMD sublayer.  And so no agreement was reached, not even within the
   SCM fraction, that basic (whatever this means) configuration of VDSL
   lines will be possible using the core VDSL MIB of vdsl-09 without
   additional LCS parameters.  Thus the development of an LCS-specific
   framework for both SCM and MCM by the DSLF and the development of
   a corresponding LCS VDSL extension MIB are a MUST since otherwise
   vendor-specific MIBs need to be implemented at the disadvantage of
   customers (who regularly require multi-vendor capability).

   I therefore requested in previous emails the standardization of a
   VDSL Line Extension MIB, at least regarding LCS line configuration
   profile tables, and the statement of this MUST requirement within
   the core VDSL Line MIB document.  In this email I emphasize this
   request by proposing the introduction of a reference to profile
   extension tables within the VDSL line table.  This gives back the
   missing trace to the removed LCS configuration profile tables.

   Randy's comment 711c753,759 is resolved by a reformulation of
   the complained text (see the "3. Proposal" and the related
   "2. Proposal" below).  Moti's comment regarding 711c753,759
   is resolved by the new "1. Proposal" below.

1. Proposal

   Enhance in section 2.5 of vdsl-09 the text describing line
   configuration profiles as follows:
   ...
   o   Line Configuration Profiles - These profiles contain parameters
       for configuring VDSL lines and their channels.  They are defined
       in the line-code independent vdslLineConfProfileTable and in
       supplementary line-code specific (LCS) configuration profile
       tables.  vdslLineConfProfileTable is defined in the VDSL-LINE MIB
       module that is specified in this RFC, and LCS configuration
       profile tables are defined in the VDSL-LINE-EXT MIB module that
       is specified in a separate RFC.  Each entry of vdslLineTable
       references a row of vdslLineConfProfileTable and a common index
       into one or more applicable LCS configuration profile tables.
       The referenced LCS row(s) augment(s) the line-code independent
       parameter set by an LCS parameter set (which may be empty).
   ...
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

2. Proposal

   Enhance the DESCRIPTION of MODULE-IDENTITY as follows:
    ...
            Tx   -- Transmit
            Blks -- Blocks

    --  Note

    This MIB module does not contain line-code specific (LCS) elements
    for neither MCM lines nor SCM lines.  An LCS VDSL Line Extension
    MIB (VDSL-LINE-EXT-MIB) module MUST be standardized as a supplement
    to the core VDSL-LINE-MIB, since otherwise both SCM and MCM lines
    can only be fully configured in a proprietary way.

    Therefore the VDSL line table refers not only to the line-code
    independent configuration profile table vdslLineConfProfileTable,
    defined in this MIB module, but also to a commonly indexed set of
    applicable LCS configuration profile tables, either all SCM-specific
    or all MCM-specific, that are defined in VDSL-LINE-EXT-MIB."
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

3. Proposal

   Enhance the REVISION clauses of MODULE-IDENTITY as follows:
    --  Revision history
    ...
    REVISION "200304180000Z" -- April 18, 2003
    DESCRIPTION "Brought into conformance with DSLF TR-057.
                This means in particular that all line-code specific
                (LCS) elements have been removed for both, MCM lines
                and SCM lines."
    ...
    REVISION "200306020000Z" -- June 2, 2003
    DESCRIPTION "Added vdslLineConfLineType
                to vdslLineCodeProfileEntry.

                Added vdslLineConfProfileLCSExt
                to vdslLineEntry.

                Enhanced in section 2.5 the description of
                line configuration profiles.

                Added note to DESCRIPTION of MODULE-IDENTITY
                regarding necessity of LCS MIB extensions.

                Corrected many mechanical and editorial flaws,
                added various clarifications."
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

4. Proposal

   Enhance the conceptual row vdslLineEntry by the new parameter
   "vdslLineConfProfileExtension":
    ...
    VdslLineEntry ::=
        SEQUENCE 
            {
            vdslLineCoding                         VdslLineCodingType,
            vdslLineType                           INTEGER,
            vdslLineConfProfile                    SnmpAdminString,
            vdslLineConfProfileLCSExt              SnmpAdminString,
            vdslLineAlarmConfProfile               SnmpAdminString
            }
    ...
        ::= { vdslLineEntry 3 }

    vdslLineConfProfileLCSExt OBJECT-TYPE
        SYNTAX       SnmpAdminString (SIZE(1..32))
        MAX-ACCESS   read-write
        STATUS       current
        DESCRIPTION
            "The value of this object identifies the row in
            one or more LCS VDSL configuration profile tables,
            which applies for this VDSL line and its channels.
            The LCS tables are defined in the VDSL Line Extension
            MIB (VDSL-LINE-EXT-MIB) and are commonly indexed by 
            the object vdslLineConfProfileLCSExtName.

            It MUST be the case that either all referenced LCS tables
            are SCM-specific or all these tables are MCM-specific.
            Correspondingly the LCS extension of the core configuration
            profile is called SCM-specific or MCM-specific.  An
            SCM-specific extension profile MUST NOT be assigned to an
            MCM line (according to vdslLineCoding), and an MCM-specific
            extension profile MUST NOT be assigned to an SCM line.
            
            A value of NULL has the meaning that this VDSL line has
            no LCS extension profile assigned and the VDSL link will
            be established based on the information specified in the
            core configuration profile and additionally on any
            measurement or probing of the line as necessary."
        ::= { vdslLineEntry 4 }

    vdslLineAlarmConfProfile OBJECT-TYPE
    ...
        ::= { vdslLineEntry 5 }
    ...
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I do not plan an update of "draft-ietf-adslmib-vdsl-09a.txt" according
to the various emails sent out so far but would like to leave the
incorporation of all mechanical and editorial changes, and of all
accepted substantial changes, to the co-editors.  IMHO a final draft
version "draft-ietf-adslmib-vdsl-10.txt" could be useful to check the
incorporations (if it does not hold up the RFC procedure unnecessarily).

Regards,

Felix

-----Original Message-----
From: Flemisch Felix 
Sent: Sunday, June 01, 2003 12:28 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: VDSL Line Type Naming and Configuration

Hi all,

I wrote

> The announced email on "VDSL Line Type Configuration and
> VDSL Line Extension MIB" will be sent out next Monday.

It turned out to be convenient to split the email in two parts.
Here is the first part on VDSL Line Type Naming and Configuration.

...

The announced email on "VDSL Line Extension MIB" will be sent out
tomorrow.

...

Regards,

Felix Flemisch

Siemens AG
Information and Communication Networks
Carrier Products Systems Engineering
Hofmannstr. 51
D-81359 Munich
Germany
Phone    +49 89 722 62175
Email    [email-masked]
Internet http://www.siemens.com/

-----Original Message-----
From: Flemisch Felix 
Sent: Saturday, May 31, 2003 3:10 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt

Hi all,

Randy Presuhn wrote

> I did a diff of the -09- and "09a" documents, and have
> a few comments on the proposed changes.

Thanks Randy for so quickly producing diffs and commenting them!
You identified a number of obscurities indeed.
Here are my answers.

...

The announced email on "VDSL Line Type Configuration and
VDSL Line Extension MIB" will be sent out next Monday.

Regards,

Felix

-----Original Message-----
From: Flemisch Felix 
Sent: Friday, May 30, 2003 10:42 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'
Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt

Hi all,

please find attached a plain ASCII text version of the updated
"draft-ietf-adslmib-vdsl-09.txt" that I previously distributed
as a Word document with continuous line numbering where I have
added my comments using change tracking.  I have named this
updated document "draft-ietf-adslmib-vdsl-09a.txt".

...

Best Regards,

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

---

From: Bob Ray <[email-masked]>
Date: 04 Jun 2003 15:00:12 -0500

> for this VDSL line and its channels (if applicable).

If there is to be a LCS extension MIB module, then the table(s)
within it should use vdslLineConfProfileName as an index instead
of what you propose.  This is functionally equivalent to your proposed
object, but does not require an 

      object-from-a-MIB-to-be-written-at-a-later-date.

Further, this would be in keeping with the LCS tables in earlier
revisions of the VDSL Line MIB.

Regards,
Bob Ray
PESA Switching Systems

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jun 2003 10:32:27 -0700

Hi -

Please note that my comments are as a "mib doctor" and not
as any sort of *DSL person.

> From: "Flemisch Felix" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, June 02, 2003 4:37 AM
> Subject: [Adslmib] VDSL Line Extension MIB

....
...
...

This use of "MUST" is not consistent with RFC 2119.  The second sentence
should be deleted, or, if the WG is agreed that this work should be pursued,
replaced with a statement to the effect that a line extension module is planned.

>     or all MCM-specific, that are defined in VDSL-LINE-EXT-MIB."

This last sentence is over-specific, since it would preclude
reference to any generic tables that might be defined in the future.
In the IETF we have generally *not* tried to spell out potential future re-uses
of indexes.  I'd be OK with this addition if it  read something like:

| The VDSL line table refers not only to the line-code
| independent configuration profile table vdslLineConfProfileTable
| defined in this MIB module, but also to, for example, the set of
| commonly indexed applicable LCS configuration profile tables.

This stuff will all go away; the RFC will contain a single REVISION clause
saying that this is the initial version of this MIB module. 

...
>         SYNTAX       SnmpAdminString (SIZE(1..32))
....
>             are SCM-specific or all these tables are MCM-specific.

This is over-specification, since it would preclude the definition of
a future generic table.  My own experience as an implementor of
related MIB tables is that it is better to define the semantics of
   1) the existence of an irrelevant table entry (e.g.,  "corresponding
       entries in tables not applicable to this line type have no effect")
   2) the absence of a relevant table entry
Both of these are probably best done in the *referenced* table's
DESCRIPTION, rather than here, especially when the referenced
tables haven't been defined yet.

>             extension profile MUST NOT be assigned to an SCM line.

This needs to be cleared up: is this advice to the (writer or user of) the
management application?  Is this to be enforced at the agent?  If so,
what error code is expected?  What happens when stuff is being provisioned
for hardware that hasn't been installed?  What happens if the hardware
changes?

...

Please don't use "NULL".  A zero-length string would be appropriate.
Unfortunately, the SIZE(1..32)  above precludes that possibility.  The
range should be extended to include zero.

More fundamentally, why would it be necessary for this string to exist
at all?  Wouldn't the using  the profile index work just as well,
and avoid potential confusion?  For example, if I have profiles "A",
"B", and "C", with profile "A" usable for line type 1, "B" usable
for line type 2, and "C" usable for either, then the MIB tables
could be populated like this:

Profile Table         type-1-specific               type-2-specific
--------------------------------------------------------------------
A                           A
B                                                          B
C                           C                              C

This seems simpler than adding yet another index, and also avoids
the complex inter-dependencies.  A line references its profile entry,
and any corresponding line-type-specific entries according to its
line type.  Any line-type specific entries that might happen to
exist for other line types would be irrelevant to that particular line.
(It's up to the WG to decide whether this is appropriate for
this particular technology!)

Randy