From mailnull@www1.ietf.org Thu May 1 09:45:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09784 for ; Thu, 1 May 2003 09:45:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Dpkw32328 for adslmib-archive@odin.ietf.org; Thu, 1 May 2003 09:51:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Dpk832325 for ; Thu, 1 May 2003 09:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09732 for ; Thu, 1 May 2003 09:45:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEPD-0001LC-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 09:47:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BEPD-0001L3-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 09:47:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DpY832260; Thu, 1 May 2003 09:51:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Dos832227 for ; Thu, 1 May 2003 09:50:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09687 for ; Thu, 1 May 2003 09:44:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEO8-0001KM-00 for adslmib@ietf.org; Thu, 01 May 2003 09:46:16 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19BEO2-0001K4-00 for adslmib@ietf.org; Thu, 01 May 2003 09:46:10 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h41DjhHb647581 for ; Thu, 1 May 2003 08:45:43 -0500 (CDT) Received: from rray ([192.168.0.108]) by pesahsv.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Thu, 01 May 2003 08:45:40 -0500 From: "Bob Ray" To: "Adslmib" Date: Thu, 1 May 2003 08:45:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 192.168.0.108 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: adslmib@ietf.org Content-Transfer-Encoding: 7bit Subject: [Adslmib] six objects - hopefully last message on this subject 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Good morning! Here are the six, one more time. I've put them in the MIB and will have -09 out to the draft editor today some time. Bob Ray ----------------------------------------------------------------- vdslChanCurrTxFastFecOverhead OBJECT-TYPE SYNTAX Gauge32 (0..50) UNITS "%" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Forward Error Correction (FEC) redundancy related overhead for a fast channel. This parameter is not applicable to an interleaved (slow) channel. For interleaved channels, a value of zero shall be returned." ::= { vdslChanEntry 4 } vdslChanCurrTxSlowBurstProtection OBJECT-TYPE SYNTAX Gauge32 (0..50) UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual level of impulse noise (burst) protection for an interleaved (slow) channel. This parameter is not applicable to fast channels. For fast channels, a value of zero shall be returned." REFERENCE "ITU-T G.997.1" -- section 7.3.2.3 ::= { vdslChanEntry 5 } vdslLineConfDownstreamTargetSlowBurstProtection OBJECT-TYPE SYNTAX Unsigned32 (0..1275) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target level of impulse noise (burst) protection for an interleaved (slow) channel." DEFVAL { 0 } REFERENCE "ITU-T G.997.1" -- section 7.3.2.3 ::= { vdslLineConfProfileEntry 41 } vdslLineConfUpstreamTargetSlowBurstProtection OBJECT-TYPE SYNTAX Unsigned32 (0..1275) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target level of impulse noise (burst) protection for an interleaved (slow) channel." DEFVAL { 0 } REFERENCE "ITU-T G.997.1" -- section 7.3.2.3 ::= { vdslLineConfProfileEntry 42 } vdslLineConfDownstreamMaxFastFecOverhead OBJECT-TYPE SYNTAX Unsigned32 (0..50) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the maximum level of Forward Error Correction (FEC) redundancy related overhead to be maintained for the Fast channel." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 43 } vdslLineConfUpstreamMaxFastFecOverhead OBJECT-TYPE SYNTAX Unsigned32 (0..50) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the maximum level of Forward Error Correction (FEC) redundancy related overhead to be maintained for the Fast channel." DEFVAL { 0 } ::= { vdslLineConfProfileEntry 44 } _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu May 1 10:06:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10979 for ; Thu, 1 May 2003 10:06:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41EC7a05307 for adslmib-archive@odin.ietf.org; Thu, 1 May 2003 10:12:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EC7805304 for ; Thu, 1 May 2003 10:12:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10957 for ; Thu, 1 May 2003 10:05:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEif-0001dX-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 10:07:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BEie-0001dS-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 10:07:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41EBe805268; Thu, 1 May 2003 10:11:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41E6T803008 for ; Thu, 1 May 2003 10:06:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10548 for ; Thu, 1 May 2003 09:59:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEdD-0001X5-00 for adslmib@ietf.org; Thu, 01 May 2003 10:01:51 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19BEd7-0001X2-00 for adslmib@ietf.org; Thu, 01 May 2003 10:01:45 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h41E2GHb680909 for ; Thu, 1 May 2003 09:02:16 -0500 (CDT) Received: from [192.168.0.122] ([192.168.0.122]) by pesahsv.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Thu, 01 May 2003 09:02:13 -0500 Subject: Re: [Adslmib] six objects - argh From: Bob Ray Reply-To: rray@pesa.com To: adslmib mail list In-Reply-To: References: Content-Type: text/plain Message-Id: <1051797732.2827.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 May 2003 09:02:13 -0500 Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-05-01 at 08:45, Bob Ray wrote: > Good morning! Here are the six, one more time. I've put them in the > MIB and will have -09 out to the draft editor today some time. > > Bob Ray > ----------------------------------------------------------------- > > vdslChanCurrTxSlowBurstProtection OBJECT-TYPE > SYNTAX Gauge32 (0..50) > UNITS "microseconds" make that (0..1275). Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu May 1 15:03:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29845 for ; Thu, 1 May 2003 15:03:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41J9wE12850 for adslmib-archive@odin.ietf.org; Thu, 1 May 2003 15:09:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41J9w812847 for ; Thu, 1 May 2003 15:09:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29395 for ; Thu, 1 May 2003 14:59:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BJJY-0005M3-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 15:01:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BJJX-0005Lz-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 15:01:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41J60810723; Thu, 1 May 2003 15:06:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ULx9804194 for ; Wed, 30 Apr 2003 17:59:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25377 for ; Wed, 30 Apr 2003 17:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AzXe-0003ui-00 for adslmib@ietf.org; Wed, 30 Apr 2003 17:55:06 -0400 Received: from smtp.nlc.com ([209.204.132.15]) by ietf-mx with esmtp (Exim 4.12) id 19AzXY-0003uS-00 for adslmib@ietf.org; Wed, 30 Apr 2003 17:55:01 -0400 Received: from exchange4.nlc.com (exchange4.nlc.com [10.0.0.85]) by smtp.nlc.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3ULrx528176; Wed, 30 Apr 2003 14:53:59 -0700 (PDT) Received: by exchange4.nlc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 14:54:05 -0700 Message-ID: <50859C0B9DE9D411811F009027B11DAC015D4101@exchange4.nlc.com> From: "Say, Sabit" To: Rajesh Abbi , rray@pesa.com Cc: Sabit Say , Randy Presuhn , adslmib mail list , Moti Morgenstern Subject: RE: [Adslmib] six objects - redux Date: Wed, 30 Apr 2003 14:54:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , I leave the rest up to you experts. Sabit -----Original Message----- From: Rajesh Abbi [mailto:Rajesh.Abbi@alcatel.com] Sent: Wednesday, April 30, 2003 5:19 PM To: rray@pesa.com Cc: Sabit Say; Randy Presuhn; adslmib mail list; Moti Morgenstern Subject: Re: [Adslmib] six objects - redux Since the parmeter vaues do not reflect exact configuration - only Minimum/Maximum and Target values, it does not make sense to put unnecessary constraints on the steps. The units should be simple (normally used). So I agree with Randy that we should simply use % and microseconds as the units in incements of 1 (1% or 1 microsecond). Enough from me. Bob, go get a beer ! ;-) Rajesh Bob Ray wrote: > On Wed, 2003-04-30 at 15:13, Say, Sabit wrote: > > > Correct this and you are done: > > vdslLineConfUpstreamTargetSlowBurstProtection OBJECT-TYPE > > Got it. Thanks. Was also missing the word "of" in the > vdslChanCurrFastFecOverhead description. That, or change > "a value of zero" to "the value zero" elsewhere. But that > leads to a metaphysical trench, I think (is there one and > only one one?). <- lame humor > > > 1) Is it clear from the range and the variable type that the 0-1275 range is > > in increments of 5 [microseconds]? > > Nope. In the object description its in increments of 1 microsecond. > If I change it to increments of 5 microseconds, the range is changed > to (0..255). That is, UNITS gets changed to UNITS "5 microseconds". > > > 2) 0 to 50 for % overhead makes sense. > > Or if you do not want any range checking, you can define it as 0 to 63.75 in > > 0.25 increments. > > Similarly, would result in a range of (0..255) with UNITS of 0.25%. > > I suppose the (0..255) ranges are the more accurate translations of > the underlying mechanisms. Rajesh will argue about anything greater > than 50%. > > > 4) The reported parameters do not have upstream/downstream attached to them, > > but I presume they can be reported for both. Is that correct? > > The vdslChanCurrXXXX objects are for each ifIndex and vdslLineEntity > (Vtuc, Vtur). As fast and interleave channels will each have an > ifEntry, and as each end of the line (Vtuc, Vtur) will have an > entry in the vdslChanTable, then, yes, it is reported for Upstream > (Vtur -> Vtuc) and Downstream (Vtuc -> Vtur). Perhaps better object > names: > > vdslChanTxOverhead (NOTE: "Tx") > vdslChanTxBurstProtection (NOTE: "Tx") > > this would indicate which channel and in which direction the objects > refer (when taken in the context of their ifIndex and vdslLineEntity). > > Bob Ray > > p.s. I need a beer. _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu May 1 15:42:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04439 for ; Thu, 1 May 2003 15:42:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Jmfu25972 for adslmib-archive@odin.ietf.org; Thu, 1 May 2003 15:48:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Jmf825969 for ; Thu, 1 May 2003 15:48:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04384 for ; Thu, 1 May 2003 15:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BJyU-0005nw-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 15:44:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BJyU-0005nt-00 for adslmib-web-archive@ietf.org; Thu, 01 May 2003 15:44:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JmQ825865; Thu, 1 May 2003 15:48:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JVO818200 for ; Thu, 1 May 2003 15:31:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02444; Thu, 1 May 2003 15:24:41 -0400 (EDT) Message-Id: <200305011924.PAA02444@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: Thu, 01 May 2003 15:24:41 -0400 Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-vdsl-09.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: , --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 Objects for Very High Speed Digital Subscriber Lines (VDSL) Author(s) : B. Ray, R. Abbi Filename : draft-ietf-adslmib-vdsl-09.txt Pages : 64 Date : 2003-5-1 This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very high speed Digital Subscriber Line (VDSL) interfaces [T1E1311, T1E1011, T1E1013, ETSI2701, ETSI2702, ITU9931]. This document specifies a MIB module in a manner that is compliant to the SMIv2 (STD 58 [RFC2578, RFC2579, RFC2580]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-vdsl-09.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-09.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-09.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: <2003-5-1153502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-adslmib-vdsl-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-adslmib-vdsl-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153502.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Mon May 5 11:39:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05818 for ; Mon, 5 May 2003 11:39:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45FlNB11531 for adslmib-archive@odin.ietf.org; Mon, 5 May 2003 11:47:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45FlN811528 for ; Mon, 5 May 2003 11:47:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05787 for ; Mon, 5 May 2003 11:38:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ci53-0006as-00 for adslmib-web-archive@ietf.org; Mon, 05 May 2003 11:40:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ci52-0006am-00 for adslmib-web-archive@ietf.org; Mon, 05 May 2003 11:40:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Fkg811468; Mon, 5 May 2003 11:46:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Fg8811314 for ; Mon, 5 May 2003 11:42:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05674 for ; Mon, 5 May 2003 11:33:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Chzy-0006ZH-00 for adslmib@ietf.org; Mon, 05 May 2003 11:35:26 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19Chzs-0006Yf-00 for adslmib@ietf.org; Mon, 05 May 2003 11:35:21 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h45FZaHd1016219 for ; Mon, 5 May 2003 10:35:39 -0500 (CDT) Received: from rray ([192.168.0.108]) by pesahsv.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Mon, 05 May 2003 10:35:34 -0500 From: "Bob Ray" To: "Adslmib" Cc: , , , "Flemisch Felix" , "Say, Sabit" Date: Mon, 5 May 2003 10:35:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <50859C0B9DE9D411811F009027B11DAC015D3F4D@exchange4.nlc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MDRemoteIP: 192.168.0.108 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: adslmib@ietf.org Content-Transfer-Encoding: 7bit Subject: [Adslmib] vdsl-09 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The -09 draft is available at http://www.ietf.org/internet-drafts/draft-ietf-adslmib-vdsl-09.txt Please take the time to read it. Hopefully, we can move it and the companion document http://www.ietf.org/internet-drafts/draft-ietf-adslmib-hc-tc-03.txt on to the next step... Regards, Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu May 8 15:06:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04366 for ; Thu, 8 May 2003 15:06:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48JGWc09426 for adslmib-archive@odin.ietf.org; Thu, 8 May 2003 15:16:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48JGW809423 for ; Thu, 8 May 2003 15:16:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04296 for ; Thu, 8 May 2003 15:06:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dqkn-00059h-00 for adslmib-web-archive@ietf.org; Thu, 08 May 2003 15:08:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dqkm-00059d-00 for adslmib-web-archive@ietf.org; Thu, 08 May 2003 15:08:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48JGF809387; Thu, 8 May 2003 15:16:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48JFS809341 for ; Thu, 8 May 2003 15:15:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04180 for ; Thu, 8 May 2003 15:05:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dqjl-000597-00 for adslmib@ietf.org; Thu, 08 May 2003 15:07:25 -0400 Received: from services.paradyne.com ([135.90.22.16] helo=pigeon.is.paradyne.com) by ietf-mx with esmtp (Exim 4.12) id 19Dqjl-00058x-00 for adslmib@ietf.org; Thu, 08 May 2003 15:07:25 -0400 Received: from paradyne.com ([135.26.21.26]) by pigeon.is.paradyne.com (Netscape Messaging Server 4.15) with ESMTP id HEL14R00.7V1; Thu, 8 May 2003 15:07:39 -0400 Message-ID: <3EBAAB05.31906291@paradyne.com> Date: Thu, 08 May 2003 15:07:49 -0400 From: Clay Sikes Organization: Paradyne Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: adslmib@ietf.org CC: Miguel.Peeters@broadcom.com, Grepg.Bathrick@nokia.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h48JFT809342 Subject: [Adslmib] MIB Support for ADSL2 and ADSL2+ 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Does anyone know the status of updates to the ADSL-LINE-MIB, ADSL-LINE-EXT-MIB, or any others to support ADSL2 and ADSL2+? I think the last thing I heard was that the ITU to finalize G.997.1 before the updates could begin. It seems like G.997.1 should be finalized about now. Miguel can you provide an update on the G.997.1 status? Thanks, Clay Sikes Paradyne Corp. _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu May 8 17:27:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11979 for ; Thu, 8 May 2003 17:27:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48LbLL22056 for adslmib-archive@odin.ietf.org; Thu, 8 May 2003 17:37:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48LbL822045 for ; Thu, 8 May 2003 17:37:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11971 for ; Thu, 8 May 2003 17:27:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dsx2-0006is-00 for adslmib-web-archive@ietf.org; Thu, 08 May 2003 17:29:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dsx1-0006ip-00 for adslmib-web-archive@ietf.org; Thu, 08 May 2003 17:29:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Lb9821695; Thu, 8 May 2003 17:37:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48LZn821506 for ; Thu, 8 May 2003 17:35:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11943 for ; Thu, 8 May 2003 17:25:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DsvX-0006if-00 for adslmib@ietf.org; Thu, 08 May 2003 17:27:43 -0400 Received: from hostr490.alcatel.com ([143.209.4.144] helo=aurmsd.aur.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 19DsvX-0006ib-00 for adslmib@ietf.org; Thu, 08 May 2003 17:27:43 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by aurmsd.aur.alcatel.com (8.12.8+Sun/8.11.3) with ESMTP id h48LRuRk028412; Thu, 8 May 2003 17:27:59 -0400 (EDT) Message-ID: <3EBACC06.7701239A@alcatel.com> Date: Thu, 08 May 2003 17:28:39 -0400 From: Rajesh Abbi Organization: Alcatel USA, Inc. X-Sender: "Rajesh Abbi" <@relay.aur.alcatel.com> X-Mailer: Mozilla 4.73 [en]C-CCK-MCD office (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Clay Sikes CC: adslmib@ietf.org, Miguel.Peeters@broadcom.com, Grepg.Bathrick@nokia.com Subject: Re: [Adslmib] MIB Support for ADSL2 and ADSL2+ References: <3EBAAB05.31906291@paradyne.com> Content-Type: text/plain; charset=us-ascii 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Clay, The DSL Forum has just begun work on capturing the requirements as well as a protocol independent object model for managing the next generation ADSL technologies (including ADSL2, ADSL2+...). This work will be based on ITU-T G.997.1bis being finalized now, and is expected to form the basis for SNMP MIB definition work to be undertaken by IETF. Regards, Rajesh Abbi Alcatel Clay Sikes wrote: > Hi, > > Does anyone know the status of updates to the ADSL-LINE-MIB, > ADSL-LINE-EXT-MIB, or any others to support ADSL2 and ADSL2+? > > I think the last thing I heard was that the ITU to finalize G.997.1 > before the updates could begin. It seems like G.997.1 should be > finalized about now. Miguel can you provide an update on the G.997.1 > status? > > Thanks, > Clay Sikes > Paradyne Corp. > _______________________________________________ > 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 mailnull@www1.ietf.org Thu May 8 17:57:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12847 for ; Thu, 8 May 2003 17:57:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48M7Or24504 for adslmib-archive@odin.ietf.org; Thu, 8 May 2003 18:07:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48M7O824501 for ; Thu, 8 May 2003 18:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12800 for ; Thu, 8 May 2003 17:57:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtQ5-0006uI-00 for adslmib-web-archive@ietf.org; Thu, 08 May 2003 17:59:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DtQ5-0006uF-00 for adslmib-web-archive@ietf.org; Thu, 08 May 2003 17:59:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48M77824003; Thu, 8 May 2003 18:07:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48M6r823919 for ; Thu, 8 May 2003 18:06:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12786 for ; Thu, 8 May 2003 17:56:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DtPb-0006tu-00 for adslmib@ietf.org; Thu, 08 May 2003 17:58:47 -0400 Received: from services.paradyne.com ([135.90.22.16] helo=pigeon.is.paradyne.com) by ietf-mx with esmtp (Exim 4.12) id 19DtPa-0006tg-00 for adslmib@ietf.org; Thu, 08 May 2003 17:58:46 -0400 Received: from paradyne.com ([135.26.21.26]) by pigeon.is.paradyne.com (Netscape Messaging Server 4.15) with ESMTP id HEL92D00.10Z; Thu, 8 May 2003 17:59:01 -0400 Message-ID: <3EBAD32E.91D44D3D@paradyne.com> Date: Thu, 08 May 2003 17:59:11 -0400 From: Clay Sikes Organization: Paradyne Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rajesh Abbi CC: adslmib@ietf.org, Miguel.Peeters@broadcom.com, Greg.Bathrick@nokia.com Subject: Re: [Adslmib] MIB Support for ADSL2 and ADSL2+ References: <3EBAAB05.31906291@paradyne.com> <3EBACC06.7701239A@alcatel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h48M6r823922 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Rajesh, Thanks for the quick response. Do you have an idea when something will be available? If it's in the time frame of months, would it be worth an effort to extend AdslTransmissionType TC in a draft version of the ADSL-LINE-EXT-MIB to support the ADSL2 and ADSL2+ in the short term time frame? Thanks, Clay Sikes Paradyne Corp. Rajesh Abbi wrote: > Hi Clay, > > The DSL Forum has just begun work on capturing the requirements as well > as a > protocol independent object model for managing the next generation ADSL > technologies (including ADSL2, ADSL2+...). This work will be based on > ITU-T > G.997.1bis being finalized now, and is expected to form the basis for > SNMP MIB > definition work to be undertaken by IETF. > > Regards, > > Rajesh Abbi > Alcatel > > Clay Sikes wrote: > > > Hi, > > > > Does anyone know the status of updates to the ADSL-LINE-MIB, > > ADSL-LINE-EXT-MIB, or any others to support ADSL2 and ADSL2+? > > > > I think the last thing I heard was that the ITU to finalize G.997.1 > > before the updates could begin. It seems like G.997.1 should be > > finalized about now. Miguel can you provide an update on the G.997.1 > > status? > > > > Thanks, > > Clay Sikes > > Paradyne Corp. > > _______________________________________________ > > 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 mailnull@www1.ietf.org Tue May 13 15:44:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27273 for ; Tue, 13 May 2003 15:44:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DJB8f23367 for adslmib-archive@odin.ietf.org; Tue, 13 May 2003 15:11:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJB8B23364 for ; Tue, 13 May 2003 15:11:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27263 for ; Tue, 13 May 2003 15:44:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FfjE-0007De-00 for adslmib-web-archive@ietf.org; Tue, 13 May 2003 15:46:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FfjD-0007Da-00 for adslmib-web-archive@ietf.org; Tue, 13 May 2003 15:46:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJ9GB23291; Tue, 13 May 2003 15:09:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJ8oB23267 for ; Tue, 13 May 2003 15:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27173 for ; Tue, 13 May 2003 15:42:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ffh0-0007Ck-00 for adslmib@ietf.org; Tue, 13 May 2003 15:44:06 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19Ffgz-0007Cc-00 for adslmib@ietf.org; Tue, 13 May 2003 15:44:06 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h4DJj531971679 for ; Tue, 13 May 2003 14:45:06 -0500 (CDT) Received: from [192.168.0.122] ([192.168.0.122]) by pesahsv.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Tue, 13 May 2003 14:45:04 -0500 From: Bob Ray Reply-To: rray@pesa.com To: adslmib mail list Content-Type: text/plain Message-Id: <1052855103.29204.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 May 2003 14:45:04 -0500 Content-Transfer-Encoding: 7bit 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] vdsl-09 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit No comments? Everybody happy? -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Tue May 13 16:13:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27853 for ; Tue, 13 May 2003 16:13:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DJdXO25203 for adslmib-archive@odin.ietf.org; Tue, 13 May 2003 15:39:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJdWB25200 for ; Tue, 13 May 2003 15:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27841 for ; Tue, 13 May 2003 16:12:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FgAi-0007Jz-00 for adslmib-web-archive@ietf.org; Tue, 13 May 2003 16:14:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FgAh-0007Jw-00 for adslmib-web-archive@ietf.org; Tue, 13 May 2003 16:14:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJdAB25186; Tue, 13 May 2003 15:39:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DJcxB25160 for ; Tue, 13 May 2003 15:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27831 for ; Tue, 13 May 2003 16:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FgAA-0007Jo-00 for adslmib@ietf.org; Tue, 13 May 2003 16:14:14 -0400 Received: from hostr51.alcatel.com ([143.209.5.1] helo=aurfsy.aur.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 19FgA9-0007Ji-00 for adslmib@ietf.org; Tue, 13 May 2003 16:14:13 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by aurfsy.aur.alcatel.com (8.11.6+Sun/8.11.3) with ESMTP id h4DKEmK03243; Tue, 13 May 2003 16:14:48 -0400 (EDT) Message-ID: <3EC15237.28B7FC98@alcatel.com> Date: Tue, 13 May 2003 16:14:47 -0400 From: Rajesh Abbi Organization: Alcatel X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rray@pesa.com CC: adslmib mail list Subject: Re: [Adslmib] vdsl-09 References: <1052855103.29204.0.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Bob, Only an editorial comment. We should include a reference to DSL Forum TR-057 (which is in the REVISIONs section). [DSLFTR057] DSL Forum TR-057, "VDSL Network Element Management", February 2003. Thanks for the hard work! Regards, Rajesh Bob Ray wrote: > No comments? Everybody happy? > > -- > 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 mailnull@www1.ietf.org Wed May 28 10:34:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06401 for ; Wed, 28 May 2003 10:34:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SEYOO07813 for adslmib-archive@odin.ietf.org; Wed, 28 May 2003 10:34:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SEYNB07810 for ; Wed, 28 May 2003 10:34:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06396 for ; Wed, 28 May 2003 10:34:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L1ys-0003fm-00 for adslmib-web-archive@ietf.org; Wed, 28 May 2003 10:32:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L1ys-0003fi-00 for adslmib-web-archive@ietf.org; Wed, 28 May 2003 10:32:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SEYHB07802; Wed, 28 May 2003 10:34:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SEXGB07769 for ; Wed, 28 May 2003 10:33:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06360 for ; Wed, 28 May 2003 10:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L1xn-0003fI-00 for adslmib@ietf.org; Wed, 28 May 2003 10:31:35 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19L1xm-0003fD-00 for adslmib@ietf.org; Wed, 28 May 2003 10:31:34 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h4SEX7GI646052 for ; Wed, 28 May 2003 09:33:08 -0500 (CDT) Received: from [192.168.0.122] ([192.168.0.122]) by pesahsv.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Wed, 28 May 2003 09:33:04 -0500 From: Bob Ray Reply-To: rray@pesa.com To: Valeria Garello Cc: adslmib mail list In-Reply-To: References: Content-Type: text/plain Message-Id: <1054132384.2849.43.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 28 May 2003 09:33:04 -0500 Content-Transfer-Encoding: 7bit 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] Re: About configuring line mode in draft-ietf-adslmib-vdsl-09 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-05-28 at 03:32, Valeria Garello wrote: > how can you configure the VDSL physical line mode (no channel, fast, > interleave, fast Or interleave, fast And interleave) ? > In draft-ietf-adslmib-vdsl-09 MIB there is not an object that can be used > in read-create mode for that purpose. The VDSL Line MIB uses ifIndex from the interfaces MIB. You might review RFC 2863 and section 2 of draft-ietf-adslmib-vdsl-09. In short, there is no creation of interfaces within the VDSL Line MIB. Your agent must also support the interfaces MIB. When a new VDSL Line is discovered (i.e. line card insertion, perhaps), the tables in the interfaces MIB and VDSL Line MIB are updated by your agent. Note that your agent will also be expected to provision the line using the default profile. Hope this helps! Out of curiousity, which Marconi office are you in? Pittsburg, PA USA? -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed May 28 14:31:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15087 for ; Wed, 28 May 2003 14:31:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SIVPl27169 for adslmib-archive@odin.ietf.org; Wed, 28 May 2003 14:31:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIVPB27166 for ; Wed, 28 May 2003 14:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15077 for ; Wed, 28 May 2003 14:31:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L5gG-0005yX-00 for adslmib-web-archive@ietf.org; Wed, 28 May 2003 14:29:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L5gF-0005yU-00 for adslmib-web-archive@ietf.org; Wed, 28 May 2003 14:29:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIVBB27154; Wed, 28 May 2003 14:31:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIUYB27082 for ; Wed, 28 May 2003 14:30:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15024 for ; Wed, 28 May 2003 14:30:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L5fQ-0005xb-00 for adslmib@ietf.org; Wed, 28 May 2003 14:28:52 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19L5fQ-0005xY-00 for adslmib@ietf.org; Wed, 28 May 2003 14:28:52 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h4SIURGI800797 for ; Wed, 28 May 2003 13:30:28 -0500 (CDT) Received: from [192.168.0.122] ([192.168.0.122]) by pesahsv.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Wed, 28 May 2003 13:30:24 -0500 Subject: Re: [Adslmib] Re: About configuring line mode in draft-ietf -adslmib-vdsl-09 From: Bob Ray Reply-To: rray@pesa.com To: Ettore Guadagnino Cc: adslmib mail list In-Reply-To: References: Content-Type: text/plain Message-Id: <1054146623.24292.279.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 28 May 2003 13:30:24 -0500 Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-05-28 at 10:30, Ettore Guadagnino wrote: > thank you Bob. I'm just wondering why in the ADSL-EXT-MIB the object > adslConfProfileLineType has been defined so that the manager can select > among the line mode to use (noChannel, fast, interleaved, fastOrInterleave, > fastAndinterleave). > Why this is not needed for VDSL? > What do I miss ? > > Bye, Ettore. I agree that SOME mechanism for changing the line type is needed for establishing which channel(s) are being used. The reason such an object is NOT in the VDSL Line MIB is that it introduces a great flood of complications, not to mention violating a bunch of rules. You need to remember that a VDSL Line has THREE entries in the ifTable: the physical line, ifType = vdsl(97), a fast channel, ifType = fast(124), and an interleave channel, ifType = interleave(125) If we were to make vdslLineType read-write, for example, then an administrator/user might change vdslLineType from both(5) to noChannel(1). One might expect such a change to influence the ifTable in various ways. Perhaps even to expect the agent to delete the entries (horror!) of type fast and interleave. Given that there are rules about the persistence of interfaces, this would introduce a dilemma (not to mention the additional text I would have to write for the VDSL Line MIB!!!). An alternative to deleting the entries in the ifTable (or adding them somehow when the converse change is made), would be to change the status of the entries. That is, change ifOperStatus to notPresent(6) (or up(1) in the converse). But if this interaction between an ifEntry and a VDSL Line must be maintained by an agent, then why not simply use the facilities in ifTable to control the channels in the first place? For example, when a VDSL Line Card is first inserted, create three new entries in the ifTable - the line, fast, and interleaved. Then enable and/or disable these elements via ifOperStatus or ifAdminStatus per the mechanics discussed in RFC 2863. vdslLineType would reflect these settings. Does this help? Regards, Bob Ray PESA Switching Systems http://www.pesa.com _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri May 30 08:08:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01854 for ; Fri, 30 May 2003 08:08:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UC8Ld28869 for adslmib-archive@odin.ietf.org; Fri, 30 May 2003 08:08:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UC8KB28866 for ; Fri, 30 May 2003 08:08:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01839 for ; Fri, 30 May 2003 08:08:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Liec-00032L-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 08:06:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Liec-00032H-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 08:06:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UC8EB28849; Fri, 30 May 2003 08:08:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UC75B28001 for ; Fri, 30 May 2003 08:07:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01765 for ; Fri, 30 May 2003 08:07:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LidP-00030h-00 for adslmib@ietf.org; Fri, 30 May 2003 08:05:23 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19LidN-00030Y-00 for adslmib@ietf.org; Fri, 30 May 2003 08:05:22 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA11845; Fri, 30 May 2003 14:06:51 +0200 (MET DST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA18076; Fri, 30 May 2003 14:06:51 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 14:06:25 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE70@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'moti.morgenstern@inoviatele.com'" , "'ssay@nlc.com'" , "'menachem.dodge@infineon.com'" , "'randy_presuhn@mindspring.com'" , "'greg.bathrick@nokia.com'" , 'p.f.adams@btopenworld.com', Kopetzky Walter , Muhn Harald Date: Fri, 30 May 2003 14:06:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Adslmib] RE: WG Last Call: draft-ietf-adslmib-vdsl-09.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: , Hi all, I sent the mentioned Word document to Mike, Bob, and Rajesh. I will not send it to the Adslmib mailing list (which accepts only plain text attachments) but see the summary of my comments below. Best Regards, Felix Flemisch Siemens AG -----Original Message----- From: Flemisch Felix Sent: Friday, May 30, 2003 1:58 PM To: 'sneedmike@hotmail.com'; 'rray@pesa.com'; 'rajesh.abbi@alcatel.com' Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt Mike, Bob, and Rajesh, please find attached a Word version of draft-ietf-adslmib-vdsl-09 with continuous line numbering where I have added my comments using change tracking. In the following I summarize the proposed changes. Mechanical and editorial changes were made to the following lines: 1-4, 128, 133, 146, 165, 183/184, 204, 255/256, 260-263, 269, 313, 348/349, 378-380, 384-387, 389, 391, 396, 400, 420, 427, 431/432, 454, 459/460, 477/478, 482, 487, 494-496, 505-510, 521/522, 607, 609, 614, 637, 644, 653, 663, 669/670, 678, 683, 696, 700, 715, 719, 721, 722ff, 723, 815, 819, 839, 849/850, 948, 960, 1007/1008, 1134, 1620, 1760/1761, 2078, 2141/2142, 2203, 2205, 2253/2254, 2276, 2278, 2322, 2333, 2689-2691, 2986, 3215, 3228, 3246, 3487, 3534, 3576, 3594, 3600, 3602, 3605, 3621, 3701, 3709. Clarifications were made to, or between, the following lines: 142ff, 259f, 663ff, 673f, 2445ff, 2455ff, 2490ff, 2500ff, 2732ff, 2744ff, 2760ff, 2762/2763, 2775ff, 2792f, 2797, 2801, 2806, 2810, 2815, 2819, 2824, 2833. Changes according to my email of 13th March (Adslmib digest #77) were made to, or between, the following lines: 805-808f, 830, 2252, 2704, 2719-2720f. Substantial changes were made between the following lines: 548f, 678ff, 711ff, 2267f, 2879ff, 2900, 3424f, 3556ff. Please use the Word file itself and not this line number account for reviewing and discussing my comments. Best Regards, Felix Flemisch Siemens AG -----Original Message----- From: Flemisch Felix Sent: Friday, May 30, 2003 12:12 PM To: 'adslmib@ietf.org' Cc: 'sneedmike@hotmail.com'; 'rray@pesa.com'; 'rajesh.abbi@alcatel.com'; 'moti.morgenstern@inoviatele.com'; 'ssay@nlc.com'; 'menachem.dodge@infineon.com'; 'randy_presuhn@mindspring.com'; 'greg.bathrick@nokia.com'; 'p.f.adams@btopenworld.com'; Kopetzky Walter; Muhn Harald Subject: WG Last Call: draft-ietf-adslmib-vdsl-09.txt Hi all, on 16th May I requested additional time to review draft-ietf-adslmib-vdsl-09 personally and to collect comments by Siemens. This is completed now, and I will send out the details with the next email. As a matter of fact, to ease the consideration of integration of the comments [mechanical, editorial, clarifying, substantial] into the RFC (or, maybe only into draft-ietf-adslmib-vdsl-10) I have prepared a detailed WORD update of draft-ietf-adslmib-vdsl-09.txt with change tracking. This email provides a high-level summary of our position and proposals how to proceed. The result is that I vote YES WITH COMMENTS but request willingness for utmost acceleration of line-code specific (LCS) VDSL management framework and MIB standardization in both DSLF and IETF to avoid a longer period where urgently needed LCS parameters have to be specified on a proprietary base. The LCS MIB(s), for SCM and MCM, MUST then be used together with the core VDSL-LINE-MIB. VDSL MIB standardization seems to be in a sort of unhappy state at the moment but I'm much confident that this can be improved considerably on the short term. The standardization work on VDSL line management is ongoing for quite some time now in both DSLF and IETF, and a couple of months ago it seemed to turn out to be a never-ending story. A major reason for this paralysis is, of course, the religious battle for the true line code: SCM/QAM/Coalition or MCM/DMT/Alliance, that's the question. But then the DSLF found the philosophers' stone, and split off all LCS issues in order to be able to specify a core protocol-independent management framework for VDSL lines. This pioneering task resulted in the publication of TR-057 in February 2003. Though it was realized in the meantime that TR-057 has some flaws (which are already addressed by DSLF's OpNM WG with a new WT for an addendum to TR-057 that will be fast tracked through straw ballot), IETF's ADSLMIB WG agreed to adopt DSLF's strategy and created a VDSL MIB that consists of a core set of essential parameters for managing VDSL lines in a line-code independent manner and is fully aligned with TR-057, and even includes first flaw resolutions (configuration of slow burst protection and fast FEC overhead). This equally pioneering work should not be held up unnecessarily. It turned out, however, that the agreed core set covers completely the PMS-TC sublayer but not completely enough the PMD sublayer. As a consequence no agreement was reached, not even within the SCM fraction, that basic (whatever this means) configuration of VDSL lines will be possible using the core VDSL MIB of draft-ietf-adslmib-vdsl-09 without additional LCS parameters. Therefore the development of an LCS-specific framework for both SCM and MCM by the DSLF and the development of one (or two) corresponding LCS VDSL MIB(s) are a MUST since otherwise vendor-specific MIBs need to be implemented at the disadvantage of customers (who regularly require multi-vendor capability). Also, the important, line-code independent question of how to configure the read-only channelization mode "vdslLineType" at start-up could not be settled. For the latter I'm proposing a new read-create parameter "vdslLineConfLineType" while for the LCS defects I'm proposing to add a note to the description of the VDSL-LINE-MIB module stating that a standardized LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module is seen as a MANDATORY supplement to VDSL-LINE-MIB. All other comments are clarifications or based on my earlier comments of 13th March. For details see my next email. Best Regards, Felix Flemisch Siemens AG _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri May 30 09:27:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06011 for ; Fri, 30 May 2003 09:27:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UDRTk01798 for adslmib-archive@odin.ietf.org; Fri, 30 May 2003 09:27:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDRTB01795 for ; Fri, 30 May 2003 09:27:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06001 for ; Fri, 30 May 2003 09:27:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LjtB-0004Eu-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 09:25:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LjtA-0004Er-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 09:25:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDRHB01779; Fri, 30 May 2003 09:27:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UAE2B21043 for ; Fri, 30 May 2003 06:14:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26832 for ; Fri, 30 May 2003 06:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lgry-0001oH-00 for adslmib@ietf.org; Fri, 30 May 2003 06:12:18 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19Lgrx-0001oD-00 for adslmib@ietf.org; Fri, 30 May 2003 06:12:17 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA10258; Fri, 30 May 2003 12:13:04 +0200 (MET DST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA06425; Fri, 30 May 2003 12:13:00 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 12:12:33 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE6D@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'sneedmike@hotmail.com'" , "'rray@pesa.com'" , "'rajesh.abbi@alcatel.com'" , "'moti.morgenstern@inoviatele.com'" , "'ssay@nlc.com'" , "'menachem.dodge@infineon.com'" , "'randy_presuhn@mindspring.com'" , "'greg.bathrick@nokia.com'" , Kopetzky Walter , Muhn Harald Date: Fri, 30 May 2003 12:11:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Adslmib] WG Last Call: draft-ietf-adslmib-vdsl-09.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: , Hi all, on 16th May I requested additional time to review draft-ietf-adslmib-vdsl-09 personally and to collect comments by Siemens. This is completed now, and I will send out the details with the next email. As a matter of fact, to ease the consideration of integration of the comments [mechanical, editorial, clarifying, substantial] into the RFC (or, maybe only into draft-ietf-adslmib-vdsl-10) I have prepared a detailed WORD update of draft-ietf-adslmib-vdsl-09.txt with change tracking. This email provides a high-level summary of our position and proposals how to proceed. The result is that I vote YES WITH COMMENTS but request willingness for utmost acceleration of line-code specific (LCS) VDSL framework and MIB standardization in both DSLF and IETF to avoid a longer period where urgently needed LCS parameters have to be specified on a proprietary base. The LCS MIB(s), for SCM and MCM, MUST then be used together with the core VDSL-LINE-MIB. VDSL MIB standardization seems to be in a sort of unhappy state at the moment but I'm much confident that this can be improved considerably on the short term. The standardization work on VDSL line management is ongoing for quite some time now in both DSLF and IETF, and a couple of months ago it seemed to turn out to be a never-ending story. A major reason for this paralysis is, of course, the religious battle for the true line code: SCM/QAM/Coalition or MCM/DMT/Alliance, that's the question. But then the DSLF found the philosophers' stone, and split off all LCS issues in order to be able to specify a core protocol-independent management framework for VDSL lines. This pioneering task resulted in the publication of TR-057 in February 2003. Though it was realized in the meantime that TR-057 has some flaws (which are already addressed by DSLF's OpNM WG with a new WT for an addendum to TR-057 that will be fast tracked through straw ballot), IETF's ADSLMIB WG agreed to adopt DSLF's strategy and created a VDSL MIB that consists of a core set of essential parameters for managing VDSL lines in a line-code independent manner and is fully aligned with TR-057, and even includes first flaw resolutions (configuration of slow burst protection and fast FEC overhead). This equally pioneering work should not be held up unnecessarily. It turned out, however, that the agreed core set covers completely the PMS-TC sublayer but not completely enough the PMD sublayer. As a consequence no agreement was reached, not even within the SCM fraction, that basic (whatever this means) configuration of VDSL lines will be possible using the core VDSL MIB of draft-ietf-adslmib-vdsl-09 without additional LCS parameters. Therefore the development of an LCS-specific framework for both SCM and MCM by the DSLF and the development of one (or two) corresponding LCS VDSL MIB(s) are a MUST since otherwise vendor-specific MIBs need to be implemented at the disadvantage of customers (who regularly require multi-vendor capability). Also, the important, line-code independent question of how to configure the read-only channelization mode "vdslLineType" at start-up could not be settled. For the latter I'm proposing a new read-create parameter "vdslLineConfLineType" while for the LCS defects I'm proposing to add a note to the description of the VDSL-LINE-MIB module stating that a standardized LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module is seen as a MANDATORY supplement to VDSL-LINE-MIB. All other comments are clarifications or based on my earlier comments of 13th March. For details see my next email. Best Regards, Felix Flemisch Siemens AG _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri May 30 11:57:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14225 for ; Fri, 30 May 2003 11:57:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UFvNL14857 for adslmib-archive@odin.ietf.org; Fri, 30 May 2003 11:57:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFvNB14854 for ; Fri, 30 May 2003 11:57:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14211 for ; Fri, 30 May 2003 11:57:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LmEH-0005yk-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 11:55:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LmEH-0005yh-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 11:55:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFvAB14837; Fri, 30 May 2003 11:57:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFu6B14799 for ; Fri, 30 May 2003 11:56:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14175 for ; Fri, 30 May 2003 11:56:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LmD2-0005yB-00 for adslmib@ietf.org; Fri, 30 May 2003 11:54:24 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 19LmD1-0005y8-00 for adslmib@ietf.org; Fri, 30 May 2003 11:54:23 -0400 Received: from h-68-164-23-187.snvacaid.covad.net ([68.164.23.187] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19LmEd-0000yW-00 for adslmib@ietf.org; Fri, 30 May 2003 08:56:03 -0700 Message-ID: <00ed01c326c3$085d0d20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE70@mchh2a8e.mchh.siemens.de> Date: Fri, 30 May 2003 08:49:19 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.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: , Hi - > From: "Flemisch Felix" > To: > Cc: ; ; ; ; ; <'p.f.adams@btopenworld.com'>; "Kopetzky Walter" ; "Muhn Harald" > Sent: Friday, May 30, 2003 5:06 AM > Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt > > > Hi all, > > I sent the mentioned Word document to Mike, Bob, and Rajesh. I will not send it to the Adslmib mailing list (which accepts only plain text attachments) but see the summary of my comments below. ... I object. Particularly at this late stage in the process (WG last call!), I believe it is important that any changes that are not purely editorial or mechanical should be posted to the WG mailing list, in plain text. Randy _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri May 30 12:09:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14582 for ; Fri, 30 May 2003 12:09:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UG9Kr16769 for adslmib-archive@odin.ietf.org; Fri, 30 May 2003 12:09:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UG9KB16766 for ; Fri, 30 May 2003 12:09:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14563 for ; Fri, 30 May 2003 12:09:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LmPq-00063a-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 12:07:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LmPj-00063T-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 12:07:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UG98B16755; Fri, 30 May 2003 12:09:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UG8EB16730 for ; Fri, 30 May 2003 12:08:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14549 for ; Fri, 30 May 2003 12:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LmOm-00063D-00 for adslmib@ietf.org; Fri, 30 May 2003 12:06:32 -0400 Received: from law14-f56.law14.hotmail.com ([64.4.21.56] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19LmOl-00062i-00 for adslmib@ietf.org; Fri, 30 May 2003 12:06:31 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 May 2003 09:07:41 -0700 Received: from 66.152.60.98 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 30 May 2003 16:07:40 GMT X-Originating-IP: [66.152.60.98] X-Originating-Email: [sneedmike@hotmail.com] From: "Michael Sneed" To: randy_presuhn@mindspring.com, adslmib@ietf.org Subject: Re: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.txt Date: Fri, 30 May 2003 12:07:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 May 2003 16:07:41.0271 (UTC) FILETIME=[98EEDE70:01C326C5] 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: , Thanks for the thorough contribution Felix, but Randy is right. If anyone is interested in the Word document, I have in the past been able to make that available on the ftp server, but we need plain text for general distribution. Regards, Mike >From: "Randy Presuhn" >To: >Subject: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.txt >Date: Fri, 30 May 2003 08:49:19 -0700 > >Hi - > > > From: "Flemisch Felix" > > To: > > Cc: ; ; >; ; >; <'p.f.adams@btopenworld.com'>; "Kopetzky Walter" >; "Muhn Harald" > > > Sent: Friday, May 30, 2003 5:06 AM > > Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt > > > > > > > Hi all, > > > > I sent the mentioned Word document to Mike, Bob, and Rajesh. I will not >send it to the Adslmib mailing list (which accepts only >plain text attachments) but see the summary of my comments below. >... > >I object. Particularly at this late stage in the process (WG last call!), >I believe it is important that any changes that are not purely editorial >or mechanical should be posted to the WG mailing list, in plain text. > >Randy > > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www1.ietf.org/mailman/listinfo/adslmib _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri May 30 17:21:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28913 for ; Fri, 30 May 2003 17:21:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ULKhJ07788 for adslmib-archive@odin.ietf.org; Fri, 30 May 2003 17:20:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ULKhB07785 for ; Fri, 30 May 2003 17:20:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28909 for ; Fri, 30 May 2003 17:20:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LrH8-0001lr-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 17:18:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LrH7-0001lo-00 for adslmib-web-archive@ietf.org; Fri, 30 May 2003 17:18:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ULKFB07762; Fri, 30 May 2003 17:20:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKhPB04380 for ; Fri, 30 May 2003 16:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27156 for ; Fri, 30 May 2003 16:43:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lqh3-0001H4-00 for adslmib@ietf.org; Fri, 30 May 2003 16:41:41 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19Lqh0-0001H1-00 for adslmib@ietf.org; Fri, 30 May 2003 16:41:38 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id WAA18478; Fri, 30 May 2003 22:42:13 +0200 (MET DST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id WAA21544; Fri, 30 May 2003 22:42:12 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 22:41:46 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE74@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'sneedmike@hotmail.com'" , "'rray@pesa.com'" , "'rajesh.abbi@alcatel.com'" , "'randy_presuhn@mindspring.com'" Date: Fri, 30 May 2003 22:41:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C326EB.E23833D0" Subject: [Adslmib] RE: WG Last Call: draft-ietf-adslmib-vdsl-09.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: , 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_000_01C326EB.E23833D0 Content-Type: text/plain; charset="ISO-8859-1" Hi all, please find attached a plain ASCII text version of the updated "draft-ietf-adslmib-vdsl-09.txt" that I previously distributed as a Word document with continuous line numbering where I have added my comments using change tracking. I have named this updated document "draft-ietf-adslmib-vdsl-09a.txt". In the following I summarize the proposed changes. Please note that the line numbers refer to the reviewed "draft-ietf-adslmib-vdsl-09.txt" and not to the updated, attached "draft-ietf-adslmib-vdsl-09a.txt"! Also, the page formatting is unchanged from vdsl-09. When required, you may use an appropriate file comparison tool to keep track of the changes (most editorial or mechanical) between the two .txt files. Mechanical and editorial changes were made to the following (old) lines: 1-4, 128, 133, 146, 165, 183/184, 204, 255/256, 260-263, 269, 313, 348/349, 378-380, 384-387, 389, 391, 396, 400, 420, 427, 431/432, 454, 459/460, 477/478, 482, 487, 494-496, 505-510, 521/522, 607, 609, 614, 637, 644, 653, 663, 669/670, 678, 683, 696, 700, 715, 719, 721, 722ff, 723, 815, 819, 839, 849/850, 948, 960, 1007/1008, 1134, 1620, 1760/1761, 2078, 2141/2142, 2203, 2205, 2253/2254, 2276, 2278, 2322, 2333, 2689-2691, 2986, 3215, 3228, 3246, 3487, 3534, 3576, 3594, 3600, 3602, 3605, 3621, 3701, 3709. Clarifications were made to, or between, the following (old) lines: 142ff, 259f, 663ff, 673f, 2445ff, 2455ff, 2490ff, 2500ff, 2732ff, 2744ff, 2760ff, 2762/2763, 2775ff, 2792f, 2797, 2801, 2806, 2810, 2815, 2819, 2824, 2833. Changes according to my email of 13th March (Adslmib digest #77) were made to, or between, the following (old) lines: 805-808f, 830, 2252, 2704, 2719-2720f. Substantial changes were made between the following (old) lines: 548f, 678ff, 711ff, 2267f, 2879ff, 2900, 3424f, 3556ff. The originally distributed Word file was meant to provide a major simplification for quick reviewing and discussing my comments since both the large and the tiny updates can easily be checked there. It would also be very easy to accept or reject step-by-step individual change proposals in Word. Best Regards, Felix Flemisch Siemens AG -----Original Message----- From: Flemisch Felix Sent: Friday, May 30, 2003 12:12 PM To: 'adslmib@ietf.org' Cc: 'sneedmike@hotmail.com'; 'rray@pesa.com'; 'rajesh.abbi@alcatel.com'; 'moti.morgenstern@inoviatele.com'; 'ssay@nlc.com'; 'menachem.dodge@infineon.com'; 'randy_presuhn@mindspring.com'; 'greg.bathrick@nokia.com'; Kopetzky Walter; Muhn Harald Subject: WG Last Call: draft-ietf-adslmib-vdsl-09.txt Hi all, on 16th May I requested additional time to review draft-ietf-adslmib-vdsl-09 personally and to collect comments by Siemens. This is completed now, and I will send out the details with the next email. As a matter of fact, to ease the consideration of integration of the comments [mechanical, editorial, clarifying, substantial] into the RFC (or, maybe only into draft-ietf-adslmib-vdsl-10) I have prepared a detailed WORD update of draft-ietf-adslmib-vdsl-09.txt with change tracking. This email provides a high-level summary of our position and proposals how to proceed. The result is that I vote YES WITH COMMENTS but request willingness for utmost acceleration of line-code specific (LCS) VDSL management framework and MIB standardization in both DSLF and IETF to avoid a longer period where urgently needed LCS parameters have to be specified on a proprietary base. The LCS MIB(s), for SCM and MCM, MUST then be used together with the core VDSL-LINE-MIB. VDSL MIB standardization seems to be in a sort of unhappy state at the moment but I'm much confident that this can be improved considerably on the short term. The standardization work on VDSL line management is ongoing for quite some time now in both DSLF and IETF, and a couple of months ago it seemed to turn out to be a never-ending story. A major reason for this paralysis is, of course, the religious battle for the true line code: SCM/QAM/Coalition or MCM/DMT/Alliance, that's the question. But then the DSLF found the philosophers' stone, and split off all LCS issues in order to be able to specify a core protocol-independent management framework for VDSL lines. This pioneering task resulted in the publication of TR-057 in February 2003. Though it was realized in the meantime that TR-057 has some flaws (which are already addressed by DSLF's OpNM WG with a new WT for an addendum to TR-057 that will be fast tracked through straw ballot), IETF's ADSLMIB WG agreed to adopt DSLF's strategy and created a VDSL MIB that consists of a core set of essential parameters for managing VDSL lines in a line-code independent manner and is fully aligned with TR-057, and even includes first flaw resolutions (configuration of slow burst protection and fast FEC overhead). This equally pioneering work should not be held up unnecessarily. It turned out, however, that the agreed core set covers completely the PMS-TC sublayer but not completely enough the PMD sublayer. As a consequence no agreement was reached, not even within the SCM fraction, that basic (whatever this means) configuration of VDSL lines will be possible using the core VDSL MIB of draft-ietf-adslmib-vdsl-09 without additional LCS parameters. Therefore the development of an LCS-specific framework for both SCM and MCM by the DSLF and the development of one (or two) corresponding LCS VDSL MIB(s) are a MUST since otherwise vendor-specific MIBs need to be implemented at the disadvantage of customers (who regularly require multi-vendor capability). Also, the important, line-code independent question of how to configure the read-only channelization mode "vdslLineType" at start-up could not be settled. For the latter I'm proposing a new read-create parameter "vdslLineConfLineType" while for the LCS defects I'm proposing to add a note to the description of the VDSL-LINE-MIB module stating that a standardized LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module is seen as a MANDATORY supplement to VDSL-LINE-MIB. All other comments are clarifications or based on my earlier comments of 13th March. For details see my next email. Best Regards, Felix Flemisch Siemens AG ------_=_NextPart_000_01C326EB.E23833D0 Content-Type: text/plain; name="draft-ietf-adslmib-vdsl-09a.txt" Content-Disposition: attachment; filename="draft-ietf-adslmib-vdsl-09a.txt" Content-Transfer-Encoding: quoted-printable Network Working Group B. = Ray Category: Internet Draft PESA Switching = Systems R. = Abbi = Alcatel June = 2003 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) draft-ietf-adslmib-vdsl-09a.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines a Management Information Base (MIB) module for = use with network management protocols in the Internet community. In = particular, it describes objects used for managing Very high speed Digital Subscriber Line (VDSL) interfaces [T1E1311, T1E1011, = T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971]. This document specifies a MIB module in a manner that is compliant=20 to the SMIv2 (STD 58 [RFC2578, RFC2579, RFC2580]). Expires December 1, 2003 [Page = 1] INTERNET-DRAFT VDSL-LINE MIB May = 2003 Table of Contents 1. The SNMP Management Framework ............................. = 2 2. Overview .................................................. = 3 2.1 Relationship of the VDSL Line MIB to other MIBs ........... = 3 2.2 Conventions used in the MIB ............................... = 5 2.3 Structure ................................................. = 5 2.4 Counters, Interval Buckets and Thresholds ................. = 7 2.5 Profiles .................................................. = 7 2.6 Notifications ............................................. = 8 2.7 Persistence ............................................... = 9 3. Conformance and Compliance ................................ = 10 4. Definitions ............................................... = 10 References ................................................ = 58 Security Considerations ................................... = 62 IANA Considerations ....................................... = 62 Acknowledgments ........................................... = 62 Intellectual Property Notice .............................. = 63 Authors' Addresses ........................................ = 63 Full Copyright Statement .................................. = 64 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16 [RFC1155, RFC1212] and RFC 1215 [RFC1215]. The second=20 version, called SMIv2, is described in STD 58 [RFC2578, RFC2579, RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 = [RFC2573] and the view-based access control mechanism described in RFC Expires December 1, 2003 [Page = 2] INTERNET-DRAFT VDSL-LINE MIB May = 2003 2575 [RFC2575]. A more detailed introduction to the current SNMP Management = Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. = The textual conventions used in this MIB module cannot be translated to SMIv1 since the Counter64 type does not exist in SMIv1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119=20 [RFC2119]. 2. Overview This document describes an SNMP MIB for managing VDSL Lines. These definitions are based upon the specifications for VDSL as defined=20 in T1E1, ETSI, and ITU documentation [T1E1311, T1E1011, T1E1013,=20 ETSI2701, ETSI2702, ITU9931, ITU9971]. Additionally the protocol- independent (and line-code independent) management framework for = VDSL lines specified by DSLF has be taken into consideration [DSLFTR057]. The MIB is located in the MIB tree under MIB 2 transmission, as=20 discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of=20 this document. 2.1 Relationship of the VDSL Line MIB to other MIBs This section outlines the relationship of this MIB with other MIBs=20 described in RFCs. Specifically, IF-MIB as presented RFC 2863 [RFC2863] is discussed. 2.1.1 General IF-MIB Integration (RFC 2863) The VDSL Line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifType to VDSL: IANAifType ::=3D TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... vdsl(97), -- Very High-speed Digital Subscriber Loop/Line ... } Additionally, a VDSL line may contain an optional fast channel and an optional interleaved channel which also integrate into RFC=20 2863 [RFC2863]. The IANA has assigned the following ifTypes to = these channels: Expires December 1, 2003 [Page = 3] INTERNET-DRAFT VDSL-LINE MIB May = 2003 IANAifType ::=3D TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... interleave(124), -- Interleaved channel fast(125), -- Fast channel ... } 2.1.2 Usage of ifTable The MIB branch identified by this ifType contains tables appropriate for this interface type. Most such tables extend the ifEntry table, and are indexed by ifIndex. For interfaces in systems implementing this MIB, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneral group = in RFC 2863 [RFC2863], and are not duplicated in the VDSL Line MIB. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ifIndex Interface index. ifDescr See interfaces MIB [RFC2863]. ifType vdsl(97), interleave(124), or fast(125) ifSpeed Set as appropriate. =20 ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB [RFC2863]. ifOperStatus See interfaces MIB [RFC2863]. ifLastChange See interfaces MIB [RFC2863]. ifName See interfaces MIB [RFC2863]. ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. ifLinkUpDownTrapEnable Default to enabled(1). = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Figure 1: Use of ifTable Objects Section 2.3, below, describes the structure of this MIB in relation to ifEntry in greater detail. Expires December 1, 2003 [Page = 4] INTERNET-DRAFT VDSL-LINE MIB May = 2003 2.2 Conventions used in the MIB 2.2.1 Naming Conventions A. Vtuc -- (VTUC) modem at near (Central) end of line B. Vtur -- (VTUR) modem at Remote end of line C. Vtu -- One of either Vtuc or Vtur D. Curr -- Current E. Prev -- Previous F. Atn -- Attenuation G. ES -- Errored Second H. SES -- Severely Errored Second I. UAS -- Unavailable Second J. LCS -- Line Code Specific K. Lof -- Loss of Frame L. Lol -- Loss of Link M. Los -- Loss of Signal N. Lpr -- Loss of Power O. xxxs -- Interval of Seconds in which xxx occurs (e.g., xxx =3D Lof, Los, Lpr, Lol) P. Max -- Maximum Q. Mgn -- Margin R. Min -- Minimum S. ms -- Milliseconds T. Psd -- Power Spectral Density U. Snr -- Signal to Noise Ratio V. Tx -- Transmit W. Blks -- Blocks 2.2.2 Textual Conventions The following textual conventions are defined to reflect the line=20 topology in the MIB (further discussed in the following section) and to define the behaviour of the statistics to be maintained by an agent. o VdslLineCodingType : Attributes with this syntax identify the line coding used. Specified as an INTEGER, the three values are: other(1) -- none of the following mcm(2) -- Multiple Carrier Modulation=20 scm(3) -- Single Carrier Modulation o VdslLineEntity : Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values are: vtuc(1) -- central site modem vtur(2) -- remote site modem 2.3 Structure Expires December 1, 2003 [Page = 5] INTERNET-DRAFT VDSL-LINE MIB May = 2003 The MIB is structured into following MIB groups: o vdslGroup : This group supports all line code independent MIB objects found in this MIB. The following tables contain objects permitted for ifType vdsl(97): - vdslLineTable=20 - vdslPhysTable=20 - vdslPerfDataTable - vdslPerfIntervalTable - vdslPerf1DayIntervalTable - vdslLineConfProfileTable - vdslLineAlarmConfProfileTable=20 The following tables contain objects permitted for ifTypes=20 interleave(124) and fast(125): - vdslChanTable=20 - vdslChanPerfDataTable - vdslChanPerfIntervalTable - vdslChanPerf1DayIntervalTable Figure 2, below, displays the relationship of the tables in the vdslGroup to ifEntry (and each other): ifEntry(ifType=3D97) ----> vdslLineTableEntry 1:(0..1) vdslLineTableEntry ----> vdslPhysTableEntry 1:(0..2) ----> vdslPerfDataEntry 1:(0..2) ----> vdslLineConfProfileEntry 1:(0..1) ----> vdslLineAlarmConfProfileEntry 1:(0..1) vdslPhysTableEntry ----> vdslPerfIntervalEntry 1:(0..96) =20 ----> vdslPerf1DayIntervalEntry 1:(0..30) ifEntry(ifType=3D124) ----> vdslChanEntry 1:(0..2) ----> vdslChanPerfDataEntry 1:(0..2) ifEntry(ifType=3D125) ----> vdslChanEntry 1:(0..2) ----> vdslChanPerfDataEntry 1:(0..2) vdslChanEntry ----> vdslchanPerfIntervalEntry 1:(0..96) ----> vdslchan1DayPerfIntervalEntry 1:(0..30) Figure 2: Table Relationships 2.3.1 Line Topology A VDSL Line consists of two units =96 a Vtuc (the central = transceiver unit) and a Vtur (the remote transceiver unit). Expires December 1, 2003 [Page = 6] INTERNET-DRAFT VDSL-LINE MIB May = 2003 <-- Network Side Customer Side --> || +-------+ +-------+ | | | | | Vtuc +------------------+ Vtur | | | | | +-------+ +-------+ =20 Figure 3: General topology for a VDSL Line 2.4 Counters, Interval Buckets and Thresholds For Loss of Frame (lof), Loss of Link (lol), Loss of Signal (los), and Loss of Power (lpr), Errored Seconds (ES), Severely Errored Seconds (SES), and Unavailable Seconds (UAS) there are event=20 counters, current 15-minute, 0 to 96 15-minute history bucket(s), and 0 to 30 1-day history bucket(s) of "interval-counters". Each current 15-minute event bucket has an associated threshold=20 notification. Each of these counters uses the textual conventions defined in the HC-PerfHist-TC-MIB. The HC-PerfHist-TC-MIB [RFChctc] simply defines 64-bit versions of the textual conventions found in RFC 2493 [RFC2493]. There is no requirement for an agent to ensure a fixed relationship between the start of a fifteen minute interval and any wall clock; however, some implementations may align the fifteen minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with the start of a day. Counters are not reset when a Vtu is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). 2.5 Profiles As a managed node can handle a large number of Vtus, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on = every Vtu may become burdensome. Moreover, most lines are provisioned=20 identically with the same set of parameters. To simplify the=20 provisioning process, this MIB makes use of profiles. A profile is = a set of parameters that can be shared by multiple lines using the = same configuration. The following profiles are used in this MIB: o Line Configuration Profiles - Line configuration profiles = contain parameters for configuring VDSL lines. They are defined in the vdslLineConfProfileTable. Expires December 1, 2003 [Page = 7] INTERNET-DRAFT VDSL-LINE MIB May = 2003 o Alarm Configuration Profiles - These profiles contain parameters = for configuring alarm thresholds for VDSL modems. These = profiles are defined in the vdslLineAlarmConfProfileTable. One or more lines may be configured to share parameters of a single profile by setting its vdslLineConfProfile objects to the value of=20 this profile. If a change is made to the profile, all lines that=20 refer to it will be reconfigured to the changed parameters. Before a profile can be deleted or taken out of service it must be first=20 unreferenced from all associated lines. Implementations MUST provide a default profile with an index value = of `DEFVAL' for each profile type. The values of the associated=20 parameters will be vendor specific unless otherwise indicated in = this document. Before a line's profiles have been set, these profiles=20 will be automatically used by setting vdslLineConfProfile and vdslLineAlarmConfProfile to `DEFVAL' where appropriate. This default profile name, `DEFVAL', is considered reserved in the = context of profiles defined in this MIB module. Profiles are created, assigned, and deleted dynamically using the profile name and profile row status in each of the ten profile tables (nine line configuration tables and one alarm configuration table). Profile changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line. 2.6 Notifications The ability to generate the SNMP notifications coldStart/WarmStart (per [RFC2863]) which are per agent (e.g., per Digital Subscriber=20 Line Access Multiplexer, or DSLAM, in such a device), and=20 linkUp/linkDown (per [RFC2863]) which are per interface (i.e., VDSL=20 line) is required. The notifications defined in this MIB are for initialization failure and for the threshold crossings associated with the following = events: lof, lol, los, lpr, ES, SES, and UAS. Each threshold has its own=20 enable/threshold value. When that value is 0, the notification is=20 disabled. A linkDown notification MAY be generated whenever any of lof, lol, los, lpr, ES, SES, or UAS threshold crossing event (as defined in this MIB module) occurs. The corresponding linkUp notification=20 MAY be sent when all link failure conditions are cleared. The vdslCurrStatus is a bitmask representing all outstanding error=20 conditions associated with a particular VDSL modem. Note that since = status of remote modems is obtained via the EOC, this information=20 may be unavailable for units that are unreachable via EOC during a=20 line error condition. Therefore, not all conditions may always be=20 included in its current status. Notifications corresponding to the=20 Expires December 1, 2003 [Page = 8] INTERNET-DRAFT VDSL-LINE MIB May = 2003 bit fields in this object are defined. A threshold notification occurs whenever the corresponding current=20 15-minute interval error counter becomes equal to, or exceeds the=20 threshold value. One notification may be sent per interval per=20 interface. Since the current 15-minute counter are reset to 0 every = 15 minutes, if the condition persists, the notification may recur as = often as every 15 minutes. For example, to get a notification=20 whenever a "loss of" event occurs (but at most once every 15=20 minutes), set the corresponding threshold to 1. The agent will=20 generate a notification when the event originally occurs. Note that the Network Management System, or NMS, may receive a=20 linkDown notification, as well, if enabled (via=20 ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15 minute interval, the counter is reset. When the first second goes=20 by and the event occurs, the current interval bucket will be 1,=20 which equals the threshold and the notification will be sent again. 2.7 Persistence All objects defined in this MIB module, which may be set (read-write = or read-create), SHOULD be stored persistently. Following is=20 an exhaustive list of these persistent objects: vdslLineConfProfile vdslLineAlarmConfProfile vdslLineConfProfileName vdslLineConfDownstreamRateMode vdslLineConfUpstreamRateMode vdslLineConfDownstreamMaxPwr vdslLineConfUpstreamMaxPwr vdslLineConfDownstreamMaxSnrMgn vdslLineConfDownstreamMinSnrMgn vdslLineConfDownstreamTargetSnrMgn vdslLineConfUpstreamMaxSnrMgn vdslLineConfUpstreamMinSnrMgn vdslLineConfUpstreamTargetSnrMgn vdslLineConfDownstreamFastMaxDataRate vdslLineConfDownstreamFastMinDataRate vdslLineConfDownstreamSlowMaxDataRate vdslLineConfDownstreamSlowMinDataRate vdslLineConfUpstreamFastMaxDataRate vdslLineConfUpstreamFastMinDataRate vdslLineConfUpstreamSlowMaxDataRate vdslLineConfUpstreamSlowMinDataRate vdslLineConfDownstreamRateRatio vdslLineConfUpstreamRateRatio vdslLineConfDownstreamMaxInterDelay vdslLineConfUpstreamMaxInterDelay vdslLineConfDownstreamPboControl vdslLineConfUpstreamPboControl vdslLineConfDownstreamPboLevel vdslLineConfUpstreamPboLevel Expires December 1, 2003 [Page = 9] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslLineConfDeploymentScenario vdslLineConfAdslPresence vdslLineConfApplicableStandard vdslLineConfBandPlan vdslLineConfBandPlanFx vdslLineConfBandU0Usage vdslLineConfUpstreamPsdTemplate vdslLineConfDownstreamPsdTemplate vdslLineConfHamBandMask vdslLineConfCustomNotch1Start vdslLineConfCustomNotch1Stop vdslLineConfCustomNotch2Start vdslLineConfCustomNotch2Stop vdslLineConfDownstreamTargetSlowBurstProtection vdslLineConfUpstreamTargetSlowBurstProtection vdslLineConfDownstreamMaxFastFecOverhead vdslLineConfUpstreamMaxFastFecOverhead vdslLineConfLineType vdslLineConfProfileRowStatus vdslLineAlarmConfProfileName vdslThresh15MinLofs vdslThresh15MinLoss vdslThresh15MinLprs vdslThresh15MinLols vdslThresh15MinESs vdslThresh15MinSESs vdslThresh15MinUASs vdslInitFailureNotificationEnable vdslLineAlarmConfProfileRowStatus It should also be noted that interface indices in this MIB are=20 maintained persistently. VACM data relating to these should be=20 stored persistently as well. 3. Conformance and Compliance For VDSL lines, the following group is mandatory: - vdslGroup 4. Definitions VDSL-LINE-MIB DEFINITIONS ::=3D BEGIN IMPORTS MODULE-IDENTITY,=20 OBJECT-TYPE, Counter64, Gauge32, Integer32, Unsigned32, NOTIFICATION-TYPE, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION, Expires December 1, 2003 [Page = 10] INTERNET-DRAFT VDSL-LINE MIB May = 2003 RowStatus, TruthValue FROM SNMPv2-TC HCPerfValidIntervals, HCPerfInvalidIntervals, HCPerfTimeElapsed, HCPerfIntervalThreshold, HCPerfCurrentCount, HCPerfIntervalCount FROM HC-PerfHist-TC-MIB MODULE-COMPLIANCE,=20 OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; vdslMIB MODULE-IDENTITY LAST-UPDATED "200305010000Z" -- May 1, 2003 ORGANIZATION "IETF ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: = https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh, NC 27627-7324 USA Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-editor: Bob Ray PESA Switching Systems, Inc. Postal: 330-A Wynn Drive Huntsville, AL 35805 USA Email: rray@pesa.com Phone: +1 256 726 9200 ext. 142 Co-editor: Rajesh Abbi Alcatel USA Postal: 2912 Wake Forest Road Raleigh, NC 27609-7860 USA Email: Rajesh.Abbi@alcatel.com Phone: +1 919 850 6194 " DESCRIPTION "The MIB module defining objects for the management of a pair = of VDSL modems at each end of the VDSL line. Each such line has an entry in an ifTable which may include multiple modem lines. An agent may reside at either end of the line. However, the MIB is designed to require no management communication between them beyond that inherent in the low-level VDSL line protocol. The agent may monitor and control this protocol for its needs. VDSL lines may support optional Fast or Interleaved channels. If these are supported, additional entries corresponding to the supported channels must be created in the ifTable. Thus a VDSL Expires December 1, 2003 [Page = 11] INTERNET-DRAFT VDSL-LINE MIB May = 2003 line that supports both channels will have three entries in the ifTable, one for each physical, fast, and interleaved, whose ifType values are equal to vdsl(97), fast(125), and interleave(124), respectively. The ifStackTable is used to represent the relationship between the entries. =20 Naming Conventions: Vtuc -- (VTUC) modem at near (Central) end of line Vtur -- (VTUR) modem at Remote end of line Vtu -- One of either Vtuc or Vtur Curr -- Current Prev -- Previous Atn -- Attenuation ES -- Errored Second SES -- Severely Errored Second UAS -- Unavailable Second LCS -- Line Code Specific Lof -- Loss of Frame Lol -- Loss of Link Los -- Loss of Signal Lpr -- Loss of Power xxxs -- Interval of Seconds in which xxx occurs (e.g., xxx =3D Lof, Los, Lpr) Max -- Maximum Mgn -- Margin Min -- Minimum ms -- Milliseconds Psd -- Power Spectral Density Snr -- Signal to Noise Ratio Tx -- Transmit Blks -- Blocks " -- Note This MIB module does not contain line-code-specific (LCS) elements for neither MCM lines nor SCM lines. However, a standardized LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module is seen as a MANDATORY supplement to the VDSL-LINE-MIB since otherwise both MCM and SCM lines can be fully configured in a proprietary way only." -- Revision history REVISION "200111010000Z" =96 November 1, 2001 DESCRIPTION "Initial draft." REVISION "200203310000Z" -- March 31, 2002 DESCRIPTION "Added Rajesh Abbi as co-author." REVISION "200204090000Z" -- April 9, 2002 DESCRIPTION "Removed use of IMPLIED profile indices." REVISION "200206160000Z" -- June 16, 2002 DESCRIPTION "Revised per input from DSL Forum." REVISION "200209230000Z" -- September 23, 2002 DESCRIPTION "Revised per more input from DSL Forum." REVISION "200210150000Z" -- October 15, 2002 DESCRIPTION "Modified per input from Randy Presuhn and Moti Morgenstern." REVISION "200210300000Z" -- October 30, 2002 DESCRIPTION "Modified per input from Umberto Bonollo and Travis Levin." REVISION "200212300000Z" -- December 30, 2002 DESCRIPTION "Changed profile indices to strings." Expires December 1, 2003 [Page = 12] INTERNET-DRAFT VDSL-LINE MIB May = 2003 REVISION "200304180000Z" -- April 18, 2003 DESCRIPTION "Brought into conformance with DSLF TR-057. This means in particular that all line-code-specific (LCS) elements have been removed for both, MCM lines and SCM lines. However, a standardized LCS VDSL Line Extension MIB module is seen as a MANDATORY supplement to the VDSL-LINE-MIB since otherwise neither MCM lines nor SCM lines can be fully configured." REVISION "200305010000Z" -- May 1, 2003 DESCRIPTION "Added vdslLineConfDownstreamTargetSlowBurstProtection, vdslLineConfUpstreamTargetSlowBurstProtection, vdslLineConfDownstreamMaxFastFecOverhead, vdslLineConfUpstreamMaxFastFecOverhead, vdslChanCurrTxSlowBurstProtection, vdslChanCurrTxFastFecOverhead. Changed 1024 to 1000 (1 kbps =3D 1000 bps) for objects related to transmission speeds." REVISION "200305290000Z" -- May 29, 2003 DESCRIPTION "Added vdslLineConfLineType, added note to DESCRIPTION of MODULE-IDENTITY regarding necessity of LCS MIB extensions, corrected mechanical and editorial flaws, added various clarifications." ::=3D { transmission 97 } vdslLineMib OBJECT IDENTIFIER ::=3D { vdslMIB 1 } vdslMibObjects OBJECT IDENTIFIER ::=3D { vdslLineMib 1 } -- -- textual conventions used in this MIB -- VdslLineCodingType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax for the VDSL Line Code." SYNTAX INTEGER=20 { other(1), -- none of the following mcm(2), -- Multiple Carrier Modulation=20 scm(3) -- Single Carrier Modulation } VdslLineEntity ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a modem as being either Vtuc or Vtur. A VDSL line consists of two modems, a Vtuc and a Vtur." SYNTAX INTEGER=20 { vtuc(1), -- central site modem vtur(2) -- remote site modem } -- -- objects -- vdslLineTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineEntry MAX-ACCESS not-accessible STATUS current Expires December 1, 2003 [Page = 13] INTERNET-DRAFT VDSL-LINE MIB May = 2003 DESCRIPTION "This table includes common attributes describing both ends of the line. It is required for all VDSL physical interfaces. VDSL physical interfaces are those ifEntries where ifType is equal to vdsl(97)." ::=3D { vdslMibObjects 1 } vdslLineEntry OBJECT-TYPE SYNTAX VdslLineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslLineTable." INDEX { ifIndex } ::=3D { vdslLineTable 1 } VdslLineEntry ::=3D SEQUENCE=20 { vdslLineCoding VdslLineCodingType, vdslLineType INTEGER, vdslLineConfProfile SnmpAdminString, vdslLineAlarmConfProfile SnmpAdminString } vdslLineCoding OBJECT-TYPE SYNTAX VdslLineCodingType MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the VDSL coding type used on this line." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineEntry 1 } vdslLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- fast channel exists only interleavedOnly(3), -- interleaved channel exists only fastOrInterleaved(4), -- either fast or interleaved -- channels can exist, but -- only one at any time fastAndInterleaved(5) -- both fast and interleaved -- channels exist } MAX-ACCESS read-only STATUS current DESCRIPTION "Defines the type of VDSL physical line entity that exists, by defining whether and how the line is channellized. If the line is channellized, the value will be other than noChannel(1). This object defines which channel type(s) are supported. In the case that the line is channellized, the manager can use the ifStackTable to determine the ifIndex for the associated channel(s). Expires December 1, 2003 [Page = 14] INTERNET-DRAFT VDSL-LINE MIB May = 2003 Note that slow and interleaved refer to the same channel." ::=3D { vdslLineEntry 2 } vdslLineConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL Line Configuration Profile Table ( vdslLineConfProfileTable ), which applies for this VDSL line, and channels if applicable." ::=3D { vdslLineEntry 3 } vdslLineAlarmConfProfile OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the VDSL Line Alarm Configuration Profile Table ( vdslLineAlarmConfProfileTable ), which applies to this VDSL line, and channels if applicable." ::=3D { vdslLineEntry 4 } vdslPhysTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu. Each row=20 contains the Physical Layer Parameters table for that=20 Vtu. VDSL physical interfaces are those ifEntries where=20 ifType is equal to vdsl(97)." ::=3D { vdslMibObjects 2 } vdslPhysEntry OBJECT-TYPE SYNTAX VdslPhysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslPhysTable." INDEX { ifIndex,=20 vdslPhysSide } ::=3D { vdslPhysTable 1 } VdslPhysEntry ::=3D SEQUENCE=20 { vdslPhysSide VdslLineEntity, vdslInvSerialNumber SnmpAdminString, vdslInvVendorID SnmpAdminString, Expires December 1, 2003 [Page = 15] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslInvVersionNumber SnmpAdminString, vdslCurrSnrMgn Integer32, vdslCurrAtn Gauge32, vdslCurrStatus BITS, vdslCurrOutputPwr Integer32, vdslCurrAttainableRate Gauge32, vdslCurrLineRate Gauge32 } vdslPhysSide OBJECT-TYPE SYNTAX VdslLineEntity MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies whether the modem is the Vtuc or Vtur." ::=3D { vdslPhysEntry 1 } vdslInvSerialNumber OBJECT-TYPE SYNTAX SnmpAdminString(SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific string that identifies the vendor equipment." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 2 } vdslInvVendorID OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor ID code is a copy of the binary vendor=20 identification field expressed as readable characters." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 3 } vdslInvVersionNumber OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The vendor specific version number sent by this Vtu as part of the initialization messages. It is a copy of the binary version number field expressed as=20 readable characters." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 4 } vdslCurrSnrMgn OBJECT-TYPE SYNTAX Integer32 (-127..127) UNITS "0.25dBm" MAX-ACCESS read-only STATUS current Expires December 1, 2003 [Page = 16] INTERNET-DRAFT VDSL-LINE MIB May = 2003 DESCRIPTION "Noise Margin as seen by this Vtu with respect to its received signal in 0.25dB. The effective range is -31.75..+31.75 dB." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 5 } vdslCurrAtn OBJECT-TYPE SYNTAX Gauge32 (0..255) UNITS "0.25dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured difference in the total power transmitted by=20 the peer Vtu and the total power received by this Vtu. The effective range is 0..+63.75 dB." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 6 } vdslCurrStatus OBJECT-TYPE SYNTAX BITS=20 { noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), lossOfSignalQuality(4), lossOfLink(5), dataInitFailure(6), configInitFailure(7), protocolInitFailure(8), noPeerVtuPresent(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state of the Vtu line. This is a bit-map of possible conditions. The various bit positions are: 0 noDefect There no defects on the line 1 lossOfFraming Vtu failure due to not receiving=20 a valid frame. 2 lossOfSignal Vtu failure due to not receiving=20 signal. 3 lossOfPower Vtu failure due to loss of power. 4 lossOfSignalQuality Loss of Signal Quality is declared when the Noise Margin falls below=20 the Minimum Noise Margin, or the=20 bit-error-rate exceeds 10^-7. Expires December 1, 2003 [Page = 17] INTERNET-DRAFT VDSL-LINE MIB May = 2003 5 lossOfLink Vtu failure due to inability to=20 link with peer Vtu. Set whenever the transceiver is in the "Warm=20 Start" state. 6 dataInitFailure Vtu failure during initialization=20 due to bit errors corrupting startup exchange data. 7 configInitFailure Vtu failure during initialization=20 due to peer Vtu not able to = support requested configuration. 8 protocolInitFailure Vtu failure during initialization=20 due to incompatible protocol used=20 by the peer Vtu. 9 noPeerVtuPresent Vtu failure during initialization=20 due to no activation sequence=20 detected from peer Vtu. This is intended to supplement ifOperStatus." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 7 } vdslCurrOutputPwr OBJECT-TYPE SYNTAX Integer32 (0..160) UNITS "0.1dBm" MAX-ACCESS read-only STATUS current DESCRIPTION "Measured total output power transmitted by this VTU. This is the measurement that was reported during the last activation sequence." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 8 } vdslCurrAttainableRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kbps" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the maximum currently attainable data rate in steps of 1000 bits/second by the Vtu. This value=20 will be equal to or greater than vdslCurrLineRate. Note that for SCM, the minimum and maximum data rates=20 are equal. Note: 1 kbps =3D 1000 bps." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 9 } vdslCurrLineRate OBJECT-TYPE SYNTAX Gauge32 Expires December 1, 2003 [Page = 18] INTERNET-DRAFT VDSL-LINE MIB May = 2003 UNITS "kbps" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current data rate in steps of 1000 bits/second by the Vtu. This value will be less than or equal to vdslCurrAttainableRate. Note: 1 kbps =3D=20 1000 bps." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPhysEntry 10 } vdslChanTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu channel. VDSL channel interfaces are those ifEntries where=20 ifType is equal to interleave(124) or fast(125)." ::=3D { vdslMibObjects 3 } vdslChanEntry OBJECT-TYPE SYNTAX VdslChanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION =20 "An entry in the vdslChanTable." INDEX { ifIndex,=20 vdslPhysSide } ::=3D { vdslChanTable 1 } VdslChanEntry ::=3D SEQUENCE=20 { vdslChanInterleaveDelay Gauge32, vdslChanCrcBlockLength Gauge32, vdslChanCurrTxRate Gauge32, vdslChanCurrTxSlowBurstProtection Gauge32, vdslChanCurrTxFastFecOverhead Gauge32 } vdslChanInterleaveDelay OBJECT-TYPE SYNTAX Gauge32 UNITS "ms" MAX-ACCESS read-only STATUS current DESCRIPTION "Interleave Delay for this channel. Interleave delay applies only to the interleave=20 (slow) channel and defines the mapping (relative=20 spacing) between subsequent input bytes at the=20 interleaver input and their placement in the bit=20 stream at the interleaver output. Larger numbers=20 Expires December 1, 2003 [Page = 19] INTERNET-DRAFT VDSL-LINE MIB May = 2003 provide greater separation between consecutive=20 input bytes in the output bit stream allowing for=20 improved impulse noise immunity at the expense of=20 payload latency. In the case where the ifType is fast(125), use noSuchObject." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanEntry 1 } vdslChanCrcBlockLength OBJECT-TYPE SYNTAX Gauge32 UNITS "bytes" MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the length of the channel data-block on which the CRC operates." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanEntry 2 } vdslChanCurrTxRate OBJECT-TYPE SYNTAX Gauge32 UNITS "kbps" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual transmit data rate on this channel. Note: 1 kbps =3D 1000 bps." ::=3D { vdslChanEntry 3 } vdslChanCurrTxSlowBurstProtection OBJECT-TYPE SYNTAX Gauge32 (0..1275) UNITS "microseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual level of impulse noise (burst) protection=20 for an interleaved (slow) channel. This parameter is=20 not applicable to fast channels. For fast channels,=20 a value of zero shall be returned." REFERENCE "ITU-T G.997.1" -- section 7.3.2.3 ::=3D { vdslChanEntry 4 } vdslChanCurrTxFastFecOverhead OBJECT-TYPE SYNTAX Gauge32 (0..50) UNITS "%" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Forward Error Correction (FEC) redundancy=20 related overhead for a fast channel. This parameter is not applicable to an interleaved (slow) channel. For interleaved channels, a value of zero shall be=20 Expires December 1, 2003 [Page = 20] INTERNET-DRAFT VDSL-LINE MIB May = 2003 returned." ::=3D { vdslChanEntry 5 } vdslPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each VDSL physical interface. VDSL physical interfaces are those ifEntries where ifType is equal to vdsl(97)." ::=3D { vdslMibObjects 4 } vdslPerfDataEntry OBJECT-TYPE SYNTAX VdslPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION =20 "An entry in the vdslPerfDataTable." INDEX { ifIndex,=20 vdslPhysSide } ::=3D { vdslPerfDataTable 1 } VdslPerfDataEntry ::=3D SEQUENCE=20 { vdslPerfValidIntervals HCPerfValidIntervals, vdslPerfInvalidIntervals HCPerfInvalidIntervals, vdslPerfLofs Counter64, vdslPerfLoss Counter64, vdslPerfLprs Counter64, vdslPerfLols Counter64, vdslPerfESs Counter64, vdslPerfSESs Counter64, vdslPerfUASs Counter64, vdslPerfInits Counter64, vdslPerfCurr15MinTimeElapsed HCPerfTimeElapsed, vdslPerfCurr15MinLofs HCPerfCurrentCount, vdslPerfCurr15MinLoss HCPerfCurrentCount, vdslPerfCurr15MinLprs HCPerfCurrentCount, vdslPerfCurr15MinLols HCPerfCurrentCount, vdslPerfCurr15MinESs HCPerfCurrentCount, vdslPerfCurr15MinSESs HCPerfCurrentCount, vdslPerfCurr15MinUASs HCPerfCurrentCount, vdslPerfCurr15MinInits HCPerfCurrentCount, vdslPerf1DayValidIntervals HCPerfValidIntervals, vdslPerf1DayInvalidIntervals HCPerfInvalidIntervals, vdslPerfCurr1DayTimeElapsed HCPerfTimeElapsed, vdslPerfCurr1DayLofs Counter64, vdslPerfCurr1DayLoss Counter64, vdslPerfCurr1DayLprs Counter64, vdslPerfCurr1DayLols Counter64, vdslPerfCurr1DayESs Counter64, vdslPerfCurr1DaySESs Counter64, Expires December 1, 2003 [Page = 21] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslPerfCurr1DayUASs Counter64, vdslPerfCurr1DayInits Counter64 } vdslPerfValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION "Valid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslPerfDataEntry 1 } vdslPerfInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION "Invalid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslPerfDataEntry 2 } vdslPerfLofs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there=20 was Loss of Framing." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 3 } vdslPerfLoss OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there=20 was Loss of Signal." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 4 } vdslPerfLprs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there=20 was Loss of Power." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 5 } Expires December 1, 2003 [Page = 22] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslPerfLols OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds since the unit was last reset that there=20 was Loss of Link." ::=3D { vdslPerfDataEntry 6 } vdslPerfESs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds since the unit was last reset. An Errored Second is a one-second interval containing one=20 or more crc anomalies, or one or more los or lof defects." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 7 } vdslPerfSESs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds since the unit was last reset." ::=3D { vdslPerfDataEntry 8 } vdslPerfUASs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds since the unit was last=20 reset." ::=3D { vdslPerfDataEntry 9 } vdslPerfInits OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts since the unit was last reset. This count includes both successful and=20 failed attempts." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 10 } Expires December 1, 2003 [Page = 23] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslPerfCurr15MinTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Total elapsed seconds in this interval." ::=3D { vdslPerfDataEntry 11 } vdslPerfCurr15MinLofs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there=20 was Loss of Framing." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 12 } vdslPerfCurr15MinLoss OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there=20 was Loss of Signal." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 13 } vdslPerfCurr15MinLprs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there=20 was Loss of Power." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 14 } vdslPerfCurr15MinLols OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds during this interval that there=20 was Loss of Link." ::=3D { vdslPerfDataEntry 15 } vdslPerfCurr15MinESs OBJECT-TYPE SYNTAX HCPerfCurrentCount Expires December 1, 2003 [Page = 24] INTERNET-DRAFT VDSL-LINE MIB May = 2003 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds during this interval. An Errored = Second is a one-second interval containing one or more crc=20 anomalies, or one or more los or lof defects." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 16 } vdslPerfCurr15MinSESs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds during this interval." ::=3D { vdslPerfDataEntry 17 } vdslPerfCurr15MinUASs OBJECT-TYPE SYNTAX HCPerfCurrentCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds during this interval." ::=3D { vdslPerfDataEntry 18 } vdslPerfCurr15MinInits OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts during this interval. This count includes both successful and=20 failed attempts." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfDataEntry 19 } vdslPerf1DayValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Valid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslPerfDataEntry 20 } vdslPerf1DayInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Invalid Intervals per definition found in=20 Expires December 1, 2003 [Page = 25] INTERNET-DRAFT VDSL-LINE MIB May = 2003 HC-PerfHist-TC-MIB." ::=3D { vdslPerfDataEntry 21 } vdslPerfCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 22 } vdslPerfCurr1DayLofs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Framing (LOF) Seconds since the=20 beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 23 } vdslPerfCurr1DayLoss OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Signal (LOS) Seconds since the beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 24 } vdslPerfCurr1DayLprs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Power (LPR) Seconds since the beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 25 } vdslPerfCurr1DayLols OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Link (LOL) Seconds since the beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 26 } vdslPerfCurr1DayESs OBJECT-TYPE Expires December 1, 2003 [Page = 26] INTERNET-DRAFT VDSL-LINE MIB May = 2003 SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) since the beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 27 } vdslPerfCurr1DaySESs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) since the=20 beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 28 } vdslPerfCurr1DayUASs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) since the beginning of the current 1-day interval." ::=3D { vdslPerfDataEntry 29 } vdslPerfCurr1DayInits OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts since the=20 beginning of the current 1-day interval. This count includes both successful and failed attempts." =20 ::=3D { vdslPerfDataEntry 30 } vdslPerfIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslPerfIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu performance=20 data collection interval. VDSL physical interfaces are those ifEntries where ifType is equal to vdsl(97)." ::=3D { vdslMibObjects 5 } vdslPerfIntervalEntry OBJECT-TYPE SYNTAX VdslPerfIntervalEntry MAX-ACCESS not-accessible STATUS current Expires December 1, 2003 [Page = 27] INTERNET-DRAFT VDSL-LINE MIB May = 2003 DESCRIPTION =20 "An entry in the vdslPerfIntervalTable." INDEX { ifIndex,=20 vdslPhysSide,=20 vdslIntervalNumber } ::=3D { vdslPerfIntervalTable 1 } VdslPerfIntervalEntry ::=3D SEQUENCE=20 { vdslIntervalNumber Unsigned32, vdslIntervalLofs HCPerfIntervalCount, vdslIntervalLoss HCPerfIntervalCount, vdslIntervalLprs HCPerfIntervalCount, vdslIntervalLols HCPerfIntervalCount, vdslIntervalESs HCPerfIntervalCount, vdslIntervalSESs HCPerfIntervalCount, vdslIntervalUASs HCPerfIntervalCount, vdslIntervalInits HCPerfIntervalCount } vdslIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the most=20 recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::=3D { vdslPerfIntervalEntry 1 } vdslIntervalLofs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Framing." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfIntervalEntry 2 } vdslIntervalLoss OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Signal." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfIntervalEntry 3 } vdslIntervalLprs OBJECT-TYPE Expires December 1, 2003 [Page = 28] INTERNET-DRAFT VDSL-LINE MIB May = 2003 SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Power." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfIntervalEntry 4 } vdslIntervalLols OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of seconds in the interval when there was Loss of Link." ::=3D { vdslPerfIntervalEntry 5 } vdslIntervalESs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) in the interval. An Errored = Second is a one-second interval containing one or more crc=20 anomalies, one or more los or lof defects." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfIntervalEntry 6 } vdslIntervalSESs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds in the interval." ::=3D { vdslPerfIntervalEntry 7 } vdslIntervalUASs OBJECT-TYPE SYNTAX HCPerfIntervalCount UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds in the interval." ::=3D { vdslPerfIntervalEntry 8 } vdslIntervalInits OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current Expires December 1, 2003 [Page = 29] INTERNET-DRAFT VDSL-LINE MIB May = 2003 DESCRIPTION "Count of the line initialization attempts during this interval. This count includes both successful and=20 failed attempts." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslPerfIntervalEntry 9 } vdsl1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF Vdsl1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each VDSL performance=20 data collection interval. This table contains live data=20 from equipment. As such, it is NOT persistent." ::=3D { vdslMibObjects 6 } vdsl1DayIntervalEntry OBJECT-TYPE SYNTAX Vdsl1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdsl1DayIntervalTable." INDEX { ifIndex,=20 vdslPhysSide,=20 vdsl1DayIntervalNumber } ::=3D { vdsl1DayIntervalTable 1 } Vdsl1DayIntervalEntry ::=3D SEQUENCE { vdsl1DayIntervalNumber Unsigned32, vdsl1DayIntervalMoniSecs HCPerfTimeElapsed, vdsl1DayIntervalLofs Counter64, vdsl1DayIntervalLoss Counter64, vdsl1DayIntervalLprs Counter64, vdsl1DayIntervalLols Counter64, vdsl1DayIntervalESs Counter64, vdsl1DayIntervalSESs Counter64, vdsl1DayIntervalUASs Counter64, vdsl1DayIntervalInits Counter64 } vdsl1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the most recent previous day; interval 30 is 30 days ago. Intervals 2..30 are optional." ::=3D { vdsl1DayIntervalEntry 1 } vdsl1DayIntervalMoniSecs OBJECT-TYPE Expires December 1, 2003 [Page = 30] INTERNET-DRAFT VDSL-LINE MIB May = 2003 SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::=3D { vdsl1DayIntervalEntry 2 } vdsl1DayIntervalLofs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Frame (LOF) Seconds during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdsl1DayIntervalEntry 3 } vdsl1DayIntervalLoss OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Signal (LOS) Seconds during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdsl1DayIntervalEntry 4 } vdsl1DayIntervalLprs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Power (LPR) Seconds during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdsl1DayIntervalEntry 5 } vdsl1DayIntervalLols OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Loss of Link (LOL) Seconds during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." ::=3D { vdsl1DayIntervalEntry 6 } Expires December 1, 2003 [Page = 31] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdsl1DayIntervalESs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Errored Seconds (ES) during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdsl1DayIntervalEntry 7 } vdsl1DayIntervalSESs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Severely Errored Seconds (SES) during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." ::=3D { vdsl1DayIntervalEntry 8 } vdsl1DayIntervalUASs OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of Unavailable Seconds (UAS) during the 1-day=20 interval as measured by vdsl1DayIntervalMoniSecs." ::=3D { vdsl1DayIntervalEntry 9 } vdsl1DayIntervalInits OBJECT-TYPE SYNTAX Counter64 UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Count of the line initialization attempts during the 1-day interval as measured by vdsl1DayIntervalMoniSecs. This count includes both successful and failed attempts." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdsl1DayIntervalEntry 10 } vdslChanPerfDataTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu channel. VDSL channel interfaces are those ifEntries where=20 ifType is equal to interleave(124) or fast(125)." ::=3D { vdslMibObjects 7 } Expires December 1, 2003 [Page = 32] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslChanPerfDataEntry OBJECT-TYPE SYNTAX VdslChanPerfDataEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION =20 "An entry in the vdslChanPerfDataTable." INDEX { ifIndex,=20 vdslPhysSide } ::=3D { vdslChanPerfDataTable 1 } VdslChanPerfDataEntry ::=3D SEQUENCE=20 { vdslChanPerfValidIntervals HCPerfValidIntervals, vdslChanPerfInvalidIntervals = HCPerfInvalidIntervals, vdslChanCorrectedOctets Counter64, vdslChanUncorrectableBlks Counter64, vdslChanPerfCurr15MinTimeElapsed HCPerfTimeElapsed, vdslChanPerfCurr15MinCorrectedOctets HCPerfCurrentCount, vdslChanPerfCurr15MinUncorrectableBlks HCPerfCurrentCount, vdslChanPerf1DayValidIntervals = HCPerfValidIntervals, vdslChanPerf1DayInvalidIntervals = HCPerfInvalidIntervals, vdslChanPerfCurr1DayTimeElapsed HCPerfTimeElapsed, vdslChanPerfCurr1DayCorrectedOctets HCPerfCurrentCount, vdslChanPerfCurr1DayUncorrectableBlks HCPerfCurrentCount } vdslChanPerfValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Valid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslChanPerfDataEntry 1 } vdslChanPerfInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Invalid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslChanPerfDataEntry 2 } vdslChanCorrectedOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of corrected octets since the unit was last reset." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanPerfDataEntry 3 } Expires December 1, 2003 [Page = 33] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslChanUncorrectableBlks OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of uncorrectable blocks since the unit was last=20 reset." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanPerfDataEntry 4 } vdslChanPerfCurr15MinTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Total elapsed seconds in this interval." ::=3D { vdslChanPerfDataEntry 5 } vdslChanPerfCurr15MinCorrectedOctets OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of corrected octets in this interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanPerfDataEntry 6 } vdslChanPerfCurr15MinUncorrectableBlks OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of uncorrectable blocks in this interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanPerfDataEntry 7 } vdslChanPerf1DayValidIntervals OBJECT-TYPE SYNTAX HCPerfValidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Valid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslChanPerfDataEntry 8 } vdslChanPerf1DayInvalidIntervals OBJECT-TYPE SYNTAX HCPerfInvalidIntervals MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Invalid Intervals per definition found in=20 HC-PerfHist-TC-MIB." ::=3D { vdslChanPerfDataEntry 9 } Expires December 1, 2003 [Page = 34] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslChanPerfCurr1DayTimeElapsed OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of seconds that have elapsed since the beginning of the current 1-day interval." ::=3D { vdslChanPerfDataEntry 10 } vdslChanPerfCurr1DayCorrectedOctets OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of corrected octets since the beginning of the current 1-day interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanPerfDataEntry 11 } vdslChanPerfCurr1DayUncorrectableBlks OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of uncorrectable blocks since the beginning of the current 1-day interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanPerfDataEntry 12 } vdslChanIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each Vtu channel data=20 collection interval. VDSL channel interfaces are those=20 ifEntries where ifType is equal to interleave(124) or=20 fast(125)." ::=3D { vdslMibObjects 8 } vdslChanIntervalEntry OBJECT-TYPE SYNTAX VdslChanIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION =20 "An entry in the vdslChanIntervalTable." INDEX { ifIndex,=20 vdslPhysSide,=20 vdslChanIntervalNumber } ::=3D { vdslChanIntervalTable 1 } VdslChanIntervalEntry ::=3D Expires December 1, 2003 [Page = 35] INTERNET-DRAFT VDSL-LINE MIB May = 2003 SEQUENCE=20 { vdslChanIntervalNumber Unsigned32, vdslChanIntervalCorrectedOctets HCPerfIntervalCount, vdslChanIntervalUncorrectableBlks HCPerfIntervalCount } vdslChanIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (0..96) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Performance Data Interval number 1 is the most=20 recent previous interval; interval 96 is 24 hours ago. Intervals 2..96 are optional." ::=3D { vdslChanIntervalEntry 1 } vdslChanIntervalCorrectedOctets OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of corrected octets in this interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanIntervalEntry 2 } vdslChanIntervalUncorrectableBlks OBJECT-TYPE SYNTAX HCPerfIntervalCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of uncorrectable blocks in this interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChanIntervalEntry 3 } vdslChan1DayIntervalTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslChan1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides one row for each VDSL performance=20 data collection interval. This table contains live data=20 from equipment. As such, it is NOT persistent." ::=3D { vdslMibObjects 9 } vdslChan1DayIntervalEntry OBJECT-TYPE SYNTAX VdslChan1DayIntervalEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the vdslChan1DayIntervalTable." INDEX { ifIndex,=20 vdslPhysSide,=20 vdslChan1DayIntervalNumber } Expires December 1, 2003 [Page = 36] INTERNET-DRAFT VDSL-LINE MIB May = 2003 ::=3D { vdslChan1DayIntervalTable 1 } VdslChan1DayIntervalEntry ::=3D SEQUENCE { vdslChan1DayIntervalNumber Unsigned32, vdslChan1DayIntervalMoniSecs HCPerfTimeElapsed, vdslChan1DayIntervalCorrectedOctets HCPerfCurrentCount, vdslChan1DayIntervalUncorrectableBlks HCPerfCurrentCount } vdslChan1DayIntervalNumber OBJECT-TYPE SYNTAX Unsigned32 (1..30) MAX-ACCESS not-accessible STATUS current DESCRIPTION "History Data Interval number. Interval 1 is the most recent previous day; interval 30 is 30 days ago. Intervals 2..30 are optional." ::=3D { vdslChan1DayIntervalEntry 1 } vdslChan1DayIntervalMoniSecs OBJECT-TYPE SYNTAX HCPerfTimeElapsed UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of time in the 1-day interval over which the performance monitoring information is actually counted. This value will be the same as the interval duration except in a situation where performance monitoring data could not be collected for any reason." ::=3D { vdslChan1DayIntervalEntry 2 } vdslChan1DayIntervalCorrectedOctets OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of corrected octets in this interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChan1DayIntervalEntry 3 } vdslChan1DayIntervalUncorrectableBlks OBJECT-TYPE SYNTAX HCPerfCurrentCount MAX-ACCESS read-only STATUS current DESCRIPTION =20 "Count of uncorrectable blocks in this interval." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslChan1DayIntervalEntry 4 } -- -- profile tables Expires December 1, 2003 [Page = 37] INTERNET-DRAFT VDSL-LINE MIB May = 2003 -- vdslLineConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the VDSL line configuration. One entry in this table reflects a profile defined by a manager which can be used to configure the VDSL line." ::=3D { vdslMibObjects 11 } vdslLineConfProfileEntry OBJECT-TYPE SYNTAX VdslLineConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of a VDSL line. A default profile with an index of `DEFVAL', will=20 always exist and its parameters will be set to vendor=20 specific values, unless otherwise specified in this=20 document." INDEX { vdslLineConfProfileName } ::=3D { vdslLineConfProfileTable 1 } VdslLineConfProfileEntry ::=3D SEQUENCE=20 { vdslLineConfProfileName SnmpAdminString, vdslLineConfDownstreamRateMode INTEGER, vdslLineConfUpstreamRateMode INTEGER, vdslLineConfDownstreamMaxPwr Unsigned32, vdslLineConfUpstreamMaxPwr Unsigned32, vdslLineConfDownstreamMaxSnrMgn Unsigned32, vdslLineConfDownstreamMinSnrMgn Unsigned32, vdslLineConfDownstreamTargetSnrMgn Unsigned32, vdslLineConfUpstreamMaxSnrMgn Unsigned32, vdslLineConfUpstreamMinSnrMgn Unsigned32, vdslLineConfUpstreamTargetSnrMgn Unsigned32, vdslLineConfDownstreamFastMaxDataRate Unsigned32, vdslLineConfDownstreamFastMinDataRate Unsigned32, vdslLineConfDownstreamSlowMaxDataRate Unsigned32, vdslLineConfDownstreamSlowMinDataRate Unsigned32, vdslLineConfUpstreamFastMaxDataRate Unsigned32, vdslLineConfUpstreamFastMinDataRate Unsigned32, vdslLineConfUpstreamSlowMaxDataRate Unsigned32, vdslLineConfUpstreamSlowMinDataRate Unsigned32, vdslLineConfDownstreamRateRatio Unsigned32, vdslLineConfUpstreamRateRatio Unsigned32, vdslLineConfDownstreamMaxInterDelay Unsigned32, vdslLineConfUpstreamMaxInterDelay Unsigned32, Expires December 1, 2003 [Page = 38] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslLineConfDownstreamPboControl INTEGER, vdslLineConfUpstreamPboControl INTEGER, vdslLineConfDownstreamPboLevel Unsigned32, vdslLineConfUpstreamPboLevel Unsigned32, vdslLineConfDeploymentScenario INTEGER, vdslLineConfAdslPresence INTEGER, vdslLineConfApplicableStandard INTEGER, vdslLineConfBandPlan INTEGER, vdslLineConfBandPlanFx Unsigned32, vdslLineConfBandOptUsage INTEGER, vdslLineConfUpstreamPsdTemplate INTEGER, vdslLineConfDownstreamPsdTemplate INTEGER, vdslLineConfHamBandMask BITS, vdslLineConfCustomNotch1Start Unsigned32, vdslLineConfCustomNotch1Stop Unsigned32, vdslLineConfCustomNotch2Start Unsigned32, vdslLineConfCustomNotch2Stop Unsigned32, vdslLineConfDownstreamTargetSlowBurstProtection Unsigned32, vdslLineConfUpstreamTargetSlowBurstProtection Unsigned32, vdslLineConfDownstreamMaxFastFecOverhead Unsigned32, vdslLineConfUpstreamMaxFastFecOverhead Unsigned32, vdslLineConfLineType INTEGER, vdslLineConfProfileRowStatus RowStatus } vdslLineConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible=20 STATUS current DESCRIPTION "This object identifies a row in this table. A default profile with an index of `DEFVAL', will=20 always exist and its parameters will be set to vendor=20 specific values, unless otherwise specified in this=20 document." ::=3D { vdslLineConfProfileEntry 1 } vdslLineConfDownstreamRateMode OBJECT-TYPE SYNTAX INTEGER=20 { manual(1), adaptAtInit(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the rate selection behaviour for the line in the downstream direction." ::=3D { vdslLineConfProfileEntry 2 } Expires December 1, 2003 [Page = 39] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslLineConfUpstreamRateMode OBJECT-TYPE SYNTAX INTEGER=20 { manual(1), adaptAtInit(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the rate selection behaviour for the line in the upstream direction." ::=3D { vdslLineConfProfileEntry 3 } vdslLineConfDownstreamMaxPwr OBJECT-TYPE SYNTAX Unsigned32 (0..58) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum aggregate downstream power level in the range 0..14.5 dBm." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 4 } vdslLineConfUpstreamMaxPwr OBJECT-TYPE SYNTAX Unsigned32 (0..58) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum aggregate upstream power level in the range 0..14.5 dBm." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 5 } vdslLineConfDownstreamMaxSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum downstream Signal/Noise Margin in units of 0.25 dB, for a range of 0..31.75 dB." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 6 } vdslLineConfDownstreamMinSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum downstream Signal/Noise Margin in units of 0.25 dB, for a range of 0..31.75 dB." Expires December 1, 2003 [Page = 40] INTERNET-DRAFT VDSL-LINE MIB May = 2003 REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 7 } vdslLineConfDownstreamTargetSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target downstream Signal/Noise Margin in units of 0.25 dB, for a range of 0..31.75 dB. This is the Noise Margin the modems must achieve with a BER of 10-7 or better to successfully complete=20 initialization." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 8 } vdslLineConfUpstreamMaxSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum upstream Signal/Noise Margin in units of 0.25 dB, for a range of 0..31.75 dB." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 9 } vdslLineConfUpstreamMinSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum upstream Signal/Noise Margin in units of 0.25 dB, for a range of 0..31.75 dB." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 10 } vdslLineConfUpstreamTargetSnrMgn OBJECT-TYPE SYNTAX Unsigned32 (0..127) UNITS "0.25dBm" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target upstream Signal/Noise Margin in=20 units of 0.25 dB, for a range of 0..31.75 dB. This=20 is the Noise Margin the modems must achieve with a BER of=20 10-7 or better to successfully complete initialization." REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec ::=3D { vdslLineConfProfileEntry 11 } vdslLineConfDownstreamFastMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 Expires December 1, 2003 [Page = 41] INTERNET-DRAFT VDSL-LINE MIB May = 2003 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum downstream fast channel data rate in steps of 1000 bits/second." ::=3D { vdslLineConfProfileEntry 12 } vdslLineConfDownstreamFastMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum downstream fast channel data rate in steps of 1000 bits/second." ::=3D { vdslLineConfProfileEntry 13 } vdslLineConfDownstreamSlowMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum downstream slow channel data rate in steps of 1000 bits/second. The maximum aggregate downstream transmit speed of the line can be derived from the sum of maximum downstream fast and slow channel data rates." ::=3D { vdslLineConfProfileEntry 14 } vdslLineConfDownstreamSlowMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum downstream slow channel data rate in steps of 1000 bits/second. The minimum aggregate downstream transmit speed of the line can be derived from the sum of minimum downstream fast and slow channel data rates." ::=3D { vdslLineConfProfileEntry 15 } vdslLineConfUpstreamFastMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum upstream fast channel data rate in steps of 1000 bits/second." ::=3D { vdslLineConfProfileEntry 16 } vdslLineConfUpstreamFastMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION Expires December 1, 2003 [Page = 42] INTERNET-DRAFT VDSL-LINE MIB May = 2003 "Specifies the minimum upstream fast channel data rate in steps of 1000 bits/second." ::=3D { vdslLineConfProfileEntry 17 } vdslLineConfUpstreamSlowMaxDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum upstream slow channel data rate in steps of 1000 bits/second. The maximum aggregate upstream transmit speed of the line can be derived from the sum of maximum upstream fast and slow channel data rates." ::=3D { vdslLineConfProfileEntry 18 } vdslLineConfUpstreamSlowMinDataRate OBJECT-TYPE SYNTAX Unsigned32 UNITS "kbps" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the minimum upstream slow channel data rate in steps of 1000 bits/second. The minimum aggregate upstream transmit speed of the line can be derived from the sum of minimum upstream fast and slow channel data rates." ::=3D { vdslLineConfProfileEntry 19 } vdslLineConfDownstreamRateRatio OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "For dynamic rate adaptation at startup, the allocation of data rate in excess of the minimum data rate for each channel is controlled by the object. This object specifies the ratio of the allocation of the excess data rate between the fast and the slow channels. This allocation represents downstream Fast Channel Allocation / Slow Channel=20 Allocation." ::=3D { vdslLineConfProfileEntry 20 } vdslLineConfUpstreamRateRatio OBJECT-TYPE SYNTAX Unsigned32 (0..100) UNITS "percent" MAX-ACCESS read-create STATUS current DESCRIPTION "For dynamic rate adaptation at startup, the allocation of data rate in excess of the minimum data rate for each channel is controlled by the object. This object specifies the ratio of the allocation of the excess data rate between the fast and the slow channels. This allocation represents upstream Fast Channel Allocation / Slow Channel = Allocation." ::=3D { vdslLineConfProfileEntry 21 } vdslLineConfDownstreamMaxInterDelay OBJECT-TYPE Expires December 1, 2003 [Page = 43] INTERNET-DRAFT VDSL-LINE MIB May = 2003 SYNTAX Unsigned32 (0..255) UNITS "ms" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum interleave delay for the downstream slow channel." ::=3D { vdslLineConfProfileEntry 22 } vdslLineConfUpstreamMaxInterDelay OBJECT-TYPE SYNTAX Unsigned32 (0..255) UNITS "ms" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the maximum interleave delay for the upstream slow channel." ::=3D { vdslLineConfProfileEntry 23 } vdslLineConfDownstreamPboControl OBJECT-TYPE SYNTAX INTEGER=20 { disabled(1), auto(2), manual(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Downstream power backoff (PBO) control for this=20 line. For modems which do not support downstream=20 PBO control, this object MUST be fixed at disabled(1)." ::=3D { vdslLineConfProfileEntry 24 } vdslLineConfUpstreamPboControl OBJECT-TYPE SYNTAX INTEGER=20 { disabled(1), auto(2), manual(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Upstream power backoff (PBO) control for this=20 line. For modems which do not support upstream=20 PBO control, this object MUST be fixed at disabled(1)." ::=3D { vdslLineConfProfileEntry 25 } vdslLineConfDownstreamPboLevel OBJECT-TYPE SYNTAX Unsigned32 (0..160) UNITS "0.25dB" MAX-ACCESS read-create STATUS current Expires December 1, 2003 [Page = 44] INTERNET-DRAFT VDSL-LINE MIB May = 2003 DESCRIPTION "Specifies the downstream backoff level to be used when vdslLineConfDownstreamPboControl =3D manual(3)." ::=3D { vdslLineConfProfileEntry 26 } vdslLineConfUpstreamPboLevel OBJECT-TYPE SYNTAX Unsigned32 (0..160) UNITS "0.25dB" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the upstream backoff level to be used when vdslLineConfUpstreamPboControl =3D manual(3)." ::=3D { vdslLineConfProfileEntry 27 } vdslLineConfDeploymentScenario OBJECT-TYPE SYNTAX INTEGER=20 { fttCab(1), fttEx(2), other(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The VDSL line deployment scenario. When using fttCab(1), the VTU-C is located in a street cabinet. When using fttEx(2), the VTU-C is located at the central office." ::=3D { vdslLineConfProfileEntry 28 } vdslLineConfAdslPresence OBJECT-TYPE SYNTAX INTEGER { none(1), adslOverPots(2), adslOverISDN(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates presence of ADSL service in the associated=20 cable bundle/binder." ::=3D { vdslLineConfProfileEntry 29 } vdslLineConfApplicableStandard OBJECT-TYPE SYNTAX INTEGER=20 { ansi(1), etsi(2), itu(3), other(4) } MAX-ACCESS read-create Expires December 1, 2003 [Page = 45] INTERNET-DRAFT VDSL-LINE MIB May = 2003 STATUS current DESCRIPTION "The VDSL standard to be used for the line." ::=3D { vdslLineConfProfileEntry 30 } vdslLineConfBandPlan OBJECT-TYPE SYNTAX INTEGER=20 { bandPlan997(1), bandPlan998(2), bandPlanFx(3), other(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The VDSL band plan to be used for the line. =20 bandPlan997(1) is to be used for=20 ITU-T G.993.1 Bandplan-B ETSI Bandplan ANSI Plan 997 bandPlan998(2) is to be used for ITU-T G.993.1 Bandplan-A ANSI Plan 998 bandPlanFx(3) is to be used for ITU-T G.993.1 Bandplan-C. other(4) is to be used for=20 non-standard bandplans. =20 If this object is set to bandPlanFx(3), then the object vdslLineConfBandPlanFx MUST also be set." ::=3D { vdslLineConfProfileEntry 31 } vdslLineConfBandPlanFx OBJECT-TYPE SYNTAX Unsigned32 (3750..12000) UNITS "kHz" MAX-ACCESS read-create STATUS current DESCRIPTION "The frequency limit between bands D2 and U2 when vdslLineConfBandPlan is set to bandPlanFx(3)." ::=3D { vdslLineConfProfileEntry 32 } vdslLineConfBandOptUsage OBJECT-TYPE SYNTAX INTEGER=20 { unused(1), upstream(2), downstream(3) Expires December 1, 2003 [Page = 46] INTERNET-DRAFT VDSL-LINE MIB May = 2003 } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the VDSL link use of the optional frequency range=20 25..138 kHz (Opt)." REFERENCE "ITU-T G.993.1" -- section 6.1 ::=3D { vdslLineConfProfileEntry 33 } vdslLineConfUpstreamPsdTemplate OBJECT-TYPE SYNTAX INTEGER=20 { templateMask1(1), templateMask2(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The upstream PSD template to be used for the line. It depends on vdslLineConfApplicableStandard." REFERENCE "DSLF TR-057" -- section 2.4 ::=3D { vdslLineConfProfileEntry 34 } vdslLineConfDownstreamPsdTemplate OBJECT-TYPE SYNTAX INTEGER=20 { templateMask1(1), templateMask2(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The downstream PSD template to be used for the line. It depends on vdslLineConfApplicableStandard." REFERENCE "DSLF TR-057" -- section 2.4 ::=3D { vdslLineConfProfileEntry 35 } vdslLineConfHamBandMask OBJECT-TYPE SYNTAX BITS { customNotch1(0), -- custom (region-specific) notch customNotch2(1), -- custom (region-specific) notch amateurBand30m(2), -- amateur radio band notch amateurBand40m(3), -- amateur radio band notch amateurBand80m(4), -- amateur radio band notch amateurBand160m(5) -- amateur radio band notch } MAX-ACCESS read-create STATUS current DESCRIPTION "The transmit power spectral density mask code to avoid=20 interference with HAM radio bands by introducing power=20 control (notching) in one or more of these bands. =20 Amateur radio band notching is defined in the VDSL spectrum ([25..]138 kHz .. 12 MHz according to G.993.1) as follows: Band Start Frequency Stop Frequency ---- ------------------ -------------------------------- 30m 1810 kHz 2000 kHz 40m 3500 kHz 3800 kHz (ETSI); 4000 kHz (ANSI) Expires December 1, 2003 [Page = 47] INTERNET-DRAFT VDSL-LINE MIB May = 2003 80m 7000 kHz 7100 kHz (ETSI); 7300 kHz (ANSI) 160m 10100 kHz 10150 kHz ANSI T1.424-1 [T1E1311] and ETSI TS 101 270-1 [ETSI2701]=20 extend the VDSL spectrum up to 30 MHz and therefore define=20 additional five HAM bands (see normative Annex 1 of = T1.424-1 and Section 9.3.3.6.1 of TS 101 270-1), not considered = here. Notching for each standard band can be enabled or disabled via the bit mask. Two custom notches may be specified. If either of these=20 are enabled via the bit mask, then the following objects=20 MUST be specified: If customNotch1 is enabled, then both=20 vdslLineConfCustomNotch1Start vdslLineConfCustomNotch1Stop MUST be specified. If customNotch2 is enabled, then both=20 vdslLineConfCustomNotch2Start vdslLineConfCustomNotch2Stop MUST be specified." REFERENCE "DSLF TR-057" -- section 2.6 ::=3D { vdslLineConfProfileEntry 36 } =20 vdslLineConfCustomNotch1Start OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the start frequency of custom HAM notch 1." ::=3D { vdslLineConfProfileEntry 37 } vdslLineConfCustomNotch1Stop OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the stop frequency of custom HAM notch 1." ::=3D { vdslLineConfProfileEntry 38 } vdslLineConfCustomNotch2Start OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "Hz" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the start frequency of custom HAM notch 2." ::=3D { vdslLineConfProfileEntry 39 } vdslLineConfCustomNotch2Stop OBJECT-TYPE SYNTAX Unsigned32=20 UNITS "Hz" MAX-ACCESS read-create STATUS current DESCRIPTION Expires December 1, 2003 [Page = 48] INTERNET-DRAFT VDSL-LINE MIB May = 2003 "Specifies the stop frequency of custom HAM notch 2." ::=3D { vdslLineConfProfileEntry 40 } vdslLineConfDownstreamTargetSlowBurstProtection OBJECT-TYPE SYNTAX Unsigned32 (0..1275) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target level of impulse noise (burst)=20 protection for an interleaved (slow) channel." REFERENCE "ITU-T G.997.1" -- section 7.3.2.3 ::=3D { vdslLineConfProfileEntry 41 } vdslLineConfUpstreamTargetSlowBurstProtection OBJECT-TYPE SYNTAX Unsigned32 (0..1275) UNITS "microseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the target level of impulse noise (burst)=20 protection for an interleaved (slow) channel." REFERENCE "ITU-T G.997.1" -- section 7.3.2.3 ::=3D { vdslLineConfProfileEntry 42 } vdslLineConfDownstreamMaxFastFecOverhead OBJECT-TYPE SYNTAX Unsigned32 (0..50) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the maximum level of Forward Error Correction (FEC) redundancy related overhead to be maintained for a fast channel." ::=3D { vdslLineConfProfileEntry 43 } vdslLineConfUpstreamMaxFastFecOverhead OBJECT-TYPE SYNTAX Unsigned32 (0..50) UNITS "%" MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the maximum level of Forward Error Correction (FEC) redundancy related overhead to be maintained for a fast channel." ::=3D { vdslLineConfProfileEntry 44 } vdslLineConfLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- fast channel exists only interleavedOnly(3), -- interleaved channel exists only fastOrInterleaved(4), -- either fast or interleaved -- channels can exist, but -- only one at any time fastAndInterleaved(5) -- both fast and interleaved -- channels exist } MAX-ACCESS read-create STATUS current DESCRIPTION "This parameter provisions the type of VDSL physical line entity that shall exist, by defining whether and how the line shall be channellized. If the line is to be channellized, the value will be other than noChannel(1). =20 This object defines which channel type(s) are supported." ::=3D { vdslLineConfProfileEntry 45 } vdslLineConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. Expires December 1, 2003 [Page = 49] INTERNET-DRAFT VDSL-LINE MIB May = 2003 A profile activated by setting this object to `active'. =20 When `active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service, (by setting this object to `destroy' or `outOfService') it must be first unreferenced from all associated lines." ::=3D { vdslLineConfProfileEntry 46 } -- -- Alarm configuration profile table --=20 vdslLineAlarmConfProfileTable OBJECT-TYPE SYNTAX SEQUENCE OF VdslLineAlarmConfProfileEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the VDSL line alarm configuration. One entry in this table reflects a profile defined by a manager which can be used to configure the=20 VDSL line alarm thresholds." ::=3D { vdslMibObjects 20 } vdslLineAlarmConfProfileEntry OBJECT-TYPE SYNTAX VdslLineAlarmConfProfileEntry=20 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry consists of a list of parameters that represents the configuration of a VDSL line alarm profile. A default profile with an index of `DEFVAL', will=20 always exist and its parameters will be set to vendor=20 specific values, unless otherwise specified in this=20 document." INDEX { vdslLineAlarmConfProfileName } ::=3D { vdslLineAlarmConfProfileTable 1 } VdslLineAlarmConfProfileEntry ::=3D SEQUENCE=20 { vdslLineAlarmConfProfileName SnmpAdminString, vdslThresh15MinLofs HCPerfIntervalThreshold, vdslThresh15MinLoss HCPerfIntervalThreshold, vdslThresh15MinLprs HCPerfIntervalThreshold, vdslThresh15MinLols HCPerfIntervalThreshold, vdslThresh15MinESs HCPerfIntervalThreshold, vdslThresh15MinSESs HCPerfIntervalThreshold, vdslThresh15MinUASs HCPerfIntervalThreshold, vdslInitFailureNotificationEnable TruthValue, vdslLineAlarmConfProfileRowStatus RowStatus Expires December 1, 2003 [Page = 50] INTERNET-DRAFT VDSL-LINE MIB May = 2003 } vdslLineAlarmConfProfileName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name for this profile as specified by a user." ::=3D { vdslLineAlarmConfProfileEntry 1 } vdslThresh15MinLofs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of frame seconds (lofs) within any given 15-minute performance data collection interval. If the value of=20 loss of frame seconds in a particular 15-minute collection = interval reaches/exceeds this value, a=20 vdslPerfLofsThreshNotification notification will be=20 generated. No more than one notification will be sent=20 per interval." ::=3D { vdslLineAlarmConfProfileEntry 2 } vdslThresh15MinLoss OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of signal seconds (loss) within any given 15-minute performance data collection interval. If the value of=20 loss of signal seconds in a particular 15-minute = collection interval reaches/exceeds this value, a=20 vdslPerfLossThreshNotification notification will be=20 generated. One notification will be sent per interval per endpoint." ::=3D { vdslLineAlarmConfProfileEntry 3 } vdslThresh15MinLprs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of power seconds (lprs) within any given 15-minute performance data collection interval. If the value of=20 loss of power seconds in a particular 15-minute collection = interval reaches/exceeds this value, a=20 vdslPerfLprsThreshNotification notification will be=20 Expires December 1, 2003 [Page = 51] INTERNET-DRAFT VDSL-LINE MIB May = 2003 generated. No more than one notification will be sent=20 per interval." ::=3D { vdslLineAlarmConfProfileEntry 4 } vdslThresh15MinLols OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of loss of link seconds (lols) within any given 15-minute performance data collection interval. If the value of=20 loss of power seconds in a particular 15-minute collection = interval reaches/exceeds this value, a=20 vdslPerfLolsThreshNotification notification will be=20 generated. No more than one notification will be sent=20 per interval." ::=3D { vdslLineAlarmConfProfileEntry 5 } vdslThresh15MinESs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of errored seconds (ESs) within any given 15-minute performance data collection interval. If the value of=20 errored seconds in a particular 15-minute collection=20 interval reaches/exceeds this value, a=20 vdslPerfESsThreshNotification notification will be=20 generated. No more than one notification will be sent=20 per interval." ::=3D { vdslLineAlarmConfProfileEntry 6 } vdslThresh15MinSESs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of severely errored seconds (SESs) within any given 15-minute performance data collection interval. If the value of=20 severely errored seconds in a particular 15-minute=20 collection interval reaches/exceeds this value, a=20 vdslPerfSESsThreshNotification notification will be=20 generated. No more than one notification will be sent=20 per interval." ::=3D { vdslLineAlarmConfProfileEntry 7 } vdslThresh15MinUASs OBJECT-TYPE SYNTAX HCPerfIntervalThreshold Expires December 1, 2003 [Page = 52] INTERNET-DRAFT VDSL-LINE MIB May = 2003 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "This object configures the threshold for the number of unavailable seconds (UASs) within any given 15-minute performance data collection interval. If the value of=20 unavailable seconds in a particular 15-minute collection=20 interval reaches/exceeds this value, a=20 vdslPerfUASsThreshNotification notification will be=20 generated. No more than one notification will be sent=20 per interval." ::=3D { vdslLineAlarmConfProfileEntry 8 } vdslInitFailureNotificationEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies if a vdslInitFailureNotification=20 notification will be generated if an initialization failure occurs." ::=3D { vdslLineAlarmConfProfileEntry 9 } vdslLineAlarmConfProfileRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table. A profile activated by setting this object to `active'. =20 When `active' is set, the system will validate the profile. Before a profile can be deleted or taken out of service,=20 (by setting this object to `destroy' or `outOfService') it must be first unreferenced from all associated lines." ::=3D { vdslLineAlarmConfProfileEntry 10 } -- Notification definitions vdslNotifications OBJECT IDENTIFIER ::=3D { vdslLineMib 0 } vdslPerfLofsThreshNotification NOTIFICATION-TYPE OBJECTS {=20 vdslPerfCurr15MinLofs, vdslThresh15MinLofs=20 } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::=3D { vdslNotifications 1 } Expires December 1, 2003 [Page = 53] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslPerfLossThreshNotification NOTIFICATION-TYPE OBJECTS {=20 vdslPerfCurr15MinLoss, vdslThresh15MinLoss=20 } STATUS current DESCRIPTION "Loss of Signal 15-minute interval threshold reached." ::=3D { vdslNotifications 2 } vdslPerfLprsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfCurr15MinLprs, vdslThresh15MinLprs=20 } STATUS current DESCRIPTION "Loss of Power 15-minute interval threshold reached." ::=3D { vdslNotifications 3 } vdslPerfLolsThreshNotification NOTIFICATION-TYPE OBJECTS { vdslPerfCurr15MinLols, vdslThresh15MinLols=20 } STATUS current DESCRIPTION "Loss of Link 15-minute interval threshold reached." ::=3D { vdslNotifications 4 } vdslPerfESsThreshNotification NOTIFICATION-TYPE OBJECTS {=20 vdslPerfCurr15MinESs, vdslThresh15MinESs=20 } STATUS current DESCRIPTION "Errored Seconds 15-minute interval threshold reached." ::=3D { vdslNotifications 5 } vdslPerfSESsThreshNotification NOTIFICATION-TYPE OBJECTS {=20 vdslPerfCurr15MinSESs, vdslThresh15MinSESs=20 } STATUS current DESCRIPTION "Severely Errored Seconds 15-minute interval threshold=20 reached." ::=3D { vdslNotifications 6 } vdslPerfUASsThreshNotification NOTIFICATION-TYPE OBJECTS {=20 vdslPerfCurr15MinUASs, Expires December 1, 2003 [Page = 54] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslThresh15MinUASs=20 } STATUS current DESCRIPTION "Unavailable Seconds 15-minute interval threshold reached." ::=3D { vdslNotifications 7 } vdslDownMaxSnrMgnExceededNotification NOTIFICATION-TYPE OBJECTS { vdslCurrSnrMgn, vdslLineConfDownstreamMaxSnrMgn } STATUS current DESCRIPTION "The downstream Signal to Noise Margin exceeded vdslLineConfDownstreamMaxSnrMgn. The object vdslCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-R." ::=3D { vdslNotifications 8 } vdslDownMinSnrMgnExceededNotification NOTIFICATION-TYPE OBJECTS { vdslCurrSnrMgn, vdslLineConfDownstreamMinSnrMgn } STATUS current DESCRIPTION "The downstream Signal to Noise Margin fell below vdslLineConfDownstreamMinSnrMgn. The object vdslCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-R." ::=3D { vdslNotifications 9 } vdslUpMaxSnrMgnExceededNotification NOTIFICATION-TYPE OBJECTS { vdslCurrSnrMgn, vdslLineConfUpstreamMaxSnrMgn } STATUS current DESCRIPTION "The upstream Signal to Noise Margin exceeded vdslLineConfDownstreamMaxSnrMgn. The object vdslCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-C." ::=3D { vdslNotifications 10 } vdslUpMinSnrMgnExceededNotification NOTIFICATION-TYPE OBJECTS { vdslCurrSnrMgn, vdslLineConfUpstreamMinSnrMgn } STATUS current DESCRIPTION "The upstream Signal to Noise Margin fell below Expires December 1, 2003 [Page = 55] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslLineConfDownstreamMinSnrMgn. The object vdslCurrSnrMgn will contain the Signal to Noise margin as measured by the VTU-C." ::=3D { vdslNotifications 11 } vdslInitFailureNotification NOTIFICATION-TYPE OBJECTS { vdslCurrStatus=20 } STATUS current DESCRIPTION "Vtu initialization failed. See vdslCurrStatus for=20 potential reasons." ::=3D { vdslNotifications 12 } -- conformance information vdslConformance OBJECT IDENTIFIER ::=3D { vdslLineMib 3 } vdslGroups OBJECT IDENTIFIER ::=3D { vdslConformance 1 } vdslCompliances OBJECT IDENTIFIER ::=3D { vdslConformance 2 } vdslLineMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which=20 manage VDSL interfaces." MODULE -- this module MANDATORY-GROUPS { vdslGroup } ::=3D { vdslCompliances 1 } -- units of conformance vdslGroup OBJECT-GROUP OBJECTS=20 { vdslLineCoding, vdslLineType, vdslLineConfProfile, vdslLineAlarmConfProfile, vdslInvSerialNumber, vdslInvVendorID, vdslInvVersionNumber, vdslCurrSnrMgn, vdslCurrAtn, vdslCurrStatus, vdslCurrOutputPwr, vdslCurrAttainableRate, vdslCurrLineRate, vdslChanInterleaveDelay, vdslChanCrcBlockLength, Expires December 1, 2003 [Page = 56] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslChanCurrTxRate, vdslChanCurrTxSlowBurstProtection, vdslChanCurrTxFastFecOverhead, vdslPerfValidIntervals, vdslPerfInvalidIntervals, vdslPerfLofs, vdslPerfLoss, vdslPerfLprs, vdslPerfLols, vdslPerfESs, vdslPerfSESs, vdslPerfUASs, vdslPerfInits, vdslPerfCurr15MinTimeElapsed, vdslPerfCurr15MinLofs, vdslPerfCurr15MinLoss, vdslPerfCurr15MinLprs, vdslPerfCurr15MinLols, vdslPerfCurr15MinESs, vdslPerfCurr15MinSESs, vdslPerfCurr15MinUASs, vdslPerfCurr15MinInits, vdslPerf1DayValidIntervals,=20 vdslPerf1DayInvalidIntervals,=20 vdslPerfCurr1DayTimeElapsed, vdslPerfCurr1DayLofs, vdslPerfCurr1DayLoss, vdslPerfCurr1DayLprs, vdslPerfCurr1DayLols, vdslPerfCurr1DayESs, vdslPerfCurr1DaySESs, vdslPerfCurr1DayUASs, vdslPerfCurr1DayInits, vdslIntervalLofs, vdslIntervalLoss, vdslIntervalLprs, vdslIntervalLols, vdslIntervalESs, vdslIntervalSESs, vdslIntervalUASs, vdslIntervalInits, vdsl1DayIntervalMoniSecs, vdsl1DayIntervalLofs, vdsl1DayIntervalLoss, vdsl1DayIntervalLprs, vdsl1DayIntervalLols, vdsl1DayIntervalESs, vdsl1DayIntervalSESs, vdsl1DayIntervalUASs, vdsl1DayIntervalInits, vdslChanPerfValidIntervals, vdslChanPerfInvalidIntervals, vdslChanCorrectedOctets, vdslChanUncorrectableBlks, Expires December 1, 2003 [Page = 57] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslChanPerfCurr15MinTimeElapsed, vdslChanPerfCurr15MinCorrectedOctets, vdslChanPerfCurr15MinUncorrectableBlks, vdslChanPerf1DayValidIntervals, vdslChanPerf1DayInvalidIntervals, vdslChanPerfCurr1DayTimeElapsed, vdslChanPerfCurr1DayCorrectedOctets, vdslChanPerfCurr1DayUncorrectableBlks, vdslChanIntervalCorrectedOctets, vdslChanIntervalUncorrectableBlks, vdslChan1DayIntervalMoniSecs, vdslChan1DayIntervalCorrectedOctets, vdslChan1DayIntervalUncorrectableBlks, vdslLineConfDownstreamRateMode, vdslLineConfUpstreamRateMode, vdslLineConfDownstreamMaxPwr, vdslLineConfUpstreamMaxPwr, vdslLineConfDownstreamMaxSnrMgn, vdslLineConfDownstreamMinSnrMgn, vdslLineConfDownstreamTargetSnrMgn, vdslLineConfUpstreamMaxSnrMgn, vdslLineConfUpstreamMinSnrMgn, vdslLineConfUpstreamTargetSnrMgn, vdslLineConfDownstreamFastMaxDataRate, vdslLineConfDownstreamFastMinDataRate, vdslLineConfDownstreamSlowMaxDataRate, vdslLineConfDownstreamSlowMinDataRate, vdslLineConfUpstreamFastMaxDataRate, vdslLineConfUpstreamFastMinDataRate, vdslLineConfUpstreamSlowMaxDataRate, vdslLineConfUpstreamSlowMinDataRate, vdslLineConfDownstreamRateRatio, vdslLineConfUpstreamRateRatio, vdslLineConfDownstreamMaxInterDelay, vdslLineConfUpstreamMaxInterDelay, vdslLineConfDownstreamPboControl, vdslLineConfUpstreamPboControl, vdslLineConfDownstreamPboLevel, vdslLineConfUpstreamPboLevel, vdslLineConfDeploymentScenario, vdslLineConfAdslPresence, vdslLineConfApplicableStandard, vdslLineConfBandPlan, vdslLineConfBandPlanFx, vdslLineConfBandU0Usage, vdslLineConfUpstreamPsdTemplate, vdslLineConfDownstreamPsdTemplate, vdslLineConfHamBandMask, vdslLineConfCustomNotch1Start, vdslLineConfCustomNotch1Stop, vdslLineConfCustomNotch2Start, vdslLineConfCustomNotch2Stop, vdslLineConfDownstreamTargetSlowBurstProtection, vdslLineConfUpstreamTargetSlowBurstProtection, Expires December 1, 2003 [Page = 58] INTERNET-DRAFT VDSL-LINE MIB May = 2003 vdslLineConfDownstreamMaxFastFecOverhead, vdslLineConfUpstreamMaxFastFecOverhead, vdslLineConfLineType, vdslLineConfProfileRowStatus, vdslThresh15MinLofs, vdslThresh15MinLoss, vdslThresh15MinLprs, vdslThresh15MinLols, vdslThresh15MinESs, vdslThresh15MinSESs, vdslThresh15MinUASs, vdslInitFailureNotificationEnable, vdslLineAlarmConfProfileRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about a VDSL Line." ::=3D { vdslGroups 1 } vdslNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { vdslPerfLofsThreshNotification, vdslPerfLossThreshNotification, vdslPerfLprsThreshNotification, vdslPerfLolsThreshNotification, vdslPerfESsThreshNotification, vdslPerfSESsThreshNotification, vdslPerfUASsThreshNotification, vdslDownMaxSnrMgnExceededNotification, vdslDownMinSnrMgnExceededNotification, vdslUpMaxSnrMgnExceededNotification, vdslUpMinSnrMgnExceededNotification, vdslInitFailureNotification } STATUS current DESCRIPTION "This group supports notifications of significant=20 conditions associated with VDSL Lines." ::=3D { vdslGroups 2 } END Normative References [ETSI2701] ETSI TS 101 270-1 V1.2.1 "Transmission and Multiplexing=20 (TM); Access transmission systems on metallic access=20 cables; Very high speed Digital Subscriber Line (VDSL);=20 Part 1: Functional requirements", October 1999. [ETSI2702] ETSI TS 101 270-2 V1.1.1 "Transmission and Multiplexing=20 (TM); Access transmission systems on metallic access=20 cables; Very high speed Digital Subscriber Line (VDSL);=20 Part 1: Transceiver specification", February 2001. Expires December 1, 2003 [Page = 59] INTERNET-DRAFT VDSL-LINE MIB May = 2003 [ITU9931] ITU-T G.993.1 "Very-high-speed digital subscriber line=20 foundation", November 2001. [ITU9971] ITU-T G.997.1 "Physical layer management for Digital Subscriber Line (DSL) Transceivers", July 1999. [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,=20 "Introduction to Community-based SNMPv2", RFC 1901,=20 January 1996. =20 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,=20 "Protocol Operations for Version 2 of the Simple Network=20 Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,=20 "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate=20 Requirement Levels", RFC 2119, March 1997. [RFC2493] Tesink, K., "Textual Conventions for MIB Modules Using=20 Performance History Based on 15 Minute Intervals", RFC=20 2493, January 1999. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An=20 Architecture for Describing SNMP Management Frameworks",=20 RFC 2571, April 1999. [RFC2572] Case, J., Harrington D., Presuhn, R. and B. Wijnen,=20 "Message Processing and Dispatching for the Simple = Network Management Protocol (SNMP)", RFC 2572, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model=20 (USM) for version 3 of the Simple Network Management=20 Protocol (SNMPv3)", RFC 2574, April 1999. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management=20 Information Version 2 (SMIv2)", STD 58, RFC 2578, April=20 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., = Rose, M. and S. Waldbusser, "Textual Conventions for=20 SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for=20 SMIv2", STD 58, RFC 2580, April 1999. [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects=20 for the ADSL Lines", RFC 2662, August 1999. Expires December 1, 2003 [Page = 60] INTERNET-DRAFT VDSL-LINE MIB May = 2003 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group=20 MIB", RFC 2863, June 2000. [T1E1311] ANSI T1E1.4/2001-311, "Very-high-bit-rate Digital=20 Subscriber Line (VDSL) Metallic Interface, Part 1:=20 Functional Requirements and Common Specification",=20 February 2001. [T1E1011] ANSI T1E1.4/2001-011R3, "VDSL Metallic Interface, Part 2: = Technical Specification for a Single-Carrier Modulation=20 (SCM) Transceiver", November 2001. [T1E1013] ANSI T1E1.4/2001-013R4, "VDSL Metallic Interface, Part 3: = Technical Specification for a Multi-Carrier Modulation=20 (MCM) Transceiver", November 2000. [DSLFTR057] DSL Forum TR-057, "VDSL Network Element Management", February 2003. [RFChctc] Ray, B. and R. Abbi, "High Capacity Textual Conventions=20 for MIB Modules Using Performance History Based on=20 15 Minute Intervals", RFC hctc, xyz 2003. Informative References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification = of Management Information for TCP/IP-based Internets", = STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, = "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", = STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with=20 the SNMP", RFC 1215, March 1991. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,=20 "Introduction to Version 3 of the Internet-standard=20 Network Management Framework", RFC 2570, April 1999. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 = Applications", RFC 2573, April 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based=20 Access Control Model (VACM) for the Simple Network=20 Management Protocol (SNMP)", RFC 2575, April 1999. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. VDSL layer connectivity from the Vtur will permit the subscriber=20 to manipulate both the VDSL link directly and the VDSL embedded =20 operations channel (EOC) for their own loop. For example, unchecked = Expires December 1, 2003 [Page = 61] INTERNET-DRAFT VDSL-LINE MIB May = 2003 or unfiltered fluctuations initiated by the subscriber could = generate sufficient notifications to potentially overwhelm either the=20 management interface to the network or the element manager. For this reason, there are a number of managed objects in this MIB=20 that may contain sensitive information. These are: vdslThresh15MinLofs vdslThresh15MinLoss vdslThresh15MinLprs vdslThresh15MinLols vdslThresh15MinESs vdslThresh15MinSESs vdslThresh15MinUASs It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending=20 them over the network via SNMP. Not all versions of SNMP provide=20 features for such a secure environment. Further, notifications generated by agents implementing this MIB will contain the above threshold information. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is = no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View- based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. IANA Considerations=20 The VDSL-LINE-MIB MIB module requires the allocation of a single=20 object identifier for its MODULE-IDENTITY. IANA should allocate=20 this object identifier in the transmission subtree. Acknowledgments Greg Bathrick (Nokia) Umberto Bonollo (NEC) Andrew Cheers (NEC) David Horton (CiTR) Expires December 1, 2003 [Page = 62] INTERNET-DRAFT VDSL-LINE MIB May = 2003 Travis Levin (Paradyne) Moti Morgenstern (Inovia) Randy Presuhn (BMC) =20 Say Sabit (NLC) Bert Wijnen (Lucent) Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive = Director. Authors' Addresses Bob Ray PESA Switching Systems, Inc. 330-A Wynn Drive Huntsville, AL 35805 USA Phone: +1 256 726 9200 ext. 142 Fax: +1 256 726 9271 Email: rray@pesa.com Rajesh Abbi Alcatel USA 2912 Wake Forest Road Raleigh, NC 27609-7860 USA Phone: +1 919 850 6194 Email: Rajesh.Abbi@alcatel.com Expires December 1, 2003 [Page = 63] INTERNET-DRAFT VDSL-LINE MIB May = 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires December 1, 2003 [Page = 64] ------_=_NextPart_000_01C326EB.E23833D0-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Sat May 31 01:29:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12344 for ; Sat, 31 May 2003 01:29:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5TIK06060 for adslmib-archive@odin.ietf.org; Sat, 31 May 2003 01:29:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5THB06057 for ; Sat, 31 May 2003 01:29:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12333 for ; Sat, 31 May 2003 01:29:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lytw-00057I-00 for adslmib-web-archive@ietf.org; Sat, 31 May 2003 01:27:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lytw-00057F-00 for adslmib-web-archive@ietf.org; Sat, 31 May 2003 01:27:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5TBB06049; Sat, 31 May 2003 01:29:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5S9B06015 for ; Sat, 31 May 2003 01:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12307 for ; Sat, 31 May 2003 01:28:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lysq-00056r-00 for adslmib@ietf.org; Sat, 31 May 2003 01:26:24 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19Lysp-00056o-00 for adslmib@ietf.org; Sat, 31 May 2003 01:26:24 -0400 Received: from h-68-164-177-231.snvacaid.covad.net ([68.164.177.231] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19LyuR-0004AT-00 for adslmib@ietf.org; Fri, 30 May 2003 22:28:03 -0700 Message-ID: <005a01c32733$fdbc5760$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE74@mchh2a8e.mchh.siemens.de> Date: Fri, 30 May 2003 22:17:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.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: , Hi - > From: "Flemisch Felix" > To: > Cc: ; ; ; > Sent: Friday, May 30, 2003 1:41 PM > Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt ... > please find attached a plain ASCII text version of the > updated "draft-ietf-adslmib-vdsl-09.txt" that I previously ... Thanks. I did a diff of the -09- and "09a" documents, and have a few comments on the proposed changes. In the following commented "diff" output, "<" is -09- and ">" is -09a-, with each group preceded by the line numbers affected, and followed by my comment on the change. I trimmed the diffs I considered harmless. I assume the deletion of the formfeeds between pages was an oversight. 269c280 < and to define the behavior of the statistics to be maintained --- > and to define the behaviour of the statistics to be maintained Since the rest of the document uses US English spelling, "behavior" would be better than the British "behaviour" (which only looks right if one has been reading too much GDMO. :-) 348,349c361,366 < A VDSL Line consists of a two units - Vtuc (the central termination < unit) and a Vtur (the remote termination unit). --- > A VDSL Line consists of two units - a Vtuc (the central transceiver > unit) and a Vtur (the remote transceiver unit). The "-" should not be replaced with the non-ASCII thing that is in that position in the 09a document. 494,496c513,515 < All objects defined in this MIB which may be set (read-write or < read-create), should be stored persistently. Following is an < exhaustive list of these persistent objects: --- > All objects defined in this MIB module, which may be set (read-write > or read-create), SHOULD be stored persistently. Following is > an exhaustive list of these persistent objects: Rather than adding a comma, I'd remove one, resulting in a comma-free sentence. It'd be better if the relative pronoun were closer to its antecedent. Something like: All read-write and read-create objects defined in this MIB module SHOULD be stored persistently. 614c638 < Raleigh NC 27627-7324 --- > Raleigh, NC 27627-7324 USA Suggest putting the country on a separate line, as one would do when addressing mail. 711c753,759 < DESCRIPTION "Brought into conformance with DSLF TR-057." --- > DESCRIPTION "Brought into conformance with DSLF TR-057. > This means in particular that all line-code-specific > (LCS) elements have been removed for both, MCM lines > and SCM lines. However, a standardized LCS VDSL Line > Extension MIB module is seen as a MANDATORY supplement > to the VDSL-LINE-MIB since otherwise neither MCM lines > nor SCM lines can be fully configured." This is NOT the place for putting conformance material, so the second sentence should be removed, in my opinion. The phrase "MANDATORY supplement" strikes me as oxymoronic at best. Even if the WG agrees with this addition, the punctuation needs to be fixed: delete the first comma, and add a comma before "since." 723c771,779 < ::= { transmission xxxx } --- > > REVISION "200305290000Z" -- May 29, 2003 > DESCRIPTION "Added vdslLineConfLineType, > added note to DESCRIPTION of MODULE-IDENTITY > regarding necessity of LCS MIB extensions, > corrected mechanical and editorial flaws, > added various clarifications." > > ::= { transmission 97 } Uh..... Did IANA make this assignment? In any case, the REVISIONS should be chopped down to the "initial version" one. 805,808c863,869 < fastOnly(2), -- fast channel only < slowOnly(3), -- slow channel only < either(4), -- either fast or slow channel exist < both(5) -- both fast and slow channels exist --- > fastOnly(2), -- fast channel exists only > interleavedOnly(3), -- interleaved channel exists only > fastOrInterleaved(4), -- either fast or interleaved > -- channels can exist, but > -- only one at any time > fastAndInterleaved(5) -- both fast and interleaved > -- channels exist phrases of the form "NP exists only " should be "only NP exists", since "only" is functioning as a quantifier for the noun phrase rather than as an adverb. 815c876 < the line is channelized. If the line is channelized, --- > the line is channellized. If the line is channellized, This looks really strange to me. Is it a British spelling? 819c880 < In the case that the line is channelized, the manager --- > In the case that the line is channellized, the manager Ditto. 830c893 < REFERENCE "T1E1.4/2000-009R3" -- Part 1, common spec --- > Why do you think the reference should be deleted? 839c902 < in the VDSL Line Configuration Profile Table, --- > in the VDSL Line Configuration Profile Table Since the parenthesized word in the following line is really an appositive, just moving the comma isn't quite right. Suggest removing the parens, so that the appositive can be punctuated normally (preceded and followed by commas). 948c1015 < -31.75 to +31.75dB." --- > -31.75..+31.75 dB." This is much harder to read than the original. I don't see any value to be gained from changing "to" to ".." I do, however, like the added space before "dB". 960c1027 < The effective range is 0 to +63.75dB." --- > The effective range is 0..+63.75 dB." This is much harder to read than the original. I don't see any value to be gained from changing "to" to ".." I do, however, like the added space before "dB". 1007,1008c1076,1077 < the transceiver is in the 'Warm < Start' state. --- > the transceiver is in the "Warm > Start" state. NO! This is a syntax violation. 2205c2314 < A default profile with an index of 'DEFVAL', will --- > A default profile with an index of `DEFVAL', will Talk to any typographer for a sermon on why "`" is not appropriate for use as a quote character in English. :-) 2278c2390 < A default profile with an index of 'DEFVAL', will --- > A default profile with an index of `DEFVAL', will See previous comment. 2322c2436 < level in the range 0..14.5dBm." --- > level in the range 0..14.5 dBm." 2333c2447 < level in the range 0..14.5dBm." --- > level in the range 0..14.5 dBm." Based on reaction to previous, suggest replacing ".." with " to " 2732c2877,2879 < "The upstream PSD template to be used for the line." --- > "The upstream PSD template to be used for the line. > It depends on vdslLineConfApplicableStandard." > REFERENCE "DSLF TR-057" -- section 2.4 What does "depends" mean here? 2744c2891,2893 < "The downstream PSD template to be used for the line." --- > "The downstream PSD template to be used for the line. > It depends on vdslLineConfApplicableStandard." > REFERENCE "DSLF TR-057" -- section 2.4 What does "depends" mean here? 2776a2930,2934 > ANSI T1.424-1 [T1E1311] and ETSI TS 101 270-1 [ETSI2701] > extend the VDSL spectrum up to 30 MHz and therefore define > additional five HAM bands (see normative Annex 1 of T1.424-1 > and Section 9.3.3.6.1 of TS 101 270-1), not considered here. typos: "additional five" -> "five additional" ")," -> ")" Also, if you're going to use the acronym "HAM", you should provide an expansion. 2797c2957 < UNITS "kHz" --- > UNITS "Hz" Is this change intentional? 2806c2966 < UNITS "kHz" --- > UNITS "Hz" Is this change intentional? 2815c2975 < UNITS "kHz" --- > UNITS "Hz" Is this change intentional? 2824c2984 < UNITS "kHz" --- > UNITS "Hz" Is this change intentional? 2879a3042,3063 > vdslLineConfLineType OBJECT-TYPE > SYNTAX INTEGER > { > noChannel(1), -- no channels exist > fastOnly(2), -- fast channel exists only > interleavedOnly(3), -- interleaved channel exists only > fastOrInterleaved(4), -- either fast or interleaved > -- channels can exist, but > -- only one at any time > fastAndInterleaved(5) -- both fast and interleaved > -- channels exist > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This parameter provisions the type of VDSL physical line > entity that shall exist, by defining whether and how > the line shall be channellized. If the line is to be > channellized, the value will be other than noChannel(1). > This object defines which channel type(s) are supported." > ::= { vdslLineConfProfileEntry 45 } No DEFVAL? 2926c3112 < A default profile with an index of 'DEFVAL', will --- > A default profile with an index of `DEFVAL', will Please, "'" instead of "`"! Finally, one "blanket" item regarding the enumeration "interleave": would it make sense to change it to "interleaved"? This would result in a smaller number of changes, and would read better. Randy _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Sat May 31 09:11:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01144 for ; Sat, 31 May 2003 09:11:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VDBNr12836 for adslmib-archive@odin.ietf.org; Sat, 31 May 2003 09:11:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDBMB12833 for ; Sat, 31 May 2003 09:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01126 for ; Sat, 31 May 2003 09:11:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M677-0007Di-00 for adslmib-web-archive@ietf.org; Sat, 31 May 2003 09:09:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19M677-0007De-00 for adslmib-web-archive@ietf.org; Sat, 31 May 2003 09:09:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDBFB12818; Sat, 31 May 2003 09:11:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDAMB12789 for ; Sat, 31 May 2003 09:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01103 for ; Sat, 31 May 2003 09:10:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M669-0007DS-00 for adslmib@ietf.org; Sat, 31 May 2003 09:08:37 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19M668-0007DO-00 for adslmib@ietf.org; Sat, 31 May 2003 09:08:36 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA22198; Sat, 31 May 2003 15:10:15 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id PAA26336; Sat, 31 May 2003 15:10:15 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Sat, 31 May 2003 15:09:49 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE76@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'randy_presuhn@mindspring.com'" Date: Sat, 31 May 2003 15:09:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Adslmib] RE: WG Last Call: draft-ietf-adslmib-vdsl-09.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: , 1 2 3 4 5 6 7 | 8 12345678901234567890123456789012345678901234567890123456789012345678901234567890 Hi all, Randy Presuhn wrote > I did a diff of the -09- and "09a" documents, and have > a few comments on the proposed changes. Thanks Randy for so quickly producing diffs and commenting them! You identified a number of obscurities indeed. Here are my answers. 1. 269c280 I leave it to the co-editors whether they stick to US English or British English but only request that either is used uniformly. I prefer British English but am aware that you e.g. recommend to replace existing "behaviour"s by "behavior"s. 2. 348,349c361,366 The non-ASCII thing is a dash inserted by Word that needs to be replaced by a hyphen (though semantically it's a dash). 3. 494,496c513,515 I'm now proposing the following new text: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All objects defined in this MIB module that may be set (read-write or read-create) SHOULD be stored persistently. Following is an exhaustive list of these persistent objects: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 4. 614c638 When the country is put on a separate line this should also be done with Bob's and Rajesh's addresses (twice for each). 5. 711c753,759 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will send out a separate email on "VDSL Line Type Configuration and VDSL Line Extension MIB", since these are the substantial changes that I'm proposing for vdsl-09. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 6. 723c771,779 I was so naive to take the IANAifType for the VDSL line. I now think it's better to leave IANA issues to the RFC editor. The REVISIONS section would be of interest only if the WG should decide to produce "draft-ietf-adslmib-vdsl-10.txt"! 7. 805,808c863,869 Refer to the upcoming email on "VDSL Line Type Configuration and VDSL Line Extension MIB". 8. 815c876; 819c880 It is strange! Forget that spelling! One also writes e.g. "channelization". Probably I was assuming that there might be a similar US/British difference as between e.g. "modeling" and "modelling" but this does not apply here. 9. 830c893 Refer to the upcoming email on "VDSL Line Type Configuration and VDSL Line Extension MIB". 10. 839c902 I agree, and let's do the same for the Alarm Configuration Profile Table. 11. 948c1015; 960c1027; 2322c2436; 233c2447 I agree, and so let's replace WITHIN COMMENTS the interval specification ".." by " to " here, and all over the document. 12. 1007,1008c1076,1077 I regret to have to agree. 13. 2205c2314, 2278c2390, 2926c3112 ("`" vs. "'") I agree but "`" is already used in vdsl-09 as a quote character (old lines 426 and 430). I therefore propose to change the "`" in these lines to a "'", too. 14. 2732c2877,2879; 2744c2891,2893 (PSD templates) Randy, in your email of 14th May you stated the following: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > vdslLineConfUpstreamPsdTemplate and > vdslLineConfDownstreamPsdTemplate need much clearer > DESCRIPTIONs. I have no idea what they DO, even if I > make the leap of faith that "PSD" and "Psd" are the > same thing in the document. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< The proposed text that "templateMask1(1)" and "templateMask2(2)" depend on vdslLineConfApplicableStandard is a first, yet incomplete answer to this comment. I'm now proposing the following new text fragments. DESCRIPTION of vdslLineConfUpstreamPsdTemplate: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "The upstream PSD template to be used for the line. Here templateMask1(1) refers to a notched mask that limits the transmitted PSD within the internationally standardized HAM radio bands while templateMask2(2) refers to an unnotched mask. The masks depend on vdslLineConfApplicableStandard and in case of etsi(2) also on vdslLineConfAdslPresence. They are specified in the applicable T1E1/ANSI, ETSI, ITU-T standards documents or in proprietary documentation." <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< DESCRIPTION of vdslLineConfDownstreamPsdTemplate: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "The downstream PSD template to be used for the line. Refer to vdslLineConfUpstreamPsdTemplate for the semantics. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 15. 2776a2930,2934 I appreciate your corrections. HAM is a widespread equivalent, also used by TR-057, for Handheld Amateur Radio. In the past this acronym was also written out differently, however (see, for example, http://earlyradiohistory.us/sec012.htm and and http://earlyradiohistory.us/1902slng.htm). 16. 2797c2957; 2806c2966; 2815c2975; 2824c2984 ("kHz" vs. "Hz") These changes are indeed intentional since they are specified in this way in TR-057 (section 2.6.1). They allow for a much finer grained definition of custom notches. 17. 2879a3042,3063 Refer to the upcoming email on "VDSL Line Type Configuration and VDSL Line Extension MIB". 18. "interleave(124)" vs. "interleaved(124)" (see 183c191 etc.) While "interleave" is the verb "interleaved" is the adjective. Since the adjective seems to be appropriate in all places I agree with your proposal. However, the enumeration is IANA defined and used e.g. by ADSL. So I doubt whether it will be possible to change it as one should. But we should ask the RFC editor what can reasonably be achieved. I finally take the opportunity to point out three typos in "draft-ietf-adslmib-vdsl-09a.txt": (new) line 148 should read " lines specified by DSLF is taken into consideration [DSLFTR057]." (new) line 3079 should read " A profile is activated by setting this object to `active'." (new) lines 3083/3084 should read " service, by setting this object to `destroy' or" " `outOfService', it must be first unreferenced" The announced email on "VDSL Line Type Configuration and VDSL Line Extension MIB" will be sent out next Monday. Regards, Felix -----Original Message----- From: Flemisch Felix Sent: Friday, May 30, 2003 10:42 PM To: 'adslmib@ietf.org' Cc: 'sneedmike@hotmail.com'; 'rray@pesa.com'; 'rajesh.abbi@alcatel.com'; 'randy_presuhn@mindspring.com' Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt Hi all, please find attached a plain ASCII text version of the updated "draft-ietf-adslmib-vdsl-09.txt" that I previously distributed as a Word document with continuous line numbering where I have added my comments using change tracking. I have named this updated document "draft-ietf-adslmib-vdsl-09a.txt". ... Best Regards, Felix Flemisch Siemens AG _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib