From mailnull@www1.ietf.org Sun Jun 1 04:37:03 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 EAA01943 for ; Sun, 1 Jun 2003 04:37:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h518aah29164 for adslmib-archive@odin.ietf.org; Sun, 1 Jun 2003 04:36:36 -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 h518aZB29161 for ; Sun, 1 Jun 2003 04:36:35 -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 EAA01926 for ; Sun, 1 Jun 2003 04:36:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MOIj-0004cr-00 for adslmib-web-archive@ietf.org; Sun, 01 Jun 2003 04:34:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MOIj-0004co-00 for adslmib-web-archive@ietf.org; Sun, 01 Jun 2003 04:34:49 -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 h518aUB29141; Sun, 1 Jun 2003 04:36:30 -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 h518ZKB29110 for ; Sun, 1 Jun 2003 04:35: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 EAA01916; Sun, 1 Jun 2003 04:35:16 -0400 (EDT) From: Moti.Morgenstern@ecitele.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MOHV-0004cY-00; Sun, 01 Jun 2003 04:33:33 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19MOHU-0004cV-00; Sun, 01 Jun 2003 04:33:32 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h518TqpP005048; Sun, 1 Jun 2003 11:29:53 +0300 (IDT) Subject: Re: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.txt To: "Randy Presuhn" , Flemisch Felix Cc: adslmib@ietf.org, adslmib-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Sun, 1 Jun 2003 11:35:07 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 06/01/2003 11:35:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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, Referring to the changes between 09 and 09a, here is my input which ignores most of the English and wording issues: 711c753,759 Probably the "DESCRIPTION" section is not the right place for the second sentence proposed. However, the sentence provides a very important information and that information should be placed somewhere in the "front pages" (e.g., even in the paragraphs preceeding the formal MIB definitions) rather than being hidden. 805,808c863,869 I disagree on replacing the term "slow" with "interleaved". The VDSL standards call it "slow" and so should the MIB do. 2776a2930,2934 There are amateur radio bands up to 30mHz but this MIB refers to band plans 997, 998 and the flexible (Fx) bandplan which all terminate at 12mHz. The MIB allows using a non-standard band plan (it also allows using a non-standrad line code) but the MIB never documents the specific details of such "non-standard configurations". 2879a3042,3063 Again, the VDSL standards call the channel which uses the interleaving mechanism "slow" and so should the MIB do. Best regards, Moti Morgenstern Senior Systems Engineer ECI Telecoms Ltd. Inovia Broadband Access Division 30 Hasivim St. Petach Tikva, Israel 49133 Tel.: +972-3-9266258 Fax: +972-3-9268182 Cell: +972-55-786258 e-mail: Moti.Morgenstern@ecitele.com www.ecitele.com _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Sun Jun 1 06:30: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 GAA04078 for ; Sun, 1 Jun 2003 06:30:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h51AUNB03315 for adslmib-archive@odin.ietf.org; Sun, 1 Jun 2003 06:30: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 h51AUNB03312 for ; Sun, 1 Jun 2003 06:30: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 GAA04072 for ; Sun, 1 Jun 2003 06:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MQ4p-0005Gk-00 for adslmib-web-archive@ietf.org; Sun, 01 Jun 2003 06:28:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MQ4o-0005Gh-00 for adslmib-web-archive@ietf.org; Sun, 01 Jun 2003 06:28:34 -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 h51AUDB03267; Sun, 1 Jun 2003 06:30: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 h51ATUB03203 for ; Sun, 1 Jun 2003 06:29:30 -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 GAA04045 for ; Sun, 1 Jun 2003 06:29:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MQ3x-0005GP-00 for adslmib@ietf.org; Sun, 01 Jun 2003 06:27:41 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19MQ3x-0005GM-00 for adslmib@ietf.org; Sun, 01 Jun 2003 06:27:41 -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 MAA06405; Sun, 1 Jun 2003 12:28:55 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA27991; Sun, 1 Jun 2003 12:28:55 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Sun, 1 Jun 2003 12:28:30 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE77@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'randy_presuhn@mindspring.com'" , "'Moti.Morgenstern@ecitele.com'" Date: Sun, 1 Jun 2003 12:28:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Adslmib] VDSL Line Type Naming and Configuration 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 wrote > The announced email on "VDSL Line Type Configuration and > VDSL Line Extension MIB" will be sent out next Monday. It turned out to be convenient to split the email in two parts. Here is the first part on VDSL Line Type Naming and Configuration. I give a rationale for what I'm proposing in "draft-ietf-adslmib-vdsl-09a.txt", sent out on 30th May, and answer the related comments by Randy (805,808c863,869; 830c893; 2879a3042,3063; see his email of 31st May) thereby polishing the text of the previous proposals. I'm proposing the following: 1. Rename the enums of vdslLineType (within vdslLineEntry) so that they refer to the "interleaved" channel instead of refering to the "slow" channel (though this is in fact the same channel). 2. Introduce the new parameter "vdslLineConfLineType" within vdslLineConfProfileEntry to enable the configuration of vdslLineType at start-up time (and only at start-up time). As to 1.: a) Channelization capabilities of DSL equipment to provide multiple channels with different transmission qualities are of increasing importance, and the basic feature to have a fast channel, or an interleaved channel, or either, or both[, or none] is only the very beginning of those capabilities. They will increase already with ADSL2 and ADSL2+, i.e. the choices for DSL line types will increase above the currently offered five options (taken from G.997.1; however, the revision of G.997.1 removed the ADSL line type...). b) Slow and interleaved refer to the same, high-latency channel, but "slow" emphasizes the DISADVANTAGE of interleaving that it makes the channel slow, while "interleaved" emphasizes the ADVANTAGE of interleaving that it provides reliability in the presence of impulse noise or other line disturbances. So "slow" is a pessimistic point of view while "interleaved" is an optimistic point of view. Similarly "fast" emphasizes the ADVANTAGE of the fast channel that it has low throughput delay though it may include modest interleaving depending on the definition of low latency. c) Whether one replaces "slow" by "interleaved", and "either" by "fastOrInterleaved", and "both" by "fastAndInterleaved", is - a matter of taste (slow, either, both are more elegant, but slow is pessimistic) - a matter of backward compatibility with RFC 2662 and RFC 3440 ("interleaved") - a matter of compatibility with VDSL standards ("slow") - a matter of compatibility with IANA assignments ("interleave(124)" which should be "interleaved(124)", however, or could be changed to "slow(124)") d) If the WG sees no need for replacement one can basically leave it to the co-editors whether they want to stick to "slow" or change to "interleaved". In the following I summarize both alternatives where in the case of "slow" I have improved the text slightly. This answers Randy's comment 805,808c863,869. Note also that in case of "interleaved" there is no reference to T1.424-1 (which is T1E1.4/2001-311 and T1E1.4/2000-009R3) since the document uses "slow". This answers Randy's comment 830c893. The non-fast channel is designated as "slow": >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vdslLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- only fast channel exists slowOnly(3), -- only slow channel exists either(4), -- either fast or slow -- channels can exist, but -- only one at any time both(5) -- both the fast and the slow -- channel 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 channelized. If the line is channelized, the value will be other than noChannel(1). This object defines which channel type(s) are supported. In the case that the line is channelized, the manager can use the ifStackTable to determine the ifIndex for the associated channel(s). Note that 'slow' and 'interleaved' refer to the same channel." REFERENCE "T1E1.4/2000-009R3" -- Part 1 [T1E1311] ::= { vdslLineEntry 2 } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< The non-fast channel is designated as "interleaved": >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vdslLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- only fast channel exists interleavedOnly(3), -- only interleaved channel exists fastOrInterleaved(4), -- either fast or interleaved -- channels can exist, but -- only one at any time fastAndInterleaved(5) -- both the fast and the interleaved -- channel 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 channelized. If the line is channelized, the value will be other than noChannel(1). This object defines which channel type(s) are supported. In the case that the line is channelized, the manager can use the ifStackTable to determine the ifIndex for the associated channel(s). Note that 'interleaved' and 'slow' refer to the same channel." ::= { vdslLineEntry 2 } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< As to 2.: a) For VDSL equipment that offers channelization capabilities there is clearly a need to configure the VDSL line type at start-up time. However, it is also clear that nevertheless vdslLineType should remain read-only to avoid reconfiguration during showtime which would have some nasty side effects, e.g. on the ifTable (see Bob's email of 28th May). b) This has been recognized for ADSL and therefore RFC 3440 includes an extension of adslLineConfProfileEntry by adslConfProfileExtEntry which includes the parameter adslConfProfileLineType whose syntax is that of adslLineType. IMHO it is just an oversight that this parameter became not already a part of RFC 2662. c) I'm proposing to do exactly the same for VDSL. In the following I summarize the proposal using the designation "interleaved" for the non-fast channel. The "slow" alternative would be similar. This also answers Randy's comment 2879a3042,3063 since I'm stating a default value for the new parameter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vdslLineConfLineType OBJECT-TYPE SYNTAX INTEGER { noChannel(1), -- no channels exist fastOnly(2), -- only fast channel exists interleavedOnly(3), -- only interleaved channel exists fastOrInterleaved(4), -- either fast or interleaved -- channels can exist, but -- only one at any time fastAndInterleaved(5) -- both the fast and the interleaved -- channel 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 channelized, i.e. which channel type(s)are supported. If the line is to be channelized, the value will be other than noChannel(1). This configuration can be activated only during start-up. Afterwards the value of vdslLineType (within vdslLineEntry) coincides with the value of vdslLineConfLineType. Depending on this value the corresponding entries in the ifTable for the interleaved and the fast channel, i.e. ifEntry(ifType=124) and ifEntry(ifType=125), are enabled or disabled according to the value of their ifOperStatus. In the case when no value has been set, the default value 'DEFVAL' is noChannel(1)." ::= { vdslLineConfProfileEntry 45 } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< The announced email on "VDSL Line Extension MIB" will be sent out tomorrow. A final remark. There is severe doubt whether HAM is an acronym at all (see e.g. http://www.hamcity.com/knowledge/whatisham.asp). I therefore recommend not to expand it as Randy suggested. Regards, Felix Flemisch Siemens AG Information and Communication Networks Carrier Products Systems Engineering Hofmannstr. 51 D-81359 Munich Germany Phone +49 89 722 62175 Email felix.flemisch@siemens.com Internet http://www.siemens.com/ -----Original Message----- From: Flemisch Felix Sent: Saturday, May 31, 2003 3:10 PM To: 'adslmib@ietf.org' Cc: 'randy_presuhn@mindspring.com' Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt 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. ... 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 From mailnull@www1.ietf.org Mon Jun 2 07:39: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 HAA02053 for ; Mon, 2 Jun 2003 07:39:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52BdLL05139 for adslmib-archive@odin.ietf.org; Mon, 2 Jun 2003 07:39: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 h52BdLB05136 for ; Mon, 2 Jun 2003 07:39: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 HAA02041 for ; Mon, 2 Jun 2003 07:39:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mnd7-0001om-00 for adslmib-web-archive@ietf.org; Mon, 02 Jun 2003 07:37:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Mnd7-0001oj-00 for adslmib-web-archive@ietf.org; Mon, 02 Jun 2003 07:37:33 -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 h52BdDB05116; Mon, 2 Jun 2003 07:39:13 -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 h52BcvB05094 for ; Mon, 2 Jun 2003 07:38:57 -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 HAA02034 for ; Mon, 2 Jun 2003 07:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Mnck-0001oT-00 for adslmib@ietf.org; Mon, 02 Jun 2003 07:37:10 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19Mnci-0001oM-00 for adslmib@ietf.org; Mon, 02 Jun 2003 07:37:09 -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 NAA29311; Mon, 2 Jun 2003 13:38:05 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA05979; Mon, 2 Jun 2003 13:38:05 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Mon, 2 Jun 2003 13:37:39 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE79@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'randy_presuhn@mindspring.com'" , "'Moti.Morgenstern@ecitele.com'" , "'Menachem.Dodge@infineon.com'" Date: Mon, 2 Jun 2003 13:37: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] VDSL Line Extension MIB 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 wrote > The announced email on "VDSL Line Extension MIB" will be sent out > tomorrow. And here it is. I first give a rationale for what I'm proposing about LCS extensions in "draft-ietf-adslmib-vdsl-09a.txt", sent out on 30th May, and answer the related comment by Randy (711c753,759; see his email of 31st May) and the one by Moti (711c753,759; see his email of 1st June). I then formalize the MUST requirement for VDSL-LINE-EXT-MIB, at least regarding LCS line configuration profile tables, through the introduction of the new parameter "vdslLineConfProfileLCSExt" within vdslLineEntry. It identifies the row (maybe none) in the LCS Line Configuration Profile Extension Table, which applies for this VDSL line and its channels (if applicable). 0. Rationale and Answers to Comments In a major editorial step between vdsl-07 and vdsl-08 the VDSL MIB was fully aligned with TR-057 and thereby became line-code independent. In particular, the eight (!) LCS configuration profile tables were removed without trace (but keeping a trace would be useful, see "4. Proposal" below). These tables were organized to use the object vdslLineConfProfileName as a common index for all tables (including vdslLineConfProfileTable). In a further step some flaws of TR-057 were resolved by adding the configuration parameters slow burst protection and fast FEC overhead for both downstream and upstream direction. Subsequently it turned out that the agreed core parameter set covers completely the PMS-TC sublayer but not completely enough the PMD sublayer. And so 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 vdsl-09 without additional LCS parameters. Thus the development of an LCS-specific framework for both SCM and MCM by the DSLF and the development of a corresponding LCS VDSL extension MIB are a MUST since otherwise vendor-specific MIBs need to be implemented at the disadvantage of customers (who regularly require multi-vendor capability). I therefore requested in previous emails the standardization of a VDSL Line Extension MIB, at least regarding LCS line configuration profile tables, and the statement of this MUST requirement within the core VDSL Line MIB document. In this email I emphasize this request by proposing the introduction of a reference to profile extension tables within the VDSL line table. This gives back the missing trace to the removed LCS configuration profile tables. Randy's comment 711c753,759 is resolved by a reformulation of the complained text (see the "3. Proposal" and the related "2. Proposal" below). Moti's comment regarding 711c753,759 is resolved by the new "1. Proposal" below. 1. Proposal Enhance in section 2.5 of vdsl-09 the text describing line configuration profiles as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... o Line Configuration Profiles - These profiles contain parameters for configuring VDSL lines and their channels. They are defined in the line-code independent vdslLineConfProfileTable and in supplementary line-code specific (LCS) configuration profile tables. vdslLineConfProfileTable is defined in the VDSL-LINE MIB module that is specified in this RFC, and LCS configuration profile tables are defined in the VDSL-LINE-EXT MIB module that is specified in a separate RFC. Each entry of vdslLineTable references a row of vdslLineConfProfileTable and a common index into one or more applicable LCS configuration profile tables. The referenced LCS row(s) augment(s) the line-code independent parameter set by an LCS parameter set (which may be empty). ... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 2. Proposal Enhance the DESCRIPTION of MODULE-IDENTITY as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... Tx -- Transmit Blks -- Blocks -- Note This MIB module does not contain line-code specific (LCS) elements for neither MCM lines nor SCM lines. An LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module MUST be standardized as a supplement to the core VDSL-LINE-MIB, since otherwise both SCM and MCM lines can only be fully configured in a proprietary way. Therefore the VDSL line table refers not only to the line-code independent configuration profile table vdslLineConfProfileTable, defined in this MIB module, but also to a commonly indexed set of applicable LCS configuration profile tables, either all SCM-specific or all MCM-specific, that are defined in VDSL-LINE-EXT-MIB." <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 3. Proposal Enhance the REVISION clauses of MODULE-IDENTITY as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Revision history ... 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." ... REVISION "200306020000Z" -- June 2, 2003 DESCRIPTION "Added vdslLineConfLineType to vdslLineCodeProfileEntry. Added vdslLineConfProfileLCSExt to vdslLineEntry. Enhanced in section 2.5 the description of line configuration profiles. Added note to DESCRIPTION of MODULE-IDENTITY regarding necessity of LCS MIB extensions. Corrected many mechanical and editorial flaws, added various clarifications." <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 4. Proposal Enhance the conceptual row vdslLineEntry by the new parameter "vdslLineConfProfileExtension": >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... VdslLineEntry ::= SEQUENCE { vdslLineCoding VdslLineCodingType, vdslLineType INTEGER, vdslLineConfProfile SnmpAdminString, vdslLineConfProfileLCSExt SnmpAdminString, vdslLineAlarmConfProfile SnmpAdminString } ... ::= { vdslLineEntry 3 } vdslLineConfProfileLCSExt OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in one or more LCS VDSL configuration profile tables, which applies for this VDSL line and its channels. The LCS tables are defined in the VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) and are commonly indexed by the object vdslLineConfProfileLCSExtName. It MUST be the case that either all referenced LCS tables are SCM-specific or all these tables are MCM-specific. Correspondingly the LCS extension of the core configuration profile is called SCM-specific or MCM-specific. An SCM-specific extension profile MUST NOT be assigned to an MCM line (according to vdslLineCoding), and an MCM-specific extension profile MUST NOT be assigned to an SCM line. A value of NULL has the meaning that this VDSL line has no LCS extension profile assigned and the VDSL link will be established based on the information specified in the core configuration profile and additionally on any measurement or probing of the line as necessary." ::= { vdslLineEntry 4 } vdslLineAlarmConfProfile OBJECT-TYPE ... ::= { vdslLineEntry 5 } ... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I do not plan an update of "draft-ietf-adslmib-vdsl-09a.txt" according to the various emails sent out so far but would like to leave the incorporation of all mechanical and editorial changes, and of all accepted substantial changes, to the co-editors. IMHO a final draft version "draft-ietf-adslmib-vdsl-10.txt" could be useful to check the incorporations (if it does not hold up the RFC procedure unnecessarily). Regards, Felix -----Original Message----- From: Flemisch Felix Sent: Sunday, June 01, 2003 12:28 PM To: 'adslmib@ietf.org' Cc: 'randy_presuhn@mindspring.com'; 'Moti.Morgenstern@ecitele.com' Subject: VDSL Line Type Naming and Configuration Hi all, I wrote > The announced email on "VDSL Line Type Configuration and > VDSL Line Extension MIB" will be sent out next Monday. It turned out to be convenient to split the email in two parts. Here is the first part on VDSL Line Type Naming and Configuration. ... The announced email on "VDSL Line Extension MIB" will be sent out tomorrow. ... Regards, Felix Flemisch Siemens AG Information and Communication Networks Carrier Products Systems Engineering Hofmannstr. 51 D-81359 Munich Germany Phone +49 89 722 62175 Email felix.flemisch@siemens.com Internet http://www.siemens.com/ -----Original Message----- From: Flemisch Felix Sent: Saturday, May 31, 2003 3:10 PM To: 'adslmib@ietf.org' Cc: 'randy_presuhn@mindspring.com' Subject: RE: WG Last Call: draft-ietf-adslmib-vdsl-09.txt 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. ... 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 From mailnull@www1.ietf.org Wed Jun 4 11:43: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 LAA27636 for ; Wed, 4 Jun 2003 11:43:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54FhKm27787 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 11:43: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 h54FhKB27784 for ; Wed, 4 Jun 2003 11:43: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 LAA27630 for ; Wed, 4 Jun 2003 11:43:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NaOG-0004br-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 11:41:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NaOG-0004bn-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 11:41: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 h54FhDB27774; Wed, 4 Jun 2003 11:43:13 -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 h54FeGB27625 for ; Wed, 4 Jun 2003 11:40: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 LAA27433 for ; Wed, 4 Jun 2003 11:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NaLI-0004Zo-00 for adslmib@ietf.org; Wed, 04 Jun 2003 11:38:24 -0400 Received: from services.paradyne.com ([135.90.22.16] helo=pigeon.is.paradyne.com) by ietf-mx with esmtp (Exim 4.12) id 19NaLI-0004Z3-00 for adslmib@ietf.org; Wed, 04 Jun 2003 11:38:24 -0400 Received: from paradyne.com ([135.26.21.26]) by pigeon.is.paradyne.com (Netscape Messaging Server 4.15) with ESMTP id HFYRHX00.O36; Wed, 4 Jun 2003 11:39:33 -0400 Message-ID: <3EDE12BF.61811747@paradyne.com> Date: Wed, 04 Jun 2003 11:39:43 -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: Michael Sneed , ADSL MIB CC: Kent Davidson Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h54FeGB27626 Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work 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, I'm confused about what is being done to add MIB support for ADSL2 and ADSL2+. I'm going to summarize some threads that I have seen or been a part of with hope that someone will be able to figure out why I'm confused and provide me with clear direction regarding MIB support for ADSL2 and ADSL2+. 1. Tuesday, 01 March 2003, I inquired about plans to update the AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. Greg Bathrick responded that same day agreeing that the AdslTransmissionType needed to be extended along with other things. Also, he felt that the 997.1 needed to become finalized before work could begin. 2. Wednesday, 30 April 2003, I learned from a Paradyne representative at the ITU Q4 meeting, which took place two weeks prior, the G.997.1 underwent a minor revision and was approved. 3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to ADSL2 and ADSL2+ support. Rajesh Abbi responded and indicated that the DSL Forum has just beginning work on capturing the requirements as well as a protocol independent object model for managing the next generation ADSL technologies. 4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when something would be available and whether or not the AdslTransmissionType TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and ADSL2+ in the short term. I never got a response. 5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working group could start discussing an ADSL2 MIB. 6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and indicated that ADSL2 is not currently in the charter of the group. Can anyone please tell me who is working on a MIB to support ADSL2 and ADSL2+? If someone is working this issue, is there some estimate as to when the MIB would be available? If this working group is not going to support MIBs for ADSL2 and ADSL2+, what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? Will they be deprecated? As you can see, I'm really confused. Any help will be greatly appreciated. Thanks!! Clay Sikes Paradyne Corp. _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 12:54:42 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 MAA01231 for ; Wed, 4 Jun 2003 12:54:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54GsH501443 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 12:54: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 h54GsHB01440 for ; Wed, 4 Jun 2003 12:54: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 MAA01201 for ; Wed, 4 Jun 2003 12:54:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbUu-0005bZ-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 12:52:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NbUt-0005bW-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 12:52: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 h54GsAB01430; Wed, 4 Jun 2003 12:54: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 h54GrbB01376 for ; Wed, 4 Jun 2003 12:53:37 -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 MAA01182 for ; Wed, 4 Jun 2003 12:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbUG-0005b7-00 for adslmib@ietf.org; Wed, 04 Jun 2003 12:51:44 -0400 Received: from law14-f63.law14.hotmail.com ([64.4.21.63] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19NbUF-0005ay-00 for adslmib@ietf.org; Wed, 04 Jun 2003 12:51:43 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jun 2003 09:53:03 -0700 Received: from 66.152.60.98 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 04 Jun 2003 16:53:02 GMT X-Originating-IP: [66.152.60.98] X-Originating-Email: [sneedmike@hotmail.com] From: "Michael Sneed" To: csikes@paradyne.com, adslmib@ietf.org Cc: davidson@paradyne.com Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work Date: Wed, 04 Jun 2003 12:53:02 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2003 16:53:03.0412 (UTC) FILETIME=[C3855F40:01C32AB9] 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 Clay, I can only address your question partially. The IETF is not currently working on ADSL2 or ADSL2+ MIBs (or modification/expansion of existing MIBs to support ADSL2/ADSL2+), and the adslmib WG is not currently chartered to do such work. It is certainly possible to undertake an expansion of the WG charter; this would require the approval of the ADs and the IESG, which presupposes the following: 1) consensus that such MIBs are useful 2) consensus that the WG can complete the task in a timely manner 3) sufficient volunteers to assure the work will get done I think 1) is likely not a problem. 2) is more of an issue, because adslmib has tried to work with significant input from the DSL Forum. If the DSL Forum has not yet begun work on the management of ADSL2, then it may be premature to undertake such work in the IETF. 3) remains to be seen. While there has been significant interest in an ADSL2 MIB, so far no one has volunteered to work on it. This might be a consequence of the previous issue. The speed with which such a MIB can be developed is largely dependent on the amount of effort the volunteers are able to devote to the work, and on how quickly a consensus can be reached. Again, consensus is unlikely if the DSL Forum has not yet addressed the issue, in my opinion. This said, if there is a sudden outpouring of support for this work, convincing arguments that the goals are achievable, and a flood of volunteers, we can certainly attempt to get the charter expanded in the near future. The issue of expansion of the extension MIB transmission mode objects is problematic in lieu of a charter expansion, I would think. Hope this helps. Regards, Mike >From: Clay Sikes >To: Michael Sneed , ADSL MIB >CC: Kent Davidson >Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work >Date: Wed, 04 Jun 2003 11:39:43 -0400 > >Hi, > >I'm confused about what is being done to add MIB support for ADSL2 and >ADSL2+. I'm going to summarize some threads that I have seen or been a >part of with hope that someone will be able to figure out why I'm >confused and provide me with clear direction regarding MIB support for >ADSL2 and ADSL2+. > >1. Tuesday, 01 March 2003, I inquired about plans to update the >AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. >Greg Bathrick responded that same day agreeing that the >AdslTransmissionType needed to be extended along with other things. >Also, he felt that the 997.1 needed to become finalized before work >could begin. > >2. Wednesday, 30 April 2003, I learned from a Paradyne representative at >the ITU Q4 meeting, which took place two weeks prior, the G.997.1 >underwent a minor revision and was approved. > >3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about >the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to >ADSL2 and ADSL2+ support. Rajesh Abbi >responded and indicated that the DSL Forum has just beginning work on >capturing the requirements as well as a protocol independent object >model for managing the next generation ADSL technologies. > >4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when >something would be available and whether or not the AdslTransmissionType >TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and >ADSL2+ in the short term. I never got a response. > >5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working >group could start discussing an ADSL2 MIB. > >6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and >indicated that ADSL2 is not currently in the charter of the group. > > >Can anyone please tell me who is working on a MIB to support ADSL2 and >ADSL2+? > >If someone is working this issue, is there some estimate as to when the >MIB would be available? > >If this working group is not going to support MIBs for ADSL2 and ADSL2+, >what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, >and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? > >Will they be deprecated? > > >As you can see, I'm really confused. Any help will be greatly >appreciated. > >Thanks!! >Clay Sikes >Paradyne Corp. > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www1.ietf.org/mailman/listinfo/adslmib _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 13:09: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 NAA02062 for ; Wed, 4 Jun 2003 13:09:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54H9Q703076 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 13:09: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 h54H9QB03073 for ; Wed, 4 Jun 2003 13:09:26 -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 NAA02047 for ; Wed, 4 Jun 2003 13:09:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbjY-0005np-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 13:07:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NbjY-0005nm-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 13:07: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 h54H97B03058; Wed, 4 Jun 2003 13:09: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 h54H8sB03030 for ; Wed, 4 Jun 2003 13:08: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 NAA02015 for ; Wed, 4 Jun 2003 13:08:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nbj3-0005nb-00 for adslmib@ietf.org; Wed, 04 Jun 2003 13:07:01 -0400 Received: from services.paradyne.com ([135.90.22.16] helo=pigeon.is.paradyne.com) by ietf-mx with esmtp (Exim 4.12) id 19Nbj2-0005nK-00 for adslmib@ietf.org; Wed, 04 Jun 2003 13:07:00 -0400 Received: from paradyne.com ([135.26.21.26]) by pigeon.is.paradyne.com (Netscape Messaging Server 4.15) with ESMTP id HFYVLM00.DDX; Wed, 4 Jun 2003 13:08:10 -0400 Message-ID: <3EDE2784.DCAB13E8@paradyne.com> Date: Wed, 04 Jun 2003 13:08:20 -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: Michael Sneed CC: adslmib@ietf.org, davidson@paradyne.com Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h54H8sB03031 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 Michael, Thanks for your prompt reply. One last question, is this group responsible for the ADSL-LINE-EXT-MIB, or was that done somewhere else and if so where? Please keep me in mind as a potential volunteer for future work. I would welcome an opportunity to pitch in and help. Thanks, Clay Michael Sneed wrote: > Hi Clay, > > I can only address your question partially. The IETF is not currently > working on ADSL2 or ADSL2+ MIBs (or modification/expansion of existing MIBs > to support ADSL2/ADSL2+), and the adslmib WG is not currently chartered to > do such work. It is certainly possible to undertake an expansion of the WG > charter; this would require the approval of the ADs and the IESG, which > presupposes the following: > > 1) consensus that such MIBs are useful > 2) consensus that the WG can complete the task in a timely manner > 3) sufficient volunteers to assure the work will get done > > I think 1) is likely not a problem. > > 2) is more of an issue, because adslmib has tried to work with significant > input from the DSL Forum. If the DSL Forum has not yet begun work on the > management of ADSL2, then it may be premature to undertake such work in the > IETF. > > 3) remains to be seen. While there has been significant interest in an > ADSL2 MIB, so far no one has volunteered to work on it. This might be a > consequence of the previous issue. > > The speed with which such a MIB can be developed is largely dependent on the > amount of effort the volunteers are able to devote to the work, and on how > quickly a consensus can be reached. Again, consensus is unlikely if the DSL > Forum has not yet addressed the issue, in my opinion. > > This said, if there is a sudden outpouring of support for this work, > convincing arguments that the goals are achievable, and a flood of > volunteers, we can certainly attempt to get the charter expanded in the > near future. > > The issue of expansion of the extension MIB transmission mode objects is > problematic in lieu of a charter expansion, I would think. > > Hope this helps. > > Regards, > > Mike > > >From: Clay Sikes > >To: Michael Sneed , ADSL MIB > >CC: Kent Davidson > >Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work > >Date: Wed, 04 Jun 2003 11:39:43 -0400 > > > >Hi, > > > >I'm confused about what is being done to add MIB support for ADSL2 and > >ADSL2+. I'm going to summarize some threads that I have seen or been a > >part of with hope that someone will be able to figure out why I'm > >confused and provide me with clear direction regarding MIB support for > >ADSL2 and ADSL2+. > > > >1. Tuesday, 01 March 2003, I inquired about plans to update the > >AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. > >Greg Bathrick responded that same day agreeing that the > >AdslTransmissionType needed to be extended along with other things. > >Also, he felt that the 997.1 needed to become finalized before work > >could begin. > > > >2. Wednesday, 30 April 2003, I learned from a Paradyne representative at > >the ITU Q4 meeting, which took place two weeks prior, the G.997.1 > >underwent a minor revision and was approved. > > > >3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about > >the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to > >ADSL2 and ADSL2+ support. Rajesh Abbi > >responded and indicated that the DSL Forum has just beginning work on > >capturing the requirements as well as a protocol independent object > >model for managing the next generation ADSL technologies. > > > >4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when > >something would be available and whether or not the AdslTransmissionType > >TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and > >ADSL2+ in the short term. I never got a response. > > > >5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working > >group could start discussing an ADSL2 MIB. > > > >6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and > >indicated that ADSL2 is not currently in the charter of the group. > > > > > >Can anyone please tell me who is working on a MIB to support ADSL2 and > >ADSL2+? > > > >If someone is working this issue, is there some estimate as to when the > >MIB would be available? > > > >If this working group is not going to support MIBs for ADSL2 and ADSL2+, > >what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, > >and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? > > > >Will they be deprecated? > > > > > >As you can see, I'm really confused. Any help will be greatly > >appreciated. > > > >Thanks!! > >Clay Sikes > >Paradyne Corp. > > > >_______________________________________________ > >Adslmib mailing list > >Adslmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/adslmib > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 14:05:02 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 OAA03909 for ; Wed, 4 Jun 2003 14:05:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54I4aB06206 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 14:04:36 -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 h54I4aB06203 for ; Wed, 4 Jun 2003 14:04:36 -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 OAA03891 for ; Wed, 4 Jun 2003 14:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ncaw-0006HQ-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 14:02:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ncav-0006HN-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 14:02: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 h54I4DB06187; Wed, 4 Jun 2003 14:04:13 -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 h54I3mB06147 for ; Wed, 4 Jun 2003 14:03:48 -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 OAA03878 for ; Wed, 4 Jun 2003 14:03:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nca9-0006H9-00 for adslmib@ietf.org; Wed, 04 Jun 2003 14:01:53 -0400 Received: from law14-f56.law14.hotmail.com ([64.4.21.56] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19Nca8-0006Gc-00 for adslmib@ietf.org; Wed, 04 Jun 2003 14:01:52 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jun 2003 11:03:12 -0700 Received: from 66.152.60.98 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 04 Jun 2003 18:03:12 GMT X-Originating-IP: [66.152.60.98] X-Originating-Email: [sneedmike@hotmail.com] From: "Michael Sneed" To: csikes@paradyne.com Cc: adslmib@ietf.org, davidson@paradyne.com Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work Date: Wed, 04 Jun 2003 14:03:12 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2003 18:03:12.0937 (UTC) FILETIME=[9097E990:01C32AC3] 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: , Yes, it is a product of this working group. Thanks for the offer, and I will. That will certainly help. Regards, Mike >From: Clay Sikes >To: Michael Sneed >CC: adslmib@ietf.org, davidson@paradyne.com >Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work >Date: Wed, 04 Jun 2003 13:08:20 -0400 > >Michael, > >Thanks for your prompt reply. > >One last question, is this group responsible for the ADSL-LINE-EXT-MIB, or >was >that done somewhere else and if so where? > >Please keep me in mind as a potential volunteer for future work. I would >welcome an opportunity to pitch in and help. > >Thanks, >Clay > > >Michael Sneed wrote: > > > Hi Clay, > > > > I can only address your question partially. The IETF is not currently > > working on ADSL2 or ADSL2+ MIBs (or modification/expansion of existing >MIBs > > to support ADSL2/ADSL2+), and the adslmib WG is not currently chartered >to > > do such work. It is certainly possible to undertake an expansion of the >WG > > charter; this would require the approval of the ADs and the IESG, which > > presupposes the following: > > > > 1) consensus that such MIBs are useful > > 2) consensus that the WG can complete the task in a timely manner > > 3) sufficient volunteers to assure the work will get done > > > > I think 1) is likely not a problem. > > > > 2) is more of an issue, because adslmib has tried to work with >significant > > input from the DSL Forum. If the DSL Forum has not yet begun work on >the > > management of ADSL2, then it may be premature to undertake such work in >the > > IETF. > > > > 3) remains to be seen. While there has been significant interest in an > > ADSL2 MIB, so far no one has volunteered to work on it. This might be a > > consequence of the previous issue. > > > > The speed with which such a MIB can be developed is largely dependent on >the > > amount of effort the volunteers are able to devote to the work, and on >how > > quickly a consensus can be reached. Again, consensus is unlikely if the >DSL > > Forum has not yet addressed the issue, in my opinion. > > > > This said, if there is a sudden outpouring of support for this work, > > convincing arguments that the goals are achievable, and a flood of > > volunteers, we can certainly attempt to get the charter expanded in the > > near future. > > > > The issue of expansion of the extension MIB transmission mode objects is > > problematic in lieu of a charter expansion, I would think. > > > > Hope this helps. > > > > Regards, > > > > Mike > > > > >From: Clay Sikes > > >To: Michael Sneed , ADSL MIB > > >CC: Kent Davidson > > >Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work > > >Date: Wed, 04 Jun 2003 11:39:43 -0400 > > > > > >Hi, > > > > > >I'm confused about what is being done to add MIB support for ADSL2 and > > >ADSL2+. I'm going to summarize some threads that I have seen or been a > > >part of with hope that someone will be able to figure out why I'm > > >confused and provide me with clear direction regarding MIB support for > > >ADSL2 and ADSL2+. > > > > > >1. Tuesday, 01 March 2003, I inquired about plans to update the > > >AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. > > >Greg Bathrick responded that same day agreeing that the > > >AdslTransmissionType needed to be extended along with other things. > > >Also, he felt that the 997.1 needed to become finalized before work > > >could begin. > > > > > >2. Wednesday, 30 April 2003, I learned from a Paradyne representative >at > > >the ITU Q4 meeting, which took place two weeks prior, the G.997.1 > > >underwent a minor revision and was approved. > > > > > >3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about > > >the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to > > >ADSL2 and ADSL2+ support. Rajesh Abbi > > >responded and indicated that the DSL Forum has just beginning work on > > >capturing the requirements as well as a protocol independent object > > >model for managing the next generation ADSL technologies. > > > > > >4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when > > >something would be available and whether or not the >AdslTransmissionType > > >TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and > > >ADSL2+ in the short term. I never got a response. > > > > > >5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working > > >group could start discussing an ADSL2 MIB. > > > > > >6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and > > >indicated that ADSL2 is not currently in the charter of the group. > > > > > > > > >Can anyone please tell me who is working on a MIB to support ADSL2 and > > >ADSL2+? > > > > > >If someone is working this issue, is there some estimate as to when the > > >MIB would be available? > > > > > >If this working group is not going to support MIBs for ADSL2 and >ADSL2+, > > >what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, > > >and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? > > > > > >Will they be deprecated? > > > > > > > > >As you can see, I'm really confused. Any help will be greatly > > >appreciated. > > > > > >Thanks!! > > >Clay Sikes > > >Paradyne Corp. > > > > > >_______________________________________________ > > >Adslmib mailing list > > >Adslmib@ietf.org > > >https://www1.ietf.org/mailman/listinfo/adslmib > > > > _________________________________________________________________ > > MSN 8 with e-mail virus protection service: 2 months FREE* > > http://join.msn.com/?page=features/virus >_______________________________________________ >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 Wed Jun 4 16:01: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 QAA10382 for ; Wed, 4 Jun 2003 16:01:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54K1NX15734 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 16:01: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 h54K1MB15731 for ; Wed, 4 Jun 2003 16:01: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 QAA10370 for ; Wed, 4 Jun 2003 16:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NePy-0007ga-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 15:59:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NePx-0007gX-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 15:59:29 -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 h54K1DB15722; Wed, 4 Jun 2003 16:01: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 h54K0LB15666 for ; Wed, 4 Jun 2003 16:00: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 QAA10342 for ; Wed, 4 Jun 2003 16:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NeOz-0007gC-00 for adslmib@ietf.org; Wed, 04 Jun 2003 15:58:29 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19NeOz-0007g9-00 for adslmib@ietf.org; Wed, 04 Jun 2003 15:58:29 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h54K0IGI594098 for ; Wed, 4 Jun 2003 15:00:18 -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, 04 Jun 2003 15:00:13 -0500 Subject: Re: [Adslmib] VDSL Line Extension MIB From: Bob Ray Reply-To: rray@pesa.com To: Flemisch Felix Cc: "'adslmib@ietf.org'" , "'randy_presuhn@mindspring.com'" , "'Moti.Morgenstern@ecitele.com'" , "'Menachem.Dodge@infineon.com'" In-Reply-To: <99522F0FD7EFD611A47D0002A58EDAB7C8AE79@mchh2a8e.mchh.siemens.de> References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE79@mchh2a8e.mchh.siemens.de> Content-Type: text/plain Message-Id: <1054756812.2832.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Jun 2003 15:00:12 -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 Mon, 2003-06-02 at 06:37, Flemisch Felix wrote: > I then formalize the MUST requirement for VDSL-LINE-EXT-MIB, at > least regarding LCS line configuration profile tables, through the > introduction of the new parameter "vdslLineConfProfileLCSExt" > within vdslLineEntry. It identifies the row (maybe none) in the > LCS Line Configuration Profile Extension Table, which applies > for this VDSL line and its channels (if applicable). If there is to be a LCS extension MIB module, then the table(s) within it should use vdslLineConfProfileName as an index instead of what you propose. This is functionally equivalent to your proposed object, but does not require an object-from-a-MIB-to-be-written-at-a-later-date. Further, this would be in keeping with the LCS tables in earlier revisions of the VDSL Line MIB. Regards, Bob Ray PESA Switching Systems _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 16:18:21 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 QAA10933 for ; Wed, 4 Jun 2003 16:18:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54KHsU17220 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 16:17:54 -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 h54KHsB17217 for ; Wed, 4 Jun 2003 16:17: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 QAA10915 for ; Wed, 4 Jun 2003 16:17:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nefx-00001D-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 16:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nefw-00001A-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 16:16:00 -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 h54KHVB17206; Wed, 4 Jun 2003 16:17:31 -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 h54KGJB17145 for ; Wed, 4 Jun 2003 16:16:19 -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 QAA10897 for ; Wed, 4 Jun 2003 16:16:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NeeQ-00000e-00 for adslmib@ietf.org; Wed, 04 Jun 2003 16:14:26 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19NeeO-00000b-00 for adslmib@ietf.org; Wed, 04 Jun 2003 16:14:26 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h54KGCGI977159 for ; Wed, 4 Jun 2003 15:16:13 -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, 04 Jun 2003 15:16:09 -0500 Subject: Re: [Adslmib] VDSL Line Type Naming and Configuration From: Bob Ray Reply-To: rray@pesa.com To: Flemisch Felix Cc: "'adslmib@ietf.org'" , "'randy_presuhn@mindspring.com'" , "'Moti.Morgenstern@ecitele.com'" In-Reply-To: <99522F0FD7EFD611A47D0002A58EDAB7C8AE77@mchh2a8e.mchh.siemens.de> References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE77@mchh2a8e.mchh.siemens.de> Content-Type: text/plain Message-Id: <1054757768.2832.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Jun 2003 15:16:08 -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 Sun, 2003-06-01 at 05:28, Flemisch Felix wrote: > 1. Rename the enums of vdslLineType (within vdslLineEntry) so that > they refer to the "interleaved" channel instead of refering to > the "slow" channel (though this is in fact the same channel). Done. > So "slow" is a pessimistic point of view while "interleaved" > is an optimistic point of view. Life is too short to fight marketing guys :))) > 2. Introduce the new parameter "vdslLineConfLineType" within > vdslLineConfProfileEntry to enable the configuration of Done. The profile table is a far better place for this. More to come. -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 16:42: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 QAA11595 for ; Wed, 4 Jun 2003 16:42:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54KgId19040 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 16:42: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 h54KgIB19033 for ; Wed, 4 Jun 2003 16:42:18 -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 QAA11574 for ; Wed, 4 Jun 2003 16:42:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nf3Z-00009i-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 16:40:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nf3Y-00009f-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 16:40:24 -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 h54KgAB19018; Wed, 4 Jun 2003 16:42: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 h54KBuB16970 for ; Wed, 4 Jun 2003 16:11:56 -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 QAA10777 for ; Wed, 4 Jun 2003 16:11:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NeaB-0007mB-00 for adslmib@ietf.org; Wed, 04 Jun 2003 16:10:03 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19NeaA-0007ly-00 for adslmib@ietf.org; Wed, 04 Jun 2003 16:10:02 -0400 Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h54KBEBJ025297; Wed, 4 Jun 2003 22:11:14 +0200 (MEST) Received: from alcatel.be ([138.203.141.13]) by bemail01.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003060422110955:7539 ; Wed, 4 Jun 2003 22:11:09 +0200 Message-ID: <3EDE524C.1429BE4F@alcatel.be> Date: Wed, 04 Jun 2003 21:10:53 +0100 From: frank.van_der_putten@alcatel.be X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Sneed Cc: csikes@paradyne.com, adslmib@ietf.org, davidson@paradyne.com Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work References: X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/04/2003 22:11:10, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/04/2003 22:11:14, Serialize complete at 06/04/2003 22:11:14 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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 Michael, Let me point out that the G.997.1 update in ITU SG15 is approved now. It contains all the MIB elements needed for ADSL, ADSL2 and ADSL2plus. The DSL Forum has addressed the ADSL2(plus) MIB at the last meeting and sourced liaison to IETF. The DSL Forum is also progressing on interoperability testing of ADSL2. This implies system level MIBs will be needed for deployment soon. I am puzzled why you think there is not sufficient interest to take the work into IETF to "compile" G.997.1 into a useful SNMP MIB (over the next half to full year?) Regards, Frank Van der Putten ITU-T SG15/Q4 ADSL2(PLUS) editor DSLForum Board Member Michael Sneed wrote: > Hi Clay, > > I can only address your question partially. The IETF is not currently > working on ADSL2 or ADSL2+ MIBs (or modification/expansion of existing MIBs > to support ADSL2/ADSL2+), and the adslmib WG is not currently chartered to > do such work. It is certainly possible to undertake an expansion of the WG > charter; this would require the approval of the ADs and the IESG, which > presupposes the following: > > 1) consensus that such MIBs are useful > 2) consensus that the WG can complete the task in a timely manner > 3) sufficient volunteers to assure the work will get done > > I think 1) is likely not a problem. > > 2) is more of an issue, because adslmib has tried to work with significant > input from the DSL Forum. If the DSL Forum has not yet begun work on the > management of ADSL2, then it may be premature to undertake such work in the > IETF. > > 3) remains to be seen. While there has been significant interest in an > ADSL2 MIB, so far no one has volunteered to work on it. This might be a > consequence of the previous issue. > > The speed with which such a MIB can be developed is largely dependent on the > amount of effort the volunteers are able to devote to the work, and on how > quickly a consensus can be reached. Again, consensus is unlikely if the DSL > Forum has not yet addressed the issue, in my opinion. > > This said, if there is a sudden outpouring of support for this work, > convincing arguments that the goals are achievable, and a flood of > volunteers, we can certainly attempt to get the charter expanded in the > near future. > > The issue of expansion of the extension MIB transmission mode objects is > problematic in lieu of a charter expansion, I would think. > > Hope this helps. > > Regards, > > Mike > > >From: Clay Sikes > >To: Michael Sneed , ADSL MIB > >CC: Kent Davidson > >Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work > >Date: Wed, 04 Jun 2003 11:39:43 -0400 > > > >Hi, > > > >I'm confused about what is being done to add MIB support for ADSL2 and > >ADSL2+. I'm going to summarize some threads that I have seen or been a > >part of with hope that someone will be able to figure out why I'm > >confused and provide me with clear direction regarding MIB support for > >ADSL2 and ADSL2+. > > > >1. Tuesday, 01 March 2003, I inquired about plans to update the > >AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. > >Greg Bathrick responded that same day agreeing that the > >AdslTransmissionType needed to be extended along with other things. > >Also, he felt that the 997.1 needed to become finalized before work > >could begin. > > > >2. Wednesday, 30 April 2003, I learned from a Paradyne representative at > >the ITU Q4 meeting, which took place two weeks prior, the G.997.1 > >underwent a minor revision and was approved. > > > >3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about > >the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to > >ADSL2 and ADSL2+ support. Rajesh Abbi > >responded and indicated that the DSL Forum has just beginning work on > >capturing the requirements as well as a protocol independent object > >model for managing the next generation ADSL technologies. > > > >4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when > >something would be available and whether or not the AdslTransmissionType > >TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and > >ADSL2+ in the short term. I never got a response. > > > >5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working > >group could start discussing an ADSL2 MIB. > > > >6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and > >indicated that ADSL2 is not currently in the charter of the group. > > > > > >Can anyone please tell me who is working on a MIB to support ADSL2 and > >ADSL2+? > > > >If someone is working this issue, is there some estimate as to when the > >MIB would be available? > > > >If this working group is not going to support MIBs for ADSL2 and ADSL2+, > >what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, > >and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? > > > >Will they be deprecated? > > > > > >As you can see, I'm really confused. Any help will be greatly > >appreciated. > > > >Thanks!! > >Clay Sikes > >Paradyne Corp. > > > >_______________________________________________ > >Adslmib mailing list > >Adslmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/adslmib > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www1.ietf.org/mailman/listinfo/adslmib -- Frank Van der Putten, Alcatel Fellow Veldkant 7, B-2550 Kontich, Belgium Tel. +32 3 4503032 Fax. +32 3 4503570 Email frank.van_der_putten@alcatel.be _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 16:42: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 QAA11596 for ; Wed, 4 Jun 2003 16:42:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54KgIO19036 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 16:42: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 h54KgIB19031 for ; Wed, 4 Jun 2003 16:42:18 -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 QAA11577 for ; Wed, 4 Jun 2003 16:42:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nf3Z-00009m-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 16:40:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nf3Y-00009j-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 16:40:24 -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 h54Kg9B19000; Wed, 4 Jun 2003 16:42: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 h54Kf4B18961 for ; Wed, 4 Jun 2003 16:41:04 -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 QAA11532 for ; Wed, 4 Jun 2003 16:40:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nf2M-00008w-00 for adslmib@ietf.org; Wed, 04 Jun 2003 16:39:11 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19Nf2M-00008t-00 for adslmib@ietf.org; Wed, 04 Jun 2003 16:39:10 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h54Kf0GI1043810 for ; Wed, 4 Jun 2003 15:41:00 -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, 04 Jun 2003 15:40:58 -0500 Subject: Re: [Adslmib] Re: WG Last Call: draft-ietf-adslmib-vdsl-09.txt From: Bob Ray Reply-To: rray@pesa.com To: Randy Presuhn Cc: adslmib mail list In-Reply-To: <005a01c32733$fdbc5760$7f1afea9@oemcomputer> References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE74@mchh2a8e.mchh.siemens.de> <005a01c32733$fdbc5760$7f1afea9@oemcomputer> Content-Type: text/plain Message-Id: <1054759258.2832.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 04 Jun 2003 15:40:58 -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 Sat, 2003-05-31 at 00:17, Randy Presuhn wrote: > 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. Done. > Suggest putting the country on a separate line, > as one would do when addressing mail. Done. > < 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." Moot as I've removed the revisions. > 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. Done. > 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). Done. And I think this is the first email I've ever received containing the word 'appositive'. > 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". Done. > Based on reaction to previous, suggest replacing > ".." with " to " Done. > < "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? Left as is. > Also, if you're going to use the acronym "HAM", you should > provide an expansion. Added "Handheld Amateur Radio" in several DESCRIPTIONs. I'll leave it to the historians to battle over whether this is the one true meaning of those early HAM-fisted Morse code operators :) > 2824c2984 > < UNITS "kHz" > --- > > UNITS "Hz" > > Is this change intentional? Please. I've left this at kHz. -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Wed Jun 4 22:42:52 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 WAA23074 for ; Wed, 4 Jun 2003 22:42:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h552gSB11241 for adslmib-archive@odin.ietf.org; Wed, 4 Jun 2003 22:42:28 -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 h552gRB11238 for ; Wed, 4 Jun 2003 22:42:27 -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 WAA23031 for ; Wed, 4 Jun 2003 22:42:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nkg3-0002PW-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 22:40:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nkg2-0002PT-00 for adslmib-web-archive@ietf.org; Wed, 04 Jun 2003 22:40:30 -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 h552gJB11201; Wed, 4 Jun 2003 22:42:19 -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 h552f2B11148 for ; Wed, 4 Jun 2003 22:41: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 WAA22999 for ; Wed, 4 Jun 2003 22:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nkeg-0002Os-00 for adslmib@ietf.org; Wed, 04 Jun 2003 22:39:06 -0400 Received: from ns2.nec.com.au ([147.76.180.2]) by ietf-mx with esmtp (Exim 4.12) id 19Nkee-0002Oa-00 for adslmib@ietf.org; Wed, 04 Jun 2003 22:39:04 -0400 Received: from smtp2.nec.com.au (smtp2.nec.com.au [147.76.128.19]) by ns2.nec.com.au (8.11.6/8.11.6) with ESMTP id h552dEt21233; Thu, 5 Jun 2003 12:39:14 +1000 Received: from warp.ssd.neca.nec.com.au (localhost.localdomain [127.0.0.1]) by smtp2.nec.com.au (8.11.6/8.11.6) with ESMTP id h553eoH28052; Thu, 5 Jun 2003 13:40:50 +1000 Received: from miracle (miracle.ssd.neca.nec.com.au [147.76.48.132]) by warp.ssd.neca.nec.com.au (8.9.3/8.9.3) with SMTP id MAA07474; Thu, 5 Jun 2003 12:39:12 +1000 (EST) From: "Umberto Bonollo" To: , "'Michael Sneed'" , Cc: , , Subject: RE: [Adslmib] Confused about ADSL2 and ADSL2+ Work Date: Thu, 5 Jun 2003 12:39:10 +1000 Message-ID: <000301c32b0b$a5807640$84304c93@ssd.neca.nec.com.au> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3EDE524C.1429BE4F@alcatel.be> 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 Mike, I can only echo and agree with Frank's comments on ADSL2. I'd be happy to assist Bob Ray, Rajesh, Frank et al on getting an IETF ADSL2 MIB draft going. Some interesting issues will be the standing of RFC 2662 for ADSL2 (there are solutions that depend on approach taken) and based on an analysis by Rajesh et al at DSLF and on the draft G.997.1, the likelihood that channel profiles will be introduced for ADSL2 given the [up to] 4 bearer channels that could exist. Umberto Bonollo (umberto.bonollo@nec.com.au) NEC Australia -----Original Message----- From: adslmib-admin@ietf.org [mailto:adslmib-admin@ietf.org]On Behalf Of frank.van_der_putten@alcatel.be Sent: Thursday, 5 June 2003 6:11 To: Michael Sneed Cc: csikes@paradyne.com; adslmib@ietf.org; davidson@paradyne.com Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work Michael, Let me point out that the G.997.1 update in ITU SG15 is approved now. It contains all the MIB elements needed for ADSL, ADSL2 and ADSL2plus. The DSL Forum has addressed the ADSL2(plus) MIB at the last meeting and sourced liaison to IETF. The DSL Forum is also progressing on interoperability testing of ADSL2. This implies system level MIBs will be needed for deployment soon. I am puzzled why you think there is not sufficient interest to take the work into IETF to "compile" G.997.1 into a useful SNMP MIB (over the next half to full year?) Regards, Frank Van der Putten ITU-T SG15/Q4 ADSL2(PLUS) editor DSLForum Board Member Michael Sneed wrote: > Hi Clay, > > I can only address your question partially. The IETF is not currently > working on ADSL2 or ADSL2+ MIBs (or modification/expansion of existing MIBs > to support ADSL2/ADSL2+), and the adslmib WG is not currently chartered to > do such work. It is certainly possible to undertake an expansion of the WG > charter; this would require the approval of the ADs and the IESG, which > presupposes the following: > > 1) consensus that such MIBs are useful > 2) consensus that the WG can complete the task in a timely manner > 3) sufficient volunteers to assure the work will get done > > I think 1) is likely not a problem. > > 2) is more of an issue, because adslmib has tried to work with significant > input from the DSL Forum. If the DSL Forum has not yet begun work on the > management of ADSL2, then it may be premature to undertake such work in the > IETF. > > 3) remains to be seen. While there has been significant interest in an > ADSL2 MIB, so far no one has volunteered to work on it. This might be a > consequence of the previous issue. > > The speed with which such a MIB can be developed is largely dependent on the > amount of effort the volunteers are able to devote to the work, and on how > quickly a consensus can be reached. Again, consensus is unlikely if the DSL > Forum has not yet addressed the issue, in my opinion. > > This said, if there is a sudden outpouring of support for this work, > convincing arguments that the goals are achievable, and a flood of > volunteers, we can certainly attempt to get the charter expanded in the > near future. > > The issue of expansion of the extension MIB transmission mode objects is > problematic in lieu of a charter expansion, I would think. > > Hope this helps. > > Regards, > > Mike > > >From: Clay Sikes > >To: Michael Sneed , ADSL MIB > >CC: Kent Davidson > >Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work > >Date: Wed, 04 Jun 2003 11:39:43 -0400 > > > >Hi, > > > >I'm confused about what is being done to add MIB support for ADSL2 and > >ADSL2+. I'm going to summarize some threads that I have seen or been a > >part of with hope that someone will be able to figure out why I'm > >confused and provide me with clear direction regarding MIB support for > >ADSL2 and ADSL2+. > > > >1. Tuesday, 01 March 2003, I inquired about plans to update the > >AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. > >Greg Bathrick responded that same day agreeing that the > >AdslTransmissionType needed to be extended along with other things. > >Also, he felt that the 997.1 needed to become finalized before work > >could begin. > > > >2. Wednesday, 30 April 2003, I learned from a Paradyne representative at > >the ITU Q4 meeting, which took place two weeks prior, the G.997.1 > >underwent a minor revision and was approved. > > > >3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about > >the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to > >ADSL2 and ADSL2+ support. Rajesh Abbi > >responded and indicated that the DSL Forum has just beginning work on > >capturing the requirements as well as a protocol independent object > >model for managing the next generation ADSL technologies. > > > >4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when > >something would be available and whether or not the AdslTransmissionType > >TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and > >ADSL2+ in the short term. I never got a response. > > > >5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working > >group could start discussing an ADSL2 MIB. > > > >6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and > >indicated that ADSL2 is not currently in the charter of the group. > > > > > >Can anyone please tell me who is working on a MIB to support ADSL2 and > >ADSL2+? > > > >If someone is working this issue, is there some estimate as to when the > >MIB would be available? > > > >If this working group is not going to support MIBs for ADSL2 and ADSL2+, > >what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, > >and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? > > > >Will they be deprecated? > > > > > >As you can see, I'm really confused. Any help will be greatly > >appreciated. > > > >Thanks!! > >Clay Sikes > >Paradyne Corp. > > > >_______________________________________________ > >Adslmib mailing list > >Adslmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/adslmib > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www1.ietf.org/mailman/listinfo/adslmib -- Frank Van der Putten, Alcatel Fellow Veldkant 7, B-2550 Kontich, Belgium Tel. +32 3 4503032 Fax. +32 3 4503570 Email frank.van_der_putten@alcatel.be _______________________________________________ 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 Jun 5 09:25: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 JAA24070 for ; Thu, 5 Jun 2003 09:25:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55DPKr03542 for adslmib-archive@odin.ietf.org; Thu, 5 Jun 2003 09:25: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 h55DPKB03539 for ; Thu, 5 Jun 2003 09:25: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 JAA24047 for ; Thu, 5 Jun 2003 09:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NuiC-0006me-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 09:23:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NuiC-0006mb-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 09:23:24 -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 h55DPCB03531; Thu, 5 Jun 2003 09:25: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 h55DOgB03475 for ; Thu, 5 Jun 2003 09:24:42 -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 JAA24033 for ; Thu, 5 Jun 2003 09:24:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nuha-0006mC-00 for adslmib@ietf.org; Thu, 05 Jun 2003 09:22:46 -0400 Received: from hostr490.alcatel.com ([143.209.4.144] helo=aurmsd.aur.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 19Nuha-0006lz-00 for adslmib@ietf.org; Thu, 05 Jun 2003 09:22:46 -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 h55DO0Nf006288; Thu, 5 Jun 2003 09:24:00 -0400 (EDT) Message-ID: <3EDF4470.E143C377@alcatel.com> Date: Thu, 05 Jun 2003 09:24:00 -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: "'Michael Sneed'" CC: Umberto Bonollo , frank.van_der_putten@alcatel.be, rray@pesa.com, csikes@paradyne.com, adslmib@ietf.org, davidson@paradyne.com, Gregory Bathrick Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work References: <000301c32b0b$a5807640$84304c93@ssd.neca.nec.com.au> 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 Mike, The DSL Forum started work on ADSL2/... only in the last (May) meeting. A new working-text has been started. At that time it was premature to communicate much to the IETF - since we didn't even have the first draft of the working-text. The intent is to offer the working-text as a basis for the MIB work in IETF. In any case, looks like at this time there is already sufficient interest in the IETF working-group to amend the group charter. The actual MIB work will of course have to wait for the DSL Forum input. I encourage Umberto, Clay, Bob and others who are interested in ADSL2 MIB to participate in the DSL Forum work in order to expedite this process. Regards, Rajesh Umberto Bonollo wrote: > Hi Mike, > I can only echo and agree with Frank's comments on ADSL2. > I'd be happy to assist Bob Ray, Rajesh, Frank et al on getting > an IETF ADSL2 MIB draft going. > Some interesting issues will be > the standing of RFC 2662 for ADSL2 (there are solutions that depend on > approach taken) > and based on an analysis by Rajesh et al at DSLF and on > the draft G.997.1, the likelihood that > channel profiles will be introduced for ADSL2 given the > [up to] 4 bearer channels that could exist. > > Umberto Bonollo (umberto.bonollo@nec.com.au) > NEC Australia > > -----Original Message----- > From: adslmib-admin@ietf.org [mailto:adslmib-admin@ietf.org]On Behalf Of > frank.van_der_putten@alcatel.be > Sent: Thursday, 5 June 2003 6:11 > To: Michael Sneed > Cc: csikes@paradyne.com; adslmib@ietf.org; davidson@paradyne.com > Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work > > Michael, > Let me point out that the G.997.1 update in ITU SG15 is approved now. > It contains all the MIB elements needed for ADSL, ADSL2 and ADSL2plus. > The DSL Forum has addressed the ADSL2(plus) MIB at the last meeting > and sourced liaison to IETF. > The DSL Forum is also progressing on interoperability testing of ADSL2. > This implies system level MIBs will be needed for deployment soon. > I am puzzled why you think there is not sufficient interest to take the work > into IETF > to "compile" G.997.1 into a useful SNMP MIB (over the next half to full > year?) > Regards, > Frank Van der Putten > ITU-T SG15/Q4 ADSL2(PLUS) editor > DSLForum Board Member > > Michael Sneed wrote: > > > Hi Clay, > > > > I can only address your question partially. The IETF is not currently > > working on ADSL2 or ADSL2+ MIBs (or modification/expansion of existing > MIBs > > to support ADSL2/ADSL2+), and the adslmib WG is not currently chartered to > > do such work. It is certainly possible to undertake an expansion of the WG > > charter; this would require the approval of the ADs and the IESG, which > > presupposes the following: > > > > 1) consensus that such MIBs are useful > > 2) consensus that the WG can complete the task in a timely manner > > 3) sufficient volunteers to assure the work will get done > > > > I think 1) is likely not a problem. > > > > 2) is more of an issue, because adslmib has tried to work with significant > > input from the DSL Forum. If the DSL Forum has not yet begun work on the > > management of ADSL2, then it may be premature to undertake such work in > the > > IETF. > > > > 3) remains to be seen. While there has been significant interest in an > > ADSL2 MIB, so far no one has volunteered to work on it. This might be a > > consequence of the previous issue. > > > > The speed with which such a MIB can be developed is largely dependent on > the > > amount of effort the volunteers are able to devote to the work, and on how > > quickly a consensus can be reached. Again, consensus is unlikely if the > DSL > > Forum has not yet addressed the issue, in my opinion. > > > > This said, if there is a sudden outpouring of support for this work, > > convincing arguments that the goals are achievable, and a flood of > > volunteers, we can certainly attempt to get the charter expanded in the > > near future. > > > > The issue of expansion of the extension MIB transmission mode objects is > > problematic in lieu of a charter expansion, I would think. > > > > Hope this helps. > > > > Regards, > > > > Mike > > > > >From: Clay Sikes > > >To: Michael Sneed , ADSL MIB > > >CC: Kent Davidson > > >Subject: [Adslmib] Confused about ADSL2 and ADSL2+ Work > > >Date: Wed, 04 Jun 2003 11:39:43 -0400 > > > > > >Hi, > > > > > >I'm confused about what is being done to add MIB support for ADSL2 and > > >ADSL2+. I'm going to summarize some threads that I have seen or been a > > >part of with hope that someone will be able to figure out why I'm > > >confused and provide me with clear direction regarding MIB support for > > >ADSL2 and ADSL2+. > > > > > >1. Tuesday, 01 March 2003, I inquired about plans to update the > > >AdslTransmissionType TC to support bits defined in the ITU 's G.997.1. > > >Greg Bathrick responded that same day agreeing that the > > >AdslTransmissionType needed to be extended along with other things. > > >Also, he felt that the 997.1 needed to become finalized before work > > >could begin. > > > > > >2. Wednesday, 30 April 2003, I learned from a Paradyne representative at > > >the ITU Q4 meeting, which took place two weeks prior, the G.997.1 > > >underwent a minor revision and was approved. > > > > > >3. Thursday, 08 May 2003, I emailed the adslmib group inquiring about > > >the status of the ADSL-LINE-MIB and ADSL-LINE-EXT-MIB with respect to > > >ADSL2 and ADSL2+ support. Rajesh Abbi > > >responded and indicated that the DSL Forum has just beginning work on > > >capturing the requirements as well as a protocol independent object > > >model for managing the next generation ADSL technologies. > > > > > >4. Thursday, 08 May 2003, I responded to Rajesh and inquired as to when > > >something would be available and whether or not the AdslTransmissionType > > >TC in the ADSL-LINE-EXT-MIB should be extended to support ADSL2 and > > >ADSL2+ in the short term. I never got a response. > > > > > >5. On Wednesday, 21 May 2003, Morti Morgenstern, asked if the working > > >group could start discussing an ADSL2 MIB. > > > > > >6. On Wednesday, 21 May 2003, Michael Sneed, responded to Morti and > > >indicated that ADSL2 is not currently in the charter of the group. > > > > > > > > >Can anyone please tell me who is working on a MIB to support ADSL2 and > > >ADSL2+? > > > > > >If someone is working this issue, is there some estimate as to when the > > >MIB would be available? > > > > > >If this working group is not going to support MIBs for ADSL2 and ADSL2+, > > >what will happen to the adslLineTransAtucCap, adslLineTransAtucConfig, > > >and adslLineTransAutcActual MIB objects in the ADSL-LINE-EXT_MIB? > > > > > >Will they be deprecated? > > > > > > > > >As you can see, I'm really confused. Any help will be greatly > > >appreciated. > > > > > >Thanks!! > > >Clay Sikes > > >Paradyne Corp. > > > > > >_______________________________________________ > > >Adslmib mailing list > > >Adslmib@ietf.org > > >https://www1.ietf.org/mailman/listinfo/adslmib > > > > _________________________________________________________________ > > MSN 8 with e-mail virus protection service: 2 months FREE* > > http://join.msn.com/?page=features/virus > > > > _______________________________________________ > > Adslmib mailing list > > Adslmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/adslmib > > -- > Frank Van der Putten, Alcatel Fellow > Veldkant 7, B-2550 Kontich, Belgium > Tel. +32 3 4503032 Fax. +32 3 4503570 > Email frank.van_der_putten@alcatel.be > > _______________________________________________ > 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 _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu Jun 5 11:21:56 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 LAA02184 for ; Thu, 5 Jun 2003 11:21:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FLSM13542 for adslmib-archive@odin.ietf.org; Thu, 5 Jun 2003 11:21:28 -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 h55FLSB13539 for ; Thu, 5 Jun 2003 11:21: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 LAA02135 for ; Thu, 5 Jun 2003 11:21:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwWc-0000I3-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 11:19:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NwWc-0000I0-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 11:19:34 -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 h55FLGB13479; Thu, 5 Jun 2003 11:21: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 h55FIQB13292 for ; Thu, 5 Jun 2003 11:18:26 -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 LAA01434 for ; Thu, 5 Jun 2003 11:18:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwTh-0000BQ-00 for adslmib@ietf.org; Thu, 05 Jun 2003 11:16:33 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19NwTc-0000As-00 for adslmib@ietf.org; Thu, 05 Jun 2003 11:16:32 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h55FIAGM851771 for ; Thu, 5 Jun 2003 10:18:13 -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 ; Thu, 05 Jun 2003 10:18:06 -0500 Subject: Re: [Adslmib] Confused about ADSL2 and ADSL2+ Work From: Bob Ray Reply-To: rray@pesa.com To: Rajesh Abbi Cc: "'Michael Sneed'" , Umberto Bonollo , frank.van_der_putten@alcatel.be, csikes@paradyne.com, adslmib mail list , davidson@paradyne.com, Greg Bathrick In-Reply-To: <3EDF4470.E143C377@alcatel.com> References: <000301c32b0b$a5807640$84304c93@ssd.neca.nec.com.au> <3EDF4470.E143C377@alcatel.com> Content-Type: text/plain Message-Id: <1054826285.3686.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Jun 2003 10:18:05 -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-06-05 at 08:24, Rajesh Abbi wrote: > I encourage Umberto, Clay, Bob and others who are interested in ADSL2 MIB to > participate in the DSL Forum work in order to expedite this process. My current employer has no interest in DSL. They have, however, graciously allowed me to finish up my work with the IETF adslmib working group. As such, I will not be participating in any future DSL-related activities following completion of my current two drafts. That is, my participation will cease when and if the two drafts (vdsl and hc-tc) achieve RFC status, which I hope is very soon. I surely hope someone volunteers to pick up where I leave off. You get to visit a bunch of neat places. :) Regards, Bob Ray PESA Switching Systems _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu Jun 5 16:23:08 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 QAA15648 for ; Thu, 5 Jun 2003 16:23:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55KMe306313 for adslmib-archive@odin.ietf.org; Thu, 5 Jun 2003 16:22: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 h55KMeB06310 for ; Thu, 5 Jun 2003 16:22:40 -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 QAA15627 for ; Thu, 5 Jun 2003 16:22:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O1E5-00039n-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 16:20:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O1E4-00039j-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 16:20: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 h55KMKB06296; Thu, 5 Jun 2003 16:22: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 h55KJEB06162 for ; Thu, 5 Jun 2003 16:19: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 QAA15542 for ; Thu, 5 Jun 2003 16:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O1Al-00038F-00 for adslmib@ietf.org; Thu, 05 Jun 2003 16:17:19 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19O1Ak-000381-00 for adslmib@ietf.org; Thu, 05 Jun 2003 16:17:18 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id WAA24991; Thu, 5 Jun 2003 22:19:01 +0200 (MET DST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id WAA08387; Thu, 5 Jun 2003 22:18:05 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 22:18:33 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE83@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'rray@pesa.com'" , "'Menachem.Dodge@infineon.com'" Subject: RE: Re: [Adslmib] VDSL Line Extension MIB Date: Thu, 5 Jun 2003 22:18:32 +0200 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: , Hi all, on 4th June Bob Ray wrote: > On Mon, 2003-06-02 at 06:37, Flemisch Felix wrote: > > > I then formalize the MUST requirement for VDSL-LINE-EXT-MIB, at > > least regarding LCS line configuration profile tables, through the > > introduction of the new parameter "vdslLineConfProfileLCSExt" > > within vdslLineEntry. It identifies the row (maybe none) in the > > LCS Line Configuration Profile Extension Table, which applies > > for this VDSL line and its channels (if applicable). > > If there is to be a LCS extension MIB module, then the table(s) > within it should use vdslLineConfProfileName as an index instead > of what you propose. This is functionally equivalent to your proposed > object, but does not require an > > object-from-a-MIB-to-be-written-at-a-later-date. > > Further, this would be in keeping with the LCS tables in earlier > revisions of the VDSL Line MIB. To take this comment into account and to clarify the overall description I adopt the 4th Proposal of my email of 2nd June as follows: 4. Proposal, modified Enhance the conceptual row vdslLineEntry by the new parameter "vdslLineConfProfileLCSExt": >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... VdslLineEntry ::= SEQUENCE { vdslLineCoding VdslLineCodingType, vdslLineType INTEGER, vdslLineConfProfile SnmpAdminString, vdslLineConfProfileLCSExt SnmpAdminString, vdslLineAlarmConfProfile SnmpAdminString } ... ::= { vdslLineEntry 3 } vdslLineConfProfileLCSExt OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in one or more line-code specific (LCS) VDSL configuration profile tables, which applies for this VDSL line and its channels. The LCS tables are defined in the VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) and are commonly indexed by the object vdslLineConfProfileName (which is defined in the present MIB within the core VDSL Line Configuration Profile Table referred to by vdslLineConfProfile). If this VDSL line is, according to the value of vdslLineCoding, an MCM line, all referenced LCS tables MUST be MCM-specific, and if this VDSL line is an SCM line, all these tables MUST be SCM-specific. A value of NULL has the meaning that this VDSL line has no LCS extension profile table assigned and the VDSL link will be established based on the information specified in the core configuration profile table and additionally on any measurement or probing of the line as necessary." ::= { vdslLineEntry 4 } vdslLineAlarmConfProfile OBJECT-TYPE ... ::= { vdslLineEntry 5 } ... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Regards, Felix Flemisch Siemens AG Information and Communication Networks Carrier Products Systems Engineering Hofmannstr. 51 D-81359 Munich Germany Phone +49 89 722 62175 Email felix.flemisch@siemens.com Internet http://www.siemens.com/ _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu Jun 5 17:01: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 RAA17009 for ; Thu, 5 Jun 2003 17:01:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55L1PO09959 for adslmib-archive@odin.ietf.org; Thu, 5 Jun 2003 17:01: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 h55L1OB09956 for ; Thu, 5 Jun 2003 17:01: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 RAA16982 for ; Thu, 5 Jun 2003 17:01:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O1pZ-0003Wl-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 16:59:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O1pY-0003Wi-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 16:59: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 h55L1FB09944; Thu, 5 Jun 2003 17:01: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 h55L10B09620 for ; Thu, 5 Jun 2003 17:01:01 -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 RAA16959 for ; Thu, 5 Jun 2003 17:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O1pB-0003WF-00 for adslmib@ietf.org; Thu, 05 Jun 2003 16:59:05 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19O1pA-0003WC-00 for adslmib@ietf.org; Thu, 05 Jun 2003 16:59:04 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h55L0qGI643383 for ; Thu, 5 Jun 2003 16:00:55 -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 ; Thu, 05 Jun 2003 16:00:51 -0500 Subject: Re: [Adslmib] VDSL Line Extension MIB] From: Bob Ray Reply-To: rray@pesa.com To: adslmib mail list In-Reply-To: References: Content-Type: text/plain Message-Id: <1054846850.6311.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Jun 2003 16:00:50 -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 > To take this comment into account and to clarify the overall description > I adopt the 4th Proposal of my email of 2nd June as follows: > 4. Proposal, modified > Enhance the conceptual row vdslLineEntry by the new parameter > "vdslLineConfProfileLCSExt": > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > ... > VdslLineEntry ::= > SEQUENCE > { > vdslLineConfProfileLCSExt SnmpAdminString, > } > ... > ::= { vdslLineEntry 3 } There is simply no need to put such an object in the VDSL Line MIB. For example, let there be a table in a LCS extension MIB called vdslExtMCMProfileTable. This table would have as its index, the profile name from the VDSL Line MIB : IMPORTS vdslLineConfProfileName FROM VDSL-LINE-MIB; ... vdslExtMCMProfileEntry OBJECT-TYPE ... INDEX { vdslLineConfProfileName } ::= { vdslExtMCMProfileTable 1 } Tables in any extension MIB would tie into the VDSL Line MIB profile structure via the profile name. This is what I meant by the previous email. Hope this helps. Regards, Bob Ray PESA Switching Systems _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Thu Jun 5 17:25:39 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 RAA17824 for ; Thu, 5 Jun 2003 17:25:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55LPDF12046 for adslmib-archive@odin.ietf.org; Thu, 5 Jun 2003 17:25:13 -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 h55LPDB12043 for ; Thu, 5 Jun 2003 17:25:13 -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 RAA17803 for ; Thu, 5 Jun 2003 17:25:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O2Ca-0003jT-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 17:23:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O2Ca-0003jQ-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 17:23:16 -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 h55LOlB11985; Thu, 5 Jun 2003 17:24:47 -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 h55LNHB11892 for ; Thu, 5 Jun 2003 17:23: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 RAA17768 for ; Thu, 5 Jun 2003 17:23:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O2Aj-0003i8-00 for adslmib@ietf.org; Thu, 05 Jun 2003 17:21:21 -0400 Received: from hostr51.alcatel.com ([143.209.5.1] helo=aurfsy.aur.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 19O2Ai-0003hu-00 for adslmib@ietf.org; Thu, 05 Jun 2003 17:21:20 -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 h55LMfv04165; Thu, 5 Jun 2003 17:22:41 -0400 (EDT) Message-ID: <3EDFB4A0.613E29C1@alcatel.com> Date: Thu, 05 Jun 2003 17:22:40 -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 Line Extension MIB] References: <1054846850.6311.15.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 I concur with Bob. Firstly, the issue of LSC extension is still under discussion. Secondly, even if an extension MIB was defined, it can use the index in the base MIB without having an additional index in the base MIB. Regards, Rajesh Bob Ray wrote: > > To take this comment into account and to clarify the overall description > > I adopt the 4th Proposal of my email of 2nd June as follows: > > 4. Proposal, modified > > > Enhance the conceptual row vdslLineEntry by the new parameter > > "vdslLineConfProfileLCSExt": > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > ... > > VdslLineEntry ::= > > SEQUENCE > > { > > vdslLineConfProfileLCSExt SnmpAdminString, > > } > > ... > > ::= { vdslLineEntry 3 } > > There is simply no need to put such an object in the VDSL Line MIB. > > For example, let there be a table in a LCS extension MIB called > vdslExtMCMProfileTable. This table would have as its index, the > profile name from the VDSL Line MIB : > > IMPORTS vdslLineConfProfileName FROM VDSL-LINE-MIB; > ... > vdslExtMCMProfileEntry OBJECT-TYPE > ... > INDEX { vdslLineConfProfileName } > ::= { vdslExtMCMProfileTable 1 } > > Tables in any extension MIB would tie into the VDSL Line MIB profile > structure via the profile name. This is what I meant by the previous > email. > > Hope this helps. > > Regards, > Bob Ray > PESA Switching Systems > > _______________________________________________ > 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 Jun 5 19:34: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 TAA22197 for ; Thu, 5 Jun 2003 19:34:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55NYH320971 for adslmib-archive@odin.ietf.org; Thu, 5 Jun 2003 19: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 h55NYHB20968 for ; Thu, 5 Jun 2003 19:34: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 TAA22190 for ; Thu, 5 Jun 2003 19:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O4DX-0004aw-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 19:32:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19O4DW-0004at-00 for adslmib-web-archive@ietf.org; Thu, 05 Jun 2003 19:32:22 -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 h55NYBB20959; Thu, 5 Jun 2003 19:34: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 h55NXnB20929 for ; Thu, 5 Jun 2003 19:33: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 TAA22180 for ; Thu, 5 Jun 2003 19:33:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19O4D5-0004aj-00 for adslmib@ietf.org; Thu, 05 Jun 2003 19:31:55 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19O4D4-0004ag-00 for adslmib@ietf.org; Thu, 05 Jun 2003 19:31:54 -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 BAA25958; Fri, 6 Jun 2003 01:33:25 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id BAA02182; Fri, 6 Jun 2003 01:33:25 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 6 Jun 2003 01:32:59 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE84@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'rray@pesa.com'" , "'Rajesh.Abbi@alcatel.com'" , "'Menachem.Dodge@infineon.com'" Subject: RE: Re: [Adslmib] VDSL Line Extension MIB Date: Fri, 6 Jun 2003 01:32:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Hi all, on 5th June Bob Ray (16:00) and Rajesh Abbi (17:22) argued that the proposed new object "vdslLineConfProfileLCSExt" should not be needed in the VDSL Line MIB. Sorry that I have to disagree with the co-editors but it definitely IS needed. Its purpose is twofold: 1. vdslLineConfProfileLCSExt documents the commitment of the adslmib WG (and IETF) to develop an LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB). While the details of this MIB are under discussion, it is no longer the case that "the issue of LCS extension is still under discussion", as Rajesh stated. On the contrary, DSLF started work on it, and the adslmib WG shall be obliged to translate the resulting LCS management framework extension to an SNMP extension MIB. The formal starting point would be vdsl-07. 2. For an individual VDSL line, vdslLineConfProfileLCSExt clarifies whether for the configuration of this line LCS extensions are needed or not and if they are needed how the respective rows are identified. This settles a discussion that took place in the adslmib WG from 20th to 25th May and remained unsettled so far. If you do not commit to this object, you still allow ANY undocumented relationship from the core VDSL Line Configuration Profile table to vendor-specific LCS extension tables, and you leave it unclarified whether the core configuration parameters are sufficient to configure individual VDSL lines. This is clearly not what we want, and the commitment to develop a standardized VDSL-LINE-EXT-MIB is needed NOW. Note that from the object vdslLineConfProfile it is impossible to decide whether LCS configuration parameters for an individual VDSL line are needed respectively are present at all. This is what I previously called "removal of the eight LCS profile tables without trace". The proposed new object gives back the missing trace to the removed tables. Regards, Felix _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 6 11:14:52 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 LAA27985 for ; Fri, 6 Jun 2003 11:14:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FEOU32412 for adslmib-archive@odin.ietf.org; Fri, 6 Jun 2003 11:14: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 h56FEOB32409 for ; Fri, 6 Jun 2003 11:14: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 LAA27970 for ; Fri, 6 Jun 2003 11:14:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OItJ-0002yI-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 11:12:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OItI-0002yF-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 11:12: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 h56FEHB32391; Fri, 6 Jun 2003 11:14: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 h56FCsB32325 for ; Fri, 6 Jun 2003 11:12: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 LAA27941 for ; Fri, 6 Jun 2003 11:12:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIrr-0002xc-00 for adslmib@ietf.org; Fri, 06 Jun 2003 11:10:59 -0400 Received: from hostr490.alcatel.com ([143.209.4.144] helo=aurmsd.aur.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 19OIrq-0002xV-00 for adslmib@ietf.org; Fri, 06 Jun 2003 11:10:58 -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 h56FCFNf018762; Fri, 6 Jun 2003 11:12:16 -0400 (EDT) Message-ID: <3EE0AF4F.8D6A931D@alcatel.com> Date: Fri, 06 Jun 2003 11:12:15 -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: Flemisch Felix CC: adslmib@ietf.org, rray@pesa.com, Menachem.Dodge@infineon.com Subject: Re: [Adslmib] VDSL Line Extension MIB References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE84@mchh2a8e.mchh.siemens.de> 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 Felix, Please see my respone below ... Regards, Rajesh Flemisch Felix wrote: > Hi all, > > on 5th June Bob Ray (16:00) and Rajesh Abbi (17:22) argued that > the proposed new object "vdslLineConfProfileLCSExt" should not > be needed in the VDSL Line MIB. > > Sorry that I have to disagree with the co-editors > but it definitely IS needed. > > Its purpose is twofold: > > 1. vdslLineConfProfileLCSExt documents the commitment of the > adslmib WG (and IETF) to develop an LCS VDSL Line Extension > MIB (VDSL-LINE-EXT-MIB). While the details of this MIB are > under discussion, it is no longer the case that "the issue of > LCS extension is still under discussion", as Rajesh stated. > On the contrary, DSLF started work on it, and the adslmib WG > shall be obliged to translate the resulting LCS management > framework extension to an SNMP extension MIB. > The formal starting point would be vdsl-07. The DSL Forum made it an objective to keep the VDSL Management working-text (WT-068) line-code independent. There were some concerns at that time from ECI about the adequacy of the existing parameters in WT-068 for SCM management, so a separate proposed-draft (PD-015) was created to capture additional SCM-specific parameters. Subsequently, a few additional line-code independent parameters were identified that addressed the remaining concerns for SCM configuration. These additional parameters are already included in the IETF draft, and will be included in an addendum to the DSL Forum TR-057 (ex WT-068). The LCS PDs are now optional extensions to TR-057. > 2. For an individual VDSL line, vdslLineConfProfileLCSExt > clarifies whether for the configuration of this line > LCS extensions are needed or not and if they are needed > how the respective rows are identified. This settles a > discussion that took place in the adslmib WG from 20th > to 25th May and remained unsettled so far. I have seen general comments so far about how the current draft is not adequate. I would like to see specific additional parameter(s) you believe are necessary for the MIB. It should be noted that the MIB is intended to be an 'operator' interface and not a chipset/driver interface. Only parameters that an operator wishes to control are included in order to keep it simple to use. > If you do not commit to this object, you still allow ANY > undocumented relationship from the core VDSL Line Configuration > Profile table to vendor-specific LCS extension tables, and you > leave it unclarified whether the core configuration parameters > are sufficient to configure individual VDSL lines. > This is clearly not what we want, and the commitment to develop > a standardized VDSL-LINE-EXT-MIB is needed NOW. > > Note that from the object vdslLineConfProfile it is impossible > to decide whether LCS configuration parameters for an individual > VDSL line are needed respectively are present at all. This is > what I previously called "removal of the eight LCS profile > tables without trace". The proposed new object gives back > the missing trace to the removed tables. The LCS extensions are simply that. The core MIB should not be made 'aware' of the extensions. As noted above, at this time LCS extensions are still deemed 'optional'. Hopefully we can keep it that way to avoid unnecessary complication for the user. > Regards, > > Felix _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 6 13:01:34 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 NAA02436 for ; Fri, 6 Jun 2003 13:01:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56H19409702 for adslmib-archive@odin.ietf.org; Fri, 6 Jun 2003 13:01: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 h56H19B09699 for ; Fri, 6 Jun 2003 13:01: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 NAA02420 for ; Fri, 6 Jun 2003 13:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKYa-00049Y-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 12:59:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OKYY-00049S-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 12:59: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 h56H0jB09649; Fri, 6 Jun 2003 13:00: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 h56GxaB09588 for ; Fri, 6 Jun 2003 12:59:36 -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 MAA02375 for ; Fri, 6 Jun 2003 12:59:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKX4-000498-00 for adslmib@ietf.org; Fri, 06 Jun 2003 12:57:38 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19OKX3-000492-00 for adslmib@ietf.org; Fri, 06 Jun 2003 12:57:38 -0400 Received: from h-69-3-242-190.snvacaid.covad.net ([69.3.242.190] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OKYi-0003GN-00 for adslmib@ietf.org; Fri, 06 Jun 2003 09:59:20 -0700 Message-ID: <002001c32c4c$13cdd8e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE77@mchh2a8e.mchh.siemens.de> Subject: Re: [Adslmib] VDSL Line Type Naming and Configuration Date: Fri, 6 Jun 2003 09:52:55 -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 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: Sunday, June 01, 2003 3:28 AM > Subject: [Adslmib] VDSL Line Type Naming and Configuration ... > vdslLineType OBJECT-TYPE > SYNTAX INTEGER > { > noChannel(1), -- no channels exist > fastOnly(2), -- only fast channel exists > slowOnly(3), -- only slow channel exists > either(4), -- either fast or slow > -- channels can exist, but > -- only one at any time > both(5) -- both the fast and the slow > -- channel exist > } If the WG adopts this, the material in "--" comments should be included in the DESCRIPTION. ... > vdslLineType OBJECT-TYPE > SYNTAX INTEGER > { > noChannel(1), -- no channels exist > fastOnly(2), -- only fast channel exists > interleavedOnly(3), -- only interleaved channel exists > fastOrInterleaved(4), -- either fast or interleaved > -- channels can exist, but > -- only one at any time > fastAndInterleaved(5) -- both the fast and the interleaved > -- channel exist > } ... Same comment applies to this definition as well. ... > vdslLineConfLineType OBJECT-TYPE > SYNTAX INTEGER > { > noChannel(1), -- no channels exist > fastOnly(2), -- only fast channel exists > interleavedOnly(3), -- only interleaved channel exists > fastOrInterleaved(4), -- either fast or interleaved > -- channels can exist, but > -- only one at any time > fastAndInterleaved(5) -- both the fast and the interleaved > -- channel exist > } Same comment applies to this one also. ... > A final remark. There is severe doubt whether HAM is an acronym at all > (see e.g. http://www.hamcity.com/knowledge/whatisham.asp). I therefore > recommend not to expand it as Randy suggested. ... If we take this reference as definitive, then it should be written "ham", rather than "HAM", since the lower-case form is what is used there. Randy _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 6 13:41:36 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 NAA04125 for ; Fri, 6 Jun 2003 13:41:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56HfAc13719 for adslmib-archive@odin.ietf.org; Fri, 6 Jun 2003 13:41: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 h56HfAB13716 for ; Fri, 6 Jun 2003 13:41:10 -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 NAA04022 for ; Fri, 6 Jun 2003 13:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLBF-0004ak-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 13:39:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OLBE-0004af-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 13:39:08 -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 h56HeUB13659; Fri, 6 Jun 2003 13:40:31 -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 h56Hd5B13485 for ; Fri, 6 Jun 2003 13:39: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 NAA03783 for ; Fri, 6 Jun 2003 13:39:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OL9F-0004WS-00 for adslmib@ietf.org; Fri, 06 Jun 2003 13:37:05 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19OL9A-0004WH-00 for adslmib@ietf.org; Fri, 06 Jun 2003 13:37:00 -0400 Received: from h-69-3-242-190.snvacaid.covad.net ([69.3.242.190] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OLAz-0006dz-00 for adslmib@ietf.org; Fri, 06 Jun 2003 10:38:53 -0700 Message-ID: <002a01c32c51$99ec9e20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE79@mchh2a8e.mchh.siemens.de> Subject: Re: [Adslmib] VDSL Line Extension MIB Date: Fri, 6 Jun 2003 10:32:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C32C16.ED53CA60" 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 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 is a multi-part message in MIME format. ------=_NextPart_000_0027_01C32C16.ED53CA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi - Please note that my comments are as a "mib doctor" and not as any sort of *DSL person. > From: "Flemisch Felix" > To: > Cc: ; ; = > Sent: Monday, June 02, 2003 4:37 AM > Subject: [Adslmib] VDSL Line Extension MIB .... > 2. Proposal >=20 > Enhance the DESCRIPTION of MODULE-IDENTITY as follows: ... > This MIB module does not contain line-code specific (LCS) elements > for neither MCM lines nor SCM lines. An LCS VDSL Line Extension > MIB (VDSL-LINE-EXT-MIB) module MUST be standardized as a = supplement > to the core VDSL-LINE-MIB, since otherwise both SCM and MCM lines > can only be fully configured in a proprietary way. ... This use of "MUST" is not consistent with RFC 2119. The second sentence should be deleted, or, if the WG is agreed that this work should be = pursued, replaced with a statement to the effect that a line extension module is = planned. > Therefore the VDSL line table refers not only to the line-code > independent configuration profile table vdslLineConfProfileTable, > defined in this MIB module, but also to a commonly indexed set of > applicable LCS configuration profile tables, either all = SCM-specific > or all MCM-specific, that are defined in VDSL-LINE-EXT-MIB." This last sentence is over-specific, since it would preclude reference to any generic tables that might be defined in the future. In the IETF we have generally *not* tried to spell out potential future = re-uses of indexes. I'd be OK with this addition if it read something like: | The VDSL line table refers not only to the line-code | independent configuration profile table vdslLineConfProfileTable | defined in this MIB module, but also to, for example, the set of | commonly indexed applicable LCS configuration profile tables. > = <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >=20 > 3. Proposal >=20 > Enhance the REVISION clauses of MODULE-IDENTITY as follows: This stuff will all go away; the RFC will contain a single REVISION = clause saying that this is the initial version of this MIB module.=20 ... > vdslLineConfProfileLCSExt OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(1..32)) .... > It MUST be the case that either all referenced LCS tables > are SCM-specific or all these tables are MCM-specific. This is over-specification, since it would preclude the definition of a future generic table. My own experience as an implementor of related MIB tables is that it is better to define the semantics of 1) the existence of an irrelevant table entry (e.g., "corresponding entries in tables not applicable to this line type have no = effect") 2) the absence of a relevant table entry Both of these are probably best done in the *referenced* table's DESCRIPTION, rather than here, especially when the referenced tables haven't been defined yet. > Correspondingly the LCS extension of the core = configuration > profile is called SCM-specific or MCM-specific. An > SCM-specific extension profile MUST NOT be assigned to an > MCM line (according to vdslLineCoding), and an = MCM-specific > extension profile MUST NOT be assigned to an SCM line. This needs to be cleared up: is this advice to the (writer or user of) = the management application? Is this to be enforced at the agent? If so, what error code is expected? What happens when stuff is being = provisioned for hardware that hasn't been installed? What happens if the hardware changes? > A value of NULL has the meaning that this VDSL line has ... Please don't use "NULL". A zero-length string would be appropriate. Unfortunately, the SIZE(1..32) above precludes that possibility. The range should be extended to include zero. More fundamentally, why would it be necessary for this string to exist at all? Wouldn't the using the profile index work just as well, and avoid potential confusion? For example, if I have profiles "A", "B", and "C", with profile "A" usable for line type 1, "B" usable for line type 2, and "C" usable for either, then the MIB tables could be populated like this: Profile Table type-1-specific type-2-specific -------------------------------------------------------------------- A A B B C C C This seems simpler than adding yet another index, and also avoids the complex inter-dependencies. A line references its profile entry, and any corresponding line-type-specific entries according to its line type. Any line-type specific entries that might happen to exist for other line types would be irrelevant to that particular line. (It's up to the WG to decide whether this is appropriate for this particular technology!) Randy ------=_NextPart_000_0027_01C32C16.ED53CA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi -
 
Please note that my comments = are as a "mib=20 doctor" and not
as any sort of *DSL = person.
 
> From: "Flemisch Felix" = <felix.flemisch@siemens.com>
> To: <adslmib@ietf.org>
> Cc: <randy_presuhn@mindspring.com>; <Moti.Morgenstern@ecitele.com>; <Menachem.Dodge@infineon.com>
> Sent: Monday, June 02, = 2003 4:37=20 AM
> Subject: [Adslmib] VDSL = Line Extension=20 MIB

....
> 2. Proposal
> =
>=20    Enhance the DESCRIPTION of MODULE-IDENTITY as=20 follows:
...
>     This = MIB module=20 does not contain line-code specific (LCS) elements
> =    =20 for neither MCM lines nor SCM lines.  An LCS VDSL Line = Extension
>=20     MIB (VDSL-LINE-EXT-MIB) module MUST be standardized = as a=20 supplement
>     to the core VDSL-LINE-MIB, since = otherwise=20 both SCM and MCM lines
>     can only be fully = configured=20 in a proprietary way.
...
 
This use of "MUST" is not = consistent with=20 RFC 2119.  The second sentence
should be deleted, or, if the = WG is agreed=20 that this work should be pursued,
replaced with a statement to = the effect=20 that a line extension module is planned.
 
>     = Therefore the VDSL=20 line table refers not only to the line-code
>    =20 independent configuration profile table = vdslLineConfProfileTable,
>=20     defined in this MIB module, but also to a commonly = indexed=20 set of
>     applicable LCS configuration profile = tables,=20 either all SCM-specific
>     or all MCM-specific, = that are=20 defined in VDSL-LINE-EXT-MIB."
 
This last sentence is = over-specific, since=20 it would preclude
reference to any generic tables = that might=20 be defined in the future.
In the IETF we have generally = *not* tried=20 to spell out potential future re-uses
of indexes.  I'd be OK = with this=20 addition if it  read something like:
 
| The VDSL line table refers = not only to=20 the line-code
| independent configuration profile table=20 vdslLineConfProfileTable
| defined in this MIB module, = but also to,=20 for example, the set of
| commonly = indexed applicable LCS=20 configuration profile tables.

>=20 <<<<<<<<<<<<<<<<<<&= lt;<<<<<<<<<<<<<<<<<&l= t;<<<<<<<<<<<<<<<<<<= ;<<<<<<<<<<<<<<<<<
= >=20
> 3. Proposal
>
>    Enhance the REVISION = clauses=20 of MODULE-IDENTITY as follows:
 
This stuff will all go away; = the RFC will=20 contain a single REVISION clause
saying that this is the initial = version of=20 this MIB module. 
 
...
>    =20 vdslLineConfProfileLCSExt OBJECT-TYPE
>=20        =20 SYNTAX       SnmpAdminString=20 (SIZE(1..32))
....
>=20             It = MUST be=20 the case that either all referenced LCS tables
>=20             are=20 SCM-specific or all these tables are MCM-specific.
 
This is over-specification, = since it would=20 preclude the definition of
a future generic table.  = My own=20 experience as an implementor of
related MIB tables is that it = is better to=20 define the semantics of
   1) the existence = of an=20 irrelevant table entry (e.g.,  "corresponding
      =20 entries in tables not applicable to this line type have no=20 effect")
   2) the absence of = a relevant=20 table entry
Both of these are probably best = done in the=20 *referenced* table's
DESCRIPTION, rather than here, = especially=20 when the referenced
tables haven't been defined=20 yet.

>=20            =20 Correspondingly the LCS extension of the core configuration
>=20             = profile is=20 called SCM-specific or MCM-specific.  An
>=20             = SCM-specific=20 extension profile MUST NOT be assigned to an
>=20             MCM = line=20 (according to vdslLineCoding), and an MCM-specific
>=20             = extension=20 profile MUST NOT be assigned to an SCM line.
This needs to be cleared up: is = this advice=20 to the (writer or user of) the
management application?  = Is this to be=20 enforced at the agent?  If so,
what error code is = expected?  What=20 happens when stuff is being provisioned
for hardware that hasn't been=20 installed?  What happens if the hardware
changes?

>=20             A = value of=20 NULL has the meaning that this VDSL line has
...
 
Please don't use "NULL".  = A=20 zero-length string would be appropriate.
Unfortunately, = the SIZE(1..32)=20  above precludes that possibility.  The
range should be extended to = include=20 zero.
 
 
More fundamentally, why would = it be=20 necessary for this string to exist
at all?  Wouldn't = the using=20  the profile index work just as well,
and avoid potential = confusion?  For=20 example, if I have profiles "A",
"B", and "C", with profile "A" = usable for=20 line type 1, "B" usable
for line type 2, and "C" usable = for either,=20 then the MIB tables
could be populated like = this:
 
Profile=20 Table         type-1-specifi= c            =   =20 type-2-specific
----------------------------------------------------------------= ----
A          &nb= sp;           &nbs= p;   =20 A
B          &nb= sp;           &nbs= p;            = ;            =            B
C          &nb= sp;           &nbs= p;   =20 C            =             &= nbsp;    =20 C
 
This seems simpler than adding = yet another=20 index, and also avoids
the complex = inter-dependencies.  A=20 line references its profile entry,
and any corresponding = line-type-specific=20 entries according to its
line type.  Any line-type = specific=20 entries that might happen to
exist for other line types = would be=20 irrelevant to that particular line.
(It's up to the WG to decide = whether this=20 is appropriate for
this particular = technology!)
 
Randy
------=_NextPart_000_0027_01C32C16.ED53CA60-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 6 13:41:53 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 NAA04153 for ; Fri, 6 Jun 2003 13:41:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56HfRY13737 for adslmib-archive@odin.ietf.org; Fri, 6 Jun 2003 13:41:27 -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 h56HfRB13734 for ; Fri, 6 Jun 2003 13:41:27 -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 NAA04092 for ; Fri, 6 Jun 2003 13:41:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLBX-0004cG-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 13:39:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OLBW-0004cD-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 13:39:26 -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 h56Hf2B13701; Fri, 6 Jun 2003 13:41:02 -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 h56He1B13579 for ; Fri, 6 Jun 2003 13:40:01 -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 NAA03850 for ; Fri, 6 Jun 2003 13:39:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLA8-0004XJ-00 for adslmib@ietf.org; Fri, 06 Jun 2003 13:38:00 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19OLA7-0004XG-00 for adslmib@ietf.org; Fri, 06 Jun 2003 13:37:59 -0400 Received: from h-69-3-242-190.snvacaid.covad.net ([69.3.242.190] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OLBw-0000Fc-00 for adslmib@ietf.org; Fri, 06 Jun 2003 10:39:52 -0700 Message-ID: <003301c32c51$bd0e25e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "adslmib mail list" Subject: Fw: [Adslmib] VDSL Line Extension MIB Date: Fri, 6 Jun 2003 10:33:26 -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 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 - Profuse apologies for sending HTML to the list!!!! Randy ----- Original Message ----- From: "Randy Presuhn" To: Sent: Friday, June 06, 2003 10:32 AM Subject: Re: [Adslmib] VDSL Line Extension MIB Hi - Please note that my comments are as a "mib doctor" and not as any sort of *DSL person. > From: "Flemisch Felix" > To: > Cc: ; ; > Sent: Monday, June 02, 2003 4:37 AM > Subject: [Adslmib] VDSL Line Extension MIB .... > 2. Proposal > > Enhance the DESCRIPTION of MODULE-IDENTITY as follows: ... > This MIB module does not contain line-code specific (LCS) elements > for neither MCM lines nor SCM lines. An LCS VDSL Line Extension > MIB (VDSL-LINE-EXT-MIB) module MUST be standardized as a supplement > to the core VDSL-LINE-MIB, since otherwise both SCM and MCM lines > can only be fully configured in a proprietary way. ... This use of "MUST" is not consistent with RFC 2119. The second sentence should be deleted, or, if the WG is agreed that this work should be pursued, replaced with a statement to the effect that a line extension module is planned. > Therefore the VDSL line table refers not only to the line-code > independent configuration profile table vdslLineConfProfileTable, > defined in this MIB module, but also to a commonly indexed set of > applicable LCS configuration profile tables, either all SCM-specific > or all MCM-specific, that are defined in VDSL-LINE-EXT-MIB." This last sentence is over-specific, since it would preclude reference to any generic tables that might be defined in the future. In the IETF we have generally *not* tried to spell out potential future re-uses of indexes. I'd be OK with this addition if it read something like: | The VDSL line table refers not only to the line-code | independent configuration profile table vdslLineConfProfileTable | defined in this MIB module, but also to, for example, the set of | commonly indexed applicable LCS configuration profile tables. > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > 3. Proposal > > Enhance the REVISION clauses of MODULE-IDENTITY as follows: This stuff will all go away; the RFC will contain a single REVISION clause saying that this is the initial version of this MIB module. ... > vdslLineConfProfileLCSExt OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE(1..32)) .... > It MUST be the case that either all referenced LCS tables > are SCM-specific or all these tables are MCM-specific. This is over-specification, since it would preclude the definition of a future generic table. My own experience as an implementor of related MIB tables is that it is better to define the semantics of 1) the existence of an irrelevant table entry (e.g., "corresponding entries in tables not applicable to this line type have no effect") 2) the absence of a relevant table entry Both of these are probably best done in the *referenced* table's DESCRIPTION, rather than here, especially when the referenced tables haven't been defined yet. > Correspondingly the LCS extension of the core configuration > profile is called SCM-specific or MCM-specific. An > SCM-specific extension profile MUST NOT be assigned to an > MCM line (according to vdslLineCoding), and an MCM-specific > extension profile MUST NOT be assigned to an SCM line. This needs to be cleared up: is this advice to the (writer or user of) the management application? Is this to be enforced at the agent? If so, what error code is expected? What happens when stuff is being provisioned for hardware that hasn't been installed? What happens if the hardware changes? > A value of NULL has the meaning that this VDSL line has ... Please don't use "NULL". A zero-length string would be appropriate. Unfortunately, the SIZE(1..32) above precludes that possibility. The range should be extended to include zero. More fundamentally, why would it be necessary for this string to exist at all? Wouldn't the using the profile index work just as well, and avoid potential confusion? For example, if I have profiles "A", "B", and "C", with profile "A" usable for line type 1, "B" usable for line type 2, and "C" usable for either, then the MIB tables could be populated like this: Profile Table type-1-specific type-2-specific -------------------------------------------------------------------- A A B B C C C This seems simpler than adding yet another index, and also avoids the complex inter-dependencies. A line references its profile entry, and any corresponding line-type-specific entries according to its line type. Any line-type specific entries that might happen to exist for other line types would be irrelevant to that particular line. (It's up to the WG to decide whether this is appropriate for this particular technology!) Randy _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 6 14:12:52 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 OAA05539 for ; Fri, 6 Jun 2003 14:12:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56ICRB16818 for adslmib-archive@odin.ietf.org; Fri, 6 Jun 2003 14:12:27 -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 h56ICRB16815 for ; Fri, 6 Jun 2003 14:12:27 -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 OAA05519 for ; Fri, 6 Jun 2003 14:12:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLfW-00052T-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 14:10:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OLfW-00052Q-00 for adslmib-web-archive@ietf.org; Fri, 06 Jun 2003 14:10:26 -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 h56IC4B16789; Fri, 6 Jun 2003 14:12:05 -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 h56I7kB16542 for ; Fri, 6 Jun 2003 14:07: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 OAA05287 for ; Fri, 6 Jun 2003 14:07:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OLaz-0004yu-00 for adslmib@ietf.org; Fri, 06 Jun 2003 14:05:45 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19OLay-0004yr-00 for adslmib@ietf.org; Fri, 06 Jun 2003 14:05:44 -0400 Received: from h-69-3-242-190.snvacaid.covad.net ([69.3.242.190] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19OLcm-0002tC-00 for adslmib@ietf.org; Fri, 06 Jun 2003 11:07:36 -0700 Message-ID: <004a01c32c55$9c771cc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE84@mchh2a8e.mchh.siemens.de> Subject: Re: Re: [Adslmib] VDSL Line Extension MIB Date: Fri, 6 Jun 2003 11:01:10 -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 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: Thursday, June 05, 2003 4:32 PM > Subject: RE: Re: [Adslmib] VDSL Line Extension MIB ... > 1. vdslLineConfProfileLCSExt documents the commitment of the > adslmib WG (and IETF) to develop an LCS VDSL Line Extension > MIB (VDSL-LINE-EXT-MIB). While the details of this MIB are > under discussion, it is no longer the case that "the issue of > LCS extension is still under discussion", as Rajesh stated. > On the contrary, DSLF started work on it, and the adslmib WG > shall be obliged to translate the resulting LCS management > framework extension to an SNMP extension MIB. > The formal starting point would be vdsl-07. This is hardly a valid reason for adding an object definition to a MIB module. > 2. For an individual VDSL line, vdslLineConfProfileLCSExt > clarifies whether for the configuration of this line > LCS extensions are needed or not and if they are needed > how the respective rows are identified. This settles a > discussion that took place in the adslmib WG from 20th > to 25th May and remained unsettled so far. The line type should determine which LCS extensions are applicable. For sanity's sake, I'd strongly recommend that they be indexed in the same way as the profile, unless there is a compelling reason to introduce another set of indexes with different semantics. > If you do not commit to this object, you still allow ANY > undocumented relationship from the core VDSL Line Configuration > Profile table to vendor-specific LCS extension tables, and you This will be true no matter what this working group does. Vendors are always free to define whatever extensions they may find appropriate. Even if the WG fully specified everything in this module, vendors would *still* be able to define additional stuff. This is a feature, not a bug. > leave it unclarified whether the core configuration parameters > are sufficient to configure individual VDSL lines. My understanding of the discussion so far is that this is vendor- specific. I haven't seen any arguments so far that, from the perspective of MIB module design, suggest that this module's indexing structure would require changes to adequately support future modules (either standardized or vendor-specific) to handle line-type-specific stuff. > This is clearly not what we want, and the commitment to develop > a standardized VDSL-LINE-EXT-MIB is needed NOW. That's a WG charter discussion, so I'll leave it to the chair to respond to that point. > Note that from the object vdslLineConfProfile it is impossible > to decide whether LCS configuration parameters for an individual > VDSL line are needed respectively are present at all. This is > what I previously called "removal of the eight LCS profile > tables without trace". The proposed new object gives back > the missing trace to the removed tables. ... Without knowing the names of the new table(s), the proposed object does no such thing. Putting in the names of those tables would be a normative reference, forcing a lock-step progression relationship between the documents. In any case, vendors (and WGs!) would still be free to define any number of tables indexed by the proposed object or by the existing profile index object. In the world of SNMP, one needs to know *a priori* what the set of potentially relevant tables is, and then construct appropriate indexes to find the corresponding entries. There's nothing to automagically identify what bits will need to be configured to make something work. Adding this object doesn't help anything, as far as I can see. Randy _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Sun Jun 8 21:36:53 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 VAA05995 for ; Sun, 8 Jun 2003 21:36:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h591aSB07315 for adslmib-archive@odin.ietf.org; Sun, 8 Jun 2003 21:36:28 -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 h591aSB07312 for ; Sun, 8 Jun 2003 21:36: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 VAA05980 for ; Sun, 8 Jun 2003 21:36:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PBYG-0006dV-00 for adslmib-web-archive@ietf.org; Sun, 08 Jun 2003 21:34:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PBYF-0006dR-00 for adslmib-web-archive@ietf.org; Sun, 08 Jun 2003 21:34: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 h591aLB07303; Sun, 8 Jun 2003 21:36: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 h591Z1B07269 for ; Sun, 8 Jun 2003 21:35:01 -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 VAA05965 for ; Sun, 8 Jun 2003 21:34:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PBWs-0006dF-00 for adslmib@ietf.org; Sun, 08 Jun 2003 21:32:58 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19PBWr-0006dB-00 for adslmib@ietf.org; Sun, 08 Jun 2003 21:32:57 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id DAA00620; Mon, 9 Jun 2003 03:34:29 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id DAA07681; Mon, 9 Jun 2003 03:33:34 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Mon, 9 Jun 2003 03:34:03 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE87@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'rray@pesa.com'" , "'Rajesh.Abbi@alcatel.com'" , "'randy_presuhn@mindspring.com'" Date: Mon, 9 Jun 2003 03:33:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Adslmib] VDSL Line Extension MIB - Modified 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, this email is a summary response to the comments by Bob, Rajesh, and Randy (msg00248, msg00255, msg00256, msg00258, msg00260/msg00261, msg00262) on my "VDSL Line Extension MIB" proposals (msg00243, msg00254, msg00257). It seems that the rationale of my proposals is well understood but they can nevertheless hardly be agreed upon for the following reasons: - mixing up with WG charter issues - contradictions to agreed MIB design principles - impossibility of full traceability to standardized LCS extension tables as long as the names of these tables are not yet specified - freedom of vendors to define whatever extensions they may find appropriate, which leads to undocumentable relationships from the core configuration profile table to vendor-specific generic and LCS extension tables - the index of the line-code independent configuration profile table can and should be used as index for LCS (and vendor-specific) extension tables - the indexing structure of the core VDSL line MIB does not require changes to adequately support future modules (either standardized or vendor- specific) to handle LCS stuff - danger to revive the old LCS and vendor-specific discussion that paralysed DSLF and WG work Presumably it would be of little help if I moved the proposed parameter vdslLineConfProfileLCSExt from vdslLineEntry to vdslLineConfProfileEntry (i.e., the line-code independent configuration profile would include a parameter that either refers to LCS extension parameters that are not further specified or indicates that no LCS parameters are needed). I therefore modify my original proposals as follows: 1. Proposal - modified Enhance in section 2.5 of vdsl-09 the text describing line configuration profiles as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... o Line Configuration Profiles - These profiles contain parameters for configuring VDSL lines and their channels. They are defined in the line-code independent vdslLineConfProfileTable and in supplementary standardized line-code specific (LCS) configuration profile tables. Additionally vendor-specific configuration profile extension tables may exist. vdslLineConfProfileTable is defined in the VDSL-LINE MIB module that is specified in this RFC, and standardized LCS configuration profile tables are defined in the VDSL-LINE-EXT MIB module that is specified in a planned complementary RFC. Each entry of vdslLineTable references a row of vdslLineConfProfileTable and uses the very same reference as a common index into one or more applicable LCS, or vendor-specific, configuration profile tables. The referenced specific row(s) augment(s) the line-code independent parameter set by a specific parameter set (which may be empty). ... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 2. Proposal - modified Enhance the DESCRIPTION of MODULE-IDENTITY as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... Tx -- Transmit Blks -- Blocks -- Note This MIB module does not contain line-code specific (LCS) elements for neither MCM lines nor SCM lines. An LCS VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) module is planned as a mandatory supplement to the core VDSL-LINE-MIB, since otherwise both SCM and MCM lines can possibly only be fully configured in a vendor-specific way. The VDSL line table refers not only to the line-code independent configuration profile table ( vdslLineConfProfileTable ), defined in this MIB module, but also to, for example, a set of commonly indexed applicable LCS configuration profile tables." <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 3. Proposal - modified Enhance the REVISION clauses of MODULE-IDENTITY as follows (in case a final draft version "draft-ietf-adslmib-vdsl-10.txt" is issued): >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Revision history ... 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." ... REVISION "200306080000Z" -- June 8, 2003 DESCRIPTION "Enhanced in section 2.5 the description of line configuration profiles. Added note to DESCRIPTION of MODULE-IDENTITY regarding LCS VDSL Line MIB extensions. Enhanced DESCRIPTION of vdslLineConfProfile within vdslLineEntry regarding the common indexing of LCS and vendor-specific MIB extensions. Added vdslLineConfLineType to vdslLineCodeProfileEntry. Corrected many mechanical and editorial flaws, added various clarifications." <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 4. Proposal - modified Enhance the DESCRIPTION of vdslLineConfProfile within vdslLineEntry as follows: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 its channels (if any). Since this table is indexed by vdslLineConfProfileName vdslLineConfProfile is a valid such name. The very same index MUST be used to identify the row in one or more standardized LCS configuration profile extension tables, which applies for this VDSL line and its channels. These tables are defined in the complementary VDSL Line Extension MIB (VDSL-LINE-EXT-MIB) and are commonly indexed by vdslLineConfProfileName. The very same index SHOULD be used to identify the row in one or more vendor-specific, generic or LCS, configuration profile extension tables, which applies for this VDSL line and its channels." ::= { vdslLineEntry 3 } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Regards, Felix Flemisch Siemens AG Information and Communication Networks Carrier Products Systems Engineering Hofmannstr. 51 D-81359 Munich Germany Phone +49 89 722 62175 Email felix.flemisch@siemens.com Internet http://www.siemens.com/ _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Mon Jun 9 04:27: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 EAA24014 for ; Mon, 9 Jun 2003 04:27:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h598RH111962 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 04: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 h598RHB11959 for ; Mon, 9 Jun 2003 04:27: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 EAA24009 for ; Mon, 9 Jun 2003 04:27:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PHxq-0000ed-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 04:25:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PHxp-0000ea-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 04:25:13 -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 h598R9B11948; Mon, 9 Jun 2003 04:27: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 h598QNB11919 for ; Mon, 9 Jun 2003 04:26: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 EAA24001 for ; Mon, 9 Jun 2003 04:26:19 -0400 (EDT) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PHwy-0000eU-00 for adslmib@ietf.org; Mon, 09 Jun 2003 04:24:20 -0400 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 19PHwx-0000eR-00 for adslmib@ietf.org; Mon, 09 Jun 2003 04:24:19 -0400 Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228]) by smtp2.infineon.com (8.12.9/8.12.9) with ESMTP id h598P7wi006588; Mon, 9 Jun 2003 10:25:07 +0200 (MEST) Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 10:25:38 +0200 Message-ID: To: Rajesh.Abbi@alcatel.com, felix.flemisch@siemens.com Cc: adslmib@ietf.org, rray@pesa.com Subject: RE: [Adslmib] VDSL Line Extension MIB Date: Mon, 9 Jun 2003 11:24:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: adslmib-admin@ietf.org Errors-To: adslmib-admin@ietf.org X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: ADSLMIB List-Post: List-Help: List-Subscribe: , Hi Rajesh, As an operator interface there are circumstances when the operator would like to define or monitor some or all of the physical parameters directly. The operator Should be given this choice. There are other similar choices in the MIB such as vdslLineConfDownstreamRateMode which can be set to Manual rather than be configured automatically. In addition the MIB allows non-standard bandplans and the use of them may be a necessity, due to cross talk from other equipment already deployed in the network, or even as a choice of the operator. In these circumstances the direct definition of the physical parameters is a necessity for the operator. Clearly the missing parameters are the LCS parameters that have been removed from this core MIB and will be defined in the extension MIB. Again it is not a question of unnecessary complications but one of choice/necessity of the operator. Lets agree to put this information in the extension MIB and the operator can choose whether to make use of it or not. Regards, Menachem -----Original Message----- From: Rajesh Abbi [mailto:Rajesh.Abbi@alcatel.com] Sent: Friday, June 06, 2003 5:12 PM To: Flemisch Felix Cc: adslmib@ietf.org; rray@pesa.com; Menachem Dodge Subject: Re: [Adslmib] VDSL Line Extension MIB Hi Felix, Please see my respone below ... Regards, Rajesh Flemisch Felix wrote: > Hi all, > > on 5th June Bob Ray (16:00) and Rajesh Abbi (17:22) argued that > the proposed new object "vdslLineConfProfileLCSExt" should not > be needed in the VDSL Line MIB. > > Sorry that I have to disagree with the co-editors > but it definitely IS needed. > > Its purpose is twofold: > > 1. vdslLineConfProfileLCSExt documents the commitment of the > adslmib WG (and IETF) to develop an LCS VDSL Line Extension > MIB (VDSL-LINE-EXT-MIB). While the details of this MIB are > under discussion, it is no longer the case that "the issue of > LCS extension is still under discussion", as Rajesh stated. > On the contrary, DSLF started work on it, and the adslmib WG > shall be obliged to translate the resulting LCS management > framework extension to an SNMP extension MIB. > The formal starting point would be vdsl-07. The DSL Forum made it an objective to keep the VDSL Management working-text (WT-068) line-code independent. There were some concerns at that time from ECI about the adequacy of the existing parameters in WT-068 for SCM management, so a separate proposed-draft (PD-015) was created to capture additional SCM-specific parameters. Subsequently, a few additional line-code independent parameters were identified that addressed the remaining concerns for SCM configuration. These additional parameters are already included in the IETF draft, and will be included in an addendum to the DSL Forum TR-057 (ex WT-068). The LCS PDs are now optional extensions to TR-057. > 2. For an individual VDSL line, vdslLineConfProfileLCSExt > clarifies whether for the configuration of this line > LCS extensions are needed or not and if they are needed > how the respective rows are identified. This settles a > discussion that took place in the adslmib WG from 20th > to 25th May and remained unsettled so far. I have seen general comments so far about how the current draft is not adequate. I would like to see specific additional parameter(s) you believe are necessary for the MIB. It should be noted that the MIB is intended to be an 'operator' interface and not a chipset/driver interface. Only parameters that an operator wishes to control are included in order to keep it simple to use. > If you do not commit to this object, you still allow ANY > undocumented relationship from the core VDSL Line Configuration > Profile table to vendor-specific LCS extension tables, and you > leave it unclarified whether the core configuration parameters > are sufficient to configure individual VDSL lines. > This is clearly not what we want, and the commitment to develop > a standardized VDSL-LINE-EXT-MIB is needed NOW. > > Note that from the object vdslLineConfProfile it is impossible > to decide whether LCS configuration parameters for an individual > VDSL line are needed respectively are present at all. This is > what I previously called "removal of the eight LCS profile > tables without trace". The proposed new object gives back > the missing trace to the removed tables. The LCS extensions are simply that. The core MIB should not be made 'aware' of the extensions. As noted above, at this time LCS extensions are still deemed 'optional'. Hopefully we can keep it that way to avoid unnecessary complication for the user. > Regards, > > Felix _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Mon Jun 9 10:17: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 KAA06420 for ; Mon, 9 Jun 2003 10:17:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59EHI305189 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 10:17: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 h59EHIB05185 for ; Mon, 9 Jun 2003 10:17:18 -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 KAA06415 for ; Mon, 9 Jun 2003 10:17:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNQX-0003nT-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 10:15:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PNQW-0003nQ-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 10:15:12 -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 h59EHCB05174; Mon, 9 Jun 2003 10:17: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 h59EG8B05111 for ; Mon, 9 Jun 2003 10:16: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 KAA06382 for ; Mon, 9 Jun 2003 10:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNPO-0003nE-00 for adslmib@ietf.org; Mon, 09 Jun 2003 10:14:03 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19PNPO-0003nB-00 for adslmib@ietf.org; Mon, 09 Jun 2003 10:14:02 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h59EFxGI1032150 for ; Mon, 9 Jun 2003 09:15:59 -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 ; Mon, 09 Jun 2003 09:15:56 -0500 From: Bob Ray Reply-To: rray@pesa.com To: adslmib mail list In-Reply-To: <99522F0FD7EFD611A47D0002A58EDAB7C8AE87@mchh2a8e.mchh.siemens.de> References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE87@mchh2a8e.mchh.siemens.de> Content-Type: text/plain Message-Id: <1055168155.3761.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 09 Jun 2003 09:15:55 -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: VDSL Line Extension MIB - Modified 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 Felix (and all): This insistence that the hands of the IETF be bound by specific references to work that hasn't been chartered and by work that hasn't been done is not productive. I would suggest, instead, that those who feel most strongly about the "missing tables" do the following: a) dredge up a copy of the -07 draft b) write a draft vdsl-line-extension-mib using the missing tables c) submit the draft as an individual contribution to the IETF d) at the next meeting of the adslmib working group (perhaps Vienna), suggest that the charter be amended to support an extension MIB e) humbly offer the individual contribution to the working group as a good starting point for such work. f) work with (and in) the DSL Forum to achieve agreement as to THEIR preferred management objects. I believe this approach would be FAR MORE PRODUCTIVE... See: http://www.ietf.org/ietf/1id-guidelines.txt for information on accomplishing this. Regards, Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Mon Jun 9 11:08:39 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 LAA08069 for ; Mon, 9 Jun 2003 11:08:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59F8FL09074 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 11:08: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 h59F8FB09071 for ; Mon, 9 Jun 2003 11:08:15 -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 LAA08042 for ; Mon, 9 Jun 2003 11:08:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PODp-00048P-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 11:06:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PODo-00048M-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 11:06:08 -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 h59F88B09062; Mon, 9 Jun 2003 11:08: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 h59F7CB08421 for ; Mon, 9 Jun 2003 11:07:12 -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 LAA08031 for ; Mon, 9 Jun 2003 11:07:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POCo-00048D-00 for adslmib@ietf.org; Mon, 09 Jun 2003 11:05:06 -0400 Received: from law14-f13.law14.hotmail.com ([64.4.21.13] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19POCn-000488-00 for adslmib@ietf.org; Mon, 09 Jun 2003 11:05:05 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jun 2003 08:06:35 -0700 Received: from 66.152.60.98 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 09 Jun 2003 15:06:35 GMT X-Originating-IP: [66.152.60.98] X-Originating-Email: [sneedmike@hotmail.com] From: "Michael Sneed" To: rray@pesa.com, adslmib@ietf.org Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified Date: Mon, 09 Jun 2003 11:06:35 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jun 2003 15:06:35.0837 (UTC) FILETIME=[B84B86D0:01C32E98] 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: , Bob is right, and his suggested gameplan is a sound one (given that was largely the one used for the VDSL work). It is not only unnecessary to reference undefined future work in the current MIB , it would be a very bad thing. Further, it would be a bad thing to attempt to anticipate the DSL Forum's definition of the LCS MIB. The one thing no one wants is TWO standards. My suggestion is that we drop the LCS topic for the current document, and seek a charter revision to do an LCS MIB. That will give us the opportunity to be consistent with the DSL Forum work without holding up the present documents. We really just need editor(s). If someone were to produce an individual submission ID based on DSL Forum work or the -07 draft to get the ball rolling, that would certainly help, and would assist in proving to the IESG that we are serious. It is also appropriate to discuss the details of the charter revision, if anyone feels like chiming in. Please note, however, that the working group cannot "commit" to producing an LCS MIB without a charter to do so. Regards, Mike >From: Bob Ray >Reply-To: rray@pesa.com >To: adslmib mail list >Subject: [Adslmib] Re: VDSL Line Extension MIB - Modified >Date: 09 Jun 2003 09:15:55 -0500 > >Felix (and all): > >This insistence that the hands of the IETF be bound by specific >references to work that hasn't been chartered and by work that >hasn't been done is not productive. > >I would suggest, instead, that those who feel most strongly >about the "missing tables" do the following: > >a) dredge up a copy of the -07 draft >b) write a draft vdsl-line-extension-mib using the missing > tables >c) submit the draft as an individual contribution to the > IETF >d) at the next meeting of the adslmib working group (perhaps > Vienna), suggest that the charter be amended to support > an extension MIB >e) humbly offer the individual contribution to the working > group as a good starting point for such work. >f) work with (and in) the DSL Forum to achieve agreement as > to THEIR preferred management objects. > >I believe this approach would be FAR MORE PRODUCTIVE... > >See: http://www.ietf.org/ietf/1id-guidelines.txt for information >on accomplishing this. > >Regards, >Bob Ray > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www1.ietf.org/mailman/listinfo/adslmib _________________________________________________________________ STOP MORE 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 Mon Jun 9 12:56: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 MAA12314 for ; Mon, 9 Jun 2003 12:56:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59GuNj17183 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 12:56: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 h59GuNB17180 for ; Mon, 9 Jun 2003 12:56: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 MAA12294 for ; Mon, 9 Jun 2003 12:56:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPuV-0005D0-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 12:54:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PPuV-0005Cx-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 12:54:19 -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 h59GuDB17158; Mon, 9 Jun 2003 12:56:13 -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 h59GtVB17111 for ; Mon, 9 Jun 2003 12:55:31 -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 MAA12256; Mon, 9 Jun 2003 12:55:26 -0400 (EDT) From: Moti.Morgenstern@ecitele.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPtf-0005C9-00; Mon, 09 Jun 2003 12:53:27 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19PPte-0005C6-00; Mon, 09 Jun 2003 12:53:26 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h59Go4nS017132; Mon, 9 Jun 2003 19:50:04 +0300 (IDT) Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified To: rray@pesa.com Cc: adslmib@ietf.org, adslmib-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Mon, 9 Jun 2003 19:55:14 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 06/09/2003 07:55:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: , Bob and all, Any LCS tables that were in the -07 draft certainly belong to the WG charter/scope. The 2 newer drafts do not have those tables not because the tables "do not belong to the charter" but because of considering the DSLF TR. We now know how "mature" and serious is that DSLF management model. The DSLF itself, after everyone (except for ECI and maybe others too) was happy with the content of the TR, discovered a need for correcting the model EVERY MEETING since they published TR. Part of the findings are going to be included in a new working text (WT) but currently the DSLF model doesn't match the -09 draft. It seems that tsome people in our WG don't see a need to wait until the DSLF formally accept or reject those changes but (as Mike just said) "The one thing no one wants is TWO standards". If that is correct than we MUST hold our work until the DSLF members formally evaluate the corrected model. When Mike raised the possibility of having a "core" MIB and extension(s) to that MIB I assumed that this is a procedure which is fully within the charter. Now I see that even before discussing the missing SNMP objects there is a potential scenario that we won't be able to even start such an extension. I hear arguments such as "references to work that hasn't been done is not productive", while the same WG published RFC2662 with a reference to any external (proprietary) MIB. If the ADSL MIB can have a hook for a proprietary extension, why can't the VDSL MIB include a hook for a potential LCS extensions (proprietary or by IETF)? Best regards, Moti Morgenstern Senior Systems Engineer ECI Telecoms Ltd. Inovia Broadband Access Division 30 Hasivim St. Petach Tikva, Israel 49133 Tel.: +972-3-9266258 Fax: +972-3-9268182 Cell: +972-55-786258 e-mail: Moti.Morgenstern@ecitele.com www.ecitele.com Bob Ray To: adslmib mail list Sent by: cc: adslmib-admin@ Subject: [Adslmib] Re: VDSL Line Extension MIB - Modified ietf.org 09/06/03 17:15 Please respond to rray Felix (and all): This insistence that the hands of the IETF be bound by specific references to work that hasn't been chartered and by work that hasn't been done is not productive. I would suggest, instead, that those who feel most strongly about the "missing tables" do the following: a) dredge up a copy of the -07 draft b) write a draft vdsl-line-extension-mib using the missing tables c) submit the draft as an individual contribution to the IETF d) at the next meeting of the adslmib working group (perhaps Vienna), suggest that the charter be amended to support an extension MIB e) humbly offer the individual contribution to the working group as a good starting point for such work. f) work with (and in) the DSL Forum to achieve agreement as to THEIR preferred management objects. I believe this approach would be FAR MORE PRODUCTIVE... See: http://www.ietf.org/ietf/1id-guidelines.txt for information on accomplishing this. Regards, 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 Mon Jun 9 13:54: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 NAA14228 for ; Mon, 9 Jun 2003 13:54:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59HsMp21711 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 13:54:22 -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 h59HsLB21708 for ; Mon, 9 Jun 2003 13:54: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 NAA14167 for ; Mon, 9 Jun 2003 13:54:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PQoa-0005gR-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 13:52:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PQoa-0005gO-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 13:52:16 -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 h59HsDB21648; Mon, 9 Jun 2003 13:54:13 -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 h59HnsB21437 for ; Mon, 9 Jun 2003 13:49: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 NAA14023 for ; Mon, 9 Jun 2003 13:49:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PQkG-0005d5-00 for adslmib@ietf.org; Mon, 09 Jun 2003 13:47:49 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19PQkG-0005d2-00 for adslmib@ietf.org; Mon, 09 Jun 2003 13:47:48 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h59HnmGI538639 for ; Mon, 9 Jun 2003 12:49:49 -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 ; Mon, 09 Jun 2003 12:49:47 -0500 Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified From: Bob Ray Reply-To: rray@pesa.com To: Moti Morgenstern Cc: adslmib mail list In-Reply-To: References: Content-Type: text/plain Message-Id: <1055180986.19386.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 09 Jun 2003 12:49:46 -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 Mon, 2003-06-09 at 11:55, Moti.Morgenstern@ecitele.com wrote: > Any LCS tables that were in the -07 draft certainly belong to the WG > charter/scope. The 2 newer drafts do not have those tables not because the > tables "do not belong to the charter" but because of considering the DSLF > TR. We now know how "mature" and serious is that DSLF management model. The > DSLF itself, after everyone (except for ECI and maybe others too) was happy > with the content of the TR, discovered a need for correcting the model > EVERY MEETING since they published TR. Part of the findings are going to be > included in a new working text (WT) but currently the DSLF model doesn't > match the -09 draft. It seems that tsome people in our WG don't see a need > to wait until the DSLF formally accept or reject those changes but (as Mike > just said) "The one thing no one wants is TWO standards". If that is > correct than we MUST hold our work until the DSLF members formally evaluate > the corrected model. > > When Mike raised the possibility of having a "core" MIB and extension(s) to > that MIB I assumed that this is a procedure which is fully within the > charter. Now I see that even before discussing the missing SNMP objects > there is a potential scenario that we won't be able to even start such an > extension. I hear arguments such as "references to work that hasn't been > done is not productive", while the same WG published RFC2662 with a > reference to any external (proprietary) MIB. If the ADSL MIB can have a > hook for a proprietary extension, why can't the VDSL MIB include a hook for > a potential LCS extensions (proprietary or by IETF)? > > Best regards, > Moti Morgenstern Moti: I assume you are referring to the following lines from RFC2662: in section 5.2: It is intented that Line Code Specific MIBs be located under adslLCSMib. These MIBs will be defined in separate modules. and in section 7: -- Line Code Specific Tables -- These are place holders for the Line Code Specific MIBs -- once they become available. adslLCSMib OBJECT IDENTIFIER ::= { adslMibObjects 16 } It is my opinion that the above two are totally unnecessary. What is obviously necessary is that someone needs to take a day or two to create an individual submission ID and send it in. I've already defined all the tables - it would be little more than cut-and-paste (text from -07, objects from -07, text describing general approach from ADSL extension MIB). It surely would take less time than this ceaseless bickering we're going through :) I'm sorry that the DSLF is fractious. I don't see that changing any time soon, though. Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Mon Jun 9 14:16:41 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 OAA15070 for ; Mon, 9 Jun 2003 14:16:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59IGGr24128 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 14:16: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 h59IGGB24125 for ; Mon, 9 Jun 2003 14:16: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 OAA15022 for ; Mon, 9 Jun 2003 14:16:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PR9m-0005ul-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 14:14:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PR9l-0005ui-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 14:14:09 -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 h59IGAB24089; Mon, 9 Jun 2003 14:16: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 h59IFEB24051 for ; Mon, 9 Jun 2003 14:15: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 OAA14969 for ; Mon, 9 Jun 2003 14:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PR8n-0005uI-00 for adslmib@ietf.org; Mon, 09 Jun 2003 14:13:09 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19PR8m-0005uF-00 for adslmib@ietf.org; Mon, 09 Jun 2003 14:13:08 -0400 Received: from mailserver ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h59IF9GI615982 for ; Mon, 9 Jun 2003 13:15:09 -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 ; Mon, 09 Jun 2003 13:15:05 -0500 From: Bob Ray Reply-To: rray@pesa.com To: adslmib mail list Content-Type: text/plain Message-Id: <1055182504.21030.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 09 Jun 2003 13:15: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] Proposal for charter change 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 I propose that the following text be added to the charter of the adslmib working group: The working group will define a set of line code specific (LCS) managed objects to be used for management of Very high speed Digital Subscriber Line (VDSL) services. The MIB module defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described by the current (draft) VDSL Line MIB and the interfaces MIB. The working group will consider the input of the DSL forum in the definition of this MIB. Goals and Milestones: Jun 03 Produce Internet-Draft covering VDSL LCS management objects. Jul 03 Meet at Vienna IETF to review Internet-Drafts. Oct 03 Update Internet-Draft per working group input. Nov 03 Meet at Minneapolis IETF to review Internet-Drafts. Dec 03 Submit VDSL LCS MIB to IESG for consideration as Proposed Standard. Suggestions? Regards, Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Mon Jun 9 14:16:42 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 OAA15085 for ; Mon, 9 Jun 2003 14:16:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59IGHT24144 for adslmib-archive@odin.ietf.org; Mon, 9 Jun 2003 14:16: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 h59IGHB24141 for ; Mon, 9 Jun 2003 14:16: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 OAA15031 for ; Mon, 9 Jun 2003 14:16:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PR9n-0005uz-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 14:14:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PR9m-0005uu-00 for adslmib-web-archive@ietf.org; Mon, 09 Jun 2003 14:14: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 h59IGBB24113; Mon, 9 Jun 2003 14:16: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 h59IFvB24073 for ; Mon, 9 Jun 2003 14:15:57 -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 OAA15004 for ; Mon, 9 Jun 2003 14:15:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PR9T-0005uO-00 for adslmib@ietf.org; Mon, 09 Jun 2003 14:13:51 -0400 Received: from law14-f42.law14.hotmail.com ([64.4.21.42] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19PR9T-0005uL-00 for adslmib@ietf.org; Mon, 09 Jun 2003 14:13:51 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Jun 2003 11:15:21 -0700 Received: from 66.152.60.98 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 09 Jun 2003 18:15:19 GMT X-Originating-IP: [66.152.60.98] X-Originating-Email: [sneedmike@hotmail.com] From: "Michael Sneed" To: adslmib@ietf.org Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified Date: Mon, 09 Jun 2003 14:15:19 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jun 2003 18:15:21.0894 (UTC) FILETIME=[1726AC60:01C32EB3] 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: , Just to clarify (because there are a couple of lines of argument going on here and it is easy for me to get confused): 1) The issue of LCS configuration objects in the current MIB is not a charter issue. They are neither required nor excluded by the charter. I think we all agree on this. 2) It is my assumption that producing an LCS MIB would require a charter revision. This is really only because we would be producing a new document. If editor(s) are available for this work it is unlikely the work would not be chartered. I expect the risk is probably about the same as that we get shut down before promoting the VDSL MIB for failure to reach a consensus ;-). It might be possible to do it without a new charter, since the functionality is not exluded from the current charter, but it is best to revise the charter to match the work. 3) There are three possible ways to proceed from here (as I see it): i) Promote the current VDSL MIB and recharter to do the LCS MIB when it can be done consistent with the DSLF. ii) Hold the VDSL MIB until we can do LCS configuration consistent with the DSLF. iii) Promote the VDSL MIB and drop LCS altogether for the time being. iv) Revert to the scheme of LCS management in -07 and promote that. If I understand Moti, he is recommending ii), while I recommend i). I haven't heard anyone argue for iii). I don't think I have heard anyone recommend iv), but sometimes I am not so sure. 4) There is still debate over whether to refer to LCS MIBs if we pursue option i) or iii). I don't understand this argument, because I fail to see the usefulness of the proposed references. The case of 2662 is not a good example, because the LCS MIBs were never written, and that whole issue would disappear were the document updated. So we need to reach consensus on items 3) and 4) if we are going to make progress. I would like to see the current draft move forward, because I think it is useful in its current form. The lack of LCS configuration functionality does not detract from the usefulness of what is there; delaying the LCS features simply reflects the reality of maintaining consistency with the DSLF. Can any one argue why we will not be better off with the core MIB at Proposed, rather than a constantly morphing ID? The argument that this leaves the door open to proporietary implementations does not hold water; without having the core at Proposed the door is MUCH wider, because there is NO standard. >From: Moti.Morgenstern@ecitele.com >To: rray@pesa.com >CC: adslmib@ietf.org, adslmib-admin@ietf.org >Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified >Date: Mon, 9 Jun 2003 19:55:14 +0300 > > >Bob and all, > >Any LCS tables that were in the -07 draft certainly belong to the WG >charter/scope. The 2 newer drafts do not have those tables not because the >tables "do not belong to the charter" but because of considering the DSLF >TR. We now know how "mature" and serious is that DSLF management model. The >DSLF itself, after everyone (except for ECI and maybe others too) was happy >with the content of the TR, discovered a need for correcting the model >EVERY MEETING since they published TR. Part of the findings are going to be >included in a new working text (WT) but currently the DSLF model doesn't >match the -09 draft. It seems that tsome people in our WG don't see a need >to wait until the DSLF formally accept or reject those changes but (as Mike >just said) "The one thing no one wants is TWO standards". If that is >correct than we MUST hold our work until the DSLF members formally evaluate >the corrected model. > >When Mike raised the possibility of having a "core" MIB and extension(s) to >that MIB I assumed that this is a procedure which is fully within the >charter. Now I see that even before discussing the missing SNMP objects >there is a potential scenario that we won't be able to even start such an >extension. I hear arguments such as "references to work that hasn't been >done is not productive", while the same WG published RFC2662 with a >reference to any external (proprietary) MIB. If the ADSL MIB can have a >hook for a proprietary extension, why can't the VDSL MIB include a hook for >a potential LCS extensions (proprietary or by IETF)? > >Best regards, >Moti Morgenstern > >Senior Systems Engineer >ECI Telecoms Ltd. >Inovia Broadband Access Division >30 Hasivim St. >Petach Tikva, Israel 49133 >Tel.: +972-3-9266258 >Fax: +972-3-9268182 >Cell: +972-55-786258 >e-mail: Moti.Morgenstern@ecitele.com >www.ecitele.com > > > > > Bob Ray pesa.com> To: adslmib mail list > > Sent by: cc: > adslmib-admin@ Subject: [Adslmib] Re: VDSL >Line Extension MIB - Modified > ietf.org > > > 09/06/03 17:15 > Please respond > to rray > > > > > >Felix (and all): > >This insistence that the hands of the IETF be bound by specific >references to work that hasn't been chartered and by work that >hasn't been done is not productive. > >I would suggest, instead, that those who feel most strongly >about the "missing tables" do the following: > >a) dredge up a copy of the -07 draft >b) write a draft vdsl-line-extension-mib using the missing > tables >c) submit the draft as an individual contribution to the > IETF >d) at the next meeting of the adslmib working group (perhaps > Vienna), suggest that the charter be amended to support > an extension MIB >e) humbly offer the individual contribution to the working > group as a good starting point for such work. >f) work with (and in) the DSL Forum to achieve agreement as > to THEIR preferred management objects. > >I believe this approach would be FAR MORE PRODUCTIVE... > >See: http://www.ietf.org/ietf/1id-guidelines.txt for information >on accomplishing this. > >Regards, >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 _________________________________________________________________ The new MSN 8: smart spam protection and 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 Tue Jun 10 09:33: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 JAA29540 for ; Tue, 10 Jun 2003 09:33:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ADWcI21572 for adslmib-archive@odin.ietf.org; Tue, 10 Jun 2003 09:32:38 -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 h5ADWcB21569 for ; Tue, 10 Jun 2003 09:32:38 -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 JAA29512 for ; Tue, 10 Jun 2003 09:32:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjCp-0006Hd-00 for adslmib-web-archive@ietf.org; Tue, 10 Jun 2003 09:30:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PjCp-0006HZ-00 for adslmib-web-archive@ietf.org; Tue, 10 Jun 2003 09:30: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 h5ADWPB21538; Tue, 10 Jun 2003 09:32: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 h5ADVlB21445 for ; Tue, 10 Jun 2003 09:31:47 -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 JAA29497 for ; Tue, 10 Jun 2003 09:31:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjC0-0006HH-00 for adslmib@ietf.org; Tue, 10 Jun 2003 09:29:40 -0400 Received: from hostr51.alcatel.com ([143.209.5.1] helo=aurfsy.aur.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 19PjC0-0006H9-00 for adslmib@ietf.org; Tue, 10 Jun 2003 09:29:40 -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 h5ADV5v04538; Tue, 10 Jun 2003 09:31:05 -0400 (EDT) Message-ID: <3EE5DD99.B037FB1E@alcatel.com> Date: Tue, 10 Jun 2003 09:31:05 -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: Menachem.Dodge@infineon.com CC: felix.flemisch@siemens.com, adslmib@ietf.org, rray@pesa.com Subject: Re: [Adslmib] VDSL Line Extension MIB References: 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 Menachem, The question is not about usefulness of some detailed parameters under special (mostly diagnostic) circumstances. The only issue is about such parameters being required for basic operation. The core MIB defines the parameters needed for normal operation, and should be kept as simple as possible. Support for detailed diagnostic parameters can be an optional extension. So indeed, if there is sufficient interest in developing optional line-code-specific extension MIBs, that can be undertaken as a separate work-item. The DSL Forum is capturing the requirements for just such optional LCS extensions in the current PD documents. Feel free to contribute to those. Regards, Rajesh Menachem.Dodge@infineon.com wrote: > Hi Rajesh, > > As an operator interface there are circumstances when the operator > would like to define or monitor > some or all of the physical parameters directly. The operator Should be > given this choice. There are other similar > choices in the MIB such as vdslLineConfDownstreamRateMode which can be set > to Manual rather than be configured > automatically. In addition the MIB allows non-standard bandplans and the use > of them may be a necessity, due to cross talk from other equipment already > deployed in the network, or even as a choice of the operator. In these > circumstances > the direct definition of the physical parameters is a necessity for the > operator. > Clearly the missing parameters are the LCS parameters that have been > removed from this core MIB and > will be defined in the extension MIB. Again it is not a question of > unnecessary complications but one of choice/necessity of the operator. > Lets agree to put this information in the extension MIB and the > operator can choose whether to make > use of it or not. > > Regards, > Menachem > > -----Original Message----- > From: Rajesh Abbi [mailto:Rajesh.Abbi@alcatel.com] > Sent: Friday, June 06, 2003 5:12 PM > To: Flemisch Felix > Cc: adslmib@ietf.org; rray@pesa.com; Menachem Dodge > Subject: Re: [Adslmib] VDSL Line Extension MIB > > Hi Felix, > > Please see my respone below ... > > Regards, > > Rajesh > > Flemisch Felix wrote: > > > Hi all, > > > > on 5th June Bob Ray (16:00) and Rajesh Abbi (17:22) argued that > > the proposed new object "vdslLineConfProfileLCSExt" should not > > be needed in the VDSL Line MIB. > > > > Sorry that I have to disagree with the co-editors > > but it definitely IS needed. > > > > Its purpose is twofold: > > > > 1. vdslLineConfProfileLCSExt documents the commitment of the > > adslmib WG (and IETF) to develop an LCS VDSL Line Extension > > MIB (VDSL-LINE-EXT-MIB). While the details of this MIB are > > under discussion, it is no longer the case that "the issue of > > LCS extension is still under discussion", as Rajesh stated. > > On the contrary, DSLF started work on it, and the adslmib WG > > shall be obliged to translate the resulting LCS management > > framework extension to an SNMP extension MIB. > > The formal starting point would be vdsl-07. > > The DSL Forum made it an objective to keep the VDSL Management > working-text (WT-068) line-code independent. There were some > concerns at that time from ECI about the adequacy of the existing > parameters in WT-068 for SCM management, so a separate proposed-draft > (PD-015) was created to capture additional SCM-specific parameters. > Subsequently, a few additional line-code independent parameters were > identified that addressed the remaining concerns for SCM configuration. > These additional parameters are already included in the IETF draft, and > will be included in an addendum to the DSL Forum TR-057 (ex WT-068). > The LCS PDs are now optional extensions to TR-057. > > > 2. For an individual VDSL line, vdslLineConfProfileLCSExt > > clarifies whether for the configuration of this line > > LCS extensions are needed or not and if they are needed > > how the respective rows are identified. This settles a > > discussion that took place in the adslmib WG from 20th > > to 25th May and remained unsettled so far. > > I have seen general comments so far about how the current draft is not > adequate. I would like to see specific additional parameter(s) you believe > are necessary for the MIB. > > It should be noted that the MIB is intended to be an 'operator' interface > and > not a chipset/driver interface. Only parameters that an operator wishes to > control are included in order to keep it simple to use. > > > If you do not commit to this object, you still allow ANY > > undocumented relationship from the core VDSL Line Configuration > > Profile table to vendor-specific LCS extension tables, and you > > leave it unclarified whether the core configuration parameters > > are sufficient to configure individual VDSL lines. > > > This is clearly not what we want, and the commitment to develop > > a standardized VDSL-LINE-EXT-MIB is needed NOW. > > > > Note that from the object vdslLineConfProfile it is impossible > > to decide whether LCS configuration parameters for an individual > > VDSL line are needed respectively are present at all. This is > > what I previously called "removal of the eight LCS profile > > tables without trace". The proposed new object gives back > > the missing trace to the removed tables. > > The LCS extensions are simply that. The core MIB should not be made > 'aware' of the extensions. As noted above, at this time LCS extensions > are still deemed 'optional'. Hopefully we can keep it that way to avoid > unnecessary complication for the user. > > > Regards, > > > > Felix _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Tue Jun 10 10:26: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 KAA02731 for ; Tue, 10 Jun 2003 10:26:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AEQIY26281 for adslmib-archive@odin.ietf.org; Tue, 10 Jun 2003 10:26: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 h5AEQIB26278 for ; Tue, 10 Jun 2003 10:26:18 -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 KAA02704 for ; Tue, 10 Jun 2003 10:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pk2k-0006pY-00 for adslmib-web-archive@ietf.org; Tue, 10 Jun 2003 10:24:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pk2j-0006pV-00 for adslmib-web-archive@ietf.org; Tue, 10 Jun 2003 10:24:09 -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 h5AEQ8B26240; Tue, 10 Jun 2003 10:26: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 h5AEMhB26037 for ; Tue, 10 Jun 2003 10:22: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 KAA02610; Tue, 10 Jun 2003 10:22:37 -0400 (EDT) From: Moti.Morgenstern@ecitele.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjzH-0006o2-00; Tue, 10 Jun 2003 10:20:35 -0400 Received: from mink.ecitele.com ([147.234.1.100]) by ietf-mx with esmtp (Exim 4.12) id 19PjzG-0006nz-00; Tue, 10 Jun 2003 10:20:35 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.8+Sun/8.12.8) with ESMTP id h5AEH6nS022798; Tue, 10 Jun 2003 17:17:07 +0300 (IDT) Subject: Re: [Adslmib] VDSL Line Extension MIB To: Rajesh Abbi Cc: adslmib@ietf.org, adslmib-admin@ietf.org, felix.flemisch@siemens.com, Menachem.Dodge@infineon.com, rray@pesa.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Tue, 10 Jun 2003 17:22:17 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 06/10/2003 05:22:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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 Rajesh, I believe that what Menachem and Felix say is: What you call "core MIB" is not enough for deterministically configuring ANY VDSL line. They sure don't think the missing parameters are "mostly diagnostic". Currently, we are busy in procedural issues instead of evaluating their input and decide whether their claims are true or not. The problem is that WT-68 doesn't seem to be an excellent example of a solid document that we can really be sure it reflects a "complete management model". In fact it went through ballots and became a TR even though several important objects were "forgotten" which is expected only with very detailed documents (TR-57 is relatively high-level). What I say, and I'm really sorry I have to point-out this, is that the last steps of the process were too quick, with too many sharp maneuvers and probably weren't so serious/professional. In fact I'm sure that most of the members, excluding you as the editor (this time you managed to escape from my criticism...) and me who voted "Not Approve" (and then sent a contribution against the TR), didn't even read the TR. You also remember that our group invited a BtExact person to explain the exact characteristics of "their" missing parameters, which is very strange, considering the fact that those specific parameters were already agreed 3 months before. If that wasn't sad it could be a very good joke. Best regards, Moti Rajesh Abbi cc: felix.flemisch@siemens.com, adslmib@ietf.org, rray@pesa.com Sent by: Subject: Re: [Adslmib] VDSL Line Extension MIB adslmib-admin@ ietf.org 10/06/03 16:31 Menachem, The question is not about usefulness of some detailed parameters under special (mostly diagnostic) circumstances. The only issue is about such parameters being required for basic operation. The core MIB defines the parameters needed for normal operation, and should be kept as simple as possible. Support for detailed diagnostic parameters can be an optional extension. So indeed, if there is sufficient interest in developing optional line-code-specific extension MIBs, that can be undertaken as a separate work-item. The DSL Forum is capturing the requirements for just such optional LCS extensions in the current PD documents. Feel free to contribute to those. Regards, Rajesh Menachem.Dodge@infineon.com wrote: > Hi Rajesh, > > As an operator interface there are circumstances when the operator > would like to define or monitor > some or all of the physical parameters directly. The operator Should be > given this choice. There are other similar > choices in the MIB such as vdslLineConfDownstreamRateMode which can be set > to Manual rather than be configured > automatically. In addition the MIB allows non-standard bandplans and the use > of them may be a necessity, due to cross talk from other equipment already > deployed in the network, or even as a choice of the operator. In these > circumstances > the direct definition of the physical parameters is a necessity for the > operator. > Clearly the missing parameters are the LCS parameters that have been > removed from this core MIB and > will be defined in the extension MIB. Again it is not a question of > unnecessary complications but one of choice/necessity of the operator. > Lets agree to put this information in the extension MIB and the > operator can choose whether to make > use of it or not. > > Regards, > Menachem > > -----Original Message----- > From: Rajesh Abbi [mailto:Rajesh.Abbi@alcatel.com] > Sent: Friday, June 06, 2003 5:12 PM > To: Flemisch Felix > Cc: adslmib@ietf.org; rray@pesa.com; Menachem Dodge > Subject: Re: [Adslmib] VDSL Line Extension MIB > > Hi Felix, > > Please see my respone below ... > > Regards, > > Rajesh > > Flemisch Felix wrote: > > > Hi all, > > > > on 5th June Bob Ray (16:00) and Rajesh Abbi (17:22) argued that > > the proposed new object "vdslLineConfProfileLCSExt" should not > > be needed in the VDSL Line MIB. > > > > Sorry that I have to disagree with the co-editors > > but it definitely IS needed. > > > > Its purpose is twofold: > > > > 1. vdslLineConfProfileLCSExt documents the commitment of the > > adslmib WG (and IETF) to develop an LCS VDSL Line Extension > > MIB (VDSL-LINE-EXT-MIB). While the details of this MIB are > > under discussion, it is no longer the case that "the issue of > > LCS extension is still under discussion", as Rajesh stated. > > On the contrary, DSLF started work on it, and the adslmib WG > > shall be obliged to translate the resulting LCS management > > framework extension to an SNMP extension MIB. > > The formal starting point would be vdsl-07. > > The DSL Forum made it an objective to keep the VDSL Management > working-text (WT-068) line-code independent. There were some > concerns at that time from ECI about the adequacy of the existing > parameters in WT-068 for SCM management, so a separate proposed-draft > (PD-015) was created to capture additional SCM-specific parameters. > Subsequently, a few additional line-code independent parameters were > identified that addressed the remaining concerns for SCM configuration. > These additional parameters are already included in the IETF draft, and > will be included in an addendum to the DSL Forum TR-057 (ex WT-068). > The LCS PDs are now optional extensions to TR-057. > > > 2. For an individual VDSL line, vdslLineConfProfileLCSExt > > clarifies whether for the configuration of this line > > LCS extensions are needed or not and if they are needed > > how the respective rows are identified. This settles a > > discussion that took place in the adslmib WG from 20th > > to 25th May and remained unsettled so far. > > I have seen general comments so far about how the current draft is not > adequate. I would like to see specific additional parameter(s) you believe > are necessary for the MIB. > > It should be noted that the MIB is intended to be an 'operator' interface > and > not a chipset/driver interface. Only parameters that an operator wishes to > control are included in order to keep it simple to use. > > > If you do not commit to this object, you still allow ANY > > undocumented relationship from the core VDSL Line Configuration > > Profile table to vendor-specific LCS extension tables, and you > > leave it unclarified whether the core configuration parameters > > are sufficient to configure individual VDSL lines. > > > This is clearly not what we want, and the commitment to develop > > a standardized VDSL-LINE-EXT-MIB is needed NOW. > > > > Note that from the object vdslLineConfProfile it is impossible > > to decide whether LCS configuration parameters for an individual > > VDSL line are needed respectively are present at all. This is > > what I previously called "removal of the eight LCS profile > > tables without trace". The proposed new object gives back > > the missing trace to the removed tables. > > The LCS extensions are simply that. The core MIB should not be made > 'aware' of the extensions. As noted above, at this time LCS extensions > are still deemed 'optional'. Hopefully we can keep it that way to avoid > unnecessary complication for the user. > > > Regards, > > > > Felix _______________________________________________ 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 Jun 12 07:44: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 HAA04434 for ; Thu, 12 Jun 2003 07:44:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBiG612317 for adslmib-archive@odin.ietf.org; Thu, 12 Jun 2003 07:44: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 h5CBiGm12314 for ; Thu, 12 Jun 2003 07:44: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 HAA04418 for ; Thu, 12 Jun 2003 07:44:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQT2-0000sj-00 for adslmib-web-archive@ietf.org; Thu, 12 Jun 2003 07:42:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QQT2-0000sf-00 for adslmib-web-archive@ietf.org; Thu, 12 Jun 2003 07:42:08 -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 h5CBiBm12291; Thu, 12 Jun 2003 07:44: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 h5CBhpm12271 for ; Thu, 12 Jun 2003 07:43:51 -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 HAA04390 for ; Thu, 12 Jun 2003 07:43:50 -0400 (EDT) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQSd-0000s4-00 for adslmib@ietf.org; Thu, 12 Jun 2003 07:41:43 -0400 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 19QQSc-0000rv-00 for adslmib@ietf.org; Thu, 12 Jun 2003 07:41:42 -0400 Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228]) by smtp2.infineon.com (8.12.9/8.12.9) with ESMTP id h5CBgbUL014643; Thu, 12 Jun 2003 13:42:38 +0200 (MEST) Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 13:43:09 +0200 Message-ID: To: rray@pesa.com, adslmib@ietf.org Subject: RE: [Adslmib] Proposal for charter change Date: Thu, 12 Jun 2003 14:38:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: adslmib-admin@ietf.org Errors-To: adslmib-admin@ietf.org X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: ADSLMIB List-Post: List-Help: List-Subscribe: , Hi Bob, I agree and welcome your proposal to change the charter of the adslmib working group to define the LCS managed objects. I would like to bring to the attention of the working group that the IEEE 802.3ah EFM Task Force have written a draft document D1.732 which defines a set of registers to be used for management of both SCM and MCM interfaces. They are working with the IETF Ethernet Interfaces and Hub MIB WG and should begin work on an EFM ('generic') MIB. If a common interface layering model can be worked out they will be able to benefit from our work on the VDSL MIB. This would make a lot more sense than them redefining what we have already written. I suggest that we add to our charter, the need for a common interface layer model and cooperation with the Ethernet MIB WG and the IEEE 802.3ah EFM Task Force. The second paragraph should be modified to reflect this, here is my suggestion: "The working group will consider the input of the DSL forum and the IEEE 802.3ah EFM Task Force in the definition of this MIB. The working group will cooperate with the Ethernet MIB WG in defining a common interface layering model and in defining the LCS managed objects." I also agree to the goals and milestones and hope that the working group will indeed keep to this schedule. Best Regards, Menachem Dodge. Infineon Technologies. -----Original Message----- From: Bob Ray [mailto:rray@pesa.com] Sent: Monday, June 09, 2003 8:15 PM To: adslmib mail list Subject: [Adslmib] Proposal for charter change I propose that the following text be added to the charter of the adslmib working group: The working group will define a set of line code specific (LCS) managed objects to be used for management of Very high speed Digital Subscriber Line (VDSL) services. The MIB module defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described by the current (draft) VDSL Line MIB and the interfaces MIB. The working group will consider the input of the DSL forum in the definition of this MIB. Goals and Milestones: Jun 03 Produce Internet-Draft covering VDSL LCS management objects. Jul 03 Meet at Vienna IETF to review Internet-Drafts. Oct 03 Update Internet-Draft per working group input. Nov 03 Meet at Minneapolis IETF to review Internet-Drafts. Dec 03 Submit VDSL LCS MIB to IESG for consideration as Proposed Standard. Suggestions? Regards, 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 Thu Jun 12 07:48: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 HAA04818 for ; Thu, 12 Jun 2003 07:48:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBmEr12555 for adslmib-archive@odin.ietf.org; Thu, 12 Jun 2003 07:48: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 h5CBm4m12547 for ; Thu, 12 Jun 2003 07:48:04 -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 HAA04756 for ; Thu, 12 Jun 2003 07:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQWi-0000yU-00 for adslmib-web-archive@ietf.org; Thu, 12 Jun 2003 07:45:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QQWh-0000yQ-00 for adslmib-web-archive@ietf.org; Thu, 12 Jun 2003 07:45:55 -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 h5CBl4m12514; Thu, 12 Jun 2003 07:47:04 -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 h5CBkrm12493 for ; Thu, 12 Jun 2003 07:46: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 HAA04589 for ; Thu, 12 Jun 2003 07:46:51 -0400 (EDT) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQVZ-0000uk-00 for adslmib@ietf.org; Thu, 12 Jun 2003 07:44:45 -0400 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 19QQVV-0000tt-00 for adslmib@ietf.org; Thu, 12 Jun 2003 07:44:41 -0400 Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228]) by smtp2.infineon.com (8.12.9/8.12.9) with ESMTP id h5CBjZUH015409; Thu, 12 Jun 2003 13:45:35 +0200 (MEST) Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 13:46:08 +0200 Message-ID: To: sneedmike@hotmail.com, adslmib@ietf.org Subject: RE: [Adslmib] Re: VDSL Line Extension MIB - Modified Date: Thu, 12 Jun 2003 14:41:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: adslmib-admin@ietf.org Errors-To: adslmib-admin@ietf.org X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: ADSLMIB List-Post: List-Help: List-Subscribe: , Hi Mike, I think, based on all the previous discussion, that the only way that everyone in the working group will agree to proceed is if with adopt option 3) i) "Promote the current VDSL MIB and recharter to do the LCS MIB when it can be done consistent with the DSLF." This is also consistent with Bob Ray's email suggesting a change to the charter. Option 3) iii) "Promote the VDSL MIB and drop LCS altogether for the time being." is completely unacceptable. Item 4) "There is still debate over whether to refer to LCS MIBs ..." If we divide the MIB into two parts the core MIB and the LCS MIB then it makes sense that within the core MIB there is explanation and reference to the LCS MIBs. I would have thought that the example of RFC 2662 is a good example as it shows that when there is a core MIB and an extension MIB there is a need to reference the extension in the core MIB. If we adopt 3) i) and stick to the timetable set out by Bob Ray we will not have a problem of having a core MIB with references to a non-existing extension MIB. I suggest that we accept option 3) i) and also Bob Ray's modification to the charter (with my additions) and the Goals and Milestones that Bob outlined. Regards, Menachem Dodge -----Original Message----- From: Michael Sneed [mailto:sneedmike@hotmail.com] Sent: Monday, June 09, 2003 8:15 PM To: adslmib@ietf.org Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified Just to clarify (because there are a couple of lines of argument going on here and it is easy for me to get confused): 1) The issue of LCS configuration objects in the current MIB is not a charter issue. They are neither required nor excluded by the charter. I think we all agree on this. 2) It is my assumption that producing an LCS MIB would require a charter revision. This is really only because we would be producing a new document. If editor(s) are available for this work it is unlikely the work would not be chartered. I expect the risk is probably about the same as that we get shut down before promoting the VDSL MIB for failure to reach a consensus ;-). It might be possible to do it without a new charter, since the functionality is not exluded from the current charter, but it is best to revise the charter to match the work. 3) There are three possible ways to proceed from here (as I see it): i) Promote the current VDSL MIB and recharter to do the LCS MIB when it can be done consistent with the DSLF. ii) Hold the VDSL MIB until we can do LCS configuration consistent with the DSLF. iii) Promote the VDSL MIB and drop LCS altogether for the time being. iv) Revert to the scheme of LCS management in -07 and promote that. If I understand Moti, he is recommending ii), while I recommend i). I haven't heard anyone argue for iii). I don't think I have heard anyone recommend iv), but sometimes I am not so sure. 4) There is still debate over whether to refer to LCS MIBs if we pursue option i) or iii). I don't understand this argument, because I fail to see the usefulness of the proposed references. The case of 2662 is not a good example, because the LCS MIBs were never written, and that whole issue would disappear were the document updated. So we need to reach consensus on items 3) and 4) if we are going to make progress. I would like to see the current draft move forward, because I think it is useful in its current form. The lack of LCS configuration functionality does not detract from the usefulness of what is there; delaying the LCS features simply reflects the reality of maintaining consistency with the DSLF. Can any one argue why we will not be better off with the core MIB at Proposed, rather than a constantly morphing ID? The argument that this leaves the door open to proporietary implementations does not hold water; without having the core at Proposed the door is MUCH wider, because there is NO standard. >From: Moti.Morgenstern@ecitele.com >To: rray@pesa.com >CC: adslmib@ietf.org, adslmib-admin@ietf.org >Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified >Date: Mon, 9 Jun 2003 19:55:14 +0300 > > >Bob and all, > >Any LCS tables that were in the -07 draft certainly belong to the WG >charter/scope. The 2 newer drafts do not have those tables not because the >tables "do not belong to the charter" but because of considering the DSLF >TR. We now know how "mature" and serious is that DSLF management model. The >DSLF itself, after everyone (except for ECI and maybe others too) was happy >with the content of the TR, discovered a need for correcting the model >EVERY MEETING since they published TR. Part of the findings are going to be >included in a new working text (WT) but currently the DSLF model doesn't >match the -09 draft. It seems that tsome people in our WG don't see a need >to wait until the DSLF formally accept or reject those changes but (as Mike >just said) "The one thing no one wants is TWO standards". If that is >correct than we MUST hold our work until the DSLF members formally evaluate >the corrected model. > >When Mike raised the possibility of having a "core" MIB and extension(s) to >that MIB I assumed that this is a procedure which is fully within the >charter. Now I see that even before discussing the missing SNMP objects >there is a potential scenario that we won't be able to even start such an >extension. I hear arguments such as "references to work that hasn't been >done is not productive", while the same WG published RFC2662 with a >reference to any external (proprietary) MIB. If the ADSL MIB can have a >hook for a proprietary extension, why can't the VDSL MIB include a hook for >a potential LCS extensions (proprietary or by IETF)? > >Best regards, >Moti Morgenstern > >Senior Systems Engineer >ECI Telecoms Ltd. >Inovia Broadband Access Division >30 Hasivim St. >Petach Tikva, Israel 49133 >Tel.: +972-3-9266258 >Fax: +972-3-9268182 >Cell: +972-55-786258 >e-mail: Moti.Morgenstern@ecitele.com >www.ecitele.com > > > > > Bob Ray pesa.com> To: adslmib mail list > > Sent by: cc: > adslmib-admin@ Subject: [Adslmib] Re: VDSL >Line Extension MIB - Modified > ietf.org > > > 09/06/03 17:15 > Please respond > to rray > > > > > >Felix (and all): > >This insistence that the hands of the IETF be bound by specific >references to work that hasn't been chartered and by work that >hasn't been done is not productive. > >I would suggest, instead, that those who feel most strongly >about the "missing tables" do the following: > >a) dredge up a copy of the -07 draft >b) write a draft vdsl-line-extension-mib using the missing > tables >c) submit the draft as an individual contribution to the > IETF >d) at the next meeting of the adslmib working group (perhaps > Vienna), suggest that the charter be amended to support > an extension MIB >e) humbly offer the individual contribution to the working > group as a good starting point for such work. >f) work with (and in) the DSL Forum to achieve agreement as > to THEIR preferred management objects. > >I believe this approach would be FAR MORE PRODUCTIVE... > >See: http://www.ietf.org/ietf/1id-guidelines.txt for information >on accomplishing this. > >Regards, >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 _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ 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 Fri Jun 13 04:50: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 EAA25429 for ; Fri, 13 Jun 2003 04:50:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D8oR920669 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 04:50:27 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8oRm20666 for ; Fri, 13 Jun 2003 04:50:27 -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 EAA25421 for ; Fri, 13 Jun 2003 04:50:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QkEL-0002rI-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 04:48:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QkEK-0002rF-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 04:48:16 -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 h5CJL1a18189; Thu, 12 Jun 2003 15:21:01 -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 h5CJKCm18154 for ; Thu, 12 Jun 2003 15:20:12 -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 PAA24669 for ; Thu, 12 Jun 2003 15:20:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QXaG-0005Rh-00 for adslmib@ietf.org; Thu, 12 Jun 2003 15:18:04 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19QXaF-0005Re-00 for adslmib@ietf.org; Thu, 12 Jun 2003 15:18:03 -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 VAA04999 for ; Thu, 12 Jun 2003 21:20:04 +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 VAA28905 for ; Thu, 12 Jun 2003 21:20:03 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 21:19:34 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE91@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Date: Thu, 12 Jun 2003 21:19:34 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Adslmib] Re: VDSL Line Extension MIB - Modified 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: , As a comment to my e-mail of 09 Jun 2003 03:33:53 +0200 (msg00263) Bob Ray wrote on 09 Jun 2003 09:15:55 -0500 (msg00265) > This insistence that the hands of the IETF be bound by specific > references to work that hasn't been chartered and by work that > hasn't been done is not productive. > ... > I believe this approach would be FAR MORE PRODUCTIVE... In my e-mail entitled "VDSL Line Extension MIB - Modified" I'm proposing four very concrete text fragments how to improve the current text of vdsl-09 (or vdsl-09a) regarding the structure of line configuration profile tables. That structure needs to include the agreed core table of vdsl-09 and a set of LCS tables. From the overall discussion in the WG I conclude that my point of view is widely adopted. But for some foggy reason this common understanding shall not be documented in the core VDSL MIB. The most productive way to proceed would be to provide corrections to my proposed text fragments that incorporate the positions of the WG members that do not agree with my wordings. Mike Sneed wrote on 09 Jun 2003 14:15:19 -0400 (msg00270) > 3) There are three possible ways to proceed from here (as I see it): > i) Promote the current VDSL MIB and recharter to do the LCS MIB > when it can be done consistent with the DSLF. > ii) Hold the VDSL MIB until we can do LCS configuration > consistent with the DSLF. > iii) Promote the VDSL MIB and drop LCS altogether for the time being. > iv) Revert to the scheme of LCS management in -07 and promote that. ... > 4) There is still debate over whether to refer to LCS MIBs if we > pursue option i) or iii). ... ... I recommend 3)i) and request that we do the LCS MIB in close cooperation with the DSLF so that "when it can be done consistent with the DSLF" is compeletely out of the question. Since the DSLF OpNM WG seems to be fully aware of the current state of art I can't see any problem there. Regarding 4) I recommend at the same time to refer to LCS MIBs from the core MIB (sic!) either according to my proposals (see my e-mail cited above) or according to any agreed modifications of these proposals submitted by somebody else. Regards, Felix Flemisch _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 13 09:21:30 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 JAA02616 for ; Fri, 13 Jun 2003 09:21:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DDL2U09742 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 09:21:02 -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 h5DDL2m09739 for ; Fri, 13 Jun 2003 09:21: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 JAA02594 for ; Fri, 13 Jun 2003 09:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QoSB-0004gj-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 09:18:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QoSB-0004gf-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 09:18: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 h5D5c0a27171; Fri, 13 Jun 2003 01:38: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 h5D5bcm27044 for ; Fri, 13 Jun 2003 01:37:38 -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 BAA09605 for ; Fri, 13 Jun 2003 01:37:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QhDk-0001NA-00 for adslmib@ietf.org; Fri, 13 Jun 2003 01:35:28 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19QhDj-0001N7-00 for adslmib@ietf.org; Fri, 13 Jun 2003 01:35:27 -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 HAA07609 for ; Fri, 13 Jun 2003 07:37:34 +0200 (MET DST) Received: from mchh273e.demchh201e.icn.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id HAA20842 for ; Fri, 13 Jun 2003 07:37:34 +0200 (MET DST) Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 13 Jun 2003 07:37:06 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AE92@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Date: Fri, 13 Jun 2003 07:37:05 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Adslmib] FW: Re: VDSL Line Extension MIB - Modified 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'm resending this e-mail because I'm not sure whether it reached IETF's mail server. -----Original Message----- From: Flemisch Felix Sent: Thursday, June 12, 2003 9:20 PM To: 'adslmib@ietf.org' Subject: Re: VDSL Line Extension MIB - Modified Importance: High As a comment to my e-mail of 09 Jun 2003 03:33:53 +0200 (msg00263) Bob Ray wrote on 09 Jun 2003 09:15:55 -0500 (msg00265) > This insistence that the hands of the IETF be bound by specific > references to work that hasn't been chartered and by work that > hasn't been done is not productive. > ... > I believe this approach would be FAR MORE PRODUCTIVE... In my e-mail entitled "VDSL Line Extension MIB - Modified" I'm proposing four very concrete text fragments how to improve the current text of vdsl-09 (or vdsl-09a) regarding the structure of line configuration profile tables. That structure needs to include the agreed core table of vdsl-09a and a set of LCS tables. From the overall discussion in the WG I conclude that my point of view is widely adopted. But for some foggy reason this common understanding shall not be documented in the core VDSL MIB. The most productive way to proceed would be to provide corrections to my proposed text fragments that incorporate the positions of the WG members that do not agree with my wordings. Mike Sneed wrote on 09 Jun 2003 14:15:19 -0400 (msg00270) > 3) There are three possible ways to proceed from here (as I see it): > i) Promote the current VDSL MIB and recharter to do the LCS MIB > when it can be done consistent with the DSLF. > ii) Hold the VDSL MIB until we can do LCS configuration > consistent with the DSLF. > iii) Promote the VDSL MIB and drop LCS altogether for the time being. > iv) Revert to the scheme of LCS management in -07 and promote that. ... > 4) There is still debate over whether to refer to LCS MIBs if we > pursue option i) or iii). ... ... I recommend 3)i) and request that we do the LCS MIB in close cooperation with the DSLF so that "when it can be done consistent with the DSLF" is completely out of the question. Since the DSLF OpNM WG seems to be fully aware of the current state of art I can't see any problem there. Regarding 4) I recommend at the same time to refer to LCS MIBs from the core MIB (sic!) either according to my proposals (see my e-mail cited above) or according to any agreed modifications of these proposals submitted by somebody else. Regards, Felix Flemisch _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 13 11:44:52 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 LAA10214 for ; Fri, 13 Jun 2003 11:44:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DFiO822489 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 11:44: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 h5DFiOm22486 for ; Fri, 13 Jun 2003 11:44: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 LAA10205 for ; Fri, 13 Jun 2003 11:44:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qqgv-0006HO-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 11:42:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qqgv-0006HL-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 11:42:13 -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 h5DDM1a09793; Fri, 13 Jun 2003 09:22:01 -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 h5DDLlm09777 for ; Fri, 13 Jun 2003 09:21:47 -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 JAA02632 for ; Fri, 13 Jun 2003 09:21:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QoSv-0004hA-00 for adslmib@ietf.org; Fri, 13 Jun 2003 09:19:37 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19QoSu-0004h7-00 for adslmib@ietf.org; Fri, 13 Jun 2003 09:19:36 -0400 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h5DDLbGI1044022 for ; Fri, 13 Jun 2003 08:21:38 -0500 (CDT) Received: from [192.168.0.122] ([192.168.0.122]) by pesa.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Fri, 13 Jun 2003 08:21:33 -0500 Subject: Re: [Adslmib] FW: Re: VDSL Line Extension MIB - Modified From: Bob Ray Reply-To: rray@pesa.com To: Flemisch Felix Cc: "'adslmib@ietf.org'" In-Reply-To: <99522F0FD7EFD611A47D0002A58EDAB7C8AE92@mchh2a8e.mchh.siemens.de> References: <99522F0FD7EFD611A47D0002A58EDAB7C8AE92@mchh2a8e.mchh.siemens.de> Content-Type: text/plain Message-Id: <1055510490.3503.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Jun 2003 08:21:31 -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 Fri, 2003-06-13 at 00:37, Flemisch Felix wrote: > I'm resending this e-mail because I'm not sure whether > it reached IETF's mail server. I got it. Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 13 12:58:18 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 MAA12306 for ; Fri, 13 Jun 2003 12:58:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGvpP01253 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 12:57:51 -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 h5DGvom01215 for ; Fri, 13 Jun 2003 12:57: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 MAA12195 for ; Fri, 13 Jun 2003 12:57:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrq0-0006k4-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrpz-0006k1-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:39 -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 h5DDT1a10201; Fri, 13 Jun 2003 09:29:01 -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 h5DBo7m01830 for ; Fri, 13 Jun 2003 07:50:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28830; Fri, 13 Jun 2003 07:50:06 -0400 (EDT) Message-Id: <200306131150.HAA28830@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: Fri, 13 Jun 2003 07:50:06 -0400 Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-vdsl-10.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-10.txt Pages : 69 Date : 2003-6-12 This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-vdsl-10.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-10.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-10.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-6-12132049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-adslmib-vdsl-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-adslmib-vdsl-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132049.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 13 12:58:21 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 MAA12342 for ; Fri, 13 Jun 2003 12:58:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGvrP01542 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 12:57:53 -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 h5DGvrm01539 for ; Fri, 13 Jun 2003 12:57: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 MAA12204 for ; Fri, 13 Jun 2003 12:57:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrq3-0006kH-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 12:55:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrq2-0006kE-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 12:55: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 h5DDT1a10209; Fri, 13 Jun 2003 09:29:01 -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 h5DBoCm01834 for ; Fri, 13 Jun 2003 07:50:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28846; Fri, 13 Jun 2003 07:50:10 -0400 (EDT) Message-Id: <200306131150.HAA28846@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: Fri, 13 Jun 2003 07:50:10 -0400 Subject: [Adslmib] I-D ACTION:draft-ietf-adslmib-hc-tc-04.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 : High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals Author(s) : B. Ray, R. Abbi Filename : draft-ietf-adslmib-hc-tc-04.txt Pages : 11 Date : 2003-6-12 This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 2493 to 64 bit resolution using the conventions presented in RFC 2856. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-hc-tc-04.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-hc-tc-04.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-hc-tc-04.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-6-12132104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-adslmib-hc-tc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-adslmib-hc-tc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132104.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From mailnull@www1.ietf.org Fri Jun 13 13:21:00 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 NAA14106 for ; Fri, 13 Jun 2003 13:20:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHKX618446 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 13:20:33 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHKXm18443 for ; Fri, 13 Jun 2003 13:20:33 -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 NAA14043 for ; Fri, 13 Jun 2003 13:20:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsBy-0007BB-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 13:18:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsBx-0007B8-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 13:18:21 -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 h5DEG0a14716; Fri, 13 Jun 2003 10:16:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEFrm14706 for ; Fri, 13 Jun 2003 10:15: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 KAA07198 for ; Fri, 13 Jun 2003 10:15:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QpJG-0005fx-00 for adslmib@ietf.org; Fri, 13 Jun 2003 10:13:42 -0400 Received: from law14-f47.law14.hotmail.com ([64.4.21.47] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19QpJG-0005fs-00 for adslmib@ietf.org; Fri, 13 Jun 2003 10:13:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Jun 2003 07:15:20 -0700 Received: from 66.152.60.98 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 13 Jun 2003 14:15:20 GMT X-Originating-IP: [66.152.60.98] X-Originating-Email: [sneedmike@hotmail.com] From: "Michael Sneed" To: adslmib@ietf.org Subject: RE: [Adslmib] Re: VDSL Line Extension MIB - Modified Date: Fri, 13 Jun 2003 10:15:20 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jun 2003 14:15:20.0421 (UTC) FILETIME=[38DB4950:01C331B6] 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: , The ADSLMIB is in fact a perfect example of why NOT to reference the LCS MIBs from the base MIB as in that case the LCS MIBs were never developed. Unless some miracle occurs, the reference to LCS MIBs will have be removed when this document progresses, because it can't be implemented. This is an extreme case of the problem we can run into; it is unwise to document a relationship to another MIB that has not yet been developed, because that relationship may be altered in the course of developing that MIB ( I am not suggesting that the LCS MIB for VDSL will not be developed; I am simply pointing out that the nature of that MIB may be different than we expect at this point in time.) I still fail to see the purpose of documenting a relationship to a non-existent document in the base MIB. The place to describe the relationship between the base MIB and the LCS MIB is in the LCS MIB. We can then document that relationship with perfect hindsight, rather than requiring prescience to do it in the base MIB. >From: Menachem.Dodge@infineon.com >To: sneedmike@hotmail.com, adslmib@ietf.org >Subject: RE: [Adslmib] Re: VDSL Line Extension MIB - Modified >Date: Thu, 12 Jun 2003 14:41:30 +0200 > >Hi Mike, > > I think, based on all the previous discussion, that the only way >that everyone in the working group > will agree to proceed is if with adopt option 3) i) "Promote the current >VDSL MIB and recharter to do the >LCS MIB when it can be done consistent with the DSLF." This is also >consistent with Bob Ray's email suggesting a change to the charter. > Option 3) iii) "Promote the VDSL MIB and drop LCS altogether for the >time being." is completely >unacceptable. > Item 4) "There is still debate over whether to refer to LCS MIBs >..." If we divide the MIB into two parts >the core MIB and the LCS MIB then it makes sense that within the core MIB >there is explanation and >reference to the LCS MIBs. I would have thought that the example of RFC >2662 >is a good example as it >shows that when there is a core MIB and an extension MIB there is a need to >reference the extension >in the core MIB. If we adopt 3) i) and stick to the timetable set out by >Bob >Ray we will not have a problem >of having a core MIB with references to a non-existing extension MIB. > I suggest that we accept option 3) i) and also Bob Ray's >modification to the charter (with my additions) >and the Goals and Milestones that Bob outlined. > > Regards, > Menachem Dodge > >-----Original Message----- >From: Michael Sneed [mailto:sneedmike@hotmail.com] >Sent: Monday, June 09, 2003 8:15 PM >To: adslmib@ietf.org >Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified > > > >Just to clarify (because there are a couple of lines of argument going on >here and it is easy for me to get confused): > >1) The issue of LCS configuration objects in the current MIB is not a >charter issue. They are neither required nor excluded by the charter. I >think we all agree on this. > >2) It is my assumption that producing an LCS MIB would require a charter >revision. This is really only because we would be producing a new >document. > > If editor(s) are available for this work it is unlikely the work would >not > >be chartered. I expect the risk is probably about the same as that we get >shut down before promoting the VDSL MIB for failure to reach a consensus >;-). It might be possible to do it without a new charter, since the >functionality is not exluded from the current charter, but it is best to >revise the charter to match the work. > >3) There are three possible ways to proceed from here (as I see it): > >i) Promote the current VDSL MIB and recharter to do the LCS MIB when it can >be done consistent with the DSLF. >ii) Hold the VDSL MIB until we can do LCS configuration consistent with the >DSLF. >iii) Promote the VDSL MIB and drop LCS altogether for the time being. >iv) Revert to the scheme of LCS management in -07 and promote that. > >If I understand Moti, he is recommending ii), while I recommend i). I >haven't heard anyone argue for iii). I don't think I have heard anyone >recommend iv), but sometimes I am not so sure. > >4) There is still debate over whether to refer to LCS MIBs if we pursue >option i) or iii). I don't understand this argument, because I fail to see >the usefulness of the proposed references. The case of 2662 is not a good >example, because the LCS MIBs were never written, and that whole issue >would > >disappear were the document updated. > > >So we need to reach consensus on items 3) and 4) if we are going to make >progress. I would like to see the current draft move forward, because I >think it is useful in its current form. The lack of LCS configuration >functionality does not detract from the usefulness of what is there; >delaying the LCS features simply reflects the reality of maintaining >consistency with the DSLF. Can any one argue why we will not be better off >with the core MIB at Proposed, rather than a constantly morphing ID? The >argument that this leaves the door open to proporietary implementations >does > >not hold water; without having the core at Proposed the door is MUCH wider, >because there is NO standard. > > > > > >From: Moti.Morgenstern@ecitele.com > >To: rray@pesa.com > >CC: adslmib@ietf.org, adslmib-admin@ietf.org > >Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified > >Date: Mon, 9 Jun 2003 19:55:14 +0300 > > > > > >Bob and all, > > > >Any LCS tables that were in the -07 draft certainly belong to the WG > >charter/scope. The 2 newer drafts do not have those tables not because >the > >tables "do not belong to the charter" but because of considering the DSLF > >TR. We now know how "mature" and serious is that DSLF management model. >The > >DSLF itself, after everyone (except for ECI and maybe others too) was >happy > >with the content of the TR, discovered a need for correcting the model > >EVERY MEETING since they published TR. Part of the findings are going to >be > >included in a new working text (WT) but currently the DSLF model doesn't > >match the -09 draft. It seems that tsome people in our WG don't see a >need > >to wait until the DSLF formally accept or reject those changes but (as >Mike > >just said) "The one thing no one wants is TWO standards". If that is > >correct than we MUST hold our work until the DSLF members formally >evaluate > >the corrected model. > > > >When Mike raised the possibility of having a "core" MIB and extension(s) >to > >that MIB I assumed that this is a procedure which is fully within the > >charter. Now I see that even before discussing the missing SNMP objects > >there is a potential scenario that we won't be able to even start such an > >extension. I hear arguments such as "references to work that hasn't been > >done is not productive", while the same WG published RFC2662 with a > >reference to any external (proprietary) MIB. If the ADSL MIB can have a > >hook for a proprietary extension, why can't the VDSL MIB include a hook >for > >a potential LCS extensions (proprietary or by IETF)? > > > >Best regards, > >Moti Morgenstern > > > >Senior Systems Engineer > >ECI Telecoms Ltd. > >Inovia Broadband Access Division > >30 Hasivim St. > >Petach Tikva, Israel 49133 > >Tel.: +972-3-9266258 > >Fax: +972-3-9268182 > >Cell: +972-55-786258 > >e-mail: Moti.Morgenstern@ecitele.com > >www.ecitele.com > > > > > > > > > > Bob Ray > pesa.com> To: adslmib mail >list > > > > Sent by: cc: > > adslmib-admin@ Subject: [Adslmib] Re: >VDSL > > >Line Extension MIB - Modified > > ietf.org > > > > > > 09/06/03 17:15 > > Please respond > > to rray > > > > > > > > > > > >Felix (and all): > > > >This insistence that the hands of the IETF be bound by specific > >references to work that hasn't been chartered and by work that > >hasn't been done is not productive. > > > >I would suggest, instead, that those who feel most strongly > >about the "missing tables" do the following: > > > >a) dredge up a copy of the -07 draft > >b) write a draft vdsl-line-extension-mib using the missing > > tables > >c) submit the draft as an individual contribution to the > > IETF > >d) at the next meeting of the adslmib working group (perhaps > > Vienna), suggest that the charter be amended to support > > an extension MIB > >e) humbly offer the individual contribution to the working > > group as a good starting point for such work. > >f) work with (and in) the DSL Forum to achieve agreement as > > to THEIR preferred management objects. > > > >I believe this approach would be FAR MORE PRODUCTIVE... > > > >See: http://www.ietf.org/ietf/1id-guidelines.txt for information > >on accomplishing this. > > > >Regards, > >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 > >_________________________________________________________________ >The new MSN 8: smart spam protection and 2 months FREE* >http://join.msn.com/?page=features/junkmail > >_______________________________________________ >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 _________________________________________________________________ STOP MORE 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 Jun 13 14:37:12 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 OAA17385 for ; Fri, 13 Jun 2003 14:37:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIai732282 for adslmib-archive@odin.ietf.org; Fri, 13 Jun 2003 14:36:44 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIaim31929 for ; Fri, 13 Jun 2003 14:36:44 -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 OAA17301 for ; Fri, 13 Jun 2003 14:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtNg-0000Fa-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 14:34:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtNf-0000FX-00 for adslmib-web-archive@ietf.org; Fri, 13 Jun 2003 14:34: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 h5DIB2a14525; Fri, 13 Jun 2003 14:11:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIAgm14050 for ; Fri, 13 Jun 2003 14:10:42 -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 OAA16387 for ; Fri, 13 Jun 2003 14:10:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsyV-00004d-00 for adslmib@ietf.org; Fri, 13 Jun 2003 14:08:31 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19QsyU-00004a-00 for adslmib@ietf.org; Fri, 13 Jun 2003 14:08:30 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Qt0Z-00024K-00 for adslmib@ietf.org; Fri, 13 Jun 2003 11:10:39 -0700 Message-ID: <000601c331d5$fc63cd60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Adslmib] Re: VDSL Line Extension MIB - Modified Date: Fri, 13 Jun 2003 11:02:41 -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 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: "Michael Sneed" > To: > Sent: Friday, June 13, 2003 7:15 AM > Subject: RE: [Adslmib] Re: VDSL Line Extension MIB - Modified ... > I still fail to see the purpose of documenting a relationship to a > non-existent document in the base MIB. The place to describe the > relationship between the base MIB and the LCS MIB is in the LCS MIB. We can > then document that relationship with perfect hindsight, rather than > requiring prescience to do it in the base MIB. ... As a "MIB doctor", I am in complete agreement. Randy _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Jun 17 16:44: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 QAA10358 for ; Tue, 17 Jun 2003 16:44:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HKi3e04044 for adslmib-archive@odin.ietf.org; Tue, 17 Jun 2003 16:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNJD-000139-Bq for adslmib-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 16:44:03 -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 QAA10328 for ; Tue, 17 Jun 2003 16:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNGy-0004oS-00 for adslmib-web-archive@ietf.org; Tue, 17 Jun 2003 16:41:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SNGx-0004oO-00 for adslmib-web-archive@ietf.org; Tue, 17 Jun 2003 16:41:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNJB-00010k-Gd; Tue, 17 Jun 2003 16:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNIx-0000za-Tq for adslmib@optimus.ietf.org; Tue, 17 Jun 2003 16:43:48 -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 QAA10321 for ; Tue, 17 Jun 2003 16:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNGi-0004oB-00 for adslmib@ietf.org; Tue, 17 Jun 2003 16:41:28 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19SNGh-0004o8-00 for adslmib@ietf.org; Tue, 17 Jun 2003 16:41:27 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id WAA09476; Tue, 17 Jun 2003 22:43:28 +0200 (MET DST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id WAA28360; Tue, 17 Jun 2003 22:42:28 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 22:42:57 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB7C8AEA6@mchh2a8e.mchh.siemens.de> From: Flemisch Felix To: "'adslmib@ietf.org'" Cc: "'rray@pesa.com'" , "'Rajesh.Abbi@alcatel.com'" , "'randy_presuhn@mindspring.com'" , "'sneedmike@hotmail.com'" Date: Tue, 17 Jun 2003 22:42:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Adslmib] About vdsl-10 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, thanks to the co-editors for compiling vdsl-10 which considerably improves vdsl-09. Even flaws not being discussed by e-mails have been removed (e.g., within the notifications definitions). I have final proposals for further improvement, namely some editorial issues and a smoothening of unconsidered previous text fragments. If you like you can pass them directly to the RFC editor. line(s) | proposed changes or additions --------+------------------------------------------------------------------ 103 | after "... ITU9971]." add the following sentence: | " Additionally the protocol-independent (and line code | independent) management framework for VDSL line management | specified by DSLF is taken into consideration [DSLFTR057]." --------+------------------------------------------------------------------ 131 | replace the line by the following: | vdsl(97), -- Very High-speed Digital Subscriber Loop/Line --------+------------------------------------------------------------------ 144 | replace the lines by the following: -145 | interleave(124), -- Interleaved channel | fast(125), -- Fast channel --------+------------------------------------------------------------------ 165 | replace "interleaved" by "interleave" --------+------------------------------------------------------------------ 216 | replace the lines by the following: -217 | O. xxxs -- Sum of Seconds in which xxx has occured | (e.g., xxx = Lof, Los, Lpr, Lol) --------+------------------------------------------------------------------ 274 | replace the line by the following: | " interleave(124) and fast(125):" --------+------------------------------------------------------------------ 377 | replace the lines by the following: -379 | o Line Configuration Profiles - These profiles contain parameters | for configuring VDSL lines and their channels. They are defined | in the line code independent vdslLineConfProfileTable and in | supplementary standardized line code specific (LCS) configuration | profile tables. Additionally vendor-specific configuration | profile extension tables may exist. vdslLineConfProfileTable | is defined in the VDSL-LINE-MIB module that is specified in | this RFC, and standardized LCS configuration profile tables | will be defined in a complementary extension MIB module. --------+------------------------------------------------------------------ 588 | add a comma after "Raleigh" --------+------------------------------------------------------------------ 648 | replace the lines by the following (see also lines 216-217): -649 | " xxxs -- Sum of Seconds in which xxx has occured" | " (e.g., xxx = Lof, Los, Lpr)" --------+------------------------------------------------------------------ 657 | after this line add the following text: | | -- Note | | This MIB module does not contain line code specific (LCS) elements | for neither MCM lines nor SCM lines. Supplementary standardized LCS | configuration profile tables or vendor-specific configuration profile | extension tables might be needed to fully configure VDSL lines. | --------+------------------------------------------------------------------ 786 | after this line add the following text (see also p.54): | Note that 'slow' and 'interleaved' refer to the same | channel. | --------+------------------------------------------------------------------ 2945 | replace "Stop" by "Start" --------+------------------------------------------------------------------ 3392, | replace "...Mgn. The ..." by "...Mgn. The ..." 3404, | 3416 | --------+------------------------------------------------------------------ 3670 | add RFC 2662 and RFC 3440 to the normative references -3738 | --------+------------------------------------------------------------------ 3846, | replace "EMail" by "Email" (see also p.11) 3855 | Regards, Felix Flemisch Siemens AG Information and Communication Networks Carrier Products Systems Engineering Hofmannstr. 51 D-81359 Munich Germany Phone +49 89 722 62175 Email felix.flemisch@siemens.com Internet http://www.siemens.com/ _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Tue Jun 17 17:12:00 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 RAA11952 for ; Tue, 17 Jun 2003 17:12:00 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HLBXO11008 for adslmib-archive@odin.ietf.org; Tue, 17 Jun 2003 17:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNjo-0002rT-UK for adslmib-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 17:11:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11926 for ; Tue, 17 Jun 2003 17:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNjK-0002p3-3L; Tue, 17 Jun 2003 17:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SNjB-0002oD-Sv for adslmib@optimus.ietf.org; Tue, 17 Jun 2003 17:10: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 RAA11850 for ; Tue, 17 Jun 2003 17:10:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SNgv-0005DY-00 for adslmib@ietf.org; Tue, 17 Jun 2003 17:08:33 -0400 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 19SNgj-0005Cs-00 for adslmib@ietf.org; Tue, 17 Jun 2003 17:08:23 -0400 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h5HLAQGK709767 for ; Tue, 17 Jun 2003 16:10:33 -0500 (CDT) Received: from [192.168.0.122] ([192.168.0.122]) by pesa.com ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Tue, 17 Jun 2003 16:10:21 -0500 From: Bob Ray Reply-To: rray@pesa.com To: Flemisch Felix Cc: "'adslmib@ietf.org'" , "'Rajesh.Abbi@alcatel.com'" , "'randy_presuhn@mindspring.com'" , "'sneedmike@hotmail.com'" In-Reply-To: <99522F0FD7EFD611A47D0002A58EDAB7C8AEA6@mchh2a8e.mchh.siemens.de> References: <99522F0FD7EFD611A47D0002A58EDAB7C8AEA6@mchh2a8e.mchh.siemens.de> Content-Type: text/plain Message-Id: <1055884217.6105.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Jun 2003 16:10:18 -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 vdsl-10 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 Tue, 2003-06-17 at 15:42, Flemisch Felix wrote: > I have final proposals for further improvement, namely some editorial > issues and a smoothening of unconsidered previous text fragments. > If you like you can pass them directly to the RFC editor. It doesn't happen that way. > > line(s) | proposed changes or additions > --------+------------------------------------------------------------------ > 103 | after "... ITU9971]." add the following sentence: > | " Additionally the protocol-independent (and line code > | independent) management framework for VDSL line management > | specified by DSLF is taken into consideration [DSLFTR057]." > --------+------------------------------------------------------------------ Hmmmm. Which came first, one wonders quietly to oneself. > 131 | replace the line by the following: > | vdsl(97), -- Very High-speed Digital Subscriber Loop/Line No. That line comes from the IANA document. We cannot change their document. > --------+------------------------------------------------------------------ > 144 | replace the lines by the following: > -145 | interleave(124), -- Interleaved channel > | fast(125), -- Fast channel No. Those lines comes from the IANA document. We cannot change their document. > --------+------------------------------------------------------------------ > 165 | replace "interleaved" by "interleave" This we can change. Good catch. > --------+------------------------------------------------------------------ > 216 | replace the lines by the following: > -217 | O. xxxs -- Sum of Seconds in which xxx has occured > | (e.g., xxx = Lof, Los, Lpr, Lol) Good catch. > --------+------------------------------------------------------------------ > 274 | replace the line by the following: > | " interleave(124) and fast(125):" Good catch. > --------+------------------------------------------------------------------ > 377 | replace the lines by the following: > -379 | o Line Configuration Profiles - These profiles contain parameters > | for configuring VDSL lines and their channels. They are defined > | in the line code independent vdslLineConfProfileTable and in > | supplementary standardized line code specific (LCS) configuration > | profile tables. Additionally vendor-specific configuration > | profile extension tables may exist. vdslLineConfProfileTable > | is defined in the VDSL-LINE-MIB module that is specified in > | this RFC, and standardized LCS configuration profile tables > | will be defined in a complementary extension MIB module. No. For reasons Randy and Mike have expounded upon already. Please wait seven (7) days before making this request again :) > --------+------------------------------------------------------------------ > 588 | add a comma after "Raleigh" Good catch. You're scary! > --------+------------------------------------------------------------------ > 648 | replace the lines by the following (see also lines 216-217): > -649 | " xxxs -- Sum of Seconds in which xxx has occured" > | " (e.g., xxx = Lof, Los, Lpr)" Good catch. > --------+------------------------------------------------------------------ > 657 | after this line add the following text: > | > | -- Note > | > | This MIB module does not contain line code specific (LCS) elements > | for neither MCM lines nor SCM lines. Supplementary standardized LCS > | configuration profile tables or vendor-specific configuration profile > | extension tables might be needed to fully configure VDSL lines. > | No. For reasons Randy and Mike have expounded upon already. Please wait seven (7) days before making this request again :) > --------+------------------------------------------------------------------ > 786 | after this line add the following text (see also p.54): > | Note that 'slow' and 'interleaved' refer to the same > | channel. > | Ok. > --------+------------------------------------------------------------------ > 2945 | replace "Stop" by "Start" Good catch. > --------+------------------------------------------------------------------ > 3392, | replace "...Mgn. The ..." by "...Mgn. The ..." > 3404, | > 3416 | Good catch. I'm impressed! > --------+------------------------------------------------------------------ > 3670 | add RFC 2662 and RFC 3440 to the normative references > -3738 | Neither of these are referenced in the document. > --------+------------------------------------------------------------------ > 3846, | replace "EMail" by "Email" (see also p.11) > 3855 | > Ok. Thank you for your careful reading. And please be patient about the LCS stuff (at least for a week). -- Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib From exim@www1.ietf.org Mon Jun 30 12:11:59 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 MAA03425 for ; Mon, 30 Jun 2003 12:11:59 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UGBWk01517 for adslmib-archive@odin.ietf.org; Mon, 30 Jun 2003 12:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1Fc-0000OO-9h for adslmib-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 12:11:32 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03399 for ; Mon, 30 Jun 2003 12:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1F7-0000Ms-Ge; Mon, 30 Jun 2003 12:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X1F5-0000MU-PE for adslmib@optimus.ietf.org; Mon, 30 Jun 2003 12:10: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 MAA03355 for ; Mon, 30 Jun 2003 12:10:41 -0400 (EDT) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X1En-0002GN-00 for adslmib@ietf.org; Mon, 30 Jun 2003 12:10:41 -0400 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 19X1EW-0002El-00 for adslmib@ietf.org; Mon, 30 Jun 2003 12:10:25 -0400 Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228]) by smtp2.infineon.com (8.12.9/8.12.9) with ESMTP id h5UG5HB7013698 for ; Mon, 30 Jun 2003 18:05:17 +0200 (MEST) Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 18:05:53 +0200 Message-ID: To: adslmib@ietf.org Subject: [Adslmib] Vdsl Line Extension MIB Date: Mon, 30 Jun 2003 19:04:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" 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've taken up Bob's suggestion to write a first draft of the LCS extension MIB. In order to simplify the structure and explanations I am working on two drafts one which handles the SCM extensions and the other which handles the MCM extensions. I expect to complete the work by the end of the week. Best Regards, Menachem Dodge. Infineon Technologies. _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib