From Menachem.Dodge@ecitele.com Mon Nov 2 08:59:38 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157093A67AF for ; Mon, 2 Nov 2009 08:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLRMHNsgT4iF for ; Mon, 2 Nov 2009 08:59:37 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id E95EC3A6911 for ; Mon, 2 Nov 2009 08:59:36 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by ilptiron01.ecitele.com with ESMTP; 02 Nov 2009 18:50:41 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 2 Nov 2009 18:59:55 +0200 From: Menachem Dodge To: "'adslmib@ietf.org'" Date: Mon, 2 Nov 2009 18:59:52 +0200 Thread-Topic: Vector of Profiles MIB Thread-Index: Acpb3eT28DKd1Yt7Qs+4JZu5vd23vA== Message-ID: <283DD79798619346BF9B17D7B5035A1901078BF85FBB@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_283DD79798619346BF9B17D7B5035A1901078BF85FBBILPTMAIL02e_" MIME-Version: 1.0 Subject: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:59:38 -0000 --_000_283DD79798619346BF9B17D7B5035A1901078BF85FBBILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, In April this year, several emails were exchanged regarding development of = a "Vector of Profile" MIB in accordance with the Broadband Forum TR-165 Vec= tor of Profiles document. See the attached thread. As this issue has been raised again, I would like to see if there is an int= erest amongst the members of the Working Group in this work. Please share your thoughts on this issue. Best Regards, Menachem --_000_283DD79798619346BF9B17D7B5035A1901078BF85FBBILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

In April this year, several emails were exchanged rega= rding development of a "Vector of Profile" MIB in accordance with the Broadband For= um TR-165 Vector of Profiles document.

See the attached thread.

 

As this issue has been raised again, I would like to s= ee if there is an interest amongst the members of the Working Group in this work.=

 

Please share your thoughts on this issue.

 

Best Regards,

Menachem

--_000_283DD79798619346BF9B17D7B5035A1901078BF85FBBILPTMAIL02e_-- From Menachem.Dodge@ecitele.com Mon Nov 2 09:07:10 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C44E28C1BA for ; Mon, 2 Nov 2009 09:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsc9hVbFGawH for ; Mon, 2 Nov 2009 09:07:09 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 2074928C1B6 for ; Mon, 2 Nov 2009 09:07:07 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by ilptiron01.ecitele.com with ESMTP; 02 Nov 2009 18:58:12 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 2 Nov 2009 19:07:26 +0200 From: Menachem Dodge To: "'adslmib@ietf.org'" Date: Mon, 2 Nov 2009 19:07:24 +0200 Thread-Topic: Vector of Profiles MIB Thread-Index: Acpb3eT28DKd1Yt7Qs+4JZu5vd23vAAAChEw Message-ID: <283DD79798619346BF9B17D7B5035A1901078BF85FBE@ILPTMAIL02.ecitele.com> References: <283DD79798619346BF9B17D7B5035A1901078BF85FBB@ILPTMAIL02.ecitele.com> In-Reply-To: <283DD79798619346BF9B17D7B5035A1901078BF85FBB@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_" MIME-Version: 1.0 Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:07:10 -0000 --_004_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_ Content-Type: multipart/alternative; boundary="_000_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_" --_000_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, In April this year, several emails were exchanged regarding development of = a "Vector of Profile" MIB in accordance with the Broadband Forum TR-165 Vec= tor of Profiles document. See the attached thread. As this issue has been raised again, I would like to see if there is an int= erest amongst the members of the Working Group in this work. Please share your thoughts on this issue. Best Regards, Menachem --_000_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

In April this year, several emails were exchanged rega= rding development of a "Vector of Profile" MIB in accordance with the Broadband Forum TR-165 Vector of Profiles document.

See the attached thread.

 

As this issue has been raised again, I would like to s= ee if there is an interest amongst the members of the Working Group in this work.=

 

Please share your thoughts on this issue.

 

Best Regards,

Menachem

--_000_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_-- --_004_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_ Content-Type: message/rfc822 Received: from ilptiron01.ecitele.com (147.234.242.161) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.340.0; Thu, 23 Apr 2009 18:30:35 +0300 Received: from mail.ietf.org ([64.170.98.32]) by ilptiron01.ecitele.com with ESMTP; 23 Apr 2009 18:28:28 +0300 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F983A6C19; Thu, 23 Apr 2009 08:29:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6FF3A6D09 for ; Thu, 23 Apr 2009 08:29:13 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpiYTHGrc306 for ; Thu, 23 Apr 2009 08:29:12 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id F311B3A6ADF for ; Thu, 23 Apr 2009 08:29:11 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 23 Apr 2009 17:30:18 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 17:30:18 +0200 From: "Markus.Freudenberger@t-systems.com" To: "scott.baillie@nec.com.au" CC: "adslmib@ietf.org" Sender: "adslmib-bounces@ietf.org" Content-Class: urn:content-classes:message Date: Thu, 23 Apr 2009 18:30:18 +0300 Subject: Re: [Adslmib] Influence of BBF TR-165 on the draft-ietf-adslmib-vdsl2 Thread-Topic: [Adslmib] Influence of BBF TR-165 on the draft-ietf-adslmib-vdsl2 Thread-Index: AcnD5A0VLtF27jXLRfWlb/pOrcp84AAQJ8ZA Message-ID: <1B6169C658325341A3B8066E23919E1C015EB491@S4DE8PSAANK.mitte.t-com.de> References: <1B6169C658325341A3B8066E23919E1C015EB481@S4DE8PSAANK.mitte.t-com.de> <1240386985.28785.96.camel@spot.ssd.neca.nec.com.au> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <1240386985.28785.96.camel@spot.ssd.neca.nec.com.au> X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: ILPTEXCH02.ecitele.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-originalarrivaltime: 23 Apr 2009 15:30:18.0605 (UTC) FILETIME=[686671D0:01C9C428] x-ironport-av: E=Sophos;i="4.40,235,1238965200"; d="scan'208";a="5070919" x-ironport-anti-spam-filtered: true x-ironport-anti-spam-result: AoABAA8j8ElAqmIgjmdsb2JhbACBT5QCdwEBAQEJCwgJDwe5NIIvgUYG x-virus-scanned: amavisd-new at amsl.com x-spam-level: x-spam-status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] delivered-to: adslmib@core3.amsl.com errors-to: adslmib-bounces@ietf.org x-original-to: adslmib@core3.amsl.com list-archive: list-post: list-id: ADSLMIB x-spam-flag: NO x-spam-score: -2.042 x-beenthere: adslmib@ietf.org x-mailman-version: 2.1.9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hello Scott, I can help you if you have specific questions regarding TR-165 as I was one= of the contributors to the document at the Broadband Forum. I would appreciate if the working group can decide to spend the effort in d= efining the MIB based for TR-165. I am available to help, if needed. By the way: When do you expect publication of the current VDSL2 draft MIB? Regards Markus -----Urspr=FCngliche Nachricht----- Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im Auftrag = von Scott Baillie Gesendet: Mittwoch, 22. April 2009 09:56 An: Freudenberger, Markus Cc: adslmib@ietf.org Betreff: Re: [Adslmib] Influence of BBF TR-165 onthe draft-ietf-adslmib-vds= l2 Hi Markus, I only had a quick look at the document TR-165 so I would need to spend som= e more before I can say that I understand the model being proposed. What we can say though is that the current VDSL2 draft MIB will be publishe= d pretty much "as is" with the exception that we are adding in a number of = modifications that have been proposed by the MIB doctors review team. We can discuss the management model defined in TR-165 after the current dra= ft goes RFC. Regards, Scott. On Wed, 2009-04-22 at 09:49 +0200, Markus.Freudenberger@t-systems.com wrote: > All, >=20 > The TR-165 "Vector of Profiles (VoP)" was recently published by the=20 > Broadband Forum (BBF). It defines an optimized object model for=20 > configuring DSL lines. >=20 > http://www.broadband-forum.org/technical/download/TR-165.pdf >=20 > It states in chapter 1.1:=20 > ...=20 > The Vector of Profiles specified in this Technical Report obsoletes=20 > the object model for DSL line configuration defined in the Broadband=20 > Forum's TR-129. Legacy systems may still use that object model for=20 > configuration management. All other object models of TR- > 129 remain valid.=20 > ... >=20 > As TR-129 is is used as a reference in the=20 > draft-ietf-adslmib-vdsl2-06, the influence of TR-165 has to be=20 > considered by the group and a decision has to be made asap how to=20 > further proceed. >=20 > A stated in chapter 1.1 of TR-165, it obsoletes the object model for=20 > DSL line configuration in TR-129 and this influences directy the=20 > Configuration Template and Profile part of the MIB Draft. >=20 > I think of the following options for the working group to proceed: >=20 > 1) Finish the work on the actual draft and define a new "VoP MIB" in=20 > the next step. Once, the "VoP MIB" is ready, the Configuration=20 > Template and Profile part in the existing MIB is marked as obsolete=20 > with reference to the new "VoP MIB". >=20 > 2) Finish the work on the actual draft and define a new "VoP MIB" in=20 > the next step as an altenative MIB module for DSL line configuration=20 > and leave the choice, which MIB to use to the users. >=20 > 3) Define the object structure based on TR-165 and put it into the=20 > existing MIB Draft before publication as a mandatory part and mark the=20 > Configuration Template and Profile part as optional. >=20 > 4) Leave everything as it is. >=20 > I prefer option 1). >=20 > Any comments? >=20 > Best Regards > Markus Freudenberger >=20 > T-Systems Enterprise Services GmbH >=20 > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib --_004_283DD79798619346BF9B17D7B5035A1901078BF85FBEILPTMAIL02e_-- From Menachem.Dodge@ecitele.com Mon Nov 9 00:21:20 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1AE3A687C for ; Mon, 9 Nov 2009 00:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4RJyh1QV9It for ; Mon, 9 Nov 2009 00:21:19 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 666423A69F0 for ; Mon, 9 Nov 2009 00:21:18 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by ilptiron01.ecitele.com with ESMTP; 09 Nov 2009 10:12:13 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 9 Nov 2009 10:21:43 +0200 From: Menachem Dodge To: Menachem Dodge , "'adslmib@ietf.org'" Date: Mon, 9 Nov 2009 10:21:38 +0200 Thread-Topic: Vector of Profiles MIB Thread-Index: Acpb3eT28DKd1Yt7Qs+4JZu5vd23vAAAChEwAU2FPXA= Message-ID: <283DD79798619346BF9B17D7B5035A19010797EA40C6@ILPTMAIL02.ecitele.com> References: <283DD79798619346BF9B17D7B5035A1901078BF85FBB@ILPTMAIL02.ecitele.com> <283DD79798619346BF9B17D7B5035A1901078BF85FBE@ILPTMAIL02.ecitele.com> In-Reply-To: <283DD79798619346BF9B17D7B5035A1901078BF85FBE@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_283DD79798619346BF9B17D7B5035A19010797EA40C6ILPTMAIL02e_" MIME-Version: 1.0 Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:21:20 -0000 --_000_283DD79798619346BF9B17D7B5035A19010797EA40C6ILPTMAIL02e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I haven't received any response to my email of last Monday. If anyone at all, has an interest in this item of work, please speak up now= . Best Regards, Menachem Dodge From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf = Of Menachem Dodge Sent: Monday, November 02, 2009 7:07 PM To: 'adslmib@ietf.org' Subject: Re: [Adslmib] Vector of Profiles MIB Hello All, In April this year, several emails were exchanged regarding development of = a "Vector of Profile" MIB in accordance with the Broadband Forum TR-165 Vec= tor of Profiles document. See the attached thread. As this issue has been raised again, I would like to see if there is an int= erest amongst the members of the Working Group in this work. Please share your thoughts on this issue. Best Regards, Menachem --_000_283DD79798619346BF9B17D7B5035A19010797EA40C6ILPTMAIL02e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,=

 =

I haven't received any r= esponse to my email of last Monday.

 =

If anyone at all, has an= interest in this item of work, please speak up now.

 =

Best Regards,=

Menachem Dodge

 =

From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf Of = Menachem Dodge
Sent: Monday, November 02, 2009 7:07 PM
To: 'adslmib@ietf.org'
Subject: Re: [Adslmib] Vector of Profiles MIB

 

Hello All,

 

In April this year, several emails were exchanged rega= rding development of a "Vector of Profile" MIB in accordance with the Broadband Forum TR-165 Vector of Profiles document.

See the attached thread.

 

As this issue has been raised again, I would like to s= ee if there is an interest amongst the members of the Working Group in this work.<= /o:p>

 

Please share your thoughts on this issue.

 

Best Regards,

Menachem

--_000_283DD79798619346BF9B17D7B5035A19010797EA40C6ILPTMAIL02e_-- From Markus.Freudenberger@t-systems.com Mon Nov 9 00:26:33 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435CD3A687C for ; Mon, 9 Nov 2009 00:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhzMBFLnxb-H for ; Mon, 9 Nov 2009 00:26:32 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id C72A83A67A4 for ; Mon, 9 Nov 2009 00:26:31 -0800 (PST) From: Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 09 Nov 2009 09:26:52 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 09:26:52 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6116.63117941" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 9 Nov 2009 09:26:51 +0100 Message-ID: <1B6169C658325341A3B8066E23919E1C029EC7C2@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <283DD79798619346BF9B17D7B5035A19010797EA40C6@ILPTMAIL02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: Acpb3eT28DKd1Yt7Qs+4JZu5vd23vAAAChEwAU2FPXAAAHI1sA== References: <283DD79798619346BF9B17D7B5035A1901078BF85FBB@ILPTMAIL02.ecitele.com><283DD79798619346BF9B17D7B5035A1901078BF85FBE@ILPTMAIL02.ecitele.com> <283DD79798619346BF9B17D7B5035A19010797EA40C6@ILPTMAIL02.ecitele.com> To: , X-OriginalArrivalTime: 09 Nov 2009 08:26:52.0131 (UTC) FILETIME=[63942B30:01CA6116] Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:26:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6116.63117941 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable on behalf of Deutsche Telekom, I am interested on that item. =20 Thanks Markus =20 ________________________________ Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im Auftrag von Menachem Dodge Gesendet: Montag, 9. November 2009 09:22 An: Menachem Dodge; 'adslmib@ietf.org' Betreff: Re: [Adslmib] Vector of Profiles MIB Hello, =20 I haven't received any response to my email of last Monday.=20 =20 If anyone at all, has an interest in this item of work, please speak up now. =20 Best Regards, Menachem Dodge =20 From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf Of Menachem Dodge Sent: Monday, November 02, 2009 7:07 PM To: 'adslmib@ietf.org' Subject: Re: [Adslmib] Vector of Profiles MIB =20 Hello All, =20 In April this year, several emails were exchanged regarding development of a "Vector of Profile" MIB in accordance with the Broadband Forum TR-165 Vector of Profiles document. See the attached thread. =20 As this issue has been raised again, I would like to see if there is an interest amongst the members of the Working Group in this work. =20 Please share your thoughts on this issue. =20 Best Regards, Menachem ------_=_NextPart_001_01CA6116.63117941 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
on behalf of Deutsche Telekom, I am interested = on that=20 item.
 
Thanks
Markus
 

Von: adslmib-bounces@ietf.org=20 [mailto:adslmib-bounces@ietf.org] Im Auftrag von Menachem=20 Dodge
Gesendet: Montag, 9. November 2009 09:22
An: = Menachem=20 Dodge; 'adslmib@ietf.org'
Betreff: Re: [Adslmib] Vector of = Profiles=20 MIB

Hello,

 

I haven't received = any response=20 to my email of last Monday.

 

If anyone at all, = has an=20 interest in this item of work, please speak up = now.

 

Best=20 Regards,

Menachem=20 Dodge

 

From:=20 adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf = Of=20 Menachem Dodge
Sent: Monday, November 02, 2009 7:07=20 PM
To: 'adslmib@ietf.org'
Subject: Re: [Adslmib] = Vector of=20 Profiles MIB

 

Hello All,

 

In April this year, several emails were exchanged = regarding=20 development of a "Vector of Profile" MIB in accordance with the = Broadband Forum=20 TR-165 Vector of Profiles document.

See the attached thread.

 

As this issue has been raised again, I would like = to see if=20 there is an interest amongst the members of the Working Group in this=20 work.

 

Please share your thoughts on this = issue.

 

Best=20 Regards,

Menachem

------_=_NextPart_001_01CA6116.63117941-- From sbaillie@bigpond.net.au Mon Nov 9 00:52:00 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AFE3A6920 for ; Mon, 9 Nov 2009 00:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2x4XSXi4wrK for ; Mon, 9 Nov 2009 00:52:00 -0800 (PST) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by core3.amsl.com (Postfix) with ESMTP id B4C3A3A6844 for ; Mon, 9 Nov 2009 00:51:59 -0800 (PST) Received: from nskntotgx03p.mx.bigpond.com ([61.9.169.12]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20091109085224.PDGQ1310.nskntmtas03p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com>; Mon, 9 Nov 2009 08:52:24 +0000 Received: from nskntwebs02p ([61.9.169.12]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20091109085224.LGJK24930.nskntotgx03p.mx.bigpond.com@nskntwebs02p>; Mon, 9 Nov 2009 08:52:24 +0000 Received: from 124.190.58.101 by webmail2.bigpond.com; Mon, 9 Nov 2009 8:52:23 +0000 Message-ID: <31373915.1257756744195.JavaMail.root@nskntwebs02p> Date: Mon, 9 Nov 2009 19:52:24 +1100 From: "sbaillie@bigpond.net.au" To: Markus.Freudenberger@t-systems.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.4AF7D848.00C5,ss=1,fgs=0 Cc: adslmib@ietf.org, Menachem.Dodge@ecitele.com Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:52:01 -0000 Hi Menachem and Markus, I think we should have a discussion first about the scope and purpose of the "Vector of Profiles MIB" proposal. Can we please address some of the following issues : 1. Would the new MIB cover all xDSL technologies like the VDSL2 MIB does ? 2. Would the new MIB cover all the parameters defined in G.997.1 ? 3. Would the only difference between the VDSL2 MIB and the new MIB be the way templates are represented ? 4. Can you state the things that the new MIB will have that the VDSL2 MIB does not have. 5. Can you state the things that the VDSL2 MIB has that the new MIB does not have. 6. Is the new MIB intended for embedded use such as in DSLAMs and xDSL line cards ? 7. Can you justify having two MIBs that do basically the same thing but do it in a slightly different way ? 8. If you are a developer of xDSL equipment, what criterion would you use to select one MIB or the other ? Regards, Scott. ---- Markus.Freudenberger@t-systems.com wrote: > on behalf of Deutsche Telekom, I am interested on that item. > > Thanks > Markus > > ________________________________ > > Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im > Auftrag von Menachem Dodge > Gesendet: Montag, 9. November 2009 09:22 > An: Menachem Dodge; 'adslmib@ietf.org' > Betreff: Re: [Adslmib] Vector of Profiles MIB > > > > Hello, > > > > I haven't received any response to my email of last Monday. > > > > If anyone at all, has an interest in this item of work, please speak up > now. > > > > Best Regards, > > Menachem Dodge > > > > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > Behalf Of Menachem Dodge > Sent: Monday, November 02, 2009 7:07 PM > To: 'adslmib@ietf.org' > Subject: Re: [Adslmib] Vector of Profiles MIB > > > > Hello All, > > > > In April this year, several emails were exchanged regarding development > of a "Vector of Profile" MIB in accordance with the Broadband Forum > TR-165 Vector of Profiles document. > > See the attached thread. > > > > As this issue has been raised again, I would like to see if there is an > interest amongst the members of the Working Group in this work. > > > > Please share your thoughts on this issue. > > > > Best Regards, > > Menachem > From Markus.Freudenberger@t-systems.com Mon Nov 9 02:27:10 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECC628C1E2 for ; Mon, 9 Nov 2009 02:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DJnWaEmWDNB for ; Mon, 9 Nov 2009 02:27:09 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id E4E1428C1DA for ; Mon, 9 Nov 2009 02:27:08 -0800 (PST) From: Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 09 Nov 2009 11:27:25 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:27:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 11:27:23 +0100 Message-ID: <1B6169C658325341A3B8066E23919E1C029EC7C5@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <31373915.1257756744195.JavaMail.root@nskntwebs02p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: AcphGfuNBAa3HmgbTm2Ihmj9WWu3OQAAWOPQ References: <31373915.1257756744195.JavaMail.root@nskntwebs02p> To: X-OriginalArrivalTime: 09 Nov 2009 10:27:24.0537 (UTC) FILETIME=[3A6DBE90:01CA6127] Cc: adslmib@ietf.org, Menachem.Dodge@ecitele.com Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 10:27:10 -0000 Hello Scott, First of all, I recommend to have a look at this paper: = http://www.broadband-forum.org/technical/download/TR-165.pdf. It should = answer a lot of your questions.=20 Regarding your question 1) Yes because Broadband Forum's TR-165 requires this. It obsoletes the = object model for DSL line configuration defined in the TR-129. Regarding your question 2) Yes. Regarding your question 3) I am not sure if I got your question. TR-165 structures the xDSL = configuration parameters into profiles in a different way. A vector is = defined which must not necessarily represent a template. It can be a template which summarizes a certain set of different = profiles but it can also be a single DSL line with single profiles = attached. It might be useful, if you read Appendex I in TR-165. There, the = implementation of "direct attached profiles" vs. "indirect attached = profiles" (which is similar to the templates in the VDSL2-LINE-MIB) is = described. At the end, a potintial VoP MIB should contain the option to = switch between both methods. Regarding your question 4) and 5) and 7) I recommend to read the "Purpose ans Scope" Section of TR-165 on page 7. Regarding your question 6) Yes Regarding your question 8) The criteron should be that the VDSL2-LINE-MIB is based on the object = model of TR-129, which now is obsoleted with TR-165. But please be aware that it is not a decision of using one MIB versus = another. The new "VoP MIB" deals only with configuration parameters = resp. profiles and must be linked together with the VDSL2-LINE-MIB. Most = Parts of RFC 5650 like notifications, line status, inventory or PM are = not touched by Vector of Profiles anyway. Hope this helps. Regards Markus -----Urspr=FCngliche Nachricht----- Von: sbaillie@bigpond.net.au [mailto:sbaillie@bigpond.net.au]=20 Gesendet: Montag, 9. November 2009 09:52 An: Freudenberger, Markus Cc: Menachem.Dodge@ecitele.com; adslmib@ietf.org Betreff: Re: [Adslmib] Vector of Profiles MIB Hi Menachem and Markus, I think we should have a discussion first about the scope and purpose of = the "Vector of Profiles MIB" proposal. Can we please address some of the following issues : 1. Would the new MIB cover all xDSL technologies like the VDSL2 MIB does ? 2. Would the new MIB cover all the parameters defined in G.997.1 ? 3. Would the only difference between the VDSL2 MIB and the new MIB be the way templates are represented ? 4. Can you state the things that the new MIB will have that the VDSL2 MIB does not have. 5. Can you state the things that the VDSL2 MIB has that the new MIB does not have. 6. Is the new MIB intended for embedded use such as in DSLAMs and xDSL line cards ? 7. Can you justify having two MIBs that do basically the same thing but do it in a slightly different way ? 8. If you are a developer of xDSL equipment, what criterion would you use to select one MIB or the other ? Regards, Scott. ---- Markus.Freudenberger@t-systems.com wrote:=20 > on behalf of Deutsche Telekom, I am interested on that item. > =20 > Thanks > Markus > =20 > ________________________________ >=20 > Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im=20 > Auftrag von Menachem Dodge > Gesendet: Montag, 9. November 2009 09:22 > An: Menachem Dodge; 'adslmib@ietf.org' > Betreff: Re: [Adslmib] Vector of Profiles MIB >=20 >=20 >=20 > Hello, >=20 > =20 >=20 > I haven't received any response to my email of last Monday.=20 >=20 > =20 >=20 > If anyone at all, has an interest in this item of work, please speak=20 > up now. >=20 > =20 >=20 > Best Regards, >=20 > Menachem Dodge >=20 > =20 >=20 > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On=20 > Behalf Of Menachem Dodge > Sent: Monday, November 02, 2009 7:07 PM > To: 'adslmib@ietf.org' > Subject: Re: [Adslmib] Vector of Profiles MIB >=20 > =20 >=20 > Hello All, >=20 > =20 >=20 > In April this year, several emails were exchanged regarding=20 > development of a "Vector of Profile" MIB in accordance with the=20 > Broadband Forum > TR-165 Vector of Profiles document. >=20 > See the attached thread. >=20 > =20 >=20 > As this issue has been raised again, I would like to see if there is=20 > an interest amongst the members of the Working Group in this work. >=20 > =20 >=20 > Please share your thoughts on this issue. >=20 > =20 >=20 > Best Regards, >=20 > Menachem >=20 From sbaillie@bigpond.net.au Mon Nov 9 05:22:25 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4C73A680F for ; Mon, 9 Nov 2009 05:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[AWL=-2.889, BAYES_00=-2.599, FH_FAKE_RCVD_LINE_B=5.777] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSXxhIDZNK1I for ; Mon, 9 Nov 2009 05:22:24 -0800 (PST) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by core3.amsl.com (Postfix) with ESMTP id F35A33A67E2 for ; Mon, 9 Nov 2009 05:22:23 -0800 (PST) Received: from nschwotgx02p.mx.bigpond.com ([61.9.190.9]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20091109132248.YLWG4789.nschwmtas03p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Mon, 9 Nov 2009 13:22:48 +0000 Received: from nschwwebs01p ([61.9.190.9]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20091109132247.SAQL19767.nschwotgx02p.mx.bigpond.com@nschwwebs01p>; Mon, 9 Nov 2009 13:22:47 +0000 Received: from 124.190.58.101 by webmail.bigpond.com; Mon, 9 Nov 2009 13:22:47 +0000 Message-ID: <30757091.1257772967786.JavaMail.root@nschwwebs01p> Date: Tue, 10 Nov 2009 0:22:47 +1100 From: "sbaillie@bigpond.net.au" To: Markus.Freudenberger@t-systems.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) Sensitivity: Normal X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4AF817A8.002E,ss=1,fgs=0 Cc: adslmib@ietf.org, Menachem.Dodge@ecitele.com Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 13:22:25 -0000 Hi Markus, Ok, I have read TR-165 now and I get the idea of the proposal. I am not yet convinced that the proposal is sufficiently strong to justify yet another management model for xDSL lines. I accept that Access Nodes MAY have a smaller storage requirement using the VoP approach but in practice will the extra flexibility be used. In my decade of NMS and Access Node experience I have found that ISP's want uniformity, not diversity in their networks, so the assumption that each xDSL line will have a unique configuration is not something our customers have asked for. The one case I can think of where this kind of diversity might happen is where a single SNMP agent must control a large number of line cards rather than having one SNMP agent per line card. My opinion is that we should wait for some input from the guys at Huwei and Alcatel and other big companies and see what they say. If there is no interest from those guys then I would reccomend that Deutsche Telekom implement an enterprise MIB that extends RFC5650 and use that approach rather than creating a new management model with possibly little extra benefit. Regards, Scott. ---- Markus.Freudenberger@t-systems.com wrote:=20 > Hello Scott, >=20 > First of all, I recommend to have a look at this paper: http://www.broadb= and-forum.org/technical/download/TR-165.pdf. It should answer a lot of your= questions.=20 >=20 > Regarding your question 1) > Yes because Broadband Forum's TR-165 requires this. It obsoletes the obje= ct model for DSL line configuration defined in the TR-129. >=20 > Regarding your question 2) > Yes. >=20 > Regarding your question 3) > I am not sure if I got your question. TR-165 structures the xDSL configur= ation parameters into profiles in a different way. A vector is defined whic= h must not necessarily represent a template. > It can be a template which summarizes a certain set of different profiles= but it can also be a single DSL line with single profiles attached. > It might be useful, if you read Appendex I in TR-165. There, the implemen= tation of "direct attached profiles" vs. "indirect attached profiles" (whic= h is similar to the templates in the VDSL2-LINE-MIB) is described. At the e= nd, a potintial VoP MIB should contain the option to switch between both me= thods. >=20 > Regarding your question 4) and 5) and 7) > I recommend to read the "Purpose ans Scope" Section of TR-165 on page 7. >=20 > Regarding your question 6) > Yes >=20 > Regarding your question 8) > The criteron should be that the VDSL2-LINE-MIB is based on the object mod= el of TR-129, which now is obsoleted with TR-165. > But please be aware that it is not a decision of using one MIB versus ano= ther. The new "VoP MIB" deals only with configuration parameters resp. prof= iles and must be linked together with the VDSL2-LINE-MIB. Most Parts of RFC= 5650 like notifications, line status, inventory or PM are not touched by V= ector of Profiles anyway. >=20 > Hope this helps. >=20 > Regards > Markus >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: sbaillie@bigpond.net.au [mailto:sbaillie@bigpond.net.au]=20 > Gesendet: Montag, 9. November 2009 09:52 > An: Freudenberger, Markus > Cc: Menachem.Dodge@ecitele.com; adslmib@ietf.org > Betreff: Re: [Adslmib] Vector of Profiles MIB >=20 > Hi Menachem and Markus, >=20 > I think we should have a discussion first about the scope and purpose of = the "Vector of Profiles MIB" proposal. >=20 > Can we please address some of the following issues : >=20 > 1. Would the new MIB cover all xDSL technologies like the > VDSL2 MIB does ? > 2. Would the new MIB cover all the parameters defined in G.997.1 ? > 3. Would the only difference between the VDSL2 MIB and the new > MIB be the way templates are represented ? > 4. Can you state the things that the new MIB will have that the VDSL2 > MIB does not have. > 5. Can you state the things that the VDSL2 MIB has that the new > MIB does not have. > 6. Is the new MIB intended for embedded use such as in DSLAMs > and xDSL line cards ? > 7. Can you justify having two MIBs that do basically the same thing > but do it in a slightly different way ? > 8. If you are a developer of xDSL equipment, what criterion would you > use to select one MIB or the other ? >=20 >=20 > Regards, >=20 > Scott. >=20 >=20 > ---- Markus.Freudenberger@t-systems.com wrote:=20 > > on behalf of Deutsche Telekom, I am interested on that item. > > =20 > > Thanks > > Markus > > =20 > > ________________________________ > >=20 > > Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im=20 > > Auftrag von Menachem Dodge > > Gesendet: Montag, 9. November 2009 09:22 > > An: Menachem Dodge; 'adslmib@ietf.org' > > Betreff: Re: [Adslmib] Vector of Profiles MIB > >=20 > >=20 > >=20 > > Hello, > >=20 > > =20 > >=20 > > I haven't received any response to my email of last Monday.=20 > >=20 > > =20 > >=20 > > If anyone at all, has an interest in this item of work, please speak=20 > > up now. > >=20 > > =20 > >=20 > > Best Regards, > >=20 > > Menachem Dodge > >=20 > > =20 > >=20 > > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On=20 > > Behalf Of Menachem Dodge > > Sent: Monday, November 02, 2009 7:07 PM > > To: 'adslmib@ietf.org' > > Subject: Re: [Adslmib] Vector of Profiles MIB > >=20 > > =20 > >=20 > > Hello All, > >=20 > > =20 > >=20 > > In April this year, several emails were exchanged regarding=20 > > development of a "Vector of Profile" MIB in accordance with the=20 > > Broadband Forum > > TR-165 Vector of Profiles document. > >=20 > > See the attached thread. > >=20 > > =20 > >=20 > > As this issue has been raised again, I would like to see if there is=20 > > an interest amongst the members of the Working Group in this work. > >=20 > > =20 > >=20 > > Please share your thoughts on this issue. > >=20 > > =20 > >=20 > > Best Regards, > >=20 > > Menachem > >=20 >=20 From Moti.Morgenstern@ecitele.com Mon Nov 9 06:33:43 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231953A6997 for ; Mon, 9 Nov 2009 06:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBvi3JgT-V2v for ; Mon, 9 Nov 2009 06:33:42 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 0D4383A685E for ; Mon, 9 Nov 2009 06:33:40 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by ilptiron01.ecitele.com with ESMTP; 09 Nov 2009 16:24:36 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 9 Nov 2009 16:34:06 +0200 From: Moti Morgenstern To: "sbaillie@bigpond.net.au" , "Markus.Freudenberger@t-systems.com" Date: Mon, 9 Nov 2009 16:34:03 +0200 Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: AcphGgm3vU+rBtVDRIeh+4G8ovjfwQAKelng Message-ID: <741F3E4A466A1D439C616902C7F8A8C6FD5353548C@ILPTMAIL02.ecitele.com> References: <31373915.1257756744195.JavaMail.root@nskntwebs02p> In-Reply-To: <31373915.1257756744195.JavaMail.root@nskntwebs02p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adslmib@ietf.org" , Menachem Dodge Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:33:43 -0000 Hi Scott, How are you? See my embedded answers Moti M -----Original Message----- From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf = Of sbaillie@bigpond.net.au Sent: Monday, November 09, 2009 10:52 AM To: Markus.Freudenberger@t-systems.com Cc: adslmib@ietf.org; Menachem Dodge Subject: Re: [Adslmib] Vector of Profiles MIB Hi Menachem and Markus, I think we should have a discussion first about the scope and purpose of the "Vector of Profiles MIB" proposal. Can we please address some of the following issues : 1. Would the new MIB cover all xDSL technologies like the VDSL2 MIB does ? [MM] Yes. It refers to the same TR-129 and G.997.1 documents 2. Would the new MIB cover all the parameters defined in G.997.1 ? [MM] No. It more-or-less arranges the configuration parameters in a differe= nt way. However, it does not address the status parameters, the PM parameters, alar= m=20 thresholds or notifications. 3. Would the only difference between the VDSL2 MIB and the new MIB be the way templates are represented ? [MM] In addition to (2) above, the main issue is the way 'templates' are re= presented.=20 The other issue is that the 'template', which is now called 'VoP', may belo= ng to a=20 single line. If that ('direct') mode is being utilized then the 'template' = (VoP) is=20 indexed by the line's ifIndex rather than by an ordered identifier/number. = =20 4. Can you state the things that the new MIB will have that the VDSL2 MIB does not have. [MM] In principle (ignoring few details) the configuration VoP is the same = as what=20 we call 'template'. The differences are: The 'direct' vs. 'indirect' VoP at= tachment=20 methods, and better (with some compromises) division of the configuration p= arameters=20 into smaller, focused, profiles. There are also few minor errors (in the vd= sl2 MIB) that are corrected in the new MIB. 5. Can you state the things that the VDSL2 MIB has that the new MIB does not have. [MM] First of all, we're talking about the configuration part of the vdsl2 = MIB.=20 Other parts remain the same. I think the new MIB preserves the characterist= ics of the vdsl2 MIB, except for the indexing. The VoP and related profiles ind= ices are=20 numeric rather than textual.=20 6. Is the new MIB intended for embedded use such as in DSLAMs and xDSL line cards ? [MM] yes. 7. Can you justify having two MIBs that do basically the same thing but do it in a slightly different way ? [MM] There is no justification. The reason VoP was invented is because oper= ators felt that TR-129 model does not divide the configuration parameters in an optimal way= and that may cause waste of memory. The issue of 'direct' vs. 'indirect' attachment methods co= uld also be solved=20 with the TR-129 model. Was it pleasant for the BBF to publish two managemen= t models within=20 a year or two? Certainly not. =20 8. If you are a developer of xDSL equipment, what criterion would you use to select one MIB or the other ? [MM] A very good question. There's no natural mechanism to determine, such = as different ifIndex values. Regards, Scott. ---- Markus.Freudenberger@t-systems.com wrote:=20 > on behalf of Deutsche Telekom, I am interested on that item. > =20 > Thanks > Markus > =20 > ________________________________ >=20 > Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im > Auftrag von Menachem Dodge > Gesendet: Montag, 9. November 2009 09:22 > An: Menachem Dodge; 'adslmib@ietf.org' > Betreff: Re: [Adslmib] Vector of Profiles MIB >=20 >=20 >=20 > Hello, >=20 > =20 >=20 > I haven't received any response to my email of last Monday.=20 >=20 > =20 >=20 > If anyone at all, has an interest in this item of work, please speak up > now. >=20 > =20 >=20 > Best Regards, >=20 > Menachem Dodge >=20 > =20 >=20 > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > Behalf Of Menachem Dodge > Sent: Monday, November 02, 2009 7:07 PM > To: 'adslmib@ietf.org' > Subject: Re: [Adslmib] Vector of Profiles MIB >=20 > =20 >=20 > Hello All, >=20 > =20 >=20 > In April this year, several emails were exchanged regarding development > of a "Vector of Profile" MIB in accordance with the Broadband Forum > TR-165 Vector of Profiles document. >=20 > See the attached thread. >=20 > =20 >=20 > As this issue has been raised again, I would like to see if there is an > interest amongst the members of the Working Group in this work. >=20 > =20 >=20 > Please share your thoughts on this issue. >=20 > =20 >=20 > Best Regards, >=20 > Menachem >=20 _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib From sbaillie@bigpond.net.au Mon Nov 9 07:06:41 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE623A68A6 for ; Mon, 9 Nov 2009 07:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.734 X-Spam-Level: * X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, FH_FAKE_RCVD_LINE_B=5.777] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhkELpNEjJWg for ; Mon, 9 Nov 2009 07:06:41 -0800 (PST) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by core3.amsl.com (Postfix) with ESMTP id 941D93A687D for ; Mon, 9 Nov 2009 07:06:40 -0800 (PST) Received: from nschwotgx02p.mx.bigpond.com ([61.9.190.9]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20091109150705.ICEA28093.nschwmtas05p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com>; Mon, 9 Nov 2009 15:07:05 +0000 Received: from nschwwebs01p ([61.9.190.9]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20091109150705.TYID19767.nschwotgx02p.mx.bigpond.com@nschwwebs01p>; Mon, 9 Nov 2009 15:07:05 +0000 Received: from 124.190.58.101 by webmail.bigpond.com; Mon, 9 Nov 2009 15:07:03 +0000 Message-ID: <17964993.1257779225157.JavaMail.root@nschwwebs01p> Date: Tue, 10 Nov 2009 2:07:05 +1100 From: "sbaillie@bigpond.net.au" To: Moti Morgenstern Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.4AF83019.0085,ss=1,fgs=0 Cc: Menachem Dodge , "adslmib@ietf.org" , "Markus.Freudenberger@t-systems.com" Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 15:06:42 -0000 Hi Moti, I am well, thank you. If the VoP MIB was to go ahead, do you see it as an extension to RFC5650 or would it be a completely new MIB with some copy and paste from RFC5650 to get the new MIB started. Also, what is your feeling for the demand for such a fine grained profile model ? In my experience at NEC we are being asked to provide the opposite approach, ISP's want 4 or 5 service types ( i.e. bronze, silver, gold, platinum ) and most of the configuration parameters are exactly the same because each DSLAM tends to service just one type of customer class ( e.g. FTTH or FTTC or FTTB ). Regards, Scott. ---- Moti Morgenstern wrote: > Hi Scott, > > How are you? > See my embedded answers > > Moti M > > -----Original Message----- > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf Of sbaillie@bigpond.net.au > Sent: Monday, November 09, 2009 10:52 AM > To: Markus.Freudenberger@t-systems.com > Cc: adslmib@ietf.org; Menachem Dodge > Subject: Re: [Adslmib] Vector of Profiles MIB > > Hi Menachem and Markus, > > I think we should have a discussion first about the > scope and purpose of the "Vector of Profiles MIB" proposal. > > Can we please address some of the following issues : > > 1. Would the new MIB cover all xDSL technologies like the > VDSL2 MIB does ? > [MM] Yes. It refers to the same TR-129 and G.997.1 documents > > 2. Would the new MIB cover all the parameters defined in G.997.1 ? > [MM] No. It more-or-less arranges the configuration parameters in a different way. > However, it does not address the status parameters, the PM parameters, alarm > thresholds or notifications. > > 3. Would the only difference between the VDSL2 MIB and the new > MIB be the way templates are represented ? > [MM] In addition to (2) above, the main issue is the way 'templates' are represented. > The other issue is that the 'template', which is now called 'VoP', may belong to a > single line. If that ('direct') mode is being utilized then the 'template' (VoP) is > indexed by the line's ifIndex rather than by an ordered identifier/number. > > 4. Can you state the things that the new MIB will have that the VDSL2 > MIB does not have. > [MM] In principle (ignoring few details) the configuration VoP is the same as what > we call 'template'. The differences are: The 'direct' vs. 'indirect' VoP attachment > methods, and better (with some compromises) division of the configuration parameters > into smaller, focused, profiles. There are also few minor errors (in the vdsl2 MIB) that > are corrected in the new MIB. > > 5. Can you state the things that the VDSL2 MIB has that the new > MIB does not have. > [MM] First of all, we're talking about the configuration part of the vdsl2 MIB. > Other parts remain the same. I think the new MIB preserves the characteristics > of the vdsl2 MIB, except for the indexing. The VoP and related profiles indices are > numeric rather than textual. > > 6. Is the new MIB intended for embedded use such as in DSLAMs > and xDSL line cards ? > [MM] yes. > > 7. Can you justify having two MIBs that do basically the same thing > but do it in a slightly different way ? > [MM] There is no justification. The reason VoP was invented is because operators felt that > TR-129 model does not divide the configuration parameters in an optimal way and that may cause > waste of memory. The issue of 'direct' vs. 'indirect' attachment methods could also be solved > with the TR-129 model. Was it pleasant for the BBF to publish two management models within > a year or two? Certainly not. > > 8. If you are a developer of xDSL equipment, what criterion would you > use to select one MIB or the other ? > [MM] A very good question. There's no natural mechanism to determine, such as different ifIndex values. > > > Regards, > > Scott. > > > ---- Markus.Freudenberger@t-systems.com wrote: > > on behalf of Deutsche Telekom, I am interested on that item. > > > > Thanks > > Markus > > > > ________________________________ > > > > Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im > > Auftrag von Menachem Dodge > > Gesendet: Montag, 9. November 2009 09:22 > > An: Menachem Dodge; 'adslmib@ietf.org' > > Betreff: Re: [Adslmib] Vector of Profiles MIB > > > > > > > > Hello, > > > > > > > > I haven't received any response to my email of last Monday. > > > > > > > > If anyone at all, has an interest in this item of work, please speak up > > now. > > > > > > > > Best Regards, > > > > Menachem Dodge > > > > > > > > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > > Behalf Of Menachem Dodge > > Sent: Monday, November 02, 2009 7:07 PM > > To: 'adslmib@ietf.org' > > Subject: Re: [Adslmib] Vector of Profiles MIB > > > > > > > > Hello All, > > > > > > > > In April this year, several emails were exchanged regarding development > > of a "Vector of Profile" MIB in accordance with the Broadband Forum > > TR-165 Vector of Profiles document. > > > > See the attached thread. > > > > > > > > As this issue has been raised again, I would like to see if there is an > > interest amongst the members of the Working Group in this work. > > > > > > > > Please share your thoughts on this issue. > > > > > > > > Best Regards, > > > > Menachem > > > > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www.ietf.org/mailman/listinfo/adslmib From Menachem.Dodge@ecitele.com Thu Nov 12 08:24:36 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B52B28C1ED for ; Thu, 12 Nov 2009 08:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qETOCyvpGtD7 for ; Thu, 12 Nov 2009 08:24:35 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 89A5028C1EC for ; Thu, 12 Nov 2009 08:24:34 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 12 Nov 2009 18:15:25 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 12 Nov 2009 18:25:02 +0200 From: Menachem Dodge To: "'adslmib@ietf.org'" Date: Thu, 12 Nov 2009 18:25:00 +0200 Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: AcphTlF9hIqyyWBjR/648dJ2YX1cvQCZTYnw Message-ID: <283DD79798619346BF9B17D7B5035A19010797EA489A@ILPTMAIL02.ecitele.com> References: <17964993.1257779225157.JavaMail.root@nschwwebs01p> In-Reply-To: <17964993.1257779225157.JavaMail.root@nschwwebs01p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Moti Morgenstern , "Markus.Freudenberger@t-systems.com" Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 16:24:36 -0000 SGVsbG8sIA0KDQpJcyB0aGVyZSBhbnlvbmUgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgd2hvIHdvdWxk IGxpa2UgdG8gY29tbWVudCBvbiB0aGlzIGlzc3VlPw0KDQpBdCB0aGlzIHN0YWdlIEknbSBub3Qg bG9va2luZyBmb3Igdm9sdW50ZWVycywgSSdtIGp1c3QgdHJ5aW5nIHRvIGdldCBhIGZlZWwgb2Yg aG93IG1hbnkgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgbWVtYmVycyANCmFyZSBpbnRlcmVzdGVkIHRo YXQgdGhpcyBWZWN0b3IgT2YgUHJvZmlsZXMgTUlCIGJlIGRldmVsb3BlZC4NCg0KSSB3b3VsZCBh cHByZWNpYXRlIG1vcmUgcGVvcGxlIHNwZWFraW5nIHVwIGFuZCBzaGFyaW5nIHRoZWlyIG9waW5p b25zLg0KDQpUaGFuayB5b3Uga2luZGx5LA0KTWVuYWNoZW0NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNiYWlsbGllQGJpZ3BvbmQubmV0LmF1IFttYWlsdG86c2JhaWxsaWVA YmlncG9uZC5uZXQuYXVdIA0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwOSwgMjAwOSA1OjA3IFBN DQpUbzogTW90aSBNb3JnZW5zdGVybg0KQ2M6IHNiYWlsbGllQGJpZ3BvbmQubmV0LmF1OyBNZW5h Y2hlbSBEb2RnZTsgTWFya3VzLkZyZXVkZW5iZXJnZXJAdC1zeXN0ZW1zLmNvbTsgYWRzbG1pYkBp ZXRmLm9yZw0KU3ViamVjdDogUkU6IFtBZHNsbWliXSBWZWN0b3Igb2YgUHJvZmlsZXMgTUlCDQoN CkhpIE1vdGksDQoNCkkgYW0gd2VsbCwgdGhhbmsgeW91Lg0KDQpJZiB0aGUgVm9QIE1JQiB3YXMg dG8gZ28gYWhlYWQsIGRvIHlvdSBzZWUgaXQgYXMgYW4gZXh0ZW5zaW9uIHRvDQpSRkM1NjUwIG9y IHdvdWxkIGl0IGJlIGEgY29tcGxldGVseSBuZXcgTUlCIHdpdGggc29tZSBjb3B5IGFuZA0KcGFz dGUgZnJvbSBSRkM1NjUwIHRvIGdldCB0aGUgbmV3IE1JQiBzdGFydGVkLg0KDQpBbHNvLCB3aGF0 IGlzIHlvdXIgZmVlbGluZyBmb3IgdGhlIGRlbWFuZCBmb3Igc3VjaCBhIGZpbmUgZ3JhaW5lZA0K cHJvZmlsZSBtb2RlbCA/IEluIG15IGV4cGVyaWVuY2UgYXQgTkVDIHdlIGFyZSBiZWluZyBhc2tl ZCB0bw0KcHJvdmlkZSB0aGUgb3Bwb3NpdGUgYXBwcm9hY2gsIElTUCdzIHdhbnQgNCBvciA1IHNl cnZpY2UgdHlwZXMNCiggaS5lLiBicm9uemUsIHNpbHZlciwgZ29sZCwgcGxhdGludW0gKSBhbmQg bW9zdCBvZiB0aGUgY29uZmlndXJhdGlvbg0KcGFyYW1ldGVycyBhcmUgZXhhY3RseSB0aGUgc2Ft ZSBiZWNhdXNlIGVhY2ggRFNMQU0gdGVuZHMgdG8NCnNlcnZpY2UganVzdCBvbmUgdHlwZSBvZiBj dXN0b21lciBjbGFzcyAoIGUuZy4gRlRUSCBvciBGVFRDIG9yIEZUVEIgKS4NCg0KUmVnYXJkcywN Cg0KU2NvdHQuDQoNCi0tLS0gTW90aSBNb3JnZW5zdGVybiA8TW90aS5Nb3JnZW5zdGVybkBlY2l0 ZWxlLmNvbT4gd3JvdGU6IA0KPiBIaSBTY290dCwNCj4gDQo+IEhvdyBhcmUgeW91Pw0KPiBTZWUg bXkgZW1iZWRkZWQgYW5zd2Vycw0KPiANCj4gTW90aSBNDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBhZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphZHNs bWliLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBzYmFpbGxpZUBiaWdwb25kLm5ldC5h dQ0KPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDA5LCAyMDA5IDEwOjUyIEFNDQo+IFRvOiBNYXJr dXMuRnJldWRlbmJlcmdlckB0LXN5c3RlbXMuY29tDQo+IENjOiBhZHNsbWliQGlldGYub3JnOyBN ZW5hY2hlbSBEb2RnZQ0KPiBTdWJqZWN0OiBSZTogW0Fkc2xtaWJdIFZlY3RvciBvZiBQcm9maWxl cyBNSUINCj4gDQo+IEhpIE1lbmFjaGVtIGFuZCBNYXJrdXMsDQo+IA0KPiBJIHRoaW5rIHdlIHNo b3VsZCBoYXZlIGEgZGlzY3Vzc2lvbiBmaXJzdCBhYm91dCB0aGUNCj4gc2NvcGUgYW5kIHB1cnBv c2Ugb2YgdGhlICJWZWN0b3Igb2YgUHJvZmlsZXMgTUlCIiBwcm9wb3NhbC4NCj4gDQo+IENhbiB3 ZSBwbGVhc2UgYWRkcmVzcyBzb21lIG9mIHRoZSBmb2xsb3dpbmcgaXNzdWVzIDoNCj4gDQo+IDEu IFdvdWxkIHRoZSBuZXcgTUlCIGNvdmVyIGFsbCB4RFNMIHRlY2hub2xvZ2llcyBsaWtlIHRoZQ0K PiAgICAgVkRTTDIgTUlCIGRvZXMgPw0KPiBbTU1dIFllcy4gSXQgcmVmZXJzIHRvIHRoZSBzYW1l IFRSLTEyOSBhbmQgRy45OTcuMSBkb2N1bWVudHMNCj4gDQo+IDIuIFdvdWxkIHRoZSBuZXcgTUlC IGNvdmVyIGFsbCB0aGUgcGFyYW1ldGVycyBkZWZpbmVkIGluIEcuOTk3LjEgPw0KPiBbTU1dIE5v LiBJdCBtb3JlLW9yLWxlc3MgYXJyYW5nZXMgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBp biBhIGRpZmZlcmVudCB3YXkuDQo+IEhvd2V2ZXIsIGl0IGRvZXMgbm90IGFkZHJlc3MgdGhlIHN0 YXR1cyBwYXJhbWV0ZXJzLCB0aGUgUE0gcGFyYW1ldGVycywgYWxhcm0gDQo+IHRocmVzaG9sZHMg b3Igbm90aWZpY2F0aW9ucy4NCj4gDQo+IDMuIFdvdWxkIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0 d2VlbiB0aGUgVkRTTDIgTUlCIGFuZCB0aGUgbmV3DQo+ICAgICBNSUIgYmUgdGhlIHdheSB0ZW1w bGF0ZXMgYXJlIHJlcHJlc2VudGVkID8NCj4gW01NXSBJbiBhZGRpdGlvbiB0byAoMikgYWJvdmUs IHRoZSBtYWluIGlzc3VlIGlzIHRoZSB3YXkgJ3RlbXBsYXRlcycgYXJlIHJlcHJlc2VudGVkLiAN Cj4gVGhlIG90aGVyIGlzc3VlIGlzIHRoYXQgdGhlICd0ZW1wbGF0ZScsIHdoaWNoIGlzIG5vdyBj YWxsZWQgJ1ZvUCcsIG1heSBiZWxvbmcgdG8gYSANCj4gc2luZ2xlIGxpbmUuIElmIHRoYXQgKCdk aXJlY3QnKSBtb2RlIGlzIGJlaW5nIHV0aWxpemVkIHRoZW4gdGhlICd0ZW1wbGF0ZScgKFZvUCkg aXMgDQo+IGluZGV4ZWQgYnkgdGhlIGxpbmUncyBpZkluZGV4IHJhdGhlciB0aGFuIGJ5IGFuIG9y ZGVyZWQgaWRlbnRpZmllci9udW1iZXIuICAgIA0KPiANCj4gNC4gQ2FuIHlvdSBzdGF0ZSB0aGUg dGhpbmdzIHRoYXQgdGhlIG5ldyBNSUIgd2lsbCBoYXZlIHRoYXQgdGhlIFZEU0wyDQo+ICAgICBN SUIgZG9lcyBub3QgaGF2ZS4NCj4gW01NXSBJbiBwcmluY2lwbGUgKGlnbm9yaW5nIGZldyBkZXRh aWxzKSB0aGUgY29uZmlndXJhdGlvbiBWb1AgaXMgdGhlIHNhbWUgYXMgd2hhdCANCj4gd2UgY2Fs bCAndGVtcGxhdGUnLiBUaGUgZGlmZmVyZW5jZXMgYXJlOiBUaGUgJ2RpcmVjdCcgdnMuICdpbmRp cmVjdCcgVm9QIGF0dGFjaG1lbnQgDQo+IG1ldGhvZHMsIGFuZCBiZXR0ZXIgKHdpdGggc29tZSBj b21wcm9taXNlcykgZGl2aXNpb24gb2YgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyANCj4g aW50byBzbWFsbGVyLCBmb2N1c2VkLCBwcm9maWxlcy4gVGhlcmUgYXJlIGFsc28gZmV3IG1pbm9y IGVycm9ycyAoaW4gdGhlIHZkc2wyIE1JQikgdGhhdA0KPiBhcmUgY29ycmVjdGVkIGluIHRoZSBu ZXcgTUlCLg0KPiANCj4gNS4gQ2FuIHlvdSBzdGF0ZSB0aGUgdGhpbmdzIHRoYXQgdGhlIFZEU0wy IE1JQiBoYXMgdGhhdCB0aGUgbmV3DQo+ICAgICBNSUIgZG9lcyBub3QgaGF2ZS4NCj4gW01NXSBG aXJzdCBvZiBhbGwsIHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIGNvbmZpZ3VyYXRpb24gcGFydCBv ZiB0aGUgdmRzbDIgTUlCLiANCj4gT3RoZXIgcGFydHMgcmVtYWluIHRoZSBzYW1lLiBJIHRoaW5r IHRoZSBuZXcgTUlCIHByZXNlcnZlcyB0aGUgY2hhcmFjdGVyaXN0aWNzDQo+IG9mIHRoZSB2ZHNs MiBNSUIsIGV4Y2VwdCBmb3IgdGhlIGluZGV4aW5nLiBUaGUgVm9QIGFuZCByZWxhdGVkIHByb2Zp bGVzIGluZGljZXMgYXJlIA0KPiBudW1lcmljIHJhdGhlciB0aGFuIHRleHR1YWwuIA0KPiANCj4g Ni4gSXMgdGhlIG5ldyBNSUIgaW50ZW5kZWQgZm9yIGVtYmVkZGVkIHVzZSBzdWNoIGFzIGluIERT TEFNcw0KPiAgICAgYW5kIHhEU0wgbGluZSBjYXJkcyA/DQo+IFtNTV0geWVzLg0KPiANCj4gNy4g Q2FuIHlvdSBqdXN0aWZ5IGhhdmluZyB0d28gTUlCcyB0aGF0IGRvIGJhc2ljYWxseSB0aGUgc2Ft ZSB0aGluZw0KPiAgICAgYnV0IGRvIGl0IGluIGEgc2xpZ2h0bHkgZGlmZmVyZW50IHdheSA/DQo+ IFtNTV0gVGhlcmUgaXMgbm8ganVzdGlmaWNhdGlvbi4gVGhlIHJlYXNvbiBWb1Agd2FzIGludmVu dGVkIGlzIGJlY2F1c2Ugb3BlcmF0b3JzIGZlbHQgdGhhdA0KPiBUUi0xMjkgbW9kZWwgZG9lcyBu b3QgZGl2aWRlIHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgaW4gYW4gb3B0aW1hbCB3YXkg YW5kIHRoYXQgbWF5IGNhdXNlDQo+IHdhc3RlIG9mIG1lbW9yeS4gVGhlIGlzc3VlIG9mICdkaXJl Y3QnIHZzLiAnaW5kaXJlY3QnIGF0dGFjaG1lbnQgbWV0aG9kcyBjb3VsZCBhbHNvIGJlIHNvbHZl ZCANCj4gd2l0aCB0aGUgVFItMTI5IG1vZGVsLiBXYXMgaXQgcGxlYXNhbnQgZm9yIHRoZSBCQkYg dG8gcHVibGlzaCB0d28gbWFuYWdlbWVudCBtb2RlbHMgd2l0aGluIA0KPiBhIHllYXIgb3IgdHdv PyBDZXJ0YWlubHkgbm90Lg0KPiAgICANCj4gOC4gSWYgeW91IGFyZSBhIGRldmVsb3BlciBvZiB4 RFNMIGVxdWlwbWVudCwgd2hhdCBjcml0ZXJpb24gd291bGQgeW91DQo+ICAgICB1c2UgdG8gc2Vs ZWN0IG9uZSBNSUIgb3IgdGhlIG90aGVyID8NCj4gW01NXSBBIHZlcnkgZ29vZCBxdWVzdGlvbi4g VGhlcmUncyBubyBuYXR1cmFsIG1lY2hhbmlzbSB0byBkZXRlcm1pbmUsIHN1Y2ggYXMgZGlmZmVy ZW50IGlmSW5kZXggdmFsdWVzLg0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBTY290dC4NCj4g DQo+IA0KPiAtLS0tIE1hcmt1cy5GcmV1ZGVuYmVyZ2VyQHQtc3lzdGVtcy5jb20gd3JvdGU6IA0K PiA+IG9uIGJlaGFsZiBvZiBEZXV0c2NoZSBUZWxla29tLCBJIGFtIGludGVyZXN0ZWQgb24gdGhh dCBpdGVtLg0KPiA+ICANCj4gPiBUaGFua3MNCj4gPiBNYXJrdXMNCj4gPiAgDQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiANCj4gPiBWb246IGFkc2xtaWItYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmFkc2xtaWItYm91bmNlc0BpZXRmLm9yZ10gSW0NCj4gPiBBdWZ0 cmFnIHZvbiBNZW5hY2hlbSBEb2RnZQ0KPiA+IEdlc2VuZGV0OiBNb250YWcsIDkuIE5vdmVtYmVy IDIwMDkgMDk6MjINCj4gPiBBbjogTWVuYWNoZW0gRG9kZ2U7ICdhZHNsbWliQGlldGYub3JnJw0K PiA+IEJldHJlZmY6IFJlOiBbQWRzbG1pYl0gVmVjdG9yIG9mIFByb2ZpbGVzIE1JQg0KPiA+IA0K PiA+IA0KPiA+IA0KPiA+IEhlbGxvLA0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiBJIGhhdmVuJ3Qg cmVjZWl2ZWQgYW55IHJlc3BvbnNlIHRvIG15IGVtYWlsIG9mIGxhc3QgTW9uZGF5LiANCj4gPiAN Cj4gPiAgDQo+ID4gDQo+ID4gSWYgYW55b25lIGF0IGFsbCwgaGFzIGFuIGludGVyZXN0IGluIHRo aXMgaXRlbSBvZiB3b3JrLCBwbGVhc2Ugc3BlYWsgdXANCj4gPiBub3cuDQo+ID4gDQo+ID4gIA0K PiA+IA0KPiA+IEJlc3QgUmVnYXJkcywNCj4gPiANCj4gPiBNZW5hY2hlbSBEb2RnZQ0KPiA+IA0K PiA+ICANCj4gPiANCj4gPiBGcm9tOiBhZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzph ZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gQmVoYWxmIE9mIE1lbmFjaGVtIERvZGdl DQo+ID4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAwOSA3OjA3IFBNDQo+ID4gVG86ICdh ZHNsbWliQGlldGYub3JnJw0KPiA+IFN1YmplY3Q6IFJlOiBbQWRzbG1pYl0gVmVjdG9yIG9mIFBy b2ZpbGVzIE1JQg0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiBIZWxsbyBBbGwsDQo+ID4gDQo+ID4g IA0KPiA+IA0KPiA+IEluIEFwcmlsIHRoaXMgeWVhciwgc2V2ZXJhbCBlbWFpbHMgd2VyZSBleGNo YW5nZWQgcmVnYXJkaW5nIGRldmVsb3BtZW50DQo+ID4gb2YgYSAiVmVjdG9yIG9mIFByb2ZpbGUi IE1JQiBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIEJyb2FkYmFuZCBGb3J1bQ0KPiA+IFRSLTE2NSBW ZWN0b3Igb2YgUHJvZmlsZXMgZG9jdW1lbnQuDQo+ID4gDQo+ID4gU2VlIHRoZSBhdHRhY2hlZCB0 aHJlYWQuDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IEFzIHRoaXMgaXNzdWUgaGFzIGJlZW4gcmFp c2VkIGFnYWluLCBJIHdvdWxkIGxpa2UgdG8gc2VlIGlmIHRoZXJlIGlzIGFuDQo+ID4gaW50ZXJl c3QgYW1vbmdzdCB0aGUgbWVtYmVycyBvZiB0aGUgV29ya2luZyBHcm91cCBpbiB0aGlzIHdvcmsu DQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IFBsZWFzZSBzaGFyZSB5b3VyIHRob3VnaHRzIG9uIHRo aXMgaXNzdWUuDQo+ID4gDQo+ID4gIA0KPiA+IA0KPiA+IEJlc3QgUmVnYXJkcywNCj4gPiANCj4g PiBNZW5hY2hlbQ0KPiA+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gQWRzbG1pYiBtYWlsaW5nIGxpc3QNCj4gQWRzbG1pYkBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fkc2xtaWINCg0K From Menachem.Dodge@ecitele.com Sun Nov 15 02:24:13 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACAD93A6956 for ; Sun, 15 Nov 2009 02:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-2.147, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJcZrV9ZojJX for ; Sun, 15 Nov 2009 02:24:12 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id A21B53A6957 for ; Sun, 15 Nov 2009 02:24:10 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 15 Nov 2009 12:14:55 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 15 Nov 2009 12:22:56 +0200 From: Menachem Dodge To: "pdyu@huawei.com" , "adslmib@ietf.org" Date: Sun, 15 Nov 2009 12:22:53 +0200 Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: AcphTlF9hIqyyWBjR/648dJ2YX1cvQCZTYnwABXqO1AAdHWxAA== Message-ID: <283DD79798619346BF9B17D7B5035A1901079812D21F@ILPTMAIL02.ecitele.com> References: <283DD79798619346BF9B17D7B5035A19010797EA489A@ILPTMAIL02.ecitele.com> <000301ca640b$3d853b80$482c460a@china.huawei.com> In-Reply-To: <000301ca640b$3d853b80$482c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Moti Morgenstern , "Markus.Freudenberger@t-systems.com" Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 10:24:13 -0000 SGVsbG8gUGVpZGFveXUsDQoNClRoYW5rIHlvdSBraW5kbHkgZm9yIHlvdXIgY29tbWVudHMuDQoN CkknZCBzdGlsbCBsaWtlIHRvIGhlYXIgZnJvbSBtb3JlIHBlb3BsZSBvbiB0aGlzIHN1YmplY3Qu DQoNCkJlc3QgUmVnYXJkcywNCk1lbmFjaGVtIERvZGdlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBwZWlkYW95dSBbbWFpbHRvOnBkeXVAaHVhd2VpLmNvbV0gDQpTZW50OiBG cmlkYXksIE5vdmVtYmVyIDEzLCAyMDA5IDQ6NDUgQU0NClRvOiBNZW5hY2hlbSBEb2RnZTsgYWRz bG1pYkBpZXRmLm9yZw0KQ2M6IE1vdGkgTW9yZ2Vuc3Rlcm47IE1hcmt1cy5GcmV1ZGVuYmVyZ2Vy QHQtc3lzdGVtcy5jb20NClN1YmplY3Q6ILTwuLQ6IFtBZHNsbWliXSBWZWN0b3Igb2YgUHJvZmls ZXMgTUlCDQoNCkhpIGFsbCwNClRoZSBrZXkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBWb1AgTUlC IGFuZCB0aGUgUkZDNTY1MCBpcyB0aGF0IFZvUCBNSUIgYmFzZWQNCm9uIFRSMTY1LCBhbmQgUkZD NTY1MCBiYXNlZCBvbiBUUi0xMjkgbW9kZWwuIFRSLTEyOSBtb2RlbCBoYXMgYmVlbiB1c2VkDQp3 aWRlbHkgbm93LCBhbmQgc29tZSBuZXR3b3JrIG9wZXJhdG9yIGZlZWRiYWNrIHRoYXQgdGhlIFRS MTI5IGFuZA0KobBkcmFmdC1pZXRmLWFkc2xtaWItdmRzbDIteKGxIGNhbiBub3QgbWVldCB0aGVp ciByZXF1aXJlbWVudC4gDQpNYXliZSBhZGQgdGhlIFZvUCBNSUIgdG8gUkZDNTY1MCBhbmQgcHJv dmlkZSBhIHN3aXRjaCB0byBzd2l0Y2ggb3ZlciBiZXR3ZWVuDQp0aGVzZSB0d28gbW9kZWxzIGlz IGEgZ29vZCBjaG9pY2UuDQpCZXN0IHJlZ2FyZHMNClBlaWRhb3l1DQoNCi0tLS0t08q8/tStvP4t LS0tLQ0Kt6K8/sjLOiBhZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphZHNsbWliLWJv dW5jZXNAaWV0Zi5vcmddILT6se0NCk1lbmFjaGVtIERvZGdlDQq3osvNyrG85DogMjAwOcTqMTHU wjEzyNUgMDoyNQ0KytW8/sjLOiAnYWRzbG1pYkBpZXRmLm9yZycNCrOty806IE1vdGkgTW9yZ2Vu c3Rlcm47IE1hcmt1cy5GcmV1ZGVuYmVyZ2VyQHQtc3lzdGVtcy5jb20NCtb3zOI6IFJlOiBbQWRz bG1pYl0gVmVjdG9yIG9mIFByb2ZpbGVzIE1JQg0KDQpIZWxsbywgDQoNCklzIHRoZXJlIGFueW9u ZSBpbiB0aGUgd29ya2luZyBncm91cCB3aG8gd291bGQgbGlrZSB0byBjb21tZW50IG9uIHRoaXMN Cmlzc3VlPw0KDQpBdCB0aGlzIHN0YWdlIEknbSBub3QgbG9va2luZyBmb3Igdm9sdW50ZWVycywg SSdtIGp1c3QgdHJ5aW5nIHRvIGdldCBhIGZlZWwNCm9mIGhvdyBtYW55IG9mIHRoZSB3b3JraW5n IGdyb3VwIG1lbWJlcnMgDQphcmUgaW50ZXJlc3RlZCB0aGF0IHRoaXMgVmVjdG9yIE9mIFByb2Zp bGVzIE1JQiBiZSBkZXZlbG9wZWQuDQoNCkkgd291bGQgYXBwcmVjaWF0ZSBtb3JlIHBlb3BsZSBz cGVha2luZyB1cCBhbmQgc2hhcmluZyB0aGVpciBvcGluaW9ucy4NCg0KVGhhbmsgeW91IGtpbmRs eSwNCk1lbmFjaGVtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYmFpbGxp ZUBiaWdwb25kLm5ldC5hdSBbbWFpbHRvOnNiYWlsbGllQGJpZ3BvbmQubmV0LmF1XSANClNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMDksIDIwMDkgNTowNyBQTQ0KVG86IE1vdGkgTW9yZ2Vuc3Rlcm4N CkNjOiBzYmFpbGxpZUBiaWdwb25kLm5ldC5hdTsgTWVuYWNoZW0gRG9kZ2U7IE1hcmt1cy5GcmV1 ZGVuYmVyZ2VyQHQtc3lzdGVtcy4NCmNvbTsgYWRzbG1pYkBpZXRmLm9yZw0KU3ViamVjdDogUkU6 IFtBZHNsbWliXSBWZWN0b3Igb2YgUHJvZmlsZXMgTUlCDQoNCkhpIE1vdGksDQoNCkkgYW0gd2Vs bCwgdGhhbmsgeW91Lg0KDQpJZiB0aGUgVm9QIE1JQiB3YXMgdG8gZ28gYWhlYWQsIGRvIHlvdSBz ZWUgaXQgYXMgYW4gZXh0ZW5zaW9uIHRvDQpSRkM1NjUwIG9yIHdvdWxkIGl0IGJlIGEgY29tcGxl dGVseSBuZXcgTUlCIHdpdGggc29tZSBjb3B5IGFuZA0KcGFzdGUgZnJvbSBSRkM1NjUwIHRvIGdl dCB0aGUgbmV3IE1JQiBzdGFydGVkLg0KDQpBbHNvLCB3aGF0IGlzIHlvdXIgZmVlbGluZyBmb3Ig dGhlIGRlbWFuZCBmb3Igc3VjaCBhIGZpbmUgZ3JhaW5lZA0KcHJvZmlsZSBtb2RlbCA/IEluIG15 IGV4cGVyaWVuY2UgYXQgTkVDIHdlIGFyZSBiZWluZyBhc2tlZCB0bw0KcHJvdmlkZSB0aGUgb3Bw b3NpdGUgYXBwcm9hY2gsIElTUCdzIHdhbnQgNCBvciA1IHNlcnZpY2UgdHlwZXMNCiggaS5lLiBi cm9uemUsIHNpbHZlciwgZ29sZCwgcGxhdGludW0gKSBhbmQgbW9zdCBvZiB0aGUgY29uZmlndXJh dGlvbg0KcGFyYW1ldGVycyBhcmUgZXhhY3RseSB0aGUgc2FtZSBiZWNhdXNlIGVhY2ggRFNMQU0g dGVuZHMgdG8NCnNlcnZpY2UganVzdCBvbmUgdHlwZSBvZiBjdXN0b21lciBjbGFzcyAoIGUuZy4g RlRUSCBvciBGVFRDIG9yIEZUVEIgKS4NCg0KUmVnYXJkcywNCg0KU2NvdHQuDQoNCi0tLS0gTW90 aSBNb3JnZW5zdGVybiA8TW90aS5Nb3JnZW5zdGVybkBlY2l0ZWxlLmNvbT4gd3JvdGU6IA0KPiBI aSBTY290dCwNCj4gDQo+IEhvdyBhcmUgeW91Pw0KPiBTZWUgbXkgZW1iZWRkZWQgYW5zd2Vycw0K PiANCj4gTW90aSBNDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBh ZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KT2Ygc2JhaWxsaWVAYmlncG9uZC5uZXQuYXUNCj4gU2VudDogTW9uZGF5LCBO b3ZlbWJlciAwOSwgMjAwOSAxMDo1MiBBTQ0KPiBUbzogTWFya3VzLkZyZXVkZW5iZXJnZXJAdC1z eXN0ZW1zLmNvbQ0KPiBDYzogYWRzbG1pYkBpZXRmLm9yZzsgTWVuYWNoZW0gRG9kZ2UNCj4gU3Vi amVjdDogUmU6IFtBZHNsbWliXSBWZWN0b3Igb2YgUHJvZmlsZXMgTUlCDQo+IA0KPiBIaSBNZW5h Y2hlbSBhbmQgTWFya3VzLA0KPiANCj4gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIGRpc2N1c3Np b24gZmlyc3QgYWJvdXQgdGhlDQo+IHNjb3BlIGFuZCBwdXJwb3NlIG9mIHRoZSAiVmVjdG9yIG9m IFByb2ZpbGVzIE1JQiIgcHJvcG9zYWwuDQo+IA0KPiBDYW4gd2UgcGxlYXNlIGFkZHJlc3Mgc29t ZSBvZiB0aGUgZm9sbG93aW5nIGlzc3VlcyA6DQo+IA0KPiAxLiBXb3VsZCB0aGUgbmV3IE1JQiBj b3ZlciBhbGwgeERTTCB0ZWNobm9sb2dpZXMgbGlrZSB0aGUNCj4gICAgIFZEU0wyIE1JQiBkb2Vz ID8NCj4gW01NXSBZZXMuIEl0IHJlZmVycyB0byB0aGUgc2FtZSBUUi0xMjkgYW5kIEcuOTk3LjEg ZG9jdW1lbnRzDQo+IA0KPiAyLiBXb3VsZCB0aGUgbmV3IE1JQiBjb3ZlciBhbGwgdGhlIHBhcmFt ZXRlcnMgZGVmaW5lZCBpbiBHLjk5Ny4xID8NCj4gW01NXSBOby4gSXQgbW9yZS1vci1sZXNzIGFy cmFuZ2VzIHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgaW4gYQ0KZGlmZmVyZW50IHdheS4N Cj4gSG93ZXZlciwgaXQgZG9lcyBub3QgYWRkcmVzcyB0aGUgc3RhdHVzIHBhcmFtZXRlcnMsIHRo ZSBQTSBwYXJhbWV0ZXJzLA0KYWxhcm0gDQo+IHRocmVzaG9sZHMgb3Igbm90aWZpY2F0aW9ucy4N Cj4gDQo+IDMuIFdvdWxkIHRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgVkRTTDIgTUlC IGFuZCB0aGUgbmV3DQo+ICAgICBNSUIgYmUgdGhlIHdheSB0ZW1wbGF0ZXMgYXJlIHJlcHJlc2Vu dGVkID8NCj4gW01NXSBJbiBhZGRpdGlvbiB0byAoMikgYWJvdmUsIHRoZSBtYWluIGlzc3VlIGlz IHRoZSB3YXkgJ3RlbXBsYXRlcycgYXJlDQpyZXByZXNlbnRlZC4gDQo+IFRoZSBvdGhlciBpc3N1 ZSBpcyB0aGF0IHRoZSAndGVtcGxhdGUnLCB3aGljaCBpcyBub3cgY2FsbGVkICdWb1AnLCBtYXkN CmJlbG9uZyB0byBhIA0KPiBzaW5nbGUgbGluZS4gSWYgdGhhdCAoJ2RpcmVjdCcpIG1vZGUgaXMg YmVpbmcgdXRpbGl6ZWQgdGhlbiB0aGUgJ3RlbXBsYXRlJw0KKFZvUCkgaXMgDQo+IGluZGV4ZWQg YnkgdGhlIGxpbmUncyBpZkluZGV4IHJhdGhlciB0aGFuIGJ5IGFuIG9yZGVyZWQgaWRlbnRpZmll ci9udW1iZXIuDQoNCj4gDQo+IDQuIENhbiB5b3Ugc3RhdGUgdGhlIHRoaW5ncyB0aGF0IHRoZSBu ZXcgTUlCIHdpbGwgaGF2ZSB0aGF0IHRoZSBWRFNMMg0KPiAgICAgTUlCIGRvZXMgbm90IGhhdmUu DQo+IFtNTV0gSW4gcHJpbmNpcGxlIChpZ25vcmluZyBmZXcgZGV0YWlscykgdGhlIGNvbmZpZ3Vy YXRpb24gVm9QIGlzIHRoZSBzYW1lDQphcyB3aGF0IA0KPiB3ZSBjYWxsICd0ZW1wbGF0ZScuIFRo ZSBkaWZmZXJlbmNlcyBhcmU6IFRoZSAnZGlyZWN0JyB2cy4gJ2luZGlyZWN0JyBWb1ANCmF0dGFj aG1lbnQgDQo+IG1ldGhvZHMsIGFuZCBiZXR0ZXIgKHdpdGggc29tZSBjb21wcm9taXNlcykgZGl2 aXNpb24gb2YgdGhlIGNvbmZpZ3VyYXRpb24NCnBhcmFtZXRlcnMgDQo+IGludG8gc21hbGxlciwg Zm9jdXNlZCwgcHJvZmlsZXMuIFRoZXJlIGFyZSBhbHNvIGZldyBtaW5vciBlcnJvcnMgKGluIHRo ZQ0KdmRzbDIgTUlCKSB0aGF0DQo+IGFyZSBjb3JyZWN0ZWQgaW4gdGhlIG5ldyBNSUIuDQo+IA0K PiA1LiBDYW4geW91IHN0YXRlIHRoZSB0aGluZ3MgdGhhdCB0aGUgVkRTTDIgTUlCIGhhcyB0aGF0 IHRoZSBuZXcNCj4gICAgIE1JQiBkb2VzIG5vdCBoYXZlLg0KPiBbTU1dIEZpcnN0IG9mIGFsbCwg d2UncmUgdGFsa2luZyBhYm91dCB0aGUgY29uZmlndXJhdGlvbiBwYXJ0IG9mIHRoZSB2ZHNsMg0K TUlCLiANCj4gT3RoZXIgcGFydHMgcmVtYWluIHRoZSBzYW1lLiBJIHRoaW5rIHRoZSBuZXcgTUlC IHByZXNlcnZlcyB0aGUNCmNoYXJhY3RlcmlzdGljcw0KPiBvZiB0aGUgdmRzbDIgTUlCLCBleGNl cHQgZm9yIHRoZSBpbmRleGluZy4gVGhlIFZvUCBhbmQgcmVsYXRlZCBwcm9maWxlcw0KaW5kaWNl cyBhcmUgDQo+IG51bWVyaWMgcmF0aGVyIHRoYW4gdGV4dHVhbC4gDQo+IA0KPiA2LiBJcyB0aGUg bmV3IE1JQiBpbnRlbmRlZCBmb3IgZW1iZWRkZWQgdXNlIHN1Y2ggYXMgaW4gRFNMQU1zDQo+ICAg ICBhbmQgeERTTCBsaW5lIGNhcmRzID8NCj4gW01NXSB5ZXMuDQo+IA0KPiA3LiBDYW4geW91IGp1 c3RpZnkgaGF2aW5nIHR3byBNSUJzIHRoYXQgZG8gYmFzaWNhbGx5IHRoZSBzYW1lIHRoaW5nDQo+ ICAgICBidXQgZG8gaXQgaW4gYSBzbGlnaHRseSBkaWZmZXJlbnQgd2F5ID8NCj4gW01NXSBUaGVy ZSBpcyBubyBqdXN0aWZpY2F0aW9uLiBUaGUgcmVhc29uIFZvUCB3YXMgaW52ZW50ZWQgaXMgYmVj YXVzZQ0Kb3BlcmF0b3JzIGZlbHQgdGhhdA0KPiBUUi0xMjkgbW9kZWwgZG9lcyBub3QgZGl2aWRl IHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgaW4gYW4gb3B0aW1hbA0Kd2F5IGFuZCB0aGF0 IG1heSBjYXVzZQ0KPiB3YXN0ZSBvZiBtZW1vcnkuIFRoZSBpc3N1ZSBvZiAnZGlyZWN0JyB2cy4g J2luZGlyZWN0JyBhdHRhY2htZW50IG1ldGhvZHMNCmNvdWxkIGFsc28gYmUgc29sdmVkIA0KPiB3 aXRoIHRoZSBUUi0xMjkgbW9kZWwuIFdhcyBpdCBwbGVhc2FudCBmb3IgdGhlIEJCRiB0byBwdWJs aXNoIHR3bw0KbWFuYWdlbWVudCBtb2RlbHMgd2l0aGluIA0KPiBhIHllYXIgb3IgdHdvPyBDZXJ0 YWlubHkgbm90Lg0KPiAgICANCj4gOC4gSWYgeW91IGFyZSBhIGRldmVsb3BlciBvZiB4RFNMIGVx dWlwbWVudCwgd2hhdCBjcml0ZXJpb24gd291bGQgeW91DQo+ICAgICB1c2UgdG8gc2VsZWN0IG9u ZSBNSUIgb3IgdGhlIG90aGVyID8NCj4gW01NXSBBIHZlcnkgZ29vZCBxdWVzdGlvbi4gVGhlcmUn cyBubyBuYXR1cmFsIG1lY2hhbmlzbSB0byBkZXRlcm1pbmUsIHN1Y2gNCmFzIGRpZmZlcmVudCBp ZkluZGV4IHZhbHVlcy4NCj4gDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gU2NvdHQuDQo+IA0KPiAN Cj4gLS0tLSBNYXJrdXMuRnJldWRlbmJlcmdlckB0LXN5c3RlbXMuY29tIHdyb3RlOiANCj4gPiBv biBiZWhhbGYgb2YgRGV1dHNjaGUgVGVsZWtvbSwgSSBhbSBpbnRlcmVzdGVkIG9uIHRoYXQgaXRl bS4NCj4gPiAgDQo+ID4gVGhhbmtzDQo+ID4gTWFya3VzDQo+ID4gIA0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gDQo+ID4gVm9uOiBhZHNsbWliLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzphZHNsbWliLWJvdW5jZXNAaWV0Zi5vcmddIEltDQo+ID4gQXVmdHJhZyB2 b24gTWVuYWNoZW0gRG9kZ2UNCj4gPiBHZXNlbmRldDogTW9udGFnLCA5LiBOb3ZlbWJlciAyMDA5 IDA5OjIyDQo+ID4gQW46IE1lbmFjaGVtIERvZGdlOyAnYWRzbG1pYkBpZXRmLm9yZycNCj4gPiBC ZXRyZWZmOiBSZTogW0Fkc2xtaWJdIFZlY3RvciBvZiBQcm9maWxlcyBNSUINCj4gPiANCj4gPiAN Cj4gPiANCj4gPiBIZWxsbywNCj4gPiANCj4gPiAgDQo+ID4gDQo+ID4gSSBoYXZlbid0IHJlY2Vp dmVkIGFueSByZXNwb25zZSB0byBteSBlbWFpbCBvZiBsYXN0IE1vbmRheS4gDQo+ID4gDQo+ID4g IA0KPiA+IA0KPiA+IElmIGFueW9uZSBhdCBhbGwsIGhhcyBhbiBpbnRlcmVzdCBpbiB0aGlzIGl0 ZW0gb2Ygd29yaywgcGxlYXNlIHNwZWFrIHVwDQo+ID4gbm93Lg0KPiA+IA0KPiA+ICANCj4gPiAN Cj4gPiBCZXN0IFJlZ2FyZHMsDQo+ID4gDQo+ID4gTWVuYWNoZW0gRG9kZ2UNCj4gPiANCj4gPiAg DQo+ID4gDQo+ID4gRnJvbTogYWRzbG1pYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YWRzbG1p Yi1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiA+IEJlaGFsZiBPZiBNZW5hY2hlbSBEb2RnZQ0KPiA+ IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDIsIDIwMDkgNzowNyBQTQ0KPiA+IFRvOiAnYWRzbG1p YkBpZXRmLm9yZycNCj4gPiBTdWJqZWN0OiBSZTogW0Fkc2xtaWJdIFZlY3RvciBvZiBQcm9maWxl cyBNSUINCj4gPiANCj4gPiAgDQo+ID4gDQo+ID4gSGVsbG8gQWxsLA0KPiA+IA0KPiA+ICANCj4g PiANCj4gPiBJbiBBcHJpbCB0aGlzIHllYXIsIHNldmVyYWwgZW1haWxzIHdlcmUgZXhjaGFuZ2Vk IHJlZ2FyZGluZyBkZXZlbG9wbWVudA0KPiA+IG9mIGEgIlZlY3RvciBvZiBQcm9maWxlIiBNSUIg aW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBCcm9hZGJhbmQgRm9ydW0NCj4gPiBUUi0xNjUgVmVjdG9y IG9mIFByb2ZpbGVzIGRvY3VtZW50Lg0KPiA+IA0KPiA+IFNlZSB0aGUgYXR0YWNoZWQgdGhyZWFk Lg0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiBBcyB0aGlzIGlzc3VlIGhhcyBiZWVuIHJhaXNlZCBh Z2FpbiwgSSB3b3VsZCBsaWtlIHRvIHNlZSBpZiB0aGVyZSBpcyBhbg0KPiA+IGludGVyZXN0IGFt b25nc3QgdGhlIG1lbWJlcnMgb2YgdGhlIFdvcmtpbmcgR3JvdXAgaW4gdGhpcyB3b3JrLg0KPiA+ IA0KPiA+ICANCj4gPiANCj4gPiBQbGVhc2Ugc2hhcmUgeW91ciB0aG91Z2h0cyBvbiB0aGlzIGlz c3VlLg0KPiA+IA0KPiA+ICANCj4gPiANCj4gPiBCZXN0IFJlZ2FyZHMsDQo+ID4gDQo+ID4gTWVu YWNoZW0NCj4gPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEFkc2xtaWIgbWFpbGluZyBsaXN0DQo+IEFkc2xtaWJAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZHNsbWliDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBZHNsbWliIG1haWxpbmcg bGlzdA0KQWRzbG1pYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hZHNsbWliDQoNCg== From sbaillie@bigpond.net.au Sun Nov 15 04:01:27 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9755A3A695F for ; Sun, 15 Nov 2009 04:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyyFqxU3rc5a for ; Sun, 15 Nov 2009 04:01:26 -0800 (PST) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by core3.amsl.com (Postfix) with ESMTP id 735373A692C for ; Sun, 15 Nov 2009 04:01:26 -0800 (PST) Received: from nschwotgx03p.mx.bigpond.com ([124.190.58.101]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20091115120156.XNTP4789.nschwmtas03p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com>; Sun, 15 Nov 2009 12:01:56 +0000 Received: from [192.168.1.128] (really [124.190.58.101]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20091115120156.ZEYT7394.nschwotgx03p.mx.bigpond.com@[192.168.1.128]>; Sun, 15 Nov 2009 12:01:56 +0000 From: Scott Baillie To: Menachem Dodge , "pdyu@huawei.com" , "adslmib@ietf.org" , Moti Morgenstern , "Markus.Freudenberger@t-systems.com" , "gerd.barchmann@nsn.com" , "wolfgang.krille@nsn.com" In-Reply-To: <283DD79798619346BF9B17D7B5035A1901079812D21F@ILPTMAIL02.ecitele.com> References: <283DD79798619346BF9B17D7B5035A19010797EA489A@ILPTMAIL02.ecitele.com> <000301ca640b$3d853b80$482c460a@china.huawei.com> <283DD79798619346BF9B17D7B5035A1901079812D21F@ILPTMAIL02.ecitele.com> Content-Type: text/plain Date: Sun, 15 Nov 2009 23:00:07 +1100 Message-Id: <1258286407.6131.54.camel@ethip128> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-2.fc5) Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at nschwotgx03p.mx.bigpond.com from [124.190.58.101] using ID sbaillie@bigpond.net.au at Sun, 15 Nov 2009 12:01:55 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.4AFFEDB4.007B,ss=1,fgs=0 Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 12:01:27 -0000 Hi all, As you may know from my previous messages on the subject of the Vector of Profiles MIB proposal, I do not believe that it is a good idea to introduce another VDSL2 management interface which is not compatible with the existing management interface ( RFC5650 ) unless there are compelling and significant reasons to do so. Introducing an incompatible VDSL2 management interface does not benefit the xDSL industry, it causes harm because NMS/EMS applications will now have to support two interfaces instead of one. I consider the Vector of Profiles scheme to be an implementation decision which should be considered by firmware developers in order to minimise the storage requirements for xDSL configuration in the Access Node. But this implementation decision is a low level detail and should not affect the VDSL2 management interface. A firmware developer can implement the VoP scheme inside the Access Node while remaining 100% compatible with the RFC5650 management interface. What is required is to provide a mapping between the template name and the vector, and this mapping can be kept hidden so that the operator has no knowledge of the internal implementation details. Let me state my proposal in a different way in case what I said was not very clear. 1. Internally, the xDSL configuration is stored using the efficient VoP scheme. 2. In the firmware, a mapping exists between the RFC5650 template name and the internal vector that stores the configuration for that template. This mapping may take the form of a hash map for example. 3. When a SNMP request arrives to read a row from the line profile or channel profile tables ( xdsl2LineConfProfTable, xdsl2LineConfProfModeSpecTable xdsl2LineConfProfModeSpecBandUsTable, xdsl2ChConfProfileTable ) the access node will consult its hash map and find the corresponding vector. The access node will then retrieve the data from the vector and return it in the form of a SNMP row. What this means is that storage of the xDSL configuration data is decoupled from the MIB representation of the data. Most modern SNMP agent's ( such as the Net SNMP agent ) supports decoupling of the underlying storage as I have described. 4. When a SNMP request arrives to write a row into the line profile or channel profile tables, the access node must either create a new vector to store the data of reference an existing vector which already contains that data. Using this approach, the access node gains the advantage of storing the xDSL configuration data efficiently while remaining compatible with the existing SNMP management interface. The algorithm that I have described above would need to be specified in more detail, but I am sure that every one here is an engineer and at least understands the concept that I am proposing. In conclusion, I think that the broad band forum should create a companion document that goes together with TR165 which specifies an algorithm ( similar to what I have proposed above ) that firmware developers can use to map between 5650 templates and VoP vectors instead of specifying a new VDSL2 management interface at the IETF. Regards, Scott. From Markus.Freudenberger@t-systems.com Tue Nov 17 01:05:09 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C223A69FD for ; Tue, 17 Nov 2009 01:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK-5PsCf+Ya2 for ; Tue, 17 Nov 2009 01:05:08 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 5008B3A696F for ; Tue, 17 Nov 2009 01:05:08 -0800 (PST) From: Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 17 Nov 2009 10:04:53 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 10:04:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Nov 2009 10:04:52 +0100 Message-ID: <1B6169C658325341A3B8066E23919E1C03472231@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1258286407.6131.54.camel@ethip128> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vector of Profiles MIB Thread-Index: Acpl63BNfE8e4mrvTWq3KmzwH6PZWQBdK7iw References: <283DD79798619346BF9B17D7B5035A19010797EA489A@ILPTMAIL02.ecitele.com> <000301ca640b$3d853b80$482c460a@china.huawei.com> <283DD79798619346BF9B17D7B5035A1901079812D21F@ILPTMAIL02.ecitele.com> <1258286407.6131.54.camel@ethip128> To: X-OriginalArrivalTime: 17 Nov 2009 09:04:53.0550 (UTC) FILETIME=[06B714E0:01CA6765] Cc: adslmib@ietf.org, wolfgang.krille@nsn.com, Menachem.Dodge@ecitele.com, Moti.Morgenstern@ecitele.com Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 09:05:09 -0000 Hello Scott, I understand your proposal but it does not address the complete issue.=20 Operators need more flexibility of configuring their network. The = approach of TR-129 does not scale from the OSS point view as it = multiplies the amount of different xDSL profiles/templates. In practice, = the MIB from the DSLAM (In this case represeting the TR-129 object = model) is usually mapped 1:1 into the EMS and its data model. In FTTx = deployment scenarios with specific requirements depending on the PSD = shaping on the remote DSLAM, noise margins, specific OLR features and = INP configurations, TR-129 causes a multiplication of templates as every = single parameter variation ends up in a new template and/or channel or = line profile. Therefore TR-165 needs to be implemented at the SNMP management = interface and in the associated EMS to take full effect. Be aware that only the profile configurtion of RFC5650 is affected, all = other parts are untouched and can stay as they are today. In order to = not skip the template approach from TR-129 completely, a switch, as = proposed by Peidaoyu from Huawei, might be a good solution. Regards Markus =20 -----Urspr=FCngliche Nachricht----- Von: Scott Baillie [mailto:sbaillie@bigpond.net.au]=20 Gesendet: Sonntag, 15. November 2009 13:00 An: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti Morgenstern; = Freudenberger, Markus; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com Betreff: Re: Vector of Profiles MIB Hi all, As you may know from my previous messages on the subject of the Vector = of Profiles MIB proposal, I do not believe that it is a good idea to = introduce another VDSL2 management interface which is not compatible = with the existing management interface ( RFC5650 ) unless there are = compelling and significant reasons to do so. Introducing an incompatible VDSL2 management interface does not benefit = the xDSL industry, it causes harm because NMS/EMS applications will now = have to support two interfaces instead of one. I consider the Vector of Profiles scheme to be an implementation = decision which should be considered by firmware developers in order to = minimise the storage requirements for xDSL configuration in the Access = Node. But this implementation decision is a low level detail and should not = affect the VDSL2 management interface. A firmware developer can implement the VoP scheme inside the Access Node = while remaining 100% compatible with the RFC5650 management interface. = What is required is to provide a mapping between the template name and = the vector, and this mapping can be kept hidden so that the operator has = no knowledge of the internal implementation details. Let me state my proposal in a different way in case what I said was not = very clear. 1. Internally, the xDSL configuration is stored using the efficient VoP scheme. 2. In the firmware, a mapping exists between the RFC5650 template name and the internal vector that stores the configuration for that template. This mapping may take the form of a hash map for example. 3. When a SNMP request arrives to read a row from the line profile or channel profile tables ( xdsl2LineConfProfTable, xdsl2LineConfProfModeSpecTable xdsl2LineConfProfModeSpecBandUsTable, xdsl2ChConfProfileTable ) the access node will consult its hash map and find the corresponding vector. The access node will then retrieve the data from the vector and return it in the form of a SNMP row. What this means is that storage of the xDSL configuration data is decoupled from the MIB representation of the data. Most modern SNMP agent's ( such as the Net SNMP agent ) supports decoupling of the underlying storage as I have described. 4. When a SNMP request arrives to write a row into the line profile or channel profile tables, the access node must either create a new vector to store the data of reference an existing vector which already contains that data. Using this approach, the access node gains the advantage of storing the = xDSL configuration data efficiently while remaining compatible with the = existing SNMP management interface. The algorithm that I have described above would need to be specified in = more detail, but I am sure that every one here is an engineer and at = least understands the concept that I am proposing. In conclusion, I think that the broad band forum should create a = companion document that goes together with TR165 which specifies an = algorithm ( similar to what I have proposed above ) that firmware = developers can use to map between 5650 templates and VoP vectors instead = of specifying a new VDSL2 management interface at the IETF. Regards, Scott. From Menachem.Dodge@ecitele.com Mon Nov 23 07:21:19 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBF928C163 for ; Mon, 23 Nov 2009 07:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY1UgKeCcmnn for ; Mon, 23 Nov 2009 07:21:18 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 4004128C161 for ; Mon, 23 Nov 2009 07:21:16 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 23 Nov 2009 17:11:10 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 23 Nov 2009 17:21:11 +0200 From: Menachem Dodge To: "adslmib@ietf.org" Date: Mon, 23 Nov 2009 17:21:09 +0200 Thread-Topic: Vector of Profiles MIB Thread-Index: Acpl63BNfE8e4mrvTWq3KmzwH6PZWQBdK7iwATuGd9A= Message-ID: <283DD79798619346BF9B17D7B5035A190107D8746408@ILPTMAIL02.ecitele.com> References: <283DD79798619346BF9B17D7B5035A19010797EA489A@ILPTMAIL02.ecitele.com> <000301ca640b$3d853b80$482c460a@china.huawei.com> <283DD79798619346BF9B17D7B5035A1901079812D21F@ILPTMAIL02.ecitele.com> <1258286407.6131.54.camel@ethip128> <1B6169C658325341A3B8066E23919E1C03472231@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C03472231@S4DE8PSAANK.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:21:19 -0000 Hello,=20 So far only a small number of WG members have offered their opinion as to w= hether or not the TR-165 management model should be developed. A suggestion has been proposed such that an optional extension to RFC 5650 = be developed that would contain a switch allowing either the current TR-129= model or the TR-165 model to be supported. The opinions thus far have been divided, even regarding this optional exten= sion. I would appreciate additional members of the WG to come forward and voice t= heir view. Thank you kindly, Menachem Dodge -----Original Message----- From: Markus.Freudenberger@t-systems.com [mailto:Markus.Freudenberger@t-sys= tems.com]=20 Sent: Tuesday, November 17, 2009 11:05 AM To: sbaillie@bigpond.net.au Cc: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti Morgenstern; ge= rd.barchmann@nsn.com; wolfgang.krille@nsn.com Subject: AW: Vector of Profiles MIB Hello Scott, I understand your proposal but it does not address the complete issue.=20 Operators need more flexibility of configuring their network. The approach = of TR-129 does not scale from the OSS point view as it multiplies the amoun= t of different xDSL profiles/templates. In practice, the MIB from the DSLAM= (In this case represeting the TR-129 object model) is usually mapped 1:1 i= nto the EMS and its data model. In FTTx deployment scenarios with specific = requirements depending on the PSD shaping on the remote DSLAM, noise margin= s, specific OLR features and INP configurations, TR-129 causes a multiplica= tion of templates as every single parameter variation ends up in a new temp= late and/or channel or line profile. Therefore TR-165 needs to be implemented at the SNMP management interface a= nd in the associated EMS to take full effect. Be aware that only the profile configurtion of RFC5650 is affected, all oth= er parts are untouched and can stay as they are today. In order to not skip= the template approach from TR-129 completely, a switch, as proposed by Pei= daoyu from Huawei, might be a good solution. Regards Markus =20 -----Urspr=FCngliche Nachricht----- Von: Scott Baillie [mailto:sbaillie@bigpond.net.au]=20 Gesendet: Sonntag, 15. November 2009 13:00 An: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti Morgenstern; Fr= eudenberger, Markus; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com Betreff: Re: Vector of Profiles MIB Hi all, As you may know from my previous messages on the subject of the Vector of P= rofiles MIB proposal, I do not believe that it is a good idea to introduce = another VDSL2 management interface which is not compatible with the existin= g management interface ( RFC5650 ) unless there are compelling and signific= ant reasons to do so. Introducing an incompatible VDSL2 management interface does not benefit the= xDSL industry, it causes harm because NMS/EMS applications will now have t= o support two interfaces instead of one. I consider the Vector of Profiles scheme to be an implementation decision w= hich should be considered by firmware developers in order to minimise the s= torage requirements for xDSL configuration in the Access Node. But this implementation decision is a low level detail and should not affec= t the VDSL2 management interface. A firmware developer can implement the VoP scheme inside the Access Node wh= ile remaining 100% compatible with the RFC5650 management interface. What i= s required is to provide a mapping between the template name and the vector= , and this mapping can be kept hidden so that the operator has no knowledge= of the internal implementation details. Let me state my proposal in a different way in case what I said was not ver= y clear. 1. Internally, the xDSL configuration is stored using the efficient VoP scheme. 2. In the firmware, a mapping exists between the RFC5650 template name and the internal vector that stores the configuration for that template. This mapping may take the form of a hash map for example. 3. When a SNMP request arrives to read a row from the line profile or channel profile tables ( xdsl2LineConfProfTable, xdsl2LineConfProfModeSpecTable xdsl2LineConfProfModeSpecBandUsTable, xdsl2ChConfProfileTable ) the access node will consult its hash map and find the corresponding vector. The access node will then retrieve the data from the vector and return it in the form of a SNMP row. What this means is that storage of the xDSL configuration data is decoupled from the MIB representation of the data. Most modern SNMP agent's ( such as the Net SNMP agent ) supports decoupling of the underlying storage as I have described. 4. When a SNMP request arrives to write a row into the line profile or channel profile tables, the access node must either create a new vector to store the data of reference an existing vector which already contains that data. Using this approach, the access node gains the advantage of storing the xDS= L configuration data efficiently while remaining compatible with the existi= ng SNMP management interface. The algorithm that I have described above would need to be specified in mor= e detail, but I am sure that every one here is an engineer and at least und= erstands the concept that I am proposing. In conclusion, I think that the broad band forum should create a companion = document that goes together with TR165 which specifies an algorithm ( simil= ar to what I have proposed above ) that firmware developers can use to map = between 5650 templates and VoP vectors instead of specifying a new VDSL2 ma= nagement interface at the IETF. Regards, Scott. From sbaillie@bigpond.net.au Mon Nov 23 21:44:33 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCB03A6B2E for ; Mon, 23 Nov 2009 21:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ9LaYndSAJZ for ; Mon, 23 Nov 2009 21:44:32 -0800 (PST) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by core3.amsl.com (Postfix) with ESMTP id 2AF443A687D for ; Mon, 23 Nov 2009 21:44:31 -0800 (PST) Received: from nskntotgx02p.mx.bigpond.com ([124.190.58.101]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20091124054426.KNLH10503.nskntmtas01p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Tue, 24 Nov 2009 05:44:26 +0000 Received: from [192.168.1.128] (really [124.190.58.101]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20091124054425.UWZZ5306.nskntotgx02p.mx.bigpond.com@[192.168.1.128]>; Tue, 24 Nov 2009 05:44:25 +0000 From: Scott Baillie To: Menachem Dodge In-Reply-To: <283DD79798619346BF9B17D7B5035A190107D8746408@ILPTMAIL02.ecitele.com> References: <283DD79798619346BF9B17D7B5035A19010797EA489A@ILPTMAIL02.ecitele.com> <000301ca640b$3d853b80$482c460a@china.huawei.com> <283DD79798619346BF9B17D7B5035A1901079812D21F@ILPTMAIL02.ecitele.com> <1258286407.6131.54.camel@ethip128> <1B6169C658325341A3B8066E23919E1C03472231@S4DE8PSAANK.mitte.t-com.de> <283DD79798619346BF9B17D7B5035A190107D8746408@ILPTMAIL02.ecitele.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 24 Nov 2009 16:42:36 +1100 Message-Id: <1259041356.2749.29.camel@ethip128> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-2.fc5) Content-Transfer-Encoding: 8bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at nskntotgx02p.mx.bigpond.com from [124.190.58.101] using ID sbaillie@bigpond.net.au at Tue, 24 Nov 2009 05:44:25 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4B0B72BA.005C,ss=1,fgs=0 Cc: "adslmib@ietf.org" Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:44:34 -0000 Hi All, I would like to summarise my position on the Vector of Profiles MIB proposal so that it is clearer what my position is, but I would like to hear the views of the group on these issues. My position ----------- 1. I would prefer that the TR-165 enhancements be implemented at a lower layer and hence no need to change the RFC-5650 management interface. The reasons for this are covered in my previous post. 2. If the RFC-5650 extension MIB was to go ahead anyway, I would be very much opposed to the effort unless : a) The TR-129 model is mandatory and the TR-165 model is optional. Hence, a SNMP agent MUST implement the template model but MAY implement the VoP model. b) The tables in RFC-5650 are not altered in any way, only one scalar variable is added to RFC-5650. The scalar variable would be writeable and have 2 values. c) When a SNMP agent is configured to operate in TR-165 mode, it must also be fully manageable by a SNMP manager that only understands the TR-129 model. Regards, Scott. On Mon, 2009-11-23 at 17:21 +0200, Menachem Dodge wrote: > Hello, > > So far only a small number of WG members have offered their opinion as to whether or not the TR-165 management model should be developed. > > A suggestion has been proposed such that an optional extension to RFC 5650 be developed that would contain a switch allowing either the current TR-129 model or the TR-165 model to be supported. > > The opinions thus far have been divided, even regarding this optional extension. > > I would appreciate additional members of the WG to come forward and voice their view. > > Thank you kindly, > Menachem Dodge > > > > -----Original Message----- > From: Markus.Freudenberger@t-systems.com [mailto:Markus.Freudenberger@t-systems.com] > Sent: Tuesday, November 17, 2009 11:05 AM > To: sbaillie@bigpond.net.au > Cc: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti Morgenstern; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Subject: AW: Vector of Profiles MIB > > Hello Scott, > > I understand your proposal but it does not address the complete issue. > Operators need more flexibility of configuring their network. The approach of TR-129 does not scale from the OSS point view as it multiplies the amount of different xDSL profiles/templates. In practice, the MIB from the DSLAM (In this case represeting the TR-129 object model) is usually mapped 1:1 into the EMS and its data model. In FTTx deployment scenarios with specific requirements depending on the PSD shaping on the remote DSLAM, noise margins, specific OLR features and INP configurations, TR-129 causes a multiplication of templates as every single parameter variation ends up in a new template and/or channel or line profile. > > Therefore TR-165 needs to be implemented at the SNMP management interface and in the associated EMS to take full effect. > > Be aware that only the profile configurtion of RFC5650 is affected, all other parts are untouched and can stay as they are today. In order to not skip the template approach from TR-129 completely, a switch, as proposed by Peidaoyu from Huawei, might be a good solution. > > Regards > Markus > > > -----Urspr√ľngliche Nachricht----- > Von: Scott Baillie [mailto:sbaillie@bigpond.net.au] > Gesendet: Sonntag, 15. November 2009 13:00 > An: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti Morgenstern; Freudenberger, Markus; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Betreff: Re: Vector of Profiles MIB > > Hi all, > > As you may know from my previous messages on the subject of the Vector of Profiles MIB proposal, I do not believe that it is a good idea to introduce another VDSL2 management interface which is not compatible with the existing management interface ( RFC5650 ) unless there are compelling and significant reasons to do so. > > Introducing an incompatible VDSL2 management interface does not benefit the xDSL industry, it causes harm because NMS/EMS applications will now have to support two interfaces instead of one. > > I consider the Vector of Profiles scheme to be an implementation decision which should be considered by firmware developers in order to minimise the storage requirements for xDSL configuration in the Access Node. > But this implementation decision is a low level detail and should not affect the VDSL2 management interface. > > A firmware developer can implement the VoP scheme inside the Access Node while remaining 100% compatible with the RFC5650 management interface. What is required is to provide a mapping between the template name and the vector, and this mapping can be kept hidden so that the operator has no knowledge of the internal implementation details. > > Let me state my proposal in a different way in case what I said was not very clear. > > 1. Internally, the xDSL configuration is stored using > the efficient VoP scheme. > 2. In the firmware, a mapping exists between the RFC5650 > template name and the internal vector that stores the > configuration for that template. This mapping may take > the form of a hash map for example. > 3. When a SNMP request arrives to read a row from the > line profile or channel profile tables > ( xdsl2LineConfProfTable, > xdsl2LineConfProfModeSpecTable > xdsl2LineConfProfModeSpecBandUsTable, > xdsl2ChConfProfileTable ) > the access node will consult its hash map and find > the corresponding vector. The access node will then > retrieve the data from the vector and return it in > the form of a SNMP row. > What this means is that storage of the xDSL > configuration data is decoupled from the MIB > representation of the data. Most modern SNMP agent's > ( such as the Net SNMP agent ) supports decoupling > of the underlying storage as I have described. > 4. When a SNMP request arrives to write a row into > the line profile or channel profile tables, the > access node must either create a new vector to > store the data of reference an existing vector > which already contains that data. > > Using this approach, the access node gains the advantage of storing the xDSL configuration data efficiently while remaining compatible with the existing SNMP management interface. > > The algorithm that I have described above would need to be specified in more detail, but I am sure that every one here is an engineer and at least understands the concept that I am proposing. > > In conclusion, I think that the broad band forum should create a companion document that goes together with TR165 which specifies an algorithm ( similar to what I have proposed above ) that firmware developers can use to map between 5650 templates and VoP vectors instead of specifying a new VDSL2 management interface at the IETF. > > Regards, > > Scott. > > > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www.ietf.org/mailman/listinfo/adslmib From umberto.bonollo@nec.com.au Mon Nov 23 22:02:34 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9523A67A4 for ; Mon, 23 Nov 2009 22:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeEaCKnLO42w for ; Mon, 23 Nov 2009 22:02:33 -0800 (PST) Received: from smtpa.dc.nec.com.au (smtp.dc.nec.com.au [147.76.15.3]) by core3.amsl.com (Postfix) with ESMTP id A9B083A677E for ; Mon, 23 Nov 2009 22:02:32 -0800 (PST) Received: from smtp1.nec.com.au (unknown [147.76.180.138]) by smtpa.dc.nec.com.au (Postfix) with ESMTPS id 50ED225C93 for ; Tue, 24 Nov 2009 17:02:26 +1100 (EST) Received: from smtp3.NECAU.NEC.COM.AU (smtp2.nec.com.au [172.31.8.19]) by smtp1.nec.com.au (Postfix) with ESMTP id 38E2C7FD01 for ; Tue, 24 Nov 2009 17:02:26 +1100 (EST) Received: from warp.ssd.neca.nec.com.au ([147.76.48.65]) by smtp3.NECAU.NEC.COM.AU with InterScan Messaging Security Suite; Tue, 24 Nov 2009 17:02:25 +1100 Received: from miracle ([172.31.161.98]) by warp.ssd.neca.nec.com.au (8.13.8+Sun/8.13.8) with SMTP id nAO62PNH002873; Tue, 24 Nov 2009 17:02:25 +1100 (EST) From: "Umberto Bonollo" To: "'Scott Baillie'" , "Menachem Dodge" Date: Tue, 24 Nov 2009 17:00:59 +1000 Message-ID: <004a01ca6cd3$e15e3fb0$62a11fac@ssd.neca.nec.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <1259041356.2749.29.camel@ethip128> Cc: adslmib@ietf.org Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: umberto.bonollo@nec.com.au List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 06:02:34 -0000 Hi Scott, I am in agreement with your position in 1. and 2. below. It must be possible for RFC-5650 to work independently of possible optional VOP add-on. >From very large projects in the field I'm aware of, typically, 10-100 profiles are used to manage order of 10^5 to 10^6 = xDSL lines. Regards, Umberto Bonollo RFC-5650 co-author -----Original Message----- From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org]On Behalf Of Scott Baillie Sent: Tuesday, 24 November 2009 3:43 PM To: Menachem Dodge Cc: adslmib@ietf.org Subject: Re: [Adslmib] Vector of Profiles MIB Hi All, I would like to summarise my position on the Vector of Profiles MIB proposal so that it is clearer what my position is, but I would like to hear the views of the group on these issues. My position ----------- 1. I would prefer that the TR-165 enhancements be implemented at a lower layer and hence no need to change the RFC-5650 management interface. The reasons for this are covered in my previous post. 2. If the RFC-5650 extension MIB was to go ahead anyway, I would be very much opposed to the effort unless : a) The TR-129 model is mandatory and the TR-165 model is optional. Hence, a SNMP agent MUST implement the template model but MAY implement the VoP model. b) The tables in RFC-5650 are not altered in any way, only one scalar variable is added to RFC-5650. The scalar variable would be writeable and have 2 values. c) When a SNMP agent is configured to operate in TR-165 mode, it must also be fully manageable by a SNMP manager that only understands the TR-129 model. Regards, Scott. On Mon, 2009-11-23 at 17:21 +0200, Menachem Dodge wrote: > Hello,=20 >=20 > So far only a small number of WG members have offered their opinion as = to whether or not the TR-165 management model should be developed. >=20 > A suggestion has been proposed such that an optional extension to RFC = 5650 be developed that would contain a switch allowing either the = current TR-129 model or the TR-165 model to be supported. >=20 > The opinions thus far have been divided, even regarding this optional = extension. >=20 > I would appreciate additional members of the WG to come forward and = voice their view. >=20 > Thank you kindly, > Menachem Dodge >=20 >=20 >=20 > -----Original Message----- > From: Markus.Freudenberger@t-systems.com = [mailto:Markus.Freudenberger@t-systems.com]=20 > Sent: Tuesday, November 17, 2009 11:05 AM > To: sbaillie@bigpond.net.au > Cc: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti = Morgenstern; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Subject: AW: Vector of Profiles MIB >=20 > Hello Scott, >=20 > I understand your proposal but it does not address the complete issue. = > Operators need more flexibility of configuring their network. The = approach of TR-129 does not scale from the OSS point view as it = multiplies the amount of different xDSL profiles/templates. In practice, = the MIB from the DSLAM (In this case represeting the TR-129 object = model) is usually mapped 1:1 into the EMS and its data model. In FTTx = deployment scenarios with specific requirements depending on the PSD = shaping on the remote DSLAM, noise margins, specific OLR features and = INP configurations, TR-129 causes a multiplication of templates as every = single parameter variation ends up in a new template and/or channel or = line profile. >=20 > Therefore TR-165 needs to be implemented at the SNMP management = interface and in the associated EMS to take full effect. >=20 > Be aware that only the profile configurtion of RFC5650 is affected, = all other parts are untouched and can stay as they are today. In order = to not skip the template approach from TR-129 completely, a switch, as = proposed by Peidaoyu from Huawei, might be a good solution. >=20 > Regards > Markus >=20 > =20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Scott Baillie [mailto:sbaillie@bigpond.net.au]=20 > Gesendet: Sonntag, 15. November 2009 13:00 > An: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti = Morgenstern; Freudenberger, Markus; gerd.barchmann@nsn.com; = wolfgang.krille@nsn.com > Betreff: Re: Vector of Profiles MIB >=20 > Hi all, >=20 > As you may know from my previous messages on the subject of the Vector = of Profiles MIB proposal, I do not believe that it is a good idea to = introduce another VDSL2 management interface which is not compatible = with the existing management interface ( RFC5650 ) unless there are = compelling and significant reasons to do so. >=20 > Introducing an incompatible VDSL2 management interface does not = benefit the xDSL industry, it causes harm because NMS/EMS applications = will now have to support two interfaces instead of one. >=20 > I consider the Vector of Profiles scheme to be an implementation = decision which should be considered by firmware developers in order to = minimise the storage requirements for xDSL configuration in the Access = Node. > But this implementation decision is a low level detail and should not = affect the VDSL2 management interface. >=20 > A firmware developer can implement the VoP scheme inside the Access = Node while remaining 100% compatible with the RFC5650 management = interface. What is required is to provide a mapping between the template = name and the vector, and this mapping can be kept hidden so that the = operator has no knowledge of the internal implementation details. >=20 > Let me state my proposal in a different way in case what I said was = not very clear. >=20 > 1. Internally, the xDSL configuration is stored using > the efficient VoP scheme. > 2. In the firmware, a mapping exists between the RFC5650 > template name and the internal vector that stores the > configuration for that template. This mapping may take > the form of a hash map for example. > 3. When a SNMP request arrives to read a row from the > line profile or channel profile tables > ( xdsl2LineConfProfTable, > xdsl2LineConfProfModeSpecTable > xdsl2LineConfProfModeSpecBandUsTable, > xdsl2ChConfProfileTable ) > the access node will consult its hash map and find > the corresponding vector. The access node will then > retrieve the data from the vector and return it in > the form of a SNMP row. > What this means is that storage of the xDSL > configuration data is decoupled from the MIB > representation of the data. Most modern SNMP agent's > ( such as the Net SNMP agent ) supports decoupling > of the underlying storage as I have described. > 4. When a SNMP request arrives to write a row into > the line profile or channel profile tables, the > access node must either create a new vector to > store the data of reference an existing vector > which already contains that data. >=20 > Using this approach, the access node gains the advantage of storing = the xDSL configuration data efficiently while remaining compatible with = the existing SNMP management interface. >=20 > The algorithm that I have described above would need to be specified = in more detail, but I am sure that every one here is an engineer and at = least understands the concept that I am proposing. >=20 > In conclusion, I think that the broad band forum should create a = companion document that goes together with TR165 which specifies an = algorithm ( similar to what I have proposed above ) that firmware = developers can use to map between 5650 templates and VoP vectors instead = of specifying a new VDSL2 management interface at the IETF. >=20 > Regards, >=20 > Scott. >=20 >=20 > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib From Menachem.Dodge@ecitele.com Sun Nov 29 07:26:16 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8CD3A6909 for ; Sun, 29 Nov 2009 07:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[AWL=-3.571, BAYES_50=0.001, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGCu1pjZPTLY for ; Sun, 29 Nov 2009 07:26:15 -0800 (PST) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 30FAA3A68C1 for ; Sun, 29 Nov 2009 07:26:13 -0800 (PST) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 29 Nov 2009 17:15:52 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 29 Nov 2009 17:26:06 +0200 From: Menachem Dodge To: "pdyu@huawei.com" , "umberto.bonollo@nec.com.au" , 'Scott Baillie' , Moti Morgenstern , "Markus.Freudenberger@t-systems.com" Date: Sun, 29 Nov 2009 17:26:07 +0200 Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: Acpsy8HbDloiT39wSWa2XSZd9Sd/xgAO/JFgAP5ingA= Message-ID: <283DD79798619346BF9B17D7B5035A190107D8746BCC@ILPTMAIL02.ecitele.com> References: <004a01ca6cd3$e15e3fb0$62a11fac@ssd.neca.nec.com.au> <000801ca6d0a$44181550$482c460a@china.huawei.com> In-Reply-To: <000801ca6d0a$44181550$482c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "adslmib@ietf.org" Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 15:26:16 -0000 SGVsbG8gQWxsLA0KDQpBbHRob3VnaCBvbmx5IGEgc21hbGwgbnVtYmVyIG9mIFdHIG1lbWJlcnMg aGF2ZSBiZWVuIGludm9sdmVkIGluIHRoaXMgZGlzY3Vzc2lvbiwgdGhlcmUgaGFzIG5vbmV0aGVs ZXNzIGJlZW4gc3Ryb25nIGRpZmZlcmVuY2VzIG9mIG9waW5pb24uDQoNCkhvd2V2ZXIsIEkgd291 bGQgbGlrZSB0byBzZWUgaWYgYSBjb25zZW5zdXMgY2FuIGJlIHJlYWNoZWQgYmFzZWQgb24gc3Vn Z2VzdGlvbnMgYWxyZWFkeSBwdXQgZm9yd2FyZC4NCg0KQ2FuIHdlIGFncmVlIG9uIHRoZSBmb2xs b3dpbmc6DQoNCgkxLiBUaGUgV0cgZGV2ZWxvcHMgYW4gYWRkaXRpb25hbCBvcHRpb25hbCBWZHNs MiBjb25maWd1cmF0aW9uIGV4dGVuc2lvbiBNSUIgYmFzZWQgb24gVFItMTY1LiANCgkgICAJYS4g VGhpcyBleHRlbnNpb24gY29udGFpbnMgYSAic2NhbGFyIHZhcmlhYmxlIiBvciAic3dpdGNoIiB1 c2VkIGJ5IHRoZSBtYW5hZ2VyIGFuZCB0aGUgU05NUCBhZ2VudCB0byBuZWdvdGlhdGUgDQogICAg ICAgICAgICAgICB3aGV0aGVyIFZEU0wyIGNvbmZpZ3VyYXRpb24gd2lsbCBiZSBkb25lIGJ5IHRo ZSBUUi0xNjUgVm9QIE1ldGhvZCBvciB0aGUgVFItMTI5IFJGQyA1NjUwIE1ldGhvZC4gDQoJICAg ICAgYi4gVGhlIGRlZmF1bHQgb2YgdGhlICJzY2FsYXIgdmFyaWFibGUiIGlzIFRSLTEyOSBSRkMg NTY1MCBNZXRob2QuIA0KCSAgICAgIGMuIElmIGVpdGhlciB0aGUgU05NUCBtYW5hZ2VyIG9yIHRo ZSBTTk1QIEFnZW50IGRvIG5vdCBzdXBwb3J0IHRoZSBleHRlbnNpb24gTUlCIGFuZCBoZW5jZSB0 aGUgInN3aXRjaCIsIA0KICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbiB3aWxsIGJlIGRvbmUg YnkgVFItMTI5IFJGQyA1NjUwLg0KCTIuIFJGQyA1NjUwIHJlbWFpbnMgdW5jaGFuZ2VkLiANCgkz LiBTdXBwb3J0IG9mIFJGQyA1NjUwIGlzIG1hbmRhdG9yeS4NCgkNClBsZWFzZSBpbmRpY2F0ZSBh Z3JlZW1lbnQgb3IgZGlzYWdyZWVtZW50IHRvIHRoZSBhYm92ZS4NCg0KVGhhbmsgeW91IGtpbmRs eSwNCk1lbmFjaGVtDQoJDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBl aWRhb3l1IFttYWlsdG86cGR5dUBodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVy IDI0LCAyMDA5IDM6MzAgUE0NClRvOiB1bWJlcnRvLmJvbm9sbG9AbmVjLmNvbS5hdTsgJ1Njb3R0 IEJhaWxsaWUnOyBNZW5hY2hlbSBEb2RnZQ0KQ2M6IGFkc2xtaWJAaWV0Zi5vcmcNClN1YmplY3Q6 ILTwuLQ6IFtBZHNsbWliXSBWZWN0b3Igb2YgUHJvZmlsZXMgTUlCDQoNCkhpIGFsbCwNCkkgZG9u J3QgdGhpbmsgdGhhdCAxMC0xMDAgcHJvZmlsZXMgYXJlIGVub3VnaCBmb3IgdXNlZCB0byBtYW5h Z2Ugb3JkZXIgb2YNCjEwXjUgdG8gMTBeNiB4RFNMIGxpbmVzLCBtYXliZSBpdCdzIGVub3VnaCBm b3IgYWRzbCwgYnV0IGl0oa9zIG5vdCBlbm91Z2gNCmZvciB2ZHNsMi4gRnVydGhlcm1vcmUsIHRo ZSBtZW1vcnkgaXMgbm90IHRoZSBvbmx5IHJlYXNvbiB0byBkZWZpbmUgVFIxNjUuDQpJbiBGVFR4 IG9yIERMTSBvciBEU00gY2FzZXMgdGhlIFRSMTY1IG1vZGVsIGlzIG1vcmUgc3VpdGFibGUsIGl0 IG1ha2VzDQpjb25maWd1cmF0aW9uIHNpbXBsZXIuIA0KQXMgdGhlcmUgYXJlIHR3byBtYW55IGRp ZmZlcmVuY2VzIGJldHdlZW4gdGhlc2UgdHdvIG1vZGVscywgdGhlIHRyYW5zbGF0aW9uDQpiZXR3 ZWVuIFRSLTEyOSBtb2RlbCBhbmQgVFItMTY1IG1vZGVsIGlzIGFsbW9zdCBpbXBvc3NpYmxlLCBh bmQgbWFrZXMgbm8NCnNlbnNlLiBNYXliZSBhIHN3aXRjaCBpcyBzdWl0YWJsZSwgdGhlbiBpdCB1 cCB0byB0aGUgb3BlcmF0b3IgdG8gY2hvb3NlIGENCm1hbmFnZW1lbnQgbW9kZWwgaXQgcHJlZmVy cyB0by4NClJlZ2FyZHMsDQpQZWlEYW95dQ0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGFk c2xtaWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFkc2xtaWItYm91bmNlc0BpZXRmLm9yZ10g tPqx7Q0KVW1iZXJ0byBCb25vbGxvDQq3osvNyrG85DogMjAwOcTqMTHUwjI0yNUgMTU6MDENCsrV vP7IyzogJ1Njb3R0IEJhaWxsaWUnOyBNZW5hY2hlbSBEb2RnZQ0Ks63LzTogYWRzbG1pYkBpZXRm Lm9yZw0K1vfM4jogUmU6IFtBZHNsbWliXSBWZWN0b3Igb2YgUHJvZmlsZXMgTUlCDQoNCkhpIFNj b3R0LA0KSSBhbSBpbiBhZ3JlZW1lbnQgd2l0aCB5b3VyIHBvc2l0aW9uIGluIDEuIGFuZCAyLiBi ZWxvdy4NCkl0IG11c3QgYmUgcG9zc2libGUgZm9yIFJGQy01NjUwIHRvIHdvcmsgaW5kZXBlbmRl bnRseSBvZg0KcG9zc2libGUgb3B0aW9uYWwgVk9QIGFkZC1vbi4NCkZyb20gdmVyeSBsYXJnZSBw cm9qZWN0cyBpbiB0aGUgZmllbGQgSSdtIGF3YXJlIG9mLA0KdHlwaWNhbGx5LCAgMTAtMTAwIHBy b2ZpbGVzIGFyZSB1c2VkIHRvIG1hbmFnZSBvcmRlciBvZiAxMF41IHRvIDEwXjYgeERTTA0KbGlu ZXMuDQoNClJlZ2FyZHMsDQpVbWJlcnRvIEJvbm9sbG8NClJGQy01NjUwIGNvLWF1dGhvcg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYWRzbG1pYi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86YWRzbG1pYi1ib3VuY2VzQGlldGYub3JnXU9uDQpCZWhhbGYgT2YgU2NvdHQgQmFp bGxpZQ0KU2VudDogVHVlc2RheSwgMjQgTm92ZW1iZXIgMjAwOSAzOjQzIFBNDQpUbzogTWVuYWNo ZW0gRG9kZ2UNCkNjOiBhZHNsbWliQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Fkc2xtaWJdIFZl Y3RvciBvZiBQcm9maWxlcyBNSUINCg0KDQpIaSBBbGwsDQoNCkkgd291bGQgbGlrZSB0byBzdW1t YXJpc2UgbXkgcG9zaXRpb24gb24gdGhlIFZlY3RvciBvZiBQcm9maWxlcw0KTUlCIHByb3Bvc2Fs IHNvIHRoYXQgaXQgaXMgY2xlYXJlciB3aGF0IG15IHBvc2l0aW9uIGlzLCBidXQgSQ0Kd291bGQg bGlrZSB0byBoZWFyIHRoZSB2aWV3cyBvZiB0aGUgZ3JvdXAgb24gdGhlc2UgaXNzdWVzLg0KDQpN eSBwb3NpdGlvbg0KLS0tLS0tLS0tLS0NCjEuIEkgd291bGQgcHJlZmVyIHRoYXQgdGhlIFRSLTE2 NSBlbmhhbmNlbWVudHMgYmUgaW1wbGVtZW50ZWQNCiAgIGF0IGEgbG93ZXIgbGF5ZXIgYW5kIGhl bmNlIG5vIG5lZWQgdG8gY2hhbmdlIHRoZSBSRkMtNTY1MA0KICAgbWFuYWdlbWVudCBpbnRlcmZh Y2UuIFRoZSByZWFzb25zIGZvciB0aGlzIGFyZSBjb3ZlcmVkDQogICBpbiBteSBwcmV2aW91cyBw b3N0Lg0KMi4gSWYgdGhlIFJGQy01NjUwIGV4dGVuc2lvbiBNSUIgd2FzIHRvIGdvIGFoZWFkIGFu eXdheSwNCiAgIEkgd291bGQgYmUgdmVyeSBtdWNoIG9wcG9zZWQgdG8gdGhlIGVmZm9ydCB1bmxl c3MgOg0KICAgYSkgVGhlIFRSLTEyOSBtb2RlbCBpcyBtYW5kYXRvcnkgYW5kIHRoZSBUUi0xNjUg bW9kZWwgaXMNCiAgICAgIG9wdGlvbmFsLiBIZW5jZSwgYSBTTk1QIGFnZW50IE1VU1QgaW1wbGVt ZW50IHRoZSB0ZW1wbGF0ZQ0KICAgICAgbW9kZWwgYnV0IE1BWSBpbXBsZW1lbnQgdGhlIFZvUCBt b2RlbC4NCiAgIGIpIFRoZSB0YWJsZXMgaW4gUkZDLTU2NTAgYXJlIG5vdCBhbHRlcmVkIGluIGFu eSB3YXksIG9ubHkNCiAgICAgIG9uZSBzY2FsYXIgdmFyaWFibGUgaXMgYWRkZWQgdG8gUkZDLTU2 NTAuIFRoZSBzY2FsYXINCiAgICAgIHZhcmlhYmxlIHdvdWxkIGJlIHdyaXRlYWJsZSBhbmQgaGF2 ZSAyIHZhbHVlcy4NCiAgIGMpIFdoZW4gYSBTTk1QIGFnZW50IGlzIGNvbmZpZ3VyZWQgdG8gb3Bl cmF0ZSBpbiBUUi0xNjUNCiAgICAgIG1vZGUsIGl0IG11c3QgYWxzbyBiZSBmdWxseSBtYW5hZ2Vh YmxlIGJ5IGEgU05NUA0KICAgICAgbWFuYWdlciB0aGF0IG9ubHkgdW5kZXJzdGFuZHMgdGhlIFRS LTEyOSBtb2RlbC4NCg0KUmVnYXJkcywNCg0KU2NvdHQuDQoNCk9uIE1vbiwgMjAwOS0xMS0yMyBh dCAxNzoyMSArMDIwMCwgTWVuYWNoZW0gRG9kZ2Ugd3JvdGU6DQo+IEhlbGxvLCANCj4gDQo+IFNv IGZhciBvbmx5IGEgc21hbGwgbnVtYmVyIG9mIFdHIG1lbWJlcnMgaGF2ZSBvZmZlcmVkIHRoZWly IG9waW5pb24gYXMgdG8NCndoZXRoZXIgb3Igbm90IHRoZSBUUi0xNjUgbWFuYWdlbWVudCBtb2Rl bCBzaG91bGQgYmUgZGV2ZWxvcGVkLg0KPiANCj4gQSBzdWdnZXN0aW9uIGhhcyBiZWVuIHByb3Bv c2VkIHN1Y2ggdGhhdCBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gUkZDIDU2NTANCmJlIGRldmVs b3BlZCB0aGF0IHdvdWxkIGNvbnRhaW4gYSBzd2l0Y2ggYWxsb3dpbmcgZWl0aGVyIHRoZSBjdXJy ZW50IFRSLTEyOQ0KbW9kZWwgb3IgdGhlIFRSLTE2NSBtb2RlbCB0byBiZSBzdXBwb3J0ZWQuDQo+ IA0KPiBUaGUgb3BpbmlvbnMgdGh1cyBmYXIgaGF2ZSBiZWVuIGRpdmlkZWQsIGV2ZW4gcmVnYXJk aW5nIHRoaXMgb3B0aW9uYWwNCmV4dGVuc2lvbi4NCj4gDQo+IEkgd291bGQgYXBwcmVjaWF0ZSBh ZGRpdGlvbmFsIG1lbWJlcnMgb2YgdGhlIFdHIHRvIGNvbWUgZm9yd2FyZCBhbmQgdm9pY2UNCnRo ZWlyIHZpZXcuDQo+IA0KPiBUaGFuayB5b3Uga2luZGx5LA0KPiBNZW5hY2hlbSBEb2RnZQ0KPiAN Cj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJrdXMuRnJl dWRlbmJlcmdlckB0LXN5c3RlbXMuY29tDQpbbWFpbHRvOk1hcmt1cy5GcmV1ZGVuYmVyZ2VyQHQt c3lzdGVtcy5jb21dIA0KPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxNywgMjAwOSAxMTowNSBB TQ0KPiBUbzogc2JhaWxsaWVAYmlncG9uZC5uZXQuYXUNCj4gQ2M6IE1lbmFjaGVtIERvZGdlOyBw ZHl1QGh1YXdlaS5jb207IGFkc2xtaWJAaWV0Zi5vcmc7IE1vdGkgTW9yZ2Vuc3Rlcm47DQpnZXJk LmJhcmNobWFubkBuc24uY29tOyB3b2xmZ2FuZy5rcmlsbGVAbnNuLmNvbQ0KPiBTdWJqZWN0OiBB VzogVmVjdG9yIG9mIFByb2ZpbGVzIE1JQg0KPiANCj4gSGVsbG8gU2NvdHQsDQo+IA0KPiBJIHVu ZGVyc3RhbmQgeW91ciBwcm9wb3NhbCBidXQgaXQgZG9lcyBub3QgYWRkcmVzcyB0aGUgY29tcGxl dGUgaXNzdWUuIA0KPiBPcGVyYXRvcnMgbmVlZCBtb3JlIGZsZXhpYmlsaXR5IG9mIGNvbmZpZ3Vy aW5nIHRoZWlyIG5ldHdvcmsuIFRoZSBhcHByb2FjaA0Kb2YgVFItMTI5IGRvZXMgbm90IHNjYWxl IGZyb20gdGhlIE9TUyBwb2ludCB2aWV3IGFzIGl0IG11bHRpcGxpZXMgdGhlIGFtb3VudA0Kb2Yg ZGlmZmVyZW50IHhEU0wgcHJvZmlsZXMvdGVtcGxhdGVzLiBJbiBwcmFjdGljZSwgdGhlIE1JQiBm cm9tIHRoZSBEU0xBTQ0KKEluIHRoaXMgY2FzZSByZXByZXNldGluZyB0aGUgVFItMTI5IG9iamVj dCBtb2RlbCkgaXMgdXN1YWxseSBtYXBwZWQgMToxDQppbnRvIHRoZSBFTVMgYW5kIGl0cyBkYXRh IG1vZGVsLiBJbiBGVFR4IGRlcGxveW1lbnQgc2NlbmFyaW9zIHdpdGggc3BlY2lmaWMNCnJlcXVp cmVtZW50cyBkZXBlbmRpbmcgb24gdGhlIFBTRCBzaGFwaW5nIG9uIHRoZSByZW1vdGUgRFNMQU0s IG5vaXNlDQptYXJnaW5zLCBzcGVjaWZpYyBPTFIgZmVhdHVyZXMgYW5kIElOUCBjb25maWd1cmF0 aW9ucywgVFItMTI5IGNhdXNlcyBhDQptdWx0aXBsaWNhdGlvbiBvZiB0ZW1wbGF0ZXMgYXMgZXZl cnkgc2luZ2xlIHBhcmFtZXRlciB2YXJpYXRpb24gZW5kcyB1cCBpbiBhDQpuZXcgdGVtcGxhdGUg YW5kL29yIGNoYW5uZWwgb3IgbGluZSBwcm9maWxlLg0KPiANCj4gVGhlcmVmb3JlIFRSLTE2NSBu ZWVkcyB0byBiZSBpbXBsZW1lbnRlZCBhdCB0aGUgU05NUCBtYW5hZ2VtZW50IGludGVyZmFjZQ0K YW5kIGluIHRoZSBhc3NvY2lhdGVkIEVNUyB0byB0YWtlIGZ1bGwgZWZmZWN0Lg0KPiANCj4gQmUg YXdhcmUgdGhhdCBvbmx5IHRoZSBwcm9maWxlIGNvbmZpZ3VydGlvbiBvZiBSRkM1NjUwIGlzIGFm ZmVjdGVkLCBhbGwNCm90aGVyIHBhcnRzIGFyZSB1bnRvdWNoZWQgYW5kIGNhbiBzdGF5IGFzIHRo ZXkgYXJlIHRvZGF5LiBJbiBvcmRlciB0byBub3QNCnNraXAgdGhlIHRlbXBsYXRlIGFwcHJvYWNo IGZyb20gVFItMTI5IGNvbXBsZXRlbHksIGEgc3dpdGNoLCBhcyBwcm9wb3NlZCBieQ0KUGVpZGFv eXUgZnJvbSBIdWF3ZWksIG1pZ2h0IGJlIGEgZ29vZCBzb2x1dGlvbi4NCj4gDQo+IFJlZ2FyZHMN Cj4gTWFya3VzDQo+IA0KPiAgICAgDQo+IC0tLS0tVXJzcHKouW5nbGljaGUgTmFjaHJpY2h0LS0t LS0NCj4gVm9uOiBTY290dCBCYWlsbGllIFttYWlsdG86c2JhaWxsaWVAYmlncG9uZC5uZXQuYXVd IA0KPiBHZXNlbmRldDogU29ubnRhZywgMTUuIE5vdmVtYmVyIDIwMDkgMTM6MDANCj4gQW46IE1l bmFjaGVtIERvZGdlOyBwZHl1QGh1YXdlaS5jb207IGFkc2xtaWJAaWV0Zi5vcmc7IE1vdGkgTW9y Z2Vuc3Rlcm47DQpGcmV1ZGVuYmVyZ2VyLCBNYXJrdXM7IGdlcmQuYmFyY2htYW5uQG5zbi5jb207 IHdvbGZnYW5nLmtyaWxsZUBuc24uY29tDQo+IEJldHJlZmY6IFJlOiBWZWN0b3Igb2YgUHJvZmls ZXMgTUlCDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBBcyB5b3UgbWF5IGtub3cgZnJvbSBteSBwcmV2 aW91cyBtZXNzYWdlcyBvbiB0aGUgc3ViamVjdCBvZiB0aGUgVmVjdG9yIG9mDQpQcm9maWxlcyBN SUIgcHJvcG9zYWwsIEkgZG8gbm90IGJlbGlldmUgdGhhdCBpdCBpcyBhIGdvb2QgaWRlYSB0byBp bnRyb2R1Y2UNCmFub3RoZXIgVkRTTDIgbWFuYWdlbWVudCBpbnRlcmZhY2Ugd2hpY2ggaXMgbm90 IGNvbXBhdGlibGUgd2l0aCB0aGUgZXhpc3RpbmcNCm1hbmFnZW1lbnQgaW50ZXJmYWNlICggUkZD NTY1MCApIHVubGVzcyB0aGVyZSBhcmUgY29tcGVsbGluZyBhbmQgc2lnbmlmaWNhbnQNCnJlYXNv bnMgdG8gZG8gc28uDQo+IA0KPiBJbnRyb2R1Y2luZyBhbiBpbmNvbXBhdGlibGUgVkRTTDIgbWFu YWdlbWVudCBpbnRlcmZhY2UgZG9lcyBub3QgYmVuZWZpdA0KdGhlIHhEU0wgaW5kdXN0cnksIGl0 IGNhdXNlcyBoYXJtIGJlY2F1c2UgTk1TL0VNUyBhcHBsaWNhdGlvbnMgd2lsbCBub3cgaGF2ZQ0K dG8gc3VwcG9ydCB0d28gaW50ZXJmYWNlcyBpbnN0ZWFkIG9mIG9uZS4NCj4gDQo+IEkgY29uc2lk ZXIgdGhlIFZlY3RvciBvZiBQcm9maWxlcyBzY2hlbWUgdG8gYmUgYW4gaW1wbGVtZW50YXRpb24g ZGVjaXNpb24NCndoaWNoIHNob3VsZCBiZSBjb25zaWRlcmVkIGJ5IGZpcm13YXJlIGRldmVsb3Bl cnMgaW4gb3JkZXIgdG8gbWluaW1pc2UgdGhlDQpzdG9yYWdlIHJlcXVpcmVtZW50cyBmb3IgeERT TCBjb25maWd1cmF0aW9uIGluIHRoZSBBY2Nlc3MgTm9kZS4NCj4gQnV0IHRoaXMgaW1wbGVtZW50 YXRpb24gZGVjaXNpb24gaXMgYSBsb3cgbGV2ZWwgZGV0YWlsIGFuZCBzaG91bGQgbm90DQphZmZl Y3QgdGhlIFZEU0wyIG1hbmFnZW1lbnQgaW50ZXJmYWNlLg0KPiANCj4gQSBmaXJtd2FyZSBkZXZl bG9wZXIgY2FuIGltcGxlbWVudCB0aGUgVm9QIHNjaGVtZSBpbnNpZGUgdGhlIEFjY2VzcyBOb2Rl DQp3aGlsZSByZW1haW5pbmcgMTAwJSBjb21wYXRpYmxlIHdpdGggdGhlIFJGQzU2NTAgbWFuYWdl bWVudCBpbnRlcmZhY2UuIFdoYXQNCmlzIHJlcXVpcmVkIGlzIHRvIHByb3ZpZGUgYSBtYXBwaW5n IGJldHdlZW4gdGhlIHRlbXBsYXRlIG5hbWUgYW5kIHRoZQ0KdmVjdG9yLCBhbmQgdGhpcyBtYXBw aW5nIGNhbiBiZSBrZXB0IGhpZGRlbiBzbyB0aGF0IHRoZSBvcGVyYXRvciBoYXMgbm8NCmtub3ds ZWRnZSBvZiB0aGUgaW50ZXJuYWwgaW1wbGVtZW50YXRpb24gZGV0YWlscy4NCj4gDQo+IExldCBt ZSBzdGF0ZSBteSBwcm9wb3NhbCBpbiBhIGRpZmZlcmVudCB3YXkgaW4gY2FzZSB3aGF0IEkgc2Fp ZCB3YXMgbm90DQp2ZXJ5IGNsZWFyLg0KPiANCj4gMS4gSW50ZXJuYWxseSwgdGhlIHhEU0wgY29u ZmlndXJhdGlvbiBpcyBzdG9yZWQgdXNpbmcNCj4gICAgdGhlIGVmZmljaWVudCBWb1Agc2NoZW1l Lg0KPiAyLiBJbiB0aGUgZmlybXdhcmUsIGEgbWFwcGluZyBleGlzdHMgYmV0d2VlbiB0aGUgUkZD NTY1MA0KPiAgICB0ZW1wbGF0ZSBuYW1lIGFuZCB0aGUgaW50ZXJuYWwgdmVjdG9yIHRoYXQgc3Rv cmVzIHRoZQ0KPiAgICBjb25maWd1cmF0aW9uIGZvciB0aGF0IHRlbXBsYXRlLiBUaGlzIG1hcHBp bmcgbWF5IHRha2UNCj4gICAgdGhlIGZvcm0gb2YgYSBoYXNoIG1hcCBmb3IgZXhhbXBsZS4NCj4g My4gV2hlbiBhIFNOTVAgcmVxdWVzdCBhcnJpdmVzIHRvIHJlYWQgYSByb3cgZnJvbSB0aGUNCj4g ICAgbGluZSBwcm9maWxlIG9yIGNoYW5uZWwgcHJvZmlsZSB0YWJsZXMNCj4gICAgKCB4ZHNsMkxp bmVDb25mUHJvZlRhYmxlLA0KPiAgICAgIHhkc2wyTGluZUNvbmZQcm9mTW9kZVNwZWNUYWJsZQ0K PiAgICAgIHhkc2wyTGluZUNvbmZQcm9mTW9kZVNwZWNCYW5kVXNUYWJsZSwNCj4gICAgICB4ZHNs MkNoQ29uZlByb2ZpbGVUYWJsZSApDQo+ICAgIHRoZSBhY2Nlc3Mgbm9kZSB3aWxsIGNvbnN1bHQg aXRzIGhhc2ggbWFwIGFuZCBmaW5kDQo+ICAgIHRoZSBjb3JyZXNwb25kaW5nIHZlY3Rvci4gVGhl IGFjY2VzcyBub2RlIHdpbGwgdGhlbg0KPiAgICByZXRyaWV2ZSB0aGUgZGF0YSBmcm9tIHRoZSB2 ZWN0b3IgYW5kIHJldHVybiBpdCBpbg0KPiAgICB0aGUgZm9ybSBvZiBhIFNOTVAgcm93Lg0KPiAg ICBXaGF0IHRoaXMgbWVhbnMgaXMgdGhhdCBzdG9yYWdlIG9mIHRoZSB4RFNMDQo+ICAgIGNvbmZp Z3VyYXRpb24gZGF0YSBpcyBkZWNvdXBsZWQgZnJvbSB0aGUgTUlCDQo+ICAgIHJlcHJlc2VudGF0 aW9uIG9mIHRoZSBkYXRhLiBNb3N0IG1vZGVybiBTTk1QIGFnZW50J3MNCj4gICAgKCBzdWNoIGFz IHRoZSBOZXQgU05NUCBhZ2VudCApIHN1cHBvcnRzIGRlY291cGxpbmcNCj4gICAgb2YgdGhlIHVu ZGVybHlpbmcgc3RvcmFnZSBhcyBJIGhhdmUgZGVzY3JpYmVkLg0KPiA0LiBXaGVuIGEgU05NUCBy ZXF1ZXN0IGFycml2ZXMgdG8gd3JpdGUgYSByb3cgaW50bw0KPiAgICB0aGUgbGluZSBwcm9maWxl IG9yIGNoYW5uZWwgcHJvZmlsZSB0YWJsZXMsIHRoZQ0KPiAgICBhY2Nlc3Mgbm9kZSBtdXN0IGVp dGhlciBjcmVhdGUgYSBuZXcgdmVjdG9yIHRvDQo+ICAgIHN0b3JlIHRoZSBkYXRhIG9mIHJlZmVy ZW5jZSBhbiBleGlzdGluZyB2ZWN0b3INCj4gICAgd2hpY2ggYWxyZWFkeSBjb250YWlucyB0aGF0 IGRhdGEuDQo+IA0KPiBVc2luZyB0aGlzIGFwcHJvYWNoLCB0aGUgYWNjZXNzIG5vZGUgZ2FpbnMg dGhlIGFkdmFudGFnZSBvZiBzdG9yaW5nIHRoZQ0KeERTTCBjb25maWd1cmF0aW9uIGRhdGEgZWZm aWNpZW50bHkgd2hpbGUgcmVtYWluaW5nIGNvbXBhdGlibGUgd2l0aCB0aGUNCmV4aXN0aW5nIFNO TVAgbWFuYWdlbWVudCBpbnRlcmZhY2UuDQo+IA0KPiBUaGUgYWxnb3JpdGhtIHRoYXQgSSBoYXZl IGRlc2NyaWJlZCBhYm92ZSB3b3VsZCBuZWVkIHRvIGJlIHNwZWNpZmllZCBpbg0KbW9yZSBkZXRh aWwsIGJ1dCBJIGFtIHN1cmUgdGhhdCBldmVyeSBvbmUgaGVyZSBpcyBhbiBlbmdpbmVlciBhbmQg YXQgbGVhc3QNCnVuZGVyc3RhbmRzIHRoZSBjb25jZXB0IHRoYXQgSSBhbSBwcm9wb3NpbmcuDQo+ IA0KPiBJbiBjb25jbHVzaW9uLCBJIHRoaW5rIHRoYXQgdGhlIGJyb2FkIGJhbmQgZm9ydW0gc2hv dWxkIGNyZWF0ZSBhIGNvbXBhbmlvbg0KZG9jdW1lbnQgdGhhdCBnb2VzIHRvZ2V0aGVyIHdpdGgg VFIxNjUgd2hpY2ggc3BlY2lmaWVzIGFuIGFsZ29yaXRobSAoDQpzaW1pbGFyIHRvIHdoYXQgSSBo YXZlIHByb3Bvc2VkIGFib3ZlICkgdGhhdCBmaXJtd2FyZSBkZXZlbG9wZXJzIGNhbiB1c2UgdG8N Cm1hcCBiZXR3ZWVuIDU2NTAgdGVtcGxhdGVzIGFuZCBWb1AgdmVjdG9ycyBpbnN0ZWFkIG9mIHNw ZWNpZnlpbmcgYSBuZXcgVkRTTDINCm1hbmFnZW1lbnQgaW50ZXJmYWNlIGF0IHRoZSBJRVRGLg0K PiANCj4gUmVnYXJkcywNCj4gDQo+IFNjb3R0Lg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFkc2xtaWIgbWFpbGluZyBsaXN0DQo+ IEFkc2xtaWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hZHNsbWliDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpBZHNsbWliIG1haWxpbmcgbGlzdA0KQWRzbG1pYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZHNsbWliDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBZHNsbWliIG1haWxpbmcgbGlzdA0KQWRzbG1p YkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZHNsbWli DQoNCg== From Markus.Freudenberger@t-systems.com Mon Nov 30 13:43:20 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D1A3A6931 for ; Mon, 30 Nov 2009 13:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CN_BODY_35=0.339, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehUXK8LKUgHj for ; Mon, 30 Nov 2009 13:43:18 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 182113A6867 for ; Mon, 30 Nov 2009 13:43:16 -0800 (PST) From: Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 30 Nov 2009 22:43:00 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 22:42:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Nov 2009 22:42:56 +0100 Message-ID: <1B6169C658325341A3B8066E23919E1C035349D0@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <283DD79798619346BF9B17D7B5035A190107D8746BCC@ILPTMAIL02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: Acpsy8HbDloiT39wSWa2XSZd9Sd/xgAO/JFgAP5ingAAQRYqcA== References: <004a01ca6cd3$e15e3fb0$62a11fac@ssd.neca.nec.com.au> <000801ca6d0a$44181550$482c460a@china.huawei.com> <283DD79798619346BF9B17D7B5035A190107D8746BCC@ILPTMAIL02.ecitele.com> To: X-OriginalArrivalTime: 30 Nov 2009 21:42:59.0977 (UTC) FILETIME=[161BC790:01CA7206] Cc: adslmib@ietf.org, Moti.Morgenstern@ecitele.com Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:43:20 -0000 Hello Menachem, I agree with your proposal. Regards Markus =20 -----Urspr=A8=B9ngliche Nachricht----- Von: Menachem Dodge [mailto:Menachem.Dodge@ecitele.com]=20 Gesendet: Sonntag, 29. November 2009 16:26 An: pdyu@huawei.com; umberto.bonollo@nec.com.au; 'Scott Baillie'; Moti = Morgenstern; Freudenberger, Markus Cc: adslmib@ietf.org Betreff: RE: [Adslmib] Vector of Profiles MIB Hello All, Although only a small number of WG members have been involved in this = discussion, there has nonetheless been strong differences of opinion. However, I would like to see if a consensus can be reached based on = suggestions already put forward. Can we agree on the following: 1. The WG develops an additional optional Vdsl2 configuration extension = MIB based on TR-165.=20 a. This extension contains a "scalar variable" or "switch" used by = the manager and the SNMP agent to negotiate=20 whether VDSL2 configuration will be done by the TR-165 = VoP Method or the TR-129 RFC 5650 Method.=20 b. The default of the "scalar variable" is TR-129 RFC 5650 = Method.=20 c. If either the SNMP manager or the SNMP Agent do not support = the extension MIB and hence the "switch",=20 configuration will be done by TR-129 RFC 5650. 2. RFC 5650 remains unchanged.=20 3. Support of RFC 5650 is mandatory. =09 Please indicate agreement or disagreement to the above. Thank you kindly, Menachem =09 -----Original Message----- From: peidaoyu [mailto:pdyu@huawei.com] Sent: Tuesday, November 24, 2009 3:30 PM To: umberto.bonollo@nec.com.au; 'Scott Baillie'; Menachem Dodge Cc: adslmib@ietf.org Subject: =B4=F0=B8=B4: [Adslmib] Vector of Profiles MIB Hi all, I don't think that 10-100 profiles are enough for used to manage order = of 10^5 to 10^6 xDSL lines, maybe it's enough for adsl, but it=A1=AFs not = enough for vdsl2. Furthermore, the memory is not the only reason to = define TR165. In FTTx or DLM or DSM cases the TR165 model is more suitable, it makes = configuration simpler.=20 As there are two many differences between these two models, the = translation between TR-129 model and TR-165 model is almost impossible, = and makes no sense. Maybe a switch is suitable, then it up to the = operator to choose a management model it prefers to. Regards, PeiDaoyu -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: adslmib-bounces@ietf.org = [mailto:adslmib-bounces@ietf.org] =B4=FA=B1=ED Umberto Bonollo =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C224=C8=D5 15:01 =CA=D5=BC=FE=C8=CB: 'Scott Baillie'; Menachem Dodge =B3=AD=CB=CD: adslmib@ietf.org =D6=F7=CC=E2: Re: [Adslmib] Vector of Profiles MIB Hi Scott, I am in agreement with your position in 1. and 2. below. It must be possible for RFC-5650 to work independently of possible = optional VOP add-on. >From very large projects in the field I'm aware of, typically, 10-100 = profiles are used to manage order of 10^5 to 10^6 xDSL lines. Regards, Umberto Bonollo RFC-5650 co-author -----Original Message----- From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org]On Behalf Of Scott Baillie Sent: Tuesday, 24 November 2009 3:43 PM To: Menachem Dodge Cc: adslmib@ietf.org Subject: Re: [Adslmib] Vector of Profiles MIB Hi All, I would like to summarise my position on the Vector of Profiles MIB = proposal so that it is clearer what my position is, but I would like to = hear the views of the group on these issues. My position ----------- 1. I would prefer that the TR-165 enhancements be implemented at a lower layer and hence no need to change the RFC-5650 management interface. The reasons for this are covered in my previous post. 2. If the RFC-5650 extension MIB was to go ahead anyway, I would be very much opposed to the effort unless : a) The TR-129 model is mandatory and the TR-165 model is optional. Hence, a SNMP agent MUST implement the template model but MAY implement the VoP model. b) The tables in RFC-5650 are not altered in any way, only one scalar variable is added to RFC-5650. The scalar variable would be writeable and have 2 values. c) When a SNMP agent is configured to operate in TR-165 mode, it must also be fully manageable by a SNMP manager that only understands the TR-129 model. Regards, Scott. On Mon, 2009-11-23 at 17:21 +0200, Menachem Dodge wrote: > Hello, >=20 > So far only a small number of WG members have offered their opinion as = > to whether or not the TR-165 management model should be developed. >=20 > A suggestion has been proposed such that an optional extension to RFC=20 > 5650 be developed that would contain a switch allowing either the current = TR-129 model or the TR-165 model to be supported. >=20 > The opinions thus far have been divided, even regarding this optional extension. >=20 > I would appreciate additional members of the WG to come forward and=20 > voice their view. >=20 > Thank you kindly, > Menachem Dodge >=20 >=20 >=20 > -----Original Message----- > From: Markus.Freudenberger@t-systems.com [mailto:Markus.Freudenberger@t-systems.com]=20 > Sent: Tuesday, November 17, 2009 11:05 AM > To: sbaillie@bigpond.net.au > Cc: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti=20 > Morgenstern; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Subject: AW: Vector of Profiles MIB >=20 > Hello Scott, >=20 > I understand your proposal but it does not address the complete issue. = > Operators need more flexibility of configuring their network. The=20 > approach of TR-129 does not scale from the OSS point view as it multiplies the = amount of different xDSL profiles/templates. In practice, the MIB from = the DSLAM (In this case represeting the TR-129 object model) is usually = mapped 1:1 into the EMS and its data model. In FTTx deployment scenarios = with specific requirements depending on the PSD shaping on the remote = DSLAM, noise margins, specific OLR features and INP configurations, = TR-129 causes a multiplication of templates as every single parameter = variation ends up in a new template and/or channel or line profile. >=20 > Therefore TR-165 needs to be implemented at the SNMP management=20 > interface and in the associated EMS to take full effect. >=20 > Be aware that only the profile configurtion of RFC5650 is affected,=20 > all other parts are untouched and can stay as they are today. In order to = not skip the template approach from TR-129 completely, a switch, as = proposed by Peidaoyu from Huawei, might be a good solution. >=20 > Regards > Markus >=20 > =20 > -----Urspr=A8=B9ngliche Nachricht----- > Von: Scott Baillie [mailto:sbaillie@bigpond.net.au] > Gesendet: Sonntag, 15. November 2009 13:00 > An: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti=20 > Morgenstern; Freudenberger, Markus; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Betreff: Re: Vector of Profiles MIB >=20 > Hi all, >=20 > As you may know from my previous messages on the subject of the Vector = > of Profiles MIB proposal, I do not believe that it is a good idea to = introduce another VDSL2 management interface which is not compatible = with the existing management interface ( RFC5650 ) unless there are = compelling and significant reasons to do so. >=20 > Introducing an incompatible VDSL2 management interface does not=20 > benefit the xDSL industry, it causes harm because NMS/EMS applications will now = have to support two interfaces instead of one. >=20 > I consider the Vector of Profiles scheme to be an implementation=20 > decision which should be considered by firmware developers in order to minimise = the storage requirements for xDSL configuration in the Access Node. > But this implementation decision is a low level detail and should not affect the VDSL2 management interface. >=20 > A firmware developer can implement the VoP scheme inside the Access=20 > Node while remaining 100% compatible with the RFC5650 management interface. = What is required is to provide a mapping between the template name and = the vector, and this mapping can be kept hidden so that the operator has = no knowledge of the internal implementation details. >=20 > Let me state my proposal in a different way in case what I said was=20 > not very clear. >=20 > 1. Internally, the xDSL configuration is stored using > the efficient VoP scheme. > 2. In the firmware, a mapping exists between the RFC5650 > template name and the internal vector that stores the > configuration for that template. This mapping may take > the form of a hash map for example. > 3. When a SNMP request arrives to read a row from the > line profile or channel profile tables > ( xdsl2LineConfProfTable, > xdsl2LineConfProfModeSpecTable > xdsl2LineConfProfModeSpecBandUsTable, > xdsl2ChConfProfileTable ) > the access node will consult its hash map and find > the corresponding vector. The access node will then > retrieve the data from the vector and return it in > the form of a SNMP row. > What this means is that storage of the xDSL > configuration data is decoupled from the MIB > representation of the data. Most modern SNMP agent's > ( such as the Net SNMP agent ) supports decoupling > of the underlying storage as I have described. > 4. When a SNMP request arrives to write a row into > the line profile or channel profile tables, the > access node must either create a new vector to > store the data of reference an existing vector > which already contains that data. >=20 > Using this approach, the access node gains the advantage of storing=20 > the xDSL configuration data efficiently while remaining compatible with the = existing SNMP management interface. >=20 > The algorithm that I have described above would need to be specified=20 > in more detail, but I am sure that every one here is an engineer and at = least understands the concept that I am proposing. >=20 > In conclusion, I think that the broad band forum should create a=20 > companion document that goes together with TR165 which specifies an algorithm ( = similar to what I have proposed above ) that firmware developers can use = to map between 5650 templates and VoP vectors instead of specifying a = new VDSL2 management interface at the IETF. >=20 > Regards, >=20 > Scott. >=20 >=20 > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib From Markus.Freudenberger@t-systems.com Mon Nov 30 23:38:17 2009 Return-Path: X-Original-To: adslmib@core3.amsl.com Delivered-To: adslmib@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0633728C1C4 for ; Mon, 30 Nov 2009 23:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGXp3s+JYWq7 for ; Mon, 30 Nov 2009 23:38:15 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id E095B28C1C0 for ; Mon, 30 Nov 2009 23:38:14 -0800 (PST) From: Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 01 Dec 2009 08:38:01 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 08:38:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Dec 2009 08:38:00 +0100 Message-ID: <1B6169C658325341A3B8066E23919E1C03534A4A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C035349D0@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Adslmib] Vector of Profiles MIB Thread-Index: Acpsy8HbDloiT39wSWa2XSZd9Sd/xgAO/JFgAP5ingAAQRYqcAAUwy7A References: <004a01ca6cd3$e15e3fb0$62a11fac@ssd.neca.nec.com.au><000801ca6d0a$44181550$482c460a@china.huawei.com><283DD79798619346BF9B17D7B5035A190107D8746BCC@ILPTMAIL02.ecitele.com> <1B6169C658325341A3B8066E23919E1C035349D0@S4DE8PSAANK.mitte.t-com.de> To: X-OriginalArrivalTime: 01 Dec 2009 07:38:01.0902 (UTC) FILETIME=[361D34E0:01CA7259] Cc: adslmib@ietf.org Subject: Re: [Adslmib] Vector of Profiles MIB X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:38:17 -0000 Menachem, =20 According point no. 1 in your email I want to add a minor comment: = TR-165 deals also with adsl, adsl2 and adsl2plus and not only vdsl2. =20 Markus -----Urspr=A8=B9ngliche Nachricht----- Von: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] Im = Auftrag von Freudenberger, Markus Gesendet: Montag, 30. November 2009 22:43 An: Menachem.Dodge@ecitele.com Cc: adslmib@ietf.org; Moti.Morgenstern@ecitele.com Betreff: Re: [Adslmib] Vector of Profiles MIB Hello Menachem, I agree with your proposal. Regards Markus =20 -----Urspr=A8=B9ngliche Nachricht----- Von: Menachem Dodge [mailto:Menachem.Dodge@ecitele.com] Gesendet: Sonntag, 29. November 2009 16:26 An: pdyu@huawei.com; umberto.bonollo@nec.com.au; 'Scott Baillie'; Moti = Morgenstern; Freudenberger, Markus Cc: adslmib@ietf.org Betreff: RE: [Adslmib] Vector of Profiles MIB Hello All, Although only a small number of WG members have been involved in this = discussion, there has nonetheless been strong differences of opinion. However, I would like to see if a consensus can be reached based on = suggestions already put forward. Can we agree on the following: 1. The WG develops an additional optional Vdsl2 configuration extension = MIB based on TR-165.=20 a. This extension contains a "scalar variable" or "switch" used by = the manager and the SNMP agent to negotiate=20 whether VDSL2 configuration will be done by the TR-165 = VoP Method or the TR-129 RFC 5650 Method.=20 b. The default of the "scalar variable" is TR-129 RFC 5650 = Method.=20 c. If either the SNMP manager or the SNMP Agent do not support = the extension MIB and hence the "switch",=20 configuration will be done by TR-129 RFC 5650. 2. RFC 5650 remains unchanged.=20 3. Support of RFC 5650 is mandatory. =09 Please indicate agreement or disagreement to the above. Thank you kindly, Menachem =09 -----Original Message----- From: peidaoyu [mailto:pdyu@huawei.com] Sent: Tuesday, November 24, 2009 3:30 PM To: umberto.bonollo@nec.com.au; 'Scott Baillie'; Menachem Dodge Cc: adslmib@ietf.org Subject: =B4=F0=B8=B4: [Adslmib] Vector of Profiles MIB Hi all, I don't think that 10-100 profiles are enough for used to manage order = of 10^5 to 10^6 xDSL lines, maybe it's enough for adsl, but it=A1=AFs not = enough for vdsl2. Furthermore, the memory is not the only reason to = define TR165. In FTTx or DLM or DSM cases the TR165 model is more suitable, it makes = configuration simpler.=20 As there are two many differences between these two models, the = translation between TR-129 model and TR-165 model is almost impossible, = and makes no sense. Maybe a switch is suitable, then it up to the = operator to choose a management model it prefers to. Regards, PeiDaoyu -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: adslmib-bounces@ietf.org = [mailto:adslmib-bounces@ietf.org] =B4=FA=B1=ED Umberto Bonollo =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA11=D4=C224=C8=D5 15:01 =CA=D5=BC=FE=C8=CB: 'Scott Baillie'; Menachem Dodge =B3=AD=CB=CD: adslmib@ietf.org =D6=F7=CC=E2: Re: [Adslmib] Vector of Profiles MIB Hi Scott, I am in agreement with your position in 1. and 2. below. It must be possible for RFC-5650 to work independently of possible = optional VOP add-on. >From very large projects in the field I'm aware of, typically, 10-100 = profiles are used to manage order of 10^5 to 10^6 xDSL lines. Regards, Umberto Bonollo RFC-5650 co-author -----Original Message----- From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org]On Behalf Of Scott Baillie Sent: Tuesday, 24 November 2009 3:43 PM To: Menachem Dodge Cc: adslmib@ietf.org Subject: Re: [Adslmib] Vector of Profiles MIB Hi All, I would like to summarise my position on the Vector of Profiles MIB = proposal so that it is clearer what my position is, but I would like to = hear the views of the group on these issues. My position ----------- 1. I would prefer that the TR-165 enhancements be implemented at a lower layer and hence no need to change the RFC-5650 management interface. The reasons for this are covered in my previous post. 2. If the RFC-5650 extension MIB was to go ahead anyway, I would be very much opposed to the effort unless : a) The TR-129 model is mandatory and the TR-165 model is optional. Hence, a SNMP agent MUST implement the template model but MAY implement the VoP model. b) The tables in RFC-5650 are not altered in any way, only one scalar variable is added to RFC-5650. The scalar variable would be writeable and have 2 values. c) When a SNMP agent is configured to operate in TR-165 mode, it must also be fully manageable by a SNMP manager that only understands the TR-129 model. Regards, Scott. On Mon, 2009-11-23 at 17:21 +0200, Menachem Dodge wrote: > Hello, >=20 > So far only a small number of WG members have offered their opinion as = > to whether or not the TR-165 management model should be developed. >=20 > A suggestion has been proposed such that an optional extension to RFC=20 > 5650 be developed that would contain a switch allowing either the current = TR-129 model or the TR-165 model to be supported. >=20 > The opinions thus far have been divided, even regarding this optional extension. >=20 > I would appreciate additional members of the WG to come forward and=20 > voice their view. >=20 > Thank you kindly, > Menachem Dodge >=20 >=20 >=20 > -----Original Message----- > From: Markus.Freudenberger@t-systems.com [mailto:Markus.Freudenberger@t-systems.com]=20 > Sent: Tuesday, November 17, 2009 11:05 AM > To: sbaillie@bigpond.net.au > Cc: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti=20 > Morgenstern; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Subject: AW: Vector of Profiles MIB >=20 > Hello Scott, >=20 > I understand your proposal but it does not address the complete issue. = > Operators need more flexibility of configuring their network. The=20 > approach of TR-129 does not scale from the OSS point view as it multiplies the = amount of different xDSL profiles/templates. In practice, the MIB from = the DSLAM (In this case represeting the TR-129 object model) is usually = mapped 1:1 into the EMS and its data model. In FTTx deployment scenarios = with specific requirements depending on the PSD shaping on the remote = DSLAM, noise margins, specific OLR features and INP configurations, = TR-129 causes a multiplication of templates as every single parameter = variation ends up in a new template and/or channel or line profile. >=20 > Therefore TR-165 needs to be implemented at the SNMP management=20 > interface and in the associated EMS to take full effect. >=20 > Be aware that only the profile configurtion of RFC5650 is affected,=20 > all other parts are untouched and can stay as they are today. In order to = not skip the template approach from TR-129 completely, a switch, as = proposed by Peidaoyu from Huawei, might be a good solution. >=20 > Regards > Markus >=20 > =20 > -----Urspr=A8=B9ngliche Nachricht----- > Von: Scott Baillie [mailto:sbaillie@bigpond.net.au] > Gesendet: Sonntag, 15. November 2009 13:00 > An: Menachem Dodge; pdyu@huawei.com; adslmib@ietf.org; Moti=20 > Morgenstern; Freudenberger, Markus; gerd.barchmann@nsn.com; wolfgang.krille@nsn.com > Betreff: Re: Vector of Profiles MIB >=20 > Hi all, >=20 > As you may know from my previous messages on the subject of the Vector = > of Profiles MIB proposal, I do not believe that it is a good idea to = introduce another VDSL2 management interface which is not compatible = with the existing management interface ( RFC5650 ) unless there are = compelling and significant reasons to do so. >=20 > Introducing an incompatible VDSL2 management interface does not=20 > benefit the xDSL industry, it causes harm because NMS/EMS applications will now = have to support two interfaces instead of one. >=20 > I consider the Vector of Profiles scheme to be an implementation=20 > decision which should be considered by firmware developers in order to minimise = the storage requirements for xDSL configuration in the Access Node. > But this implementation decision is a low level detail and should not affect the VDSL2 management interface. >=20 > A firmware developer can implement the VoP scheme inside the Access=20 > Node while remaining 100% compatible with the RFC5650 management interface. = What is required is to provide a mapping between the template name and = the vector, and this mapping can be kept hidden so that the operator has = no knowledge of the internal implementation details. >=20 > Let me state my proposal in a different way in case what I said was=20 > not very clear. >=20 > 1. Internally, the xDSL configuration is stored using > the efficient VoP scheme. > 2. In the firmware, a mapping exists between the RFC5650 > template name and the internal vector that stores the > configuration for that template. This mapping may take > the form of a hash map for example. > 3. When a SNMP request arrives to read a row from the > line profile or channel profile tables > ( xdsl2LineConfProfTable, > xdsl2LineConfProfModeSpecTable > xdsl2LineConfProfModeSpecBandUsTable, > xdsl2ChConfProfileTable ) > the access node will consult its hash map and find > the corresponding vector. The access node will then > retrieve the data from the vector and return it in > the form of a SNMP row. > What this means is that storage of the xDSL > configuration data is decoupled from the MIB > representation of the data. Most modern SNMP agent's > ( such as the Net SNMP agent ) supports decoupling > of the underlying storage as I have described. > 4. When a SNMP request arrives to write a row into > the line profile or channel profile tables, the > access node must either create a new vector to > store the data of reference an existing vector > which already contains that data. >=20 > Using this approach, the access node gains the advantage of storing=20 > the xDSL configuration data efficiently while remaining compatible with the = existing SNMP management interface. >=20 > The algorithm that I have described above would need to be specified=20 > in more detail, but I am sure that every one here is an engineer and at = least understands the concept that I am proposing. >=20 > In conclusion, I think that the broad band forum should create a=20 > companion document that goes together with TR165 which specifies an algorithm ( = similar to what I have proposed above ) that firmware developers can use = to map between 5650 templates and VoP vectors instead of specifying a = new VDSL2 management interface at the IETF. >=20 > Regards, >=20 > Scott. >=20 >=20 > _______________________________________________ > Adslmib mailing list > Adslmib@ietf.org > https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib