[Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02.txt

"Randy Presuhn" <randy_presuhn@mindspring.com> Fri, 26 March 2004 01:25 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07366 for <adslmib-archive@odin.ietf.org>; Thu, 25 Mar 2004 20:25:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6g5R-0005qX-AO for adslmib-archive@odin.ietf.org; Thu, 25 Mar 2004 20:24:41 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q1OfDW022472 for adslmib-archive@odin.ietf.org; Thu, 25 Mar 2004 20:24:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6g5R-0005qN-6X for adslmib-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 20:24:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07355 for <adslmib-web-archive@ietf.org>; Thu, 25 Mar 2004 20:24:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6g5P-0003st-00 for adslmib-web-archive@ietf.org; Thu, 25 Mar 2004 20:24:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6g4a-0003q5-00 for adslmib-web-archive@ietf.org; Thu, 25 Mar 2004 20:23:49 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6g3q-0003mP-00 for adslmib-web-archive@ietf.org; Thu, 25 Mar 2004 20:23:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6g3q-0005l7-0e; Thu, 25 Mar 2004 20:23:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6g3O-0005k0-NP for adslmib@optimus.ietf.org; Thu, 25 Mar 2004 20:22:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07258 for <adslmib@ietf.org>; Thu, 25 Mar 2004 20:22:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6g3M-0003jX-00 for adslmib@ietf.org; Thu, 25 Mar 2004 20:22:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6g2O-0003f3-00 for adslmib@ietf.org; Thu, 25 Mar 2004 20:21:32 -0500
Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1B6g1Q-0003bA-00 for adslmib@ietf.org; Thu, 25 Mar 2004 20:20:33 -0500
Received: from h-68-164-153-96.snvacaid.dynamic.covad.net ([68.164.153.96] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B6g1Q-0003sr-00 for adslmib@ietf.org; Thu, 25 Mar 2004 17:20:32 -0800
Message-ID: <000501c412d0$e740d5e0$7f1afea9@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: adslmib@ietf.org
Date: Thu, 25 Mar 2004 17:23:10 -0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02.txt
Sender: adslmib-admin@ietf.org
Errors-To: adslmib-admin@ietf.org
X-BeenThere: adslmib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=unsubscribe>
List-Id: ADSLMIB <adslmib.ietf.org>
List-Post: <mailto:adslmib@ietf.org>
List-Help: <mailto:adslmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60

Hi -

Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02.txt:

section 2 says:
   The MIB module is located in the MIB tree under MIB 2 transmission,
   as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section
   of this document.
but this is not how the MODULE-IDENTITY is done, and there is no
"MIB-2 Integration" section!


The table of table relationships in section 2.3 doesn't
quite match up with what the MIB says.  For example,
the relationship with entries in vdslLineMCMConfProfileTxBandTable
appears to be 1:(0..n) rather than 1:(0..1), due to the
presence of the second index, vdslLineMCMConfProfileTxBandNumber.
Ditto vdslLineMCMConfProfileTxBandTable,
vdslLineMCMConfProfileTxPSDTable, etc.

section 3 says:
    For MCM VDSL lines, the following group is optional:
      -  vdslMCMGroup
This is the only group defined here.  Earlier sections also
say things like "None, some or all of the objects in this
group MAY be implemented for MCM VDSL lines."  This seems odd.
I can understand how implementation of this MIB module might
be optional, but if someone implements it, surely *something*
is required.  As the document is currently worded, an implementation
that implements none of it would seem to be able to claim conformance!
Is this what is intended?


vdslLineMCMConfProfileTable: "The entries in this table MUST
NOT be used for single carrier (SCM) VDSL lines."  What
enforces this constraint?


vdslLineMCMConfProfileEntry: "A default profile with an
index of 'DEFVAL', will always exist" begs the question:
when there is a vdslLineConfProfileEntry with an index of
"DEFVAL", will it apply to *both* the MCM and the SCM
"DEFVAL" entries?


Are there any constraints on the values of
vdslMCMConfProfileTxBandStart and vdslMCMConfProfileTxBandStop?
For example, can they overlap with the values used in other
rows?  What is meant by "validate the profile" (in the RowStatus
column)? Just this row? Or the whole thing?


Same questions for *RxBand*.



vdslLineMCMConfProfileMaxTxPSDTone: can multiple rows be defined
for a particular profile with the same value for this column?


vdslLineMCMConfProfileTxPSDPSD: UNITS says "dBm" but description
says "dB", but then says the offset is in units of "dbm/Hz"


vdslLineMCMConfProfileMaxRxPSDTable: same issues as for
vdslLineMCMConfProfileMaxTxPSDTable.


For the indexes like vdslLineMCMConfProfileMaxTxPSDNumber,
is there any significance to the order of the entries in
a profile?


For ALL RowStatus objects, please see the "NOTE WELL" on page 8
of RFC 2579.  Specifically:
  - can other columns be modified when a row is active?
Since the other columns in these tables lack DEFVALs, it
might also be a good idea to say whether rows can go active
if these other columns have not yet been set.


Section 5: one minor thing to think about is that due to the
way in which "referenced" profile entries cannot be deleted,
a line configuration (to which a manager does not have access),
by referencing a profile, might prevent that manager from
modifying the profile, particularly if modification of active
profiles is prohibited.


Additional Editorial comments:
RFC 3667 section 5.1 requires an "IPR Disclosure Acknowledgement"

The last word of section seven is indented differently from
the rest.  (Another way to look at it is that all of the content
of section seven except the last line is indented one space
too far.)


Randy




_______________________________________________
Adslmib mailing list
Adslmib@ietf.org
https://www1.ietf.org/mailman/listinfo/adslmib