Re: FW: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt
Bob Ray <rray@pesa.com> Mon, 29 March 2004 16:40 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 LAA11606 for <adslmib-archive@odin.ietf.org>; Mon, 29 Mar 2004 11:40:05 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7znV-0005R5-1N for adslmib-archive@odin.ietf.org; Mon, 29 Mar 2004 11:39:37 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TGdbwb020890 for adslmib-archive@odin.ietf.org; Mon, 29 Mar 2004 11:39:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7znU-0005Qh-Kp for adslmib-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 11:39:36 -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 LAA11584 for <adslmib-web-archive@ietf.org>; Mon, 29 Mar 2004 11:39:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7znT-0006He-00 for adslmib-web-archive@ietf.org; Mon, 29 Mar 2004 11:39:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7zmd-0006Ag-00 for adslmib-web-archive@ietf.org; Mon, 29 Mar 2004 11:38:44 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7zlx-00063B-00 for adslmib-web-archive@ietf.org; Mon, 29 Mar 2004 11:38:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zlx-0005Gv-9K; Mon, 29 Mar 2004 11:38:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7zlV-0005B1-Ce for adslmib@optimus.ietf.org; Mon, 29 Mar 2004 11:37:33 -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 LAA11533 for <adslmib@ietf.org>; Mon, 29 Mar 2004 11:37:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7zlU-00062H-00 for adslmib@ietf.org; Mon, 29 Mar 2004 11:37:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7zkV-0005vW-00 for adslmib@ietf.org; Mon, 29 Mar 2004 11:36:32 -0500
Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B7zkM-0005pB-00 for adslmib@ietf.org; Mon, 29 Mar 2004 11:36:22 -0500
Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2TGaKKZ805059 for <adslmib@ietf.org>; Mon, 29 Mar 2004 10:36:21 -0600 (CST)
Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.1.R) with ESMTP id md50000011264.msg for <adslmib@ietf.org>; Mon, 29 Mar 2004 10:36:18 -0600
Subject: Re: FW: [Adslmib] Technical comments on draft-ietf-adslmib-vdsl-ext-mcm-02. txt
From: Bob Ray <rray@pesa.com>
Reply-To: rray@pesa.com
To: Menachem Dodge <Menachem.Dodge@infineon.com>
Cc: adslmib mail list <adslmib@ietf.org>
In-Reply-To: <AD2F581BD7340A4C908AF1AFB066EA3B0CA3FE@ntah901e.savan.com>
References: <AD2F581BD7340A4C908AF1AFB066EA3B0CA3FE@ntah901e.savan.com>
Content-Type: text/plain
Message-Id: <1080578172.2621.96.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7)
Date: Mon, 29 Mar 2004 10:36:13 -0600
Content-Transfer-Encoding: 7bit
X-Spam-Processed: pesa.com, Mon, 29 Mar 2004 10:36:18 -0600 (not processed: message from valid local sender)
X-MDRemoteIP: 192.168.0.179
X-Return-Path: rray@pesa.com
X-MDaemon-Deliver-To: adslmib@ietf.org
X-MDAV-Processed: pesa.com, Mon, 29 Mar 2004 10:36:20 -0600
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
On Mon, 2004-03-29 at 08:24, Menachem.Dodge@infineon.com wrote: > 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! > >>>>> > Menachem: I will replace this paragraph by: > > The MIB module is located in the MIB tree under the vdslMIB, which > in turn is found under MIB 2 transmission, refer to RFC 3728 > [RFC3728]. > > >>>>>> Looks accurate to me. You might consider changing ", refer to RFC 3728" to ". The reader is referred to RFC 3728 [RFC3728] for further discussion of this subject." > 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. > > >>>>>> > > Menachem: I'll change these to (0..n) > Ok by me. > > >>>>>> > > 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? This wording is a by-product of splitting one draft into three. The intent is that a MCM-based VDSL agent does not have to implement this MIB to be compliant with RFC 3728. > >>>>>> > > Menachem: Replace with : > > > If the MCM VDSL Line Extension MIB is implemented then all of the > objects in this group MUST be implemented. > Which addresses Randy's concern. > vdslLineMCMConfProfileTable: "The entries in this table MUST NOT be used > for single carrier (SCM) VDSL lines." What enforces this constraint? > > >>>>> > > Menachem: I will remove this sentence. > > Ok by me. > >>>>>> > > > > 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? > > > >>>>>> > > Menachem: I will remove this sentence. As these are optional a > default value is not necessary. > > >>>>>> A default vdslLineConfProfileEntry will exist (per RFC 3728). That it will apply to both MCM and SCM "DEFVAL" entries is true as it (vdslLineConfProfileEntry) contains no line code specific objects. If I rephrase Randy's question, then, perhaps he is asking if a vdslLineConfProfileEntry may exist that applies to BOTH an MCM modem and a SCM modem. To which I answer, heartily, "Yes!". Further, if an agent implements the MCM MIB, then it MUST have a 'DEFVAL' entry in the vdslLineMCMConfProfileTable. That this entry does not apply to SCM modems (or coffee pots for that matter) is not something I intend to lose sleep over. That is, Randy is right, although I thought the point was ... obvious. > > 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*. > > > >>>>> > > Menachem: Bob, what do you suggest ? > > >>>>> > A given MCM line is configured with a band table. A band table consists of a collection of rows, each defining a specific band. These bands must not overlap. To validate a band table entry (vdslLineMCMConfProfileTxBandEntry) then means to ensure that it makes sense in the context of a profile entry. A band must be internally consistent (Stop > Start). A band must be externally consistent in the context of all bands defined for that profile. I think we should add words that state this (to both the Tx and Rx structures). > > vdslLineMCMConfProfileMaxTxPSDTone: can multiple rows be defined for a > particular profile with the same value for this column? > > > >>>>> > > Menachem: Bob, what do you suggest ? > > >>>>> I have to look that one up... I think they are distinct. Maybe someone else can speak up quickly? > > > vdslLineMCMConfProfileTxPSDPSD: UNITS says "dBm" but description says > "dB", but then says the offset is in units of "dbm/Hz" > > >>>>>> > > Menachem: I will change all units to dBm/Hz. > > >>>>>> > Ok. > > > vdslLineMCMConfProfileMaxRxPSDTable: same issues as for > vdslLineMCMConfProfileMaxTxPSDTable. > > > For the indexes like vdslLineMCMConfProfileMaxTxPSDNumber, > is there any significance to the order of the entries in > a profile? > > >>>>> > > Menachem: The order is not significant. Bob, if you agree then > I'll add a comment stating this. > > >>>>> Ok. > > > > 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. > > > >>>>> > > Menachem: Bob, what do you suggest ? > > >>>>> My opinion is that a row must be internally and externally consistent (see above) before it can become active. I don't think a band table should support being changed "on-the-fly" (which is what the NOTE WELL is asking us to consider). That is, if a line is live using one band table, don't change the band table. Either a) create a new band table/profile and switch to that one, or b) disable the line then change the band table/profile. If everyone else is ok with this, then we just need to say so... > 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. > > >>>>> > > Menachem: Bob, what do you suggest ? > > >>>>> I think this is just the way it should be. > > > Additional Editorial comments: > RFC 3667 section 5.1 requires an "IPR Disclosure Acknowledgement" > > >>>>>> > > Menachem: I'll add this section before the Full Copyright > Statement: > > 9. IPR Disclosure Acknowledgement > > "By submitting this Internet-Draft, I certify that any applicable > patent or other IPR claims of which I am aware have been disclosed, > and any of which I become aware will be disclosed, in accordance with > RFC 3668." > > >>>>>>> > Sigh. What a world, eh? -- Bob Ray <rray@pesa.com> _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib
- FW: [Adslmib] Technical comments on draft-ietf-ad… Menachem.Dodge
- Re: FW: [Adslmib] Technical comments on draft-iet… Bob Ray
- Re: [Adslmib] Technical comments on draft-ietf-ad… Randy Presuhn
- Re: [Adslmib] Technical comments on draft-ietf-ad… Randy Presuhn