Re: [Adslmib] AD review of draft-ietf-adslmib-vdsl2-06.txt
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 22 January 2009 14:39 UTC
Return-Path: <adslmib-bounces@ietf.org>
X-Original-To: adslmib-archive@optimus.ietf.org
Delivered-To: ietfarch-adslmib-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E1228C136; Thu, 22 Jan 2009 06:39:02 -0800 (PST)
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 0A8313A6A15; Thu, 22 Jan 2009 06:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level:
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 cLK5q617r2gG; Thu, 22 Jan 2009 06:38:59 -0800 (PST)
Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 66EE93A6985; Thu, 22 Jan 2009 06:38:59 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,307,1231131600"; d="scan'208";a="158676727"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 22 Jan 2009 09:38:42 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jan 2009 09:38:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 22 Jan 2009 15:37:55 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A040132DA45@307622ANEX5.global.avaya.com>
In-Reply-To: <741F3E4A466A1D439C616902C7F8A8C6D2BC7EF2ED@ILPTMAIL02.ecitele.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AD review of draft-ietf-adslmib-vdsl2-06.txt
Thread-Index: Ackhj0+4nSF1WXyGQ8OY26tM1ZXzPQdKodOwD3lAe+A=
References: <EDC652A26FB23C4EB6384A4584434A04FD8D6B@307622ANEX5.global.avaya.com> <741F3E4A466A1D439C616902C7F8A8C6D2BC7EF2ED@ILPTMAIL02.ecitele.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Moti Morgenstern <Moti.Morgenstern@ecitele.com>, David B Harrington <dbharrington@comcast.net>
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, adslmib@ietf.org, Menachem Dodge <Menachem.Dodge@ecitele.com>, scott.baillie@nec.com.au
Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-vdsl2-06.txt
X-BeenThere: adslmib@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: ADSLMIB <adslmib.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/adslmib>
List-Post: <mailto:adslmib@ietf.org>
List-Help: <mailto:adslmib-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/adslmib>, <mailto:adslmib-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: adslmib-bounces@ietf.org
Errors-To: adslmib-bounces@ietf.org Hi Moti,
Your proposed resolution to the comments looks satisfactory to me. Please proceed with creating a revised version of this document which could be sent to IETF LC. Thanks and Regards, Dan > -----Original Message----- > From: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] > Sent: Sunday, November 09, 2008 4:53 PM > To: Romascanu, Dan (Dan); David B Harrington > Cc: MIB Doctors (E-mail); adslmib@ietf.org; Menachem Dodge; > scott.baillie@nec.com.au; umberto.bonollo@nec.com.au > Subject: RE: AD review of draft-ietf-adslmib-vdsl2-06.txt > > Hi Dan and David, > > Thank you for the comments regarding to > draft-ietf-adslmib-vdsl2-06.txt. > We, the editors, reviewed the comments and here is our > response to each (Dan's comments and then David's): > > Comment T1 > -------------- > Comment suggests writing specifically in the MIB module, in > the DESCRIPTION clauses of the MIB tables, what is the > persistence policy relative to the objects in the table. > Response: We have a section in the document called "2.5. > Persistence" which lists all persistent objects. If you > search for each of these objects in the MIB, not all of the > objects mention persistence in the DESCRIPTION clause. This > is when the persistency is relevant to ALL objects and, when > that happens, the DESCRIPTION clause of the containing table > mentions: "Entries in this table MUST be maintained in a > persistent manner." So we believe the current situation is > satisfactory. > > Comment T2 > -------------- > Comment claims that indexation by name is very resource consuming. > Response: The observation is basically correct. Despite that, > we chose name indexes on purpose for ease of use by the > operator and consistency with all other xDSL MIBs. > > Comment T3 > -------------- > Comment refers to rate-limiting notifications mentioned in > the document. > Response: We will remove the rate limiting comment altogether > because no other xDSL MIB mentions this. > > Comment T4 > -------------- > Comment is a request to explain the Reserved bits in > Xdsl2TransmissionModeType. > Response: We used reserved bits because we want the VDSL2 MIB > to closely match the source document G.997.1. > > Comment T5 > -------------- > Comment about the Textual Conventions with enumerated INTEGER > syntax in which the list of values starts from zero. > Response: Similar to T4 above this was done on purpose. We > want the MIB to closely match the source document G.997.1 > which already defines the range of enumerated values for many > attributes. Since the syntax allows that we don't see it > necessary to explain such considerations in the MIB. > > Comment T6 > -------------- > Comment about the Boolean objects with new TCs instead of > using TruthValue > Response: We use TruthValue for 10 objects in the MIB, so, > it's not that we are not familiar with that TC. The real > reason, again, is that G.997.1 specifically defines the range > of values and meaning for many attributes and our MIB follows > it as much as we could. > > Taking the Textual Conventions mentioned in this comment as examples: > Xdsl2LineLdsf- G.997.1 uses the value 0 to inhibit LDSF and 1 > for forcing LDSF. We preferred explicitly using those values. > Xdsl2LineCeFlag- CEFLAG is defined by G.997.1 as a bitmap > with a single bit. So, the values range is 0 and 1. > Xdsl2LineSnrMode-TruthValue uses the value 1 for true and 2 > for false, while G.997.1 uses 1 for disable and 2 for enable. > > There is still one TC (Xdsl2LineForceInp) that could be > replaced by the TruthValue. This will be performed. > > Comment T7 > -------------- > Comment regarding to using RowStatus only to delete rows > Response: We'll add text in the relevant DESCRIPTION clauses > to explain that the agent rejects any SET operation which > sets row status to a value other than delete(6) > > Comment T8 > -------------- > Comment: why not replace inventory information in > Xdsl2LineInventoryEntry with entPhysicalTable in RFC4133 > Response: There are several arguments against the idea. > However, the most important one is that we need to provide > the inventory for both near-end and far-end units and that > means two rows per each ifIndex. So, we cannot use RFC4133 > for inventory because the indexing scheme is inappropriate. > > Comment T9 > -------------- > Comment: what happens when row is validated, etc. > Response: We agree that there's a need to perform several > changes in the DESCRIPTION clause of row-status objects. This > will include removing the text about validating the row > content (i.e., as we cannot explain how we expect the > implementation to perform that) as well as giving more > information regarding to deleting a "referenced" row. > > Comment T10 > -------------- > Comment requests explanation about how the thresholds in the > xdsl2ChAlarmConfProfileTable are being applied > Response: First of all, RFC3705 includes TCs and we use one > of them in the referred table. Second, we suggest to add a > text in the top part of the document explaining that only one > threshold trap per interval will be issued once the > individual counter exceeds the threshold defined for it. Is > that acceptable? > > Comment T11 > -------------- > Comment suggests that the compliance should be function of > the flavor(s) of xDSL an agent implements. > Response: The MODULE-COMPLIANCE section applies to all > technology types: VDSL2/ADSL/ADSL2 and ADSL2+. The assumption > of G.997.1 is that a typical implementation supports a > mixture of technologies and transmission modes, not a single > selected one, and that's why the abstract attribute was > originally defined as a bit map rather than an enumeration of > modes. The idea is that a typical operator wishes to serve > all transmission modes supported by the remote units so he > prepares, for each service package, a setup that can satisfy > multiple use cases. > Theoretically, Most of the MIB attributes are relevant for > all or at least multiple xDSL technologies. There are still > several which are relevant for a specific technology. We > didn't want to complicate the compliance section because > otherwise we would also need to handle attributes that are > sometimes mandatory and sometimes optional (and what happens > when you have a mixed scenario..?). So, we believe an agent > implementation should conform to the compliance clause but > also consult with ITU-T G.997.1 to see exactly what is > required depending on the mixture of the various transmission > modes relevant for the specific operator. > > Comment E1 > -------------- > Comment: s/ a more comprehensive/a complementary/ > Response: The ADSL2 MIB is recommended for implementations > that do not implement VDSL2 and do not want to be affected by > it at all. The NG-xDSL MIB (this draft) has a wider scope of > technologies and is recommended for implementations of VDSL2 > (only VDSL2 or together with older DSL technologies) and are > ready to pay the "price". The "price" is expressed in various > ways, e.g., the need to implement the "subcarrier group" > related attributes for DELT also for ADSL/2/2+, although > those attributes are meaningful only in VDSL2. > So the new MIB is not a complementary one but a solution for > the same problem space, only with a wider set of DSL technologies. > > Comment E2 > -------------- > Comment: list of abbreviations > Response: OK > > Comment E3 > -------------- > Comment: Section 2.3.2 duplicates text from the TC-MIB module itself > Response: OK. We'll delete it. > > Comment E4 > -------------- > Comment: page 28 - s/This MIB allows supporting/This MIB > module allows supporting > Response: OK. > > Comment E5 > -------------- > Comment: page 31 - s/ Network Elements may /Network Elements > MAY/ and s/The xTU-C should / The xTU-C SHOULD/ > Response: OK. > > Comment E6 > -------------- > Comment: In SMIv2 we do not usually speak about attributes > but about objects > Response: We'll correct the relevant text. > > Comment E7 > -------------- > Comment: DESCRIPTION clause of the MIB module duplicates text > in the Overview section > Response: We'll use a short summary in the overview section > and a full description in the MIB module. > > Comment E8 > -------------- > Comment: 'an ifType of vdsl(xxx)'. It is good to add at least > at the first occurrence a note to the RFC Editor > Response: OK. > > Comment E9 > -------------- > Comment: The DESCRIPTION clauses of Valid Intervals and > Invalid Intervals are almost void > Response: We'll fill the DESCRIPTION clauses for these objects > > Comment E10 > -------------- > Comment: Section 4 would benefit from one or two examples of > configuration templates > Response: We prefer not to add any additional tutorial > material into the VDSL2 draft MIB. > > > Comments from David B Harrington > -------------------------------- > > Comment: "One suggestion would be to put the > VDSL2-LINE-TC-MIB in a separate document." > Response: This would require 2 RFC numbers for VDSL2 and we > don't like it. We also have an experience from RFC4706 and > the draft ANCP AN MIB (draft-ietf-ancp-mib-an-03) that have > the same structure as this draft. > > Comment:"I strongly support Dan's request to eliminate some > of the redundancy in this document, and I recommend starting > with the textual convention triplication. You can probably > save 30% of the document length getting rid of unnecessary > textual convention definitions." > Response: We have no real objection to removing the TCs that > are referenced only once and placing the definition in the > object definition. Is that also agreed by Dan? Any comment > from the WG members? > > Comment: "It might be good to have a manageability > considerations section that discusses using short strings and > internal choices to minimize the resource impact." > Response: We don't think this is necessary. > > Dan and David, Thanks again for your time and your comments. > > On behalf of the co-editors, > Moti Morgenstern > _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www.ietf.org/mailman/listinfo/adslmib
- [Adslmib] AD review of draft-ietf-adslmib-vdsl2-0… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… David B Harrington
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Menachem Dodge
- Re: [Adslmib] AD review of draft-ietf-adslmib-vds… Moti Morgenstern
- Re: [Adslmib] AD review of draft-ietf-adslmib-vds… David B Harrington
- Re: [Adslmib] AD review of draft-ietf-adslmib-vds… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Moti Morgenstern
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Bert Wijnen (IETF)
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… David B Harrington
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Andy Bierman
- Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ie… Scott Baillie
- Re: [Adslmib] [MIB-DOCTORS] AD review ofdraft-iet… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD review ofdraft-iet… Scott Baillie
- Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf… Scott Baillie
- [Adslmib] Summary of discussion regarding the use… Scott Baillie
- Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf… Romascanu, Dan (Dan)
- Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf… Bert Wijnen (IETF)
- Re: [Adslmib] [MIB-DOCTORS] AD reviewofdraft-ietf… David B Harrington