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

From: Flemisch Felix <[email-masked]>
Date: Fri, 6 Jun 2003 01:32:57 +0200

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.

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. 

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.

Regards,

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

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 06 Jun 2003 11:12:15 -0400

Hi Felix,

Please see my respone below ...

Regards,

Rajesh

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

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

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

---

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

Hi -

> From: "Flemisch Felix" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 05, 2003 4:32 PM
> Subject: RE: Re: [Adslmib] VDSL Line Extension MIB
...
>    The formal starting point would be vdsl-07.

This is hardly a valid reason for adding an object definition
to a MIB module.

>    to 25th May and remained unsettled so far.

The line type should determine which LCS extensions are
applicable.  For sanity's sake, I'd strongly recommend that
they be indexed in the same way as the profile, unless there
is a compelling reason to introduce another set of indexes
with different semantics.

> Profile table to vendor-specific LCS extension tables, and you

This will be true no matter what this working group does.
Vendors are always free to define whatever extensions they
may find appropriate.  Even if the WG fully specified everything
in this module, vendors would *still* be able to define additional
stuff.  This is a feature, not a bug.

> are sufficient to configure individual VDSL lines.

My understanding of the discussion so far is that this is vendor-
specific.  I haven't seen any arguments so far that, from the
perspective of MIB module design, suggest that this module's
indexing structure would require changes to adequately
support future modules (either standardized or vendor-specific)
to handle line-type-specific stuff.

> a standardized VDSL-LINE-EXT-MIB is needed NOW.

That's a WG charter discussion, so I'll leave it to the chair to
respond to that point.

> the missing trace to the removed tables.
...

Without knowing the names of the new table(s), the proposed
object does no such thing.  Putting in the names of those tables
would be a normative reference, forcing a lock-step progression
relationship between the documents.  In any case, vendors (and
WGs!) would still be free to define any number of tables indexed
by the proposed object or by the existing profile index object.
In the world of SNMP, one needs to know *a priori* what the set
of potentially relevant tables is, and then construct appropriate
indexes to find the corresponding entries.   There's nothing to
automagically identify what bits will need to be configured to
make something work.  Adding this object doesn't help anything,
as far as I can see.

Randy