From exim@www1.ietf.org Tue Feb 3 13:38:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23641 for ; Tue, 3 Feb 2004 13:38:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Qb-0003Ii-SW for adslmib-archive@odin.ietf.org; Tue, 03 Feb 2004 13:37:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Ibflh012678 for adslmib-archive@odin.ietf.org; Tue, 3 Feb 2004 13:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Qb-0003IH-B4 for adslmib-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 13:37: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 NAA23627 for ; Tue, 3 Feb 2004 13:37:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5QZ-00044v-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 13:37:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5Pd-0003yo-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 13:36:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5Oy-0003sq-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 13:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Oz-000310-BX; Tue, 03 Feb 2004 13:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5OV-0002yR-Oq for adslmib@optimus.ietf.org; Tue, 03 Feb 2004 13:35:32 -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 NAA23487 for ; Tue, 3 Feb 2004 13:35:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5OT-0003qH-00 for adslmib@ietf.org; Tue, 03 Feb 2004 13:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5NV-0003j7-00 for adslmib@ietf.org; Tue, 03 Feb 2004 13:34:29 -0500 Received: from bee.hiwaay.net ([216.180.54.11] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1Ao5MS-0003Xu-00 for adslmib@ietf.org; Tue, 03 Feb 2004 13:33:29 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i13IXOwP1105661 for ; Tue, 3 Feb 2004 12:33:24 -0600 (CST) Received: from 192.168.0.122 ([192.168.0.122]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 2-md50000000157.tmp for ; Tue, 03 Feb 2004 12:33:21 -0600 Subject: Re: [Adslmib] RFC3276 interpretation - line rate in 4-wire mode From: bob ray Reply-To: robertray@knology.net To: Matt Beanland Cc: "'adslmib@ietf.org'" In-Reply-To: <257FD1F0FF27504780EB0569C17A86341ED9D5@email.extel.com.au> References: <257FD1F0FF27504780EB0569C17A86341ED9D5@email.extel.com.au> Content-Type: text/plain Message-Id: <1075833201.27870.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 03 Feb 2004 12:33:21 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Tue, 03 Feb 2004 12:33:21 -0600 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 192.168.0.122 X-Return-Path: robertray@knology.net X-MDaemon-Deliver-To: adslmib@ietf.org 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Looks like a revision is in order, although it will only require changing 4 numbers. The greater effort will be converting all the text back to draft form... I'm sure there will be other changes (references, etc.) that will creep in. Anyone else have a comment? Bob Ray On Mon, 2004-01-19 at 01:42, Matt Beanland wrote: > Hi all, > > > > We have a 4-wire implementation of SHDSL using RFC3276 and have a > question whether the MIB items: > > > > hdsl2ShdslStatusMaxAttainableLineRate > hdsl2ShdslStatusActualLineRate > hdsl2ShdslSpanConfMinLineRate > > hdsl2ShdslSpanConfMaxLineRate > > > > apply individually to all wire pairs in the SHDSL span, or are for the > total? > > > > These items have a range of 0..4112000 b/s. As such, they appear to > lack the upper range for 4-wire operation according to ITU G.991.2 > section E.9.2.1, which allows operation up to 2 * (36*64+8) = 4624 > kb/s. > > > > Thanks for any assistance, > > > > Matt Beanland > > Extel Communications > 399 Ferntree Gully Road, Mt Waverley, Victoria 3149, Australia > Ph: +613 8542 9259 Fax: +613 8542 9299 _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Feb 3 15:09:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27922 for ; Tue, 3 Feb 2004 15:09: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 1Ao6qc-00021s-MA for adslmib-archive@odin.ietf.org; Tue, 03 Feb 2004 15:08:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13K8cKd007794 for adslmib-archive@odin.ietf.org; Tue, 3 Feb 2004 15:08:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6qc-00021d-Gv for adslmib-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:08:38 -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 PAA27874 for ; Tue, 3 Feb 2004 15:08:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6qZ-0005sB-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 15:08:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6pc-0005nM-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 15:07:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6p4-0005iZ-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 15:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6p3-0001AF-CM; Tue, 03 Feb 2004 15:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6ok-0000xu-NN for adslmib@optimus.ietf.org; Tue, 03 Feb 2004 15:06:42 -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 PAA27749 for ; Tue, 3 Feb 2004 15:06:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6oh-0005i9-00 for adslmib@ietf.org; Tue, 03 Feb 2004 15:06:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6nm-0005d6-00 for adslmib@ietf.org; Tue, 03 Feb 2004 15:05:43 -0500 Received: from 135090022016.paradyne.com ([135.90.22.16] helo=pigeon.is.paradyne.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao6nQ-0005XJ-00 for adslmib@ietf.org; Tue, 03 Feb 2004 15:05:21 -0500 Received: from paradyne.com ([135.26.21.95]) by pigeon.is.paradyne.com (Netscape Messaging Server 4.15) with ESMTP id HSIYFD00.9ZJ; Tue, 3 Feb 2004 15:04:25 -0500 Message-ID: <401FFEDC.2010108@paradyne.com> Date: Tue, 03 Feb 2004 15:04:44 -0500 From: "Clay Sikes" Organization: Paradyne Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: robertray@knology.net CC: Matt Beanland , "'adslmib@ietf.org'" Subject: Re: [Adslmib] RFC3276 interpretation - line rate in 4-wire mode References: <257FD1F0FF27504780EB0569C17A86341ED9D5@email.extel.com.au> <1075833201.27870.12.camel@localhost.localdomain> In-Reply-To: <1075833201.27870.12.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bob Ray, On 09, Oct 2003, I asked about modifications to RFC 3276 in support for G.shdsl.bis. If you are going to open up this MIB for modifications, please, please consider support for G.shdsl.bis. The following is a copy of the 09, Oct 2003 email. I think some things that were provisional when I send the original email have now been decided. I think the issues are with line rates which it looks like you are going to address and with the addition of a third and fourth wire pair. **** BEGIN COPY **** The ITU has a Temporary Document, DC-R15, April 2003, out for G.shdsl.bis. It looks like some MIB objects in the HDSL2-SHDSL-LINE-MIB, RFC 3276, may need to be updated to support G.sdhsl.bis. From the ITU document, it looks like the changes needed in the MIB would be to support M-pair Mode where M is up to four of wire pairs and an increased line rate. The increased line rate is a bit of a sticking point in that the ITU document does not define a upper limit on the Line Rate as the "**max** " and "** max n**" provisional numbers are in use. It appears that the following in the MIB would need to be modified to support G.shdsl.bis: 1. Hdsl2ShdslWirePair TC - Needs to have wirePair3(3) and wirePair4(4)enumerations added. 2. hdsl2ShdslSpanConfWireInterface - Needs to have sixWire(3) and eightWire(4) added. 3. hdsl2ShdslStatusMaxAttainableLineRate - See Max Line Rate Comment below. 4. hdsl2ShdslStatusActualLineRate - See Max Line Rate Comment below. 5. hdsl2ShdslSpanConfMinLineRate - See Max Line Rate Comment below. 6. hdsl2ShdslSpanConfMaxLineRate - See Max Line Rate Comment below. Max Line Rate Comment Given that an absolute upper limit in the line rate has not be nailed down, initial chip sets are likely to support different max rates. Would it be possible to remove the range limit on the Unsigned32 syntax for all v objects? Thoughts? Is there anything in the works for MIB supporting G.shdsl.bis? Chip sets are becoming available and products will be following shortly. If there is anything that I can do: edit, propose, discuss, anything, please let me know. Best Regards, Clay Sikes **** END COPY **** Thanks for considering this! Best Regards, Clay Sikes bob ray wrote: >Looks like a revision is in order, although it will only >require changing 4 numbers. The greater effort will be >converting all the text back to draft form... I'm sure >there will be other changes (references, etc.) that will >creep in. > >Anyone else have a comment? > >Bob Ray > >On Mon, 2004-01-19 at 01:42, Matt Beanland wrote: > > >>Hi all, >> >> >> >>We have a 4-wire implementation of SHDSL using RFC3276 and have a >>question whether the MIB items: >> >> >> >>hdsl2ShdslStatusMaxAttainableLineRate >>hdsl2ShdslStatusActualLineRate >>hdsl2ShdslSpanConfMinLineRate >> >>hdsl2ShdslSpanConfMaxLineRate >> >> >> >>apply individually to all wire pairs in the SHDSL span, or are for the >>total? >> >> >> >>These items have a range of 0..4112000 b/s. As such, they appear to >>lack the upper range for 4-wire operation according to ITU G.991.2 >>section E.9.2.1, which allows operation up to 2 * (36*64+8) = 4624 >>kb/s. >> >> >> >>Thanks for any assistance, >> >> >> >>Matt Beanland >> >>Extel Communications >>399 Ferntree Gully Road, Mt Waverley, Victoria 3149, Australia >>Ph: +613 8542 9259 Fax: +613 8542 9299 >> >> > > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www1.ietf.org/mailman/listinfo/adslmib > > _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Feb 3 15:33:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29405 for ; Tue, 3 Feb 2004 15:33:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Dp-0007AM-LS for adslmib-archive@odin.ietf.org; Tue, 03 Feb 2004 15:32:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KWbuj027545 for adslmib-archive@odin.ietf.org; Tue, 3 Feb 2004 15:32:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Dp-0007AC-HN for adslmib-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:32:37 -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 PAA29401 for ; Tue, 3 Feb 2004 15:32:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Do-0000GP-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 15:32:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Cu-0000BV-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 15:31:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7CH-00006A-00 for adslmib-web-archive@ietf.org; Tue, 03 Feb 2004 15:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7CH-00071C-H8; Tue, 03 Feb 2004 15:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Br-00070H-0s for adslmib@optimus.ietf.org; Tue, 03 Feb 2004 15:30:35 -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 PAA29318 for ; Tue, 3 Feb 2004 15:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Bp-00004Y-00 for adslmib@ietf.org; Tue, 03 Feb 2004 15:30:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7At-0007n3-00 for adslmib@ietf.org; Tue, 03 Feb 2004 15:29:36 -0500 Received: from bee.hiwaay.net ([216.180.54.11] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1Ao79w-0007iF-00 for adslmib@ietf.org; Tue, 03 Feb 2004 15:28:36 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i13KSZN01194283 for ; Tue, 3 Feb 2004 14:28:35 -0600 (CST) Received: from 192.168.0.122 ([192.168.0.122]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 18-md50000000159.tmp for ; Tue, 03 Feb 2004 14:28:35 -0600 Subject: Re: [Adslmib] RFC3276 interpretation - line rate in 4-wire mode From: bob ray Reply-To: robertray@knology.net To: adslmib mail list In-Reply-To: <401FFEDC.2010108@paradyne.com> References: <257FD1F0FF27504780EB0569C17A86341ED9D5@email.extel.com.au> <1075833201.27870.12.camel@localhost.localdomain> <401FFEDC.2010108@paradyne.com> Content-Type: text/plain Message-Id: <1075840114.27870.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 03 Feb 2004 14:28:34 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Tue, 03 Feb 2004 14:28:35 -0600 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 192.168.0.122 X-Return-Path: robertray@knology.net X-MDaemon-Deliver-To: adslmib@ietf.org 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tue, 2004-02-03 at 14:04, Clay Sikes wrote: > Bob Ray, > > On 09, Oct 2003, I asked about modifications to RFC 3276 in support for > G.shdsl.bis. If you are going to open up this MIB for modifications, > please, please consider support for G.shdsl.bis. The following is a copy > of the 09, Oct 2003 email. I think some things that were provisional > when I send the original email have now been decided. > > I think the issues are with line rates which it looks like you are going > to address and with the addition of a third and fourth wire pair. > Clay (and others): I have been, unfortunately, OUT of the telecommunications industry for over two years. In many ways, I'm just glad to be employed (as being unemployed is NOT FUN). I have no official status in the IETF other than guy-who-wrote-a-draft. You, too, can be a "guy-who-wrote-a-draft". Or two. Or three. :) If you see changes that need to be made because of g.shdsl.bis, I would encourage you to "take up the banner" and submit a draft/revision, then pester the various working groups, technical advisers, chairs, committees, and industry/trade groups to see it through. Bob Ray > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www1.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Feb 10 17:47:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27159 for ; Tue, 10 Feb 2004 17:47:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgey-0002YI-Fy for adslmib-archive@odin.ietf.org; Tue, 10 Feb 2004 17:47:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMlGY3009806 for adslmib-archive@odin.ietf.org; Tue, 10 Feb 2004 17:47:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgey-0002Y5-Ay for adslmib-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:47:16 -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 RAA27111 for ; Tue, 10 Feb 2004 17:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgev-00037X-00 for adslmib-web-archive@ietf.org; Tue, 10 Feb 2004 17:47:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqge4-000321-00 for adslmib-web-archive@ietf.org; Tue, 10 Feb 2004 17:46:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgdm-0002wG-00 for adslmib-web-archive@ietf.org; Tue, 10 Feb 2004 17:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgdm-0002Fw-98; Tue, 10 Feb 2004 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgcu-0002CH-T6 for adslmib@optimus.ietf.org; Tue, 10 Feb 2004 17:45:08 -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 RAA26998 for ; Tue, 10 Feb 2004 17:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgcs-0002ue-00 for adslmib@ietf.org; Tue, 10 Feb 2004 17:45:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgbt-0002pv-00 for adslmib@ietf.org; Tue, 10 Feb 2004 17:44:06 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1Aqgaz-0002lb-00 for adslmib@ietf.org; Tue, 10 Feb 2004 17:43:09 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i1AMh9tM615176 for ; Tue, 10 Feb 2004 16:43:09 -0600 (CST) Received: from 192.168.0.122 ([192.168.0.122]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 63-md50000000237.tmp for ; Tue, 10 Feb 2004 16:43:07 -0600 From: Bob Ray Reply-To: rray@pesa.com To: adslmib mail list In-Reply-To: <1075840114.27870.54.camel@localhost.localdomain> References: <257FD1F0FF27504780EB0569C17A86341ED9D5@email.extel.com.au> <1075833201.27870.12.camel@localhost.localdomain> <401FFEDC.2010108@paradyne.com> <1075840114.27870.54.camel@localhost.localdomain> Content-Type: text/plain Message-Id: <1076452986.15472.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 10 Feb 2004 16:43:07 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Tue, 10 Feb 2004 16:43:07 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.122 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: adslmib@ietf.org Content-Transfer-Encoding: 7bit Subject: [Adslmib] RFC3276 respin 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If ("IF") there were another spin on RFC3276, then, would the following list of changes suffice to support g.shdsl.bis (from Clay's list)? 1. Hdsl2ShdslWirePair TC - add wirePair3(3) and wirePair4(4) 2. hdsl2ShdslSpanConfWireInterface - add sixWire(3) and eightWire(4) 3. hdsl2ShdslStatusMaxAttainableLineRate - remove the range limit 4. hdsl2ShdslStatusActualLineRate - remove the range limit 5. hdsl2ShdslSpanConfMinLineRate - remove the range limit 6. hdsl2ShdslSpanConfMaxLineRate - remove the range limit Would these do it? Would this be all? Would this break any existing implementations (at least of embedded agents)? Would the above break any management apps? It doesn't look like it would - it sure looks like any new devices would simply have a "looser" range of values in 5 objects. -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Feb 10 21:56:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14169 for ; Tue, 10 Feb 2004 21:56:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkXF-0003Dx-BG for adslmib-archive@odin.ietf.org; Tue, 10 Feb 2004 21:55:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B2tXKv012389 for adslmib-archive@odin.ietf.org; Tue, 10 Feb 2004 21:55:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkXF-0003Dg-5i for adslmib-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 21:55: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 VAA14164 for ; Tue, 10 Feb 2004 21:55:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkXC-0003wS-00 for adslmib-web-archive@ietf.org; Tue, 10 Feb 2004 21:55:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkWP-0003pq-00 for adslmib-web-archive@ietf.org; Tue, 10 Feb 2004 21:54:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqkVj-0003hM-00 for adslmib-web-archive@ietf.org; Tue, 10 Feb 2004 21:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkVk-00037L-V6; Tue, 10 Feb 2004 21:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkV8-00031p-QX for adslmib@optimus.ietf.org; Tue, 10 Feb 2004 21:53:22 -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 VAA14088 for ; Tue, 10 Feb 2004 21:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkV5-0003fs-00 for adslmib@ietf.org; Tue, 10 Feb 2004 21:53:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkU9-0003aH-00 for adslmib@ietf.org; Tue, 10 Feb 2004 21:52:22 -0500 Received: from mail.extel.com.au ([203.94.160.3] helo=server2.extel.com.au) by ietf-mx with esmtp (Exim 4.12) id 1AqkTf-0003U9-00 for adslmib@ietf.org; Tue, 10 Feb 2004 21:51:51 -0500 Received: by SERVER2 with Internet Mail Service (5.5.2650.21) id <1ST0FJCS>; Wed, 11 Feb 2004 13:51:19 +1100 Message-ID: <257FD1F0FF27504780EB0569C17A86341EDA81@email.extel.com.au> From: Matt Beanland To: "'rray@pesa.com'" , adslmib mail list Subject: RE: [Adslmib] RFC3276 respin Date: Wed, 11 Feb 2004 13:51:18 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F049.EC740A54" 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: , List-Id: ADSLMIB List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,EXCUSE_16,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F049.EC740A54 Content-Type: text/plain Hi, Firstly, thanks to all those who were involved in RFC3276. We would hope that a new draft would include a guide for implementing the mib-2 if table, and specifically would clarify the following issue: The difficulties we are having relate to the relationship between interfaces and wirepairs. Convention is to have an ifIndex for each physical interface (wirepair). When interfaces are being operated as multi-pair, should each interface just implement one wirepair, or should the lowest interface just implement all wirepairs? Assuming the latter, then the training state for an individual wirepair is missing (the ifOperStatus in the ifTable would give the operational state for the entire line, not for each wirepair). We are doing a 4-wire implementation and have extended the hdsl2ShdslEndpointCurrTable (via our enterprise MIB) to add the hdsl2ShdslEndpointCurrLineState item, so that we can see the line state for each wirepair. Also with multiple wirepairs, it would be nice to be able to determine if wirepairs are swapped on a segment, although it is probably implementation specific as to whether this capability exists. Best Regards, Matt Extel Communications 399 Ferntree Gully Road, Mt Waverley, Victoria 3149, Australia Ph: +613 8542 9259 Fax: +613 8542 9299 -----Original Message----- From: Bob Ray [mailto:rray@pesa.com] Sent: Wednesday, 11 February 2004 9:43 AM To: adslmib mail list Subject: [Adslmib] RFC3276 respin If ("IF") there were another spin on RFC3276, then, would the following list of changes suffice to support g.shdsl.bis (from Clay's list)? 1. Hdsl2ShdslWirePair TC - add wirePair3(3) and wirePair4(4) 2. hdsl2ShdslSpanConfWireInterface - add sixWire(3) and eightWire(4) 3. hdsl2ShdslStatusMaxAttainableLineRate - remove the range limit 4. hdsl2ShdslStatusActualLineRate - remove the range limit 5. hdsl2ShdslSpanConfMinLineRate - remove the range limit 6. hdsl2ShdslSpanConfMaxLineRate - remove the range limit Would these do it? Would this be all? Would this break any existing implementations (at least of embedded agents)? Would the above break any management apps? It doesn't look like it would - it sure looks like any new devices would simply have a "looser" range of values in 5 objects. -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib ---------------------------------------------------------------------------- ------------------------ The information contained in this message and any attachments is confidential and intended for the named recipient(s). If you have received this message in error, please contact sender by return e-mail and destroy the message and any attachments. Any opinions or undertakings expressed in this message are those of the individual sender except where the sender expressly and with authority states them to be the opinions of Extel. ---------------------------------------------------------------------------- ------------------------ ------_=_NextPart_001_01C3F049.EC740A54 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Adslmib] RFC3276 respin

Hi,

Firstly, thanks to all those who were involved in = RFC3276.

We would hope that a new draft would include a guide = for implementing the mib-2 if table, and specifically would clarify the = following issue:

The difficulties we are having relate to the = relationship between interfaces and wirepairs. Convention is to have an = ifIndex for each physical interface (wirepair). When interfaces are = being operated as multi-pair, should each interface just implement one = wirepair, or should the lowest interface just implement all = wirepairs?

Assuming the latter, then the training state for an = individual wirepair is missing (the ifOperStatus in the ifTable would = give the operational state for the entire line, not for each = wirepair).

We are doing a 4-wire implementation and have = extended the hdsl2ShdslEndpointCurrTable (via our enterprise MIB) to = add the hdsl2ShdslEndpointCurrLineState item, so that we can see the = line state for each wirepair.

Also with multiple wirepairs, it would be nice to be = able to determine if wirepairs are swapped on a segment, although it is = probably implementation specific as to whether this capability = exists.

Best Regards,

Matt

Extel Communications
399 Ferntree Gully Road, Mt Waverley, Victoria 3149, = Australia
Ph: +613 8542 9259 Fax: +613 8542 9299


-----Original Message-----
From: Bob Ray [mailto:rray@pesa.com]
Sent: Wednesday, 11 February 2004 9:43 AM
To: adslmib mail list
Subject: [Adslmib] RFC3276 respin

If ("IF") there were another spin on = RFC3276, then, would the following
list of changes suffice to support g.shdsl.bis (from = Clay's list)?

1. Hdsl2ShdslWirePair TC - add wirePair3(3) and = wirePair4(4)
2. hdsl2ShdslSpanConfWireInterface - add sixWire(3) = and eightWire(4)
3. hdsl2ShdslStatusMaxAttainableLineRate - remove = the range limit
4. hdsl2ShdslStatusActualLineRate - remove the range = limit
5. hdsl2ShdslSpanConfMinLineRate - remove the range = limit
6. hdsl2ShdslSpanConfMaxLineRate - remove the range = limit

Would these do it?  Would this be all?  = Would this break any existing
implementations (at least of embedded agents)?  = Would the above break
any management apps? 

It doesn't look like it would - it sure looks like = any new devices
would simply have a "looser" range of = values in 5 objects.

--
Bob Ray <rray@pesa.com>


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

---------------------------------------------------------------= -------------------------------------
The information contained in this message and any = attachments is
confidential and intended for the named = recipient(s). If you have received
this message in error, please contact sender by = return e-mail and
destroy the message and any attachments.
Any opinions or undertakings expressed in this = message are those of the
individual sender except where the sender expressly = and with authority
states them to be the opinions of Extel.
---------------------------------------------------------------= -------------------------------------

------_=_NextPart_001_01C3F049.EC740A54-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Wed Feb 11 07:39:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29130 for ; Wed, 11 Feb 2004 07:39:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqtda-0006ZH-Cv for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 07:38:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BCcgo4025243 for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 07:38:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqtda-0006Z4-8I for adslmib-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 07:38:42 -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 HAA29115 for ; Wed, 11 Feb 2004 07:38:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqtdZ-0006ab-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 07:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqtcf-0006Uz-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 07:37:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqtbz-0006PP-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 07:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqtby-0006E4-9O; Wed, 11 Feb 2004 07:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqtbg-0006DF-3R for adslmib@optimus.ietf.org; Wed, 11 Feb 2004 07:36:44 -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 HAA29054 for ; Wed, 11 Feb 2004 07:36:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqtbf-0006Oh-00 for adslmib@ietf.org; Wed, 11 Feb 2004 07:36:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqtam-0006J6-00 for adslmib@ietf.org; Wed, 11 Feb 2004 07:35:48 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqtaK-0006Cy-00 for adslmib@ietf.org; Wed, 11 Feb 2004 07:35:20 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BCYkD17222 for ; Wed, 11 Feb 2004 06:34:47 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 11 Feb 2004 13:34:45 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC59F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'rray@pesa.com'" , adslmib mail list Subject: RE: [Adslmib] RFC3276 respin Date: Wed, 11 Feb 2004 13:34:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: , List-Id: ADSLMIB List-Post: List-Help: List-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 > If ("IF") there were another spin on RFC3276, then, would the following > list of changes suffice to support g.shdsl.bis (from Clay's list)? > > 1. Hdsl2ShdslWirePair TC - add wirePair3(3) and wirePair4(4) > 2. hdsl2ShdslSpanConfWireInterface - add sixWire(3) and eightWire(4) > 3. hdsl2ShdslStatusMaxAttainableLineRate - remove the range limit > 4. hdsl2ShdslStatusActualLineRate - remove the range limit > 5. hdsl2ShdslSpanConfMinLineRate - remove the range limit > 6. hdsl2ShdslSpanConfMaxLineRate - remove the range limit > > Would these do it? Would this be all? Would this break any existing > implementations (at least of embedded agents)? Would the above break > any management apps? > > It doesn't look like it would - it sure looks like any new devices > would simply have a "looser" range of values in 5 objects. > Formally, I do not think that you can remove the range limits. See RFC2578, sect 10. However, I agree that it does not seem to be harmfull. It certainly would not have any impact for the on the wire protocol. I think I could go along with the change if we were to update the current MODULE-COMPLIANCE such that the current ranges are inlcuded there, and then do a new MODULE-COMPLIANCE that allows for the new values, certainly for the read-write objects. Similar fixes to MODULE-COMPLIANCE would be recommend for the enumerated objects. Hope this helps, Bert > -- > Bob Ray > > > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www1.ietf.org/mailman/listinfo/adslmib > _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Wed Feb 11 10:23:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05027 for ; Wed, 11 Feb 2004 10:23:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwCO-0007x8-DD for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 10:22:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BFMmrS030567 for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 10:22:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwCO-0007ww-57 for adslmib-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 10:22:48 -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 KAA05020 for ; Wed, 11 Feb 2004 10:22:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwCL-0006z7-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 10:22:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwBS-0006tV-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 10:21:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqwAd-0006nL-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 10:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwAe-0007tr-I4; Wed, 11 Feb 2004 10:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwAO-0007tE-G1 for adslmib@optimus.ietf.org; Wed, 11 Feb 2004 10:20:44 -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 KAA04950 for ; Wed, 11 Feb 2004 10:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwAM-0006ls-00 for adslmib@ietf.org; Wed, 11 Feb 2004 10:20:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqw9S-0006gO-00 for adslmib@ietf.org; Wed, 11 Feb 2004 10:19:46 -0500 Received: from bee.hiwaay.net ([216.180.54.11] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1Aqw8Z-0006as-00 for adslmib@ietf.org; Wed, 11 Feb 2004 10:18:51 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i1BFIo7X1218395 for ; Wed, 11 Feb 2004 09:18:50 -0600 (CST) Received: from 192.168.0.122 ([192.168.0.122]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 32-md50000000243.tmp for ; Wed, 11 Feb 2004 09:18:48 -0600 Subject: RE: [Adslmib] RFC3276 respin From: Bob Ray Reply-To: rray@pesa.com To: "Bert (Bert) Wijnen" Cc: adslmib mail list In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC59F@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155028EC59F@nl0006exch001u.nl.lucent.com> Content-Type: text/plain Message-Id: <1076512728.16856.40.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 11 Feb 2004 09:18:48 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Wed, 11 Feb 2004 09:18:48 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.122 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: adslmib@ietf.org 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-02-11 at 06:34, Wijnen, Bert (Bert) wrote: > Formally, I do not think that you can remove the range limits. > See RFC2578, sect 10. Adding additional enumerations to Hdsl2ShdslWirePair and hdsl2ShdslSpanConfWireInterface are certainly allowed by 2578, section 10.2 note (1), so that is straight forward. > I think I could go along with the change if we were to update the > current MODULE-COMPLIANCE such that the current ranges are inlcuded > there, and then do a new MODULE-COMPLIANCE that allows for the new > values, certainly for the read-write objects. > > Similar fixes to MODULE-COMPLIANCE would be recommend for the enumerated > objects. I'm trying to understand - please bear with me. So, one would leave the original object declaration alone, such as: hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE SYNTAX Unsigned32(0..4112000) blah blah blah but add entries in the compliance section of the form: OBJECT hdsl2ShdslStatusMaxAttainableLineRate SYNTAX Unsigned32(0..92520000) DESCRIPTION "An extended range is applicable when implementing g.shdsl.bis." Is this right? If so, I guess similar entries would be required for hdsl2ShdslStatusActualLineRate, hdsl2ShdslSpanConfMinLineRate, and hdsl2ShdslSpanConfMaxLineRate. For hdsl2ShdslSpanConfWireInterface, then, would the following be the right syntax (in the compliance section)? OBJECT hdsl2ShdslSpanConfWireInterface SYNTAX INTEGER { twoWire(1), fourWire(2), sixWire(3), eightWire(4) } DESCRIPTION "An extended range is applicable when implementing g.shdsl.bis." If the above is correct, then, the only one left is the textual convention Hdsl2ShdslWirePair. How does one extend a textual convention in the compliance section? I don't think I've ever seen this done. Does one add an entry stating: TEXTUAL-CONVENTION Hdsl2ShdslWirePair SYNTAX INTEGER { wirePair1(1), wirePair2(2), wirePair3(3), wirePair4(4) } DESCRIPTION "An extended range is applicable when implementing g.shdsl.bis." Looks odd, I guess, but I don't know the way :) Process questions a) Were some industrious person to submit a "respin of 3276" with the above changes, would they submit a new draft to the ietf draft editor as an individual contribution or striaght away to the adslmib working group? b) Would this draft contain the full text of RFC3276 in draft form (vs RFC form) along with the above modifications? c) Would it be permissible to submit a draft noting the changes necessary to support g.shdsl.bis? That is, essentially a draft with all of the above changes discussed textually ala RFC3593? Bob _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Wed Feb 11 11:28:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07826 for ; Wed, 11 Feb 2004 11:28:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxDk-0004wF-3q for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGSGcX018982 for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 11:28:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxDj-0004w5-Rb for adslmib-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:28:15 -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 LAA07662 for ; Wed, 11 Feb 2004 11:28:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxDi-0006Va-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 11:28:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxBN-00062I-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 11:25:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxAR-0005vs-01 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 11:24:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqx8h-0002iG-Lu for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 11:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx8f-0004lq-92; Wed, 11 Feb 2004 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqx8X-0004lO-4k for adslmib@optimus.ietf.org; Wed, 11 Feb 2004 11:22:53 -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 LAA07521 for ; Wed, 11 Feb 2004 11:22:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqx8W-0005ke-00 for adslmib@ietf.org; Wed, 11 Feb 2004 11:22:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqx7c-0005fC-00 for adslmib@ietf.org; Wed, 11 Feb 2004 11:21:57 -0500 Received: from services.paradyne.com ([135.90.22.16] helo=pigeon.is.paradyne.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqx76-0005Z1-00 for adslmib@ietf.org; Wed, 11 Feb 2004 11:21:24 -0500 Received: from paradyne.com ([135.26.21.95]) by pigeon.is.paradyne.com (Netscape Messaging Server 4.15) with ESMTP id HSXHE500.58L; Wed, 11 Feb 2004 11:20:29 -0500 Message-ID: <402A5661.3060906@paradyne.com> Date: Wed, 11 Feb 2004 11:20:49 -0500 From: "Clay Sikes" Organization: Paradyne Corporation User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rray@pesa.com, "Bert (Bert) Wijnen" CC: adslmib mail list Subject: Re: [Adslmib] RFC3276 respin References: <7D5D48D2CAA3D84C813F5B154F43B155028EC59F@nl0006exch001u.nl.lucent.com> <1076512728.16856.40.camel@localhost.localdomain> In-Reply-To: <1076512728.16856.40.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bob and Bert, Thanks for moving this forward. On the limits for the rates, I think a lot of tools that compile MIBs for agents and managers may actually generate code to check any specified limits. I seem to recall, for example, the SNMP Research product does that. They may not actually use the MODULE-COMPLIANCE. If you would like, I could send them an email and ask them. Just let me know. If we can hammer out these details, with some guidance, I would be willing to help in any way. My employer won't send me to IETF meeting, but if there is anything I can do to help, I'm willing. It sounds like a great opportunity to learn the process and enable me to contribute in the future. Thanks! Clay Bob Ray wrote: >On Wed, 2004-02-11 at 06:34, Wijnen, Bert (Bert) wrote: > > > >>Formally, I do not think that you can remove the range limits. >>See RFC2578, sect 10. >> >> > >Adding additional enumerations to Hdsl2ShdslWirePair and >hdsl2ShdslSpanConfWireInterface are certainly allowed by 2578, >section 10.2 note (1), so that is straight forward. > > > >>I think I could go along with the change if we were to update the >>current MODULE-COMPLIANCE such that the current ranges are inlcuded >>there, and then do a new MODULE-COMPLIANCE that allows for the new >>values, certainly for the read-write objects. >> >>Similar fixes to MODULE-COMPLIANCE would be recommend for the enumerated >>objects. >> >> > >I'm trying to understand - please bear with me. > >So, one would leave the original object declaration alone, such as: > >hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE > SYNTAX Unsigned32(0..4112000) > blah blah blah > >but add entries in the compliance section of the form: > >OBJECT hdsl2ShdslStatusMaxAttainableLineRate > SYNTAX Unsigned32(0..92520000) > DESCRIPTION > "An extended range is applicable when implementing > g.shdsl.bis." > >Is this right? If so, I guess similar entries would be required for > hdsl2ShdslStatusActualLineRate, > hdsl2ShdslSpanConfMinLineRate, and > hdsl2ShdslSpanConfMaxLineRate. > >For hdsl2ShdslSpanConfWireInterface, then, would the following be >the right syntax (in the compliance section)? > >OBJECT hdsl2ShdslSpanConfWireInterface > SYNTAX INTEGER > { > twoWire(1), > fourWire(2), > sixWire(3), > eightWire(4) > } > DESCRIPTION > "An extended range is applicable when implementing > g.shdsl.bis." > >If the above is correct, then, the only one left is the textual >convention Hdsl2ShdslWirePair. How does one extend a textual convention >in the compliance section? I don't think I've ever seen this done. > >Does one add an entry stating: > >TEXTUAL-CONVENTION Hdsl2ShdslWirePair > SYNTAX INTEGER > { > wirePair1(1), > wirePair2(2), > wirePair3(3), > wirePair4(4) > } > DESCRIPTION > "An extended range is applicable when implementing > g.shdsl.bis." > >Looks odd, I guess, but I don't know the way :) > >Process questions > >a) Were some industrious person to submit a "respin of 3276" with the above >changes, would they submit a new draft to the ietf draft editor as an >individual contribution or striaght away to the adslmib working group? > >b) Would this draft contain the full text of RFC3276 in draft form (vs >RFC form) along with the above modifications? > >c) Would it be permissible to submit a draft noting the changes necessary >to support g.shdsl.bis? That is, essentially a draft with all of the >above changes discussed textually ala RFC3593? > >Bob > > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www1.ietf.org/mailman/listinfo/adslmib > > _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Wed Feb 11 12:58:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11656 for ; Wed, 11 Feb 2004 12:58:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqycN-0004Sx-U6 for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 12:57:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BHvlrh017160 for adslmib-archive@odin.ietf.org; Wed, 11 Feb 2004 12:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqycN-0004Sh-Q8 for adslmib-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 12:57:47 -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 MAA11643 for ; Wed, 11 Feb 2004 12:57:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqycM-0000aO-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 12:57:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqybO-0000VZ-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 12:56:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqyag-0000Qp-00 for adslmib-web-archive@ietf.org; Wed, 11 Feb 2004 12:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqyag-0004OL-7q; Wed, 11 Feb 2004 12:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqyaQ-0004Nk-LC for adslmib@optimus.ietf.org; Wed, 11 Feb 2004 12:55:47 -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 MAA11605 for ; Wed, 11 Feb 2004 12:55:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqyaO-0000QU-00 for adslmib@ietf.org; Wed, 11 Feb 2004 12:55:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqyZR-0000Lg-00 for adslmib@ietf.org; Wed, 11 Feb 2004 12:54:46 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1AqyYy-0000HC-00 for adslmib@ietf.org; Wed, 11 Feb 2004 12:54:16 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i1BHsDn1815680 for ; Wed, 11 Feb 2004 11:54:13 -0600 (CST) Received: from 192.168.0.122 ([192.168.0.122]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 48-md50000000246.tmp for ; Wed, 11 Feb 2004 11:54:12 -0600 Subject: Re: [Adslmib] RFC3276 respin From: Bob Ray Reply-To: rray@pesa.com To: Clay Sikes Cc: "Bert (Bert) Wijnen" , adslmib mail list In-Reply-To: <402A5661.3060906@paradyne.com> References: <7D5D48D2CAA3D84C813F5B154F43B155028EC59F@nl0006exch001u.nl.lucent.com> <1076512728.16856.40.camel@localhost.localdomain> <402A5661.3060906@paradyne.com> Content-Type: text/plain Message-Id: <1076522051.16856.76.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 11 Feb 2004 11:54:11 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Wed, 11 Feb 2004 11:54:12 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.122 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: adslmib@ietf.org 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-02-11 at 10:20, Clay Sikes wrote: > Bob and Bert, > > Thanks for moving this forward. > > On the limits for the rates, I think a lot of tools that compile MIBs > for agents and managers may actually generate code to check any > specified limits. I seem to recall, for example, the SNMP Research > product does that. They may not actually use the MODULE-COMPLIANCE. If > you would like, I could send them an email and ask them. Just let me know. And bother Dr.,er, Professor Case out on the farm? About this time of year, he's working full time securing pump handles. Rhetorically, if their recognizer/compiler ignores MODULE-COMPLIANCE statements and the changes are all legally specified through MODULE-COMPLIANCE statements, which is imperfect? > If we can hammer out these details, with some guidance, I would be > willing to help in any way. My employer won't send me to IETF meeting, > but if there is anything I can do to help, I'm willing. It sounds like a > great opportunity to learn the process and enable me to contribute in > the future. A volunteer! -- Bob Ray --------------------------------------------------- Footnotes for those outside the United States: a) Members of The University of Tennessee sports teams are called Volunteers. b) SNMP Research, Inc. was established on a farm outside of Knoxville, Tennessee by Jeff Case, who was/is associated with the University of Tennessee Electrical Engineering Department. c) The University of Tennessee is in Knoxville, Tennessee. d) Jeff Case often uses the saying, "You don't need to lick a pump handle in February to know it's a bad idea". e) February in Knoxville, Tennessee can be quite cold. f) Graduates of The University of Alabama, which I attended, are typically not very fond of The University of Tennessee, in a collegial, competitive, sort of way. :) g) We tend to wonder about the origins of Dr. Case's favorite saying. _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Thu Feb 12 06:44:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19738 for ; Thu, 12 Feb 2004 06:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFGS-00080j-D3 for adslmib-archive@odin.ietf.org; Thu, 12 Feb 2004 06:44:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CBiGhA030789 for adslmib-archive@odin.ietf.org; Thu, 12 Feb 2004 06:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFGS-00080W-8w for adslmib-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 06:44:16 -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 GAA19733 for ; Thu, 12 Feb 2004 06:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArFGO-00019R-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 06:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArFFW-00013q-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 06:43:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArFFB-0000xs-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 06:42:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFFE-0007xG-OD; Thu, 12 Feb 2004 06:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArFEO-0007wT-A8 for adslmib@optimus.ietf.org; Thu, 12 Feb 2004 06:42:08 -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 GAA19659 for ; Thu, 12 Feb 2004 06:42:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArFEK-0000uk-00 for adslmib@ietf.org; Thu, 12 Feb 2004 06:42:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArFDN-0000op-00 for adslmib@ietf.org; Thu, 12 Feb 2004 06:41:06 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ArFCX-0000e7-00 for adslmib@ietf.org; Thu, 12 Feb 2004 06:40:14 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1CBdb311948 for ; Thu, 12 Feb 2004 05:39:37 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 Feb 2004 12:39:35 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC5C6@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'rray@pesa.com'" , "Wijnen, Bert (Bert)" Cc: adslmib mail list Subject: RE: [Adslmib] RFC3276 respin Date: Thu, 12 Feb 2004 12:39:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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: , List-Id: ADSLMIB List-Post: List-Help: List-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 Inline > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: woensdag 11 februari 2004 16:19 > To: Bert (Bert) Wijnen > Cc: adslmib mail list > Subject: RE: [Adslmib] RFC3276 respin > > > On Wed, 2004-02-11 at 06:34, Wijnen, Bert (Bert) wrote: > > > Formally, I do not think that you can remove the range limits. > > See RFC2578, sect 10. > > Adding additional enumerations to Hdsl2ShdslWirePair and > hdsl2ShdslSpanConfWireInterface are certainly allowed by 2578, > section 10.2 note (1), so that is straight forward. > Yes it is allowed. In general though, we have adopted the technique (certainly if they are write-able objects, which I have not yet checked in thsi case) to then change the existing MODULE-COMPLIANCE to list the old enumerations explicitly. This is to ensure that any implementation that claims compliance with the existing MODULE-COMPLIANCE is not impacted and still has a very clear statement of what they do and do not support. Easu enought to do, so should not be an issue. > > I think I could go along with the change if we were to update the > > current MODULE-COMPLIANCE such that the current ranges are inlcuded > > there, and then do a new MODULE-COMPLIANCE that allows for the new > > values, certainly for the read-write objects. > > > > Similar fixes to MODULE-COMPLIANCE would be recommend for > > the enumerated objects. > > I'm trying to understand - please bear with me. > > So, one would leave the original object declaration alone, such as: > > hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE > SYNTAX Unsigned32(0..4112000) > blah blah blah > Nope, the OBJECT-TYPE would change (formally not allowed, so you must convince me and the community that it is OK... as I said, I think I personally can go along). SO new object would looke like hdsl2ShdslStatusMaxAttainableLineRate OBJECT-TYPE SYNTAX Unsigned32(0..92520000) blah blah blah I wonder though if we may need to change it a agin a few years from now. So maybe just remove the range all together? > but add entries in the compliance section of the form: > > OBJECT hdsl2ShdslStatusMaxAttainableLineRate > SYNTAX Unsigned32(0..92520000) > DESCRIPTION > "An extended range is applicable when implementing > g.shdsl.bis." > Nope, in the compliance section you would get something aka: hdsl2ShdslLineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for a managed entity that supports the orginal g.shdsl specification." blabla OBJECT hdsl2ShdslStatusMaxAttainableLineRate SYNTAX Unsigned32(0..4112000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification." blabla ::= { hdsl2ShdslCompliances 1 } And in a new compliance statement you eitehr leave it out or add some text. So something aka: hdsl2ShdslBisLineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for a managed entity that supports the enhanced g.shdsl.bis specification." blabla OBJECT hdsl2ShdslStatusMaxAttainableLineRate SYNTAX Unsigned32(0..92520000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification." blabla ::= { hdsl2ShdslCompliances 2 } Or possibly the last one supports both original g.shdsl and the new g.shdsl.bis specifications, in which case the text changes a bit. > Is this right? If so, I guess similar entries would be required for > hdsl2ShdslStatusActualLineRate, > hdsl2ShdslSpanConfMinLineRate, and > hdsl2ShdslSpanConfMaxLineRate. > > For hdsl2ShdslSpanConfWireInterface, then, would the following be > the right syntax (in the compliance section)? > Nope, you do similar things as I explained above. > OBJECT hdsl2ShdslSpanConfWireInterface > SYNTAX INTEGER > { > twoWire(1), > fourWire(2), > sixWire(3), > eightWire(4) > } > DESCRIPTION > "An extended range is applicable when implementing > g.shdsl.bis." > > If the above is correct, then, the only one left is the textual > convention Hdsl2ShdslWirePair. How does one extend a textual > convention in the compliance section? > I don't think I've ever seen this done. > There are examples, for example look at rfc2096upd specs but let us go and elaborate on this specific case > Does one add an entry stating: > > TEXTUAL-CONVENTION Hdsl2ShdslWirePair > SYNTAX INTEGER > { > wirePair1(1), > wirePair2(2), > wirePair3(3), > wirePair4(4) > } > DESCRIPTION > "An extended range is applicable when implementing > g.shdsl.bis." > > Looks odd, I guess, but I don't know the way :) > Nope. You do the following: Update the TC itself: Hdsl2ShdslWirePair ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is the referenced pair of wires in a HDSL2/SHDSL Segment. HDSL2 only supports a single pair (wirePair1), while SHDSL supports an optional second pair (wirePair2)." SYNTAX INTEGER { wirePair1(1), wirePair2(2), wirePair3(3), wirePair4(4) } Of course you need to update the description clause above as well. Leave the OBJECT-TYPE definitions untouched. In the MODULE-COMPLIANCE (existing one) add text (since the usage of this TC is in an INDEX object, you cannot add it as machine readable spec in the MODULE-COMPLIANCE. So taking the above, and adding thios, it would become something aka: hdsl2ShdslLineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for a managed entity that supports the orginal g.shdsl specification. There is an INDEX object that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT hdsl2ShdslEndpointWirePair -- SYNTAX Hdsl2ShdslWirePair (wirePair1(1), -- wirePair2(2)) -- DESCRIPTION -- This compliance (for g.shdsl) only requires -- support for wirePair1 and wirePair2. -- " blabla OBJECT hdsl2ShdslStatusMaxAttainableLineRate SYNTAX Unsigned32(0..4112000) DESCRIPTION "An implementation only has to support the range as applicable for the original g.shdsl specification." blabla ::= { hdsl2ShdslCompliances 1 } Now.. pls check, because the text may need to change somewhat here and there. Possibly where I say "g.shdsl" maybe it should say "hdsl and g.shdls..." or some such, but you know this better than I do. > Process questions > > a) Were some industrious person to submit a "respin of 3276" > with the above changes, would they submit a new draft to the ietf draft > editor as an individual contribution or striaght away to the adslmib > working group? > If the WG decides this is what they want to do (I can see that as part of the charter I think, WG chair chime in what you think) then it is up to the WG chair to decide if he wants to adopt it right away or if he rathers sees an individual draft first that teh WG then can discuss fiorst before adopting the document. > b) Would this draft contain the full text of RFC3276 in draft form (vs > RFC form) along with the above modifications? > That is one way of doing it. Note that you can ask RFC-editor for the nroff source for rfc3276. Another way (with far less text, but a bit more complex process wise cause we have only done it once sofar is to use the approach as done for the updates to rmon and rmon2 in RFC3273.txt, sect 3. AT the end of section 3, it then points to updated MIB modules. Those updated mib modules actually also contain examples of how enumerations were added and how they were dealt with in compliance section. > c) Would it be permissible to submit a draft noting the changes necessary > to support g.shdsl.bis? That is, essentially a draft with all of the > above changes discussed textually ala RFC3593? > Yep (as was done for rmon1 and rmon2), but you MUST also provide an updated MIB module (as was done for rmon1 and rmon2). And the pointers to those need to go into the I-D as well and the new modules MUST be posted (temproarily) on internet-drafts, so that people can see them. For the hcrmon (RFC3273) they were listed in revision 10 of the spec as: For convenience, updated MIB modules containing these objects may be found at: http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-08-rmon.mib http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-08-rmon2.mib Note to RFC-Editor: above 2 links to be updated to RFC-Editor location when RFC-is published Hope this helps/explains, bert _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Thu Feb 12 09:19:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24942 for ; Thu, 12 Feb 2004 09:19:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHgX-0006iU-2f for adslmib-archive@odin.ietf.org; Thu, 12 Feb 2004 09:19:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CEJLas025812 for adslmib-archive@odin.ietf.org; Thu, 12 Feb 2004 09:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHgW-0006iF-TS for adslmib-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 09:19:20 -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 JAA24928 for ; Thu, 12 Feb 2004 09:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHgR-0000oz-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 09:19:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHfT-0000ja-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 09:18:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArHfC-0000eS-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 09:17:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHfF-0006Sq-5y; Thu, 12 Feb 2004 09:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHeX-0006M9-7H for adslmib@optimus.ietf.org; Thu, 12 Feb 2004 09:17:17 -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 JAA24857 for ; Thu, 12 Feb 2004 09:17:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHeR-0000dD-00 for adslmib@ietf.org; Thu, 12 Feb 2004 09:17:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHdb-0000Xo-00 for adslmib@ietf.org; Thu, 12 Feb 2004 09:16:20 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1ArHcj-0000SQ-00 for adslmib@ietf.org; Thu, 12 Feb 2004 09:15:25 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i1CEFPWq556411 for ; Thu, 12 Feb 2004 08:15:25 -0600 (CST) Received: from 192.168.0.122 ([192.168.0.122]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 35-md50000000010.tmp for ; Thu, 12 Feb 2004 08:15:20 -0600 Subject: RE: [Adslmib] RFC3276 respin From: Bob Ray Reply-To: rray@pesa.com To: "Bert (Bert) Wijnen" Cc: adslmib mail list In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC5C6@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155028EC5C6@nl0006exch001u.nl.lucent.com> Content-Type: text/plain Message-Id: <1076595319.2612.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 12 Feb 2004 08:15:20 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Thu, 12 Feb 2004 08:15:20 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.122 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: adslmib@ietf.org 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: , List-Id: ADSLMIB List-Post: List-Help: List-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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thank you, Bert! That helps a lot. Bob On Thu, 2004-02-12 at 05:39, Wijnen, Bert (Bert) wrote: > Inline > _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Thu Feb 12 17:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19959 for ; Thu, 12 Feb 2004 17:27:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPI8-0004y0-E3 for adslmib-archive@odin.ietf.org; Thu, 12 Feb 2004 17:26:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CMQe2W019091 for adslmib-archive@odin.ietf.org; Thu, 12 Feb 2004 17:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPI8-0004xq-6v for adslmib-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 17:26:40 -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 RAA19943 for ; Thu, 12 Feb 2004 17:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPI3-0004dD-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 17:26:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPHQ-0004Xw-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 17:25:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArPGU-0004Rk-00 for adslmib-web-archive@ietf.org; Thu, 12 Feb 2004 17:24:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPGX-0004sk-KO; Thu, 12 Feb 2004 17:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcf8-0005xF-MF for adslmib@optimus.ietf.org; Tue, 10 Feb 2004 13:31:10 -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 NAA01409 for ; Tue, 10 Feb 2004 13:31:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcf6-00072W-00 for adslmib@ietf.org; Tue, 10 Feb 2004 13:31:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqceC-0006wY-00 for adslmib@ietf.org; Tue, 10 Feb 2004 13:30:13 -0500 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcdm-0006qD-00; Tue, 10 Feb 2004 13:29:46 -0500 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i1AITjk13384; Tue, 10 Feb 2004 10:29:45 -0800 (PST) Message-Id: <200402101829.i1AITjk13384@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, adslmib@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 10 Feb 2004 10:29:45 -0800 Subject: [Adslmib] RFC 3705 on High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals 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: , List-Id: ADSLMIB List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3705 Title: High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals Author(s): B. Ray, R. Abbi Status: Standards Track Date: February 2004 Mailbox: rray@pesa.com, Rajesh.Abbi@alcatel.com Pages: 11 Characters: 24158 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-adslmib-hc-tc-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3705.txt This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. This document is a product of the ADSL MIB Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040210102800.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3705 --OtherAccess Content-Type: Message/External-body; name="rfc3705.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040210102800.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Feb 17 11:02:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09597 for ; Tue, 17 Feb 2004 11:02:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7fT-0005Zm-Db for adslmib-archive@odin.ietf.org; Tue, 17 Feb 2004 11:01:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG1pXe021434 for adslmib-archive@odin.ietf.org; Tue, 17 Feb 2004 11:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7fT-0005Zd-8U for adslmib-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:01:51 -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 LAA09450 for ; Tue, 17 Feb 2004 11:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7fQ-0004vg-00 for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 11:01:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7cn-0004Nw-00 for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 10:59:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1At7bD-00047a-00 for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 10:57:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At7SD-0003jW-TN for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 10:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7S9-0003o5-Eh; Tue, 17 Feb 2004 10:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7B2-0008Q3-Jk for adslmib@optimus.ietf.org; Tue, 17 Feb 2004 10:30:24 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04415; Tue, 17 Feb 2004 10:30:20 -0500 (EST) Message-Id: <200402171530.KAA04415@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: adslmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Feb 2004 10:30:19 -0500 Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-vdsl-ext-scm-01.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: , List-Id: ADSLMIB List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding Author(s) : M. Dodge, B. Ray Filename : draft-ietf-adslmib-vdsl-ext-scm-01.txt Pages : 17 Date : 2004-2-17 This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE CORE MIB RFC XXXX [RFCXXXX] which handles the line code independent objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-vdsl-ext-scm-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-adslmib-vdsl-ext-scm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-adslmib-vdsl-ext-scm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17102934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-adslmib-vdsl-ext-scm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-adslmib-vdsl-ext-scm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17102934.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Feb 17 11:02:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09629 for ; Tue, 17 Feb 2004 11:02:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7fV-0005aB-Cc for adslmib-archive@odin.ietf.org; Tue, 17 Feb 2004 11:01:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG1rIw021453 for adslmib-archive@odin.ietf.org; Tue, 17 Feb 2004 11:01:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7fV-0005Zw-8L for adslmib-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:01:53 -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 LAA09454 for ; Tue, 17 Feb 2004 11:01:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7fS-0004vx-00 for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 11:01:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7co-0004OC-00 for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 10:59:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1At7bD-0004AI-00 for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 10:57:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At7SD-0003jV-PV for adslmib-web-archive@ietf.org; Tue, 17 Feb 2004 10:48:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7S9-0003nw-99; Tue, 17 Feb 2004 10:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7AP-0008Mw-Vs for adslmib@optimus.ietf.org; Tue, 17 Feb 2004 10:29:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04332; Tue, 17 Feb 2004 10:29:42 -0500 (EST) Message-Id: <200402171529.KAA04332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: adslmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 17 Feb 2004 10:29:41 -0500 Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-vdsl-ext-mcm-01.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: , List-Id: ADSLMIB List-Post: List-Help: List-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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding Author(s) : M. Dodge, B. Ray Filename : draft-ietf-adslmib-vdsl-ext-mcm-01.txt Pages : 22 Date : 2004-2-17 This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE CORE MIB RFC XXXX [RFCXXXX] which handles the line code independent objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-vdsl-ext-mcm-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-adslmib-vdsl-ext-mcm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-adslmib-vdsl-ext-mcm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-17102913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-adslmib-vdsl-ext-mcm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-adslmib-vdsl-ext-mcm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-17102913.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Wed Feb 18 13:28:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06879 for ; Wed, 18 Feb 2004 13:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWQX-0004Y4-FB for adslmib-archive@odin.ietf.org; Wed, 18 Feb 2004 13:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IIS50C017478 for adslmib-archive@odin.ietf.org; Wed, 18 Feb 2004 13:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWQX-0004Xp-5p for adslmib-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 13:28:05 -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 NAA06825 for ; Wed, 18 Feb 2004 13:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWQV-0006UQ-00 for adslmib-web-archive@ietf.org; Wed, 18 Feb 2004 13:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWPT-0006NJ-00 for adslmib-web-archive@ietf.org; Wed, 18 Feb 2004 13:26:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtWOX-0006J9-00 for adslmib-web-archive@ietf.org; Wed, 18 Feb 2004 13:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWOY-0004MA-3E; Wed, 18 Feb 2004 13:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtWNq-0004Ir-Dz for adslmib@optimus.ietf.org; Wed, 18 Feb 2004 13:25:18 -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 NAA06729 for ; Wed, 18 Feb 2004 13:25:16 -0500 (EST) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtWNo-0006GN-00 for adslmib@ietf.org; Wed, 18 Feb 2004 13:25:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtWN1-0006CI-00 for adslmib@ietf.org; Wed, 18 Feb 2004 13:24:28 -0500 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 1AtWMO-00064e-00 for adslmib@ietf.org; Wed, 18 Feb 2004 13:23:48 -0500 Received: from mucse012.eu.infineon.com (mucse012.ifx-mail1.com [172.29.27.229]) by smtp2.infineon.com (8.12.10/8.12.10) with ESMTP id i1IILjNP009997; Wed, 18 Feb 2004 19:21:45 +0100 (MET) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id <10RQ5BBF>; Wed, 18 Feb 2004 19:23:15 +0100 Message-ID: To: adslmib@ietf.org Cc: sneedmike@hotmail.com, rray@pesa.com Date: Wed, 18 Feb 2004 19:18:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Adslmib] VDSL Line Code Specific Extension MIBS - Last Call 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: , List-Id: ADSLMIB List-Post: List-Help: List-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.7 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi All, The version -01 of the two LCS MIBS are now available in the internet draft directories. Draft names are : draft-ietf-adslmib-vdsl-ext-mcm-01.txt draft-ietf-adslmib-vdsl-ext-scm-01.txt Please send me any comments by the 14th March 2004. This is a LAST CALL for these documents before moving them forward to proposed standards. Regards, Menachem Dodge. _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib