Subject: RE: Re: [Adslmib] VDSL Line Extension MIB

From: Flemisch Felix <[email-masked]>
Date: Thu, 5 Jun 2003 22:18:32 +0200

Hi all,

on 4th June Bob Ray wrote:

> On Mon, 2003-06-02 at 06:37, Flemisch Felix wrote:
>
> > 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).
>
> 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.

To take this comment into account and to clarify the overall description
I adopt the 4th Proposal of my email of 2nd June as follows:

4. Proposal, modified

   Enhance the conceptual row vdslLineEntry by the new parameter
   "vdslLineConfProfileLCSExt":
    ...
    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 line-code specific (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 vdslLineConfProfileName (which is defined in
            the present MIB within the core VDSL Line Configuration
            Profile Table referred to by vdslLineConfProfile).
            
            If this VDSL line is, according to the value of
            vdslLineCoding, an MCM line, all referenced LCS tables
            MUST be MCM-specific, and if this VDSL line is an
            SCM line, all these tables MUST be SCM-specific.
            
            A value of NULL has the meaning that this VDSL line has
            no LCS extension profile table assigned and the VDSL link
            will be established based on the information specified in
            the core configuration profile table and additionally on
            any measurement or probing of the line as necessary."
        ::= { vdslLineEntry 4 }

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

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/
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

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

Hi -

Profuse apologies for sending HTML to the list!!!!

Randy

----- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 06, 2003 10:32 AM
Subject: Re: [Adslmib] VDSL Line Extension MIB

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

....
> 2. Proposal
>
>    Enhance the DESCRIPTION of MODULE-IDENTITY as follows:
...
>     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.
...

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.

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

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.

> 3. Proposal
>    Enhance the REVISION clauses of MODULE-IDENTITY as follows:

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))
....
>             It MUST be the case that either all referenced LCS tables
>             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.

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

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

---

From: [email-masked]
Date: Tue, 10 Jun 2003 17:22:17 +0300

Hi Rajesh,

I believe that what Menachem and Felix say is: What you call "core MIB" is
not enough for deterministically configuring ANY VDSL line. They sure don't
think the missing parameters are "mostly diagnostic".
Currently, we are busy in procedural issues instead of evaluating their
input and decide whether their claims are true or not.
The problem is that WT-68 doesn't seem to be an excellent example of a
solid document that we can really be sure it reflects a "complete
management model". In fact it went through ballots and became a TR even
though several important objects were "forgotten" which is expected only
with very detailed documents (TR-57 is relatively high-level). What I say,
and I'm really sorry I have to point-out this, is that the last steps of
the process were too quick, with too many sharp maneuvers and probably
weren't so serious/professional. In fact I'm sure that most of the members,
excluding you as the editor (this time you managed to escape from my
criticism...) and me who voted "Not Approve" (and then sent a contribution
against the TR), didn't even read the TR. You also remember that our group
invited a BtExact person to explain the exact characteristics of "their"
missing parameters, which is very strange, considering the fact that those
specific parameters were already agreed 3 months before. If that wasn't sad
it could be a very good joke.

Best regards,
Moti

                      Rajesh Abbi                                                                                                      
                      <Rajesh.Abbi@            To:      [email-masked]                                                    
                      alcatel.com>             cc:      [email-masked], [email-masked], [email-masked]                    
                      Sent by:                 Subject: Re: [Adslmib] VDSL Line Extension MIB                                          
                      adslmib-admin@                                                                                                   
                      ietf.org                                                                                                         

                      10/06/03 16:31                                                                                                   

Menachem,

The question is not about usefulness of some detailed parameters under
special
(mostly diagnostic) circumstances.  The only issue is about such parameters
being required for basic operation.  The core MIB defines the parameters
needed
for normal operation, and should be kept as simple as possible.  Support
for detailed
diagnostic parameters can be an optional extension.  So indeed, if there is
sufficient interest in developing optional line-code-specific extension
MIBs, that
can be undertaken as a separate work-item.

The DSL Forum is capturing the requirements for just such optional LCS
extensions
in the current PD documents.  Feel free to contribute to those.

Regards,

Rajesh

[email-masked] wrote:

> Hi Rajesh,
>
>         As an operator interface there are circumstances when the
operator
> would like to define or monitor
> some or all of the physical parameters directly. The operator Should be
> given this choice. There are other similar
> choices in the MIB such as vdslLineConfDownstreamRateMode which can be
set
> to Manual rather than be configured
> automatically. In addition the MIB allows non-standard bandplans and the
use
> of them may be a necessity, due to cross talk from other equipment
already
> deployed in the network, or even as a choice of the operator. In these
> circumstances
> the direct definition of the physical parameters is a necessity for the
> operator.
>         Clearly the missing parameters are the LCS parameters that have
been
> removed from this core MIB and
> will be defined in the extension MIB. Again it is not a question of
> unnecessary complications but one of choice/necessity  of the operator.
>         Lets agree to put this information in the extension MIB and the
> operator can choose whether to make
> use of it or not.
>
>         Regards,
>         Menachem
>
> -----Original Message-----
> From: Rajesh Abbi [mailto:[email-masked]]
> Sent: Friday, June 06, 2003 5:12 PM
> To: Flemisch Felix
> Cc: [email-masked]; [email-masked]; Menachem Dodge
> Hi Felix,
> Please see my respone below ...
>
> Regards,
>
> Rajesh
>
> Flemisch Felix wrote:
>
> > Hi all,
> >
> > on 5th June Bob Ray (16:00) and Rajesh Abbi (17:22) argued that
> > the proposed new object "vdslLineConfProfileLCSExt" should not
> > be needed in the VDSL Line MIB.
> >
> > Sorry that I have to disagree with the co-editors
> > but it definitely IS needed.
> >
> > Its purpose is twofold:
> >
> > 1. vdslLineConfProfileLCSExt documents the commitment of the
> >    adslmib WG (and IETF) to develop an LCS VDSL Line Extension
> >    MIB (VDSL-LINE-EXT-MIB).  While the details of this MIB are
> >    under discussion, it is no longer the case that "the issue of
> >    LCS extension is still under discussion", as Rajesh stated.
> >    On the contrary, DSLF started work on it, and the adslmib WG
> >    shall be obliged to translate the resulting LCS management
> >    framework extension to an SNMP extension MIB.
> >    The formal starting point would be vdsl-07.
>
> The DSL Forum made it an objective to keep the VDSL Management
> working-text (WT-068) line-code independent.  There were some
> concerns at that time from ECI about the adequacy of the existing
> parameters in WT-068 for SCM management, so a separate proposed-draft
> (PD-015) was created to capture additional SCM-specific parameters.
> Subsequently, a few additional line-code independent parameters were
> identified that addressed the remaining concerns for SCM configuration.
> These additional parameters are already included in the IETF draft, and
> will be included in an addendum to the DSL Forum TR-057 (ex WT-068).
> The LCS PDs are now optional extensions to TR-057.
>
> > 2. For an individual VDSL line, vdslLineConfProfileLCSExt
> >    clarifies whether for the configuration of this line
> >    LCS extensions are needed or not and if they are needed
> >    how the respective rows are identified.  This settles a
> >    discussion that took place in the adslmib WG from 20th
> >    to 25th May and remained unsettled so far.
>
> I have seen general comments so far about how the current draft is not
> adequate.  I would like to see specific additional parameter(s) you
believe
> are necessary for the MIB.
>
> It should be noted that the MIB is intended to be an 'operator' interface
> and
> not a chipset/driver interface.  Only parameters that an operator wishes
to
> control are included in order to keep it simple to use.
>
> > If you do not commit to this object, you still allow ANY
> > undocumented relationship from the core VDSL Line Configuration
> > Profile table to vendor-specific LCS extension tables, and you
> > leave it unclarified whether the core configuration parameters
> > are sufficient to configure individual VDSL lines.
>
> > This is clearly not what we want, and the commitment to develop
> > a standardized VDSL-LINE-EXT-MIB is needed NOW.
> >
> > Note that from the object vdslLineConfProfile it is impossible
> > to decide whether LCS configuration parameters for an individual
> > VDSL line are needed respectively are present at all.  This is
> > what I previously called "removal of the eight LCS profile
> > tables without trace".  The proposed new object gives back
> > the missing trace to the removed tables.
>
> The LCS extensions are simply that.  The core MIB should not be made
> 'aware' of the extensions.  As noted above, at this time LCS extensions
> are still deemed 'optional'.  Hopefully we can keep it that way to avoid
> unnecessary complication for the user.
>
> > Regards,
> >
> > Felix