Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt
"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 16 February 2009 15:03 UTC
Return-Path: <dromasca@avaya.com>
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 137043A6C76; Mon, 16 Feb 2009 07:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level:
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 FwPBl-He5Z5h; Mon, 16 Feb 2009 07:03:05 -0800 (PST)
Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A43B03A6B03; Mon, 16 Feb 2009 07:03:04 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,216,1233550800"; d="scan'208";a="152423326"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Feb 2009 10:02:58 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Feb 2009 10:02:57 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Feb 2009 16:02:48 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A04013E01EC@307622ANEX5.global.avaya.com>
In-Reply-To: <02b301c99046$accfcda0$0600a8c0@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt
Thread-Index: Ackhj0+4nSF1WXyGQ8OY26tM1ZXzPQdKodOwD3lAe+AACTvkUAF8UT+wA16f2GAABIFEAAABdjPg
References: <EDC652A26FB23C4EB6384A4584434A04FD8D6B@307622ANEX5.global.avaya.com><741F3E4A466A1D439C616902C7F8A8C6D2BC7EF2ED@ILPTMAIL02.ecitele.com> <EDC652A26FB23C4EB6384A4584434A040132DA45@307622ANEX5.global.avaya.com> <EDC652A26FB23C4EB6384A4584434A040132DB37@307622ANEX5.global.avaya.com> <741F3E4A466A1D439C616902C7F8A8C6D4CDF7BD82@ILPTMAIL02.ecitele.com> <EDC652A26FB23C4EB6384A4584434A04013E014D@307622ANEX5.global.avaya.com> <02b301c99046$accfcda0$0600a8c0@china.huawei.com>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: David B Harrington <dbharrington@comcast.net>, Moti Morgenstern <Moti.Morgenstern@ecitele.com>
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] [MIB-DOCTORS] 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>
X-List-Received-Date: Mon, 16 Feb 2009 15:03:07 -0000
I support David's position. As I said, I could live with multiple 'special' TCs, but this is far from optimal, so I strongly suggest to the authors to reconsider this issue, in the light of David's arguments. Dan > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Monday, February 16, 2009 4:56 PM > To: Romascanu, Dan (Dan); 'Moti Morgenstern' > Cc: 'MIB Doctors (E-mail)'; adslmib@ietf.org; 'Menachem > Dodge'; scott.baillie@nec.com.au; umberto.bonollo@nec.com.au > Subject: RE: [MIB-DOCTORS] AD review of > draft-ietf-adslmib-vdsl2-06.txt > > Hi, > > It is almost always important to remember the audience for a MIB. > This MIB will be used by operators and NMS developers. > > Operators and NMS developers are accustomed to Truthvalue TCs. > Many NMS applications already have been coded to present the > values as "true" and "false" for Truthvalue TCs. When those > many NMS applications parse this MIB module and get the > special-case TCs, the NM application writer will need to > write new special-case code for these special-case TCs. > > People who helped develop the managed protocol are probably > NOT the same people who are going to work on the helpdesk or > in the IT department monitoring the values and behaviors of > the network on a daily basis, and are not the people who will > write NM applications (unless they will write special-case NM > applications for this MIB module). > > So while it might be more "natural" for the protocol > designers to think in terms of 0-1, the end-users of the MIB > are accustomed to TruthValue TCs, and NMS applications > already know how to deal with the standard TCs rather than > the special-case TCs being used in this MIB. > > Interoperability in the world of network management > protocols, like SNMP and MIBs, is all about making it > possible for NM applications to talk to managed devices in a > manner that is consistent and vendor-neutral, and > managed-technology-neutral. That is why SNMP has a standard > set of error codes, rather than different error codes for > each managed technology. That is why SMIv2 organizes data > into two-dimensional tables rather than in deep nested > structures, even if the underlying technology uses deep > nested structures. That is why SNMP has standard datatypes, > rather than different datatypes for each managed protocol. > The special-case datatypes being proposed as TCs in this MIB > module seem to be simply designer-preference - we like 0-1 > better than 1-2. > > I think there is a strong interoperability justification for > using TruthValue TC rather than MIB-specific TCs with the > same purpose. > > Over thwe past ten years or so, we have had it drilled into > our heads by the user community that we need to meet the > interoperability needs of the readers and users of MIB > modules, such as operators and NM application developers, > more than the personal preferences of the MIB module writers. > > I think this MIB should use TruthValue, not special-case TCs. > > dbh > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, February 16, 2009 7:29 AM > > To: Moti Morgenstern; 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: [MIB-DOCTORS] AD review of > > draft-ietf-adslmib-vdsl2-06.txt > > > > See my answers in-line. David, please jump in if you have > objections. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > > > -----Original Message----- > > > From: Moti Morgenstern [mailto:Moti.Morgenstern@ecitele.com] > > > Sent: Friday, January 30, 2009 12:40 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: [MIB-DOCTORS] AD review of > > > draft-ietf-adslmib-vdsl2-06.txt > > > > > > Hi Dan and David, > > > > > > The editors reviewed the additional comments against revision > > > -06 and our response is the following (numbered according to the > > > comment numbers): > > > > > > 1) As explained in our previous reference to this issue, > we prefer > > > the special TCs we use instead of replacing them with the > TruthValue > > > TC, which we do use where appropriate. This is also > because the use > > > of TrutrhValue TC is not mandatory (That can easily > understood from > > > the [RFC2119] interpretation of "SHOULD NOT"). > > > > OK - still not best IMO but I can live with this. > > > > > > > > 2) The comment is not so clear. > > > Do you mean that, instead of xdsl2Notifications OBJECT IDENTIFIER > > > ::= { vdsl2 0 } we should use xdsl2Notifications OBJECT > IDENTIFIER > > > ::= { vdsl2MIB 0 } so the notifications will reside > directly under > > > the MODULE-ENTITY? > > > We'll appreciate a quick answer for this, if possible. > > > > I clarified this I think in the separate mail sent yesterday. > > > > > > > > 3) We'll fix the abbreviation inconsistency reported. > > > > Thanks. > > > > > > > > 4-6) xdsl2LineCmndConfBpscReqCount will be renamed as > suggested and > > > we'll also change its syntax. However, we believe that there is a > > > misunderstanding of the mechanism for which we use that object. > > > Therefore we intend to change the DESCRIPTION clauses of > this object > > > and xdsl2LineCmndConfBpsc to clarify the dynamic behavior of the > > > procedure. The main point to explain is that the SNMP > agent does not > > > allow interrupting a process which is in progress. The > counter only > > > allows the manager to identify the reported measurements > are result > > > of "his" process (i.e., they may belong to a process that was > > > executed later on, after his process was already > > > complete). > > > > OK - pending on the exact edits you need to come with. > > > > > > > > 7) The results of a line diagnostic tests have their own table > > > (xdsl2SCStatusSegmentTable) and therefore > xdsl2LineSegmentTable is > > > not overloaded. > > > > OK > > > > > > > > 8) The xdsl2LineCmndConfBpsc and xdsl2LineCmndConfLdsf are > > > associated with different results tables. > > > > I am not sure that you understood our concern here. Exactly > the fact > > that there are two different tables is the reason of > concern because > > the tests can happen on the same line simultaneously, at > the request > > of two different managers, one writing xdsl2LineCmndConfBpsc and > > another xdsl2LineCmndConfLdsf. Can this happen? If not, > please explain > > what > we > > are missing. > > > > > > > > 9) > > > a) The document already describes the coexistence of RFC > 2662, RFC > > > 4706 and the current document. We can summarize that RFC2662 is > > > relevant only for managing modems that do not support any DSL > > > technology other than ADSL (e.g., G.992.1/2) especially if were > > > produced prior to approval of ITU-T > > > G.997.1 rev 3 . RFC 4706 is more appropriate for managing modems > > > that support ADSL2 technology variants (with or without > being able > > > to support the legacy ADSL). The current document > supports all ADSL, > > > ASDSL2 and VDSL2 standards but it assumes a more sophisticated > > > management model, which older modems (even ADSL2 ones) may not be > > > able to support. > > > b) It's important to notice that each modem can indicate, by the > > > ifType, what (specific) MIB it supports. E.g., It's possible to > > > upgrade from RFC 2662 to 4706 MIB, but it requires a > software change > > > on both sides of the management > > > interface and also a database conversion. > > > > The two issues above seem to be important enough to be explicitly > > mentioned in the document. > > > > > c) We do not agree that "rfc2662 does support using the > entity mib". > > > All it says is that implementing the entity MIB is optional and > > > that, if implemented, it should include a row for the the > ATU-C or > > > ATU-R based on the agent lcation. This is so obvious that > it's not a > > > surprise no other xDSL line MIB (e.g., RFC 3728 (vdsl), RFC 4319 > > > (shdsl), RFC 4706 (adsl2)) refers to that. > > > > I guess that David's intent was that he expected this reference to > the > > entity MIB to show up here as well. Sometimes it is better to state > > the obvious. > > > > > By the way, note that even RFC 2662 understands that > there can be a > > > row in the entity MIB for either the ATU-C or ATU-R, not > both. This > > > strengthen our response to Dan's previous comment T8 that > referred > > > to the entity MIB. > > > > > > Thanks for your efforts, > > > Moti Morgenstern > > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Thursday, January 22, 2009 10:42 PM > > > To: Romascanu, Dan (Dan); Moti Morgenstern; 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: [MIB-DOCTORS] AD review of > > > draft-ietf-adslmib-vdsl2-06.txt > > > > > > Hi Moti, > > > > > > There are some more comments from David Harrington listed below. > > > > > > Please address them in the new version of the MIB module > and of the > > > document. > > > > > > 1) as per RFC4181 the TruthValue TC SHOULD be used in the SYNTAX > > > clause of object definitions > > > that require a Boolean type. MIB modules SHOULD NOT use > > > enumerated > > > INTEGER types or define TCs that duplicate its semantics. > > > > > > 2) the MIB organization does not follow the RECOMMENDED OID > > > assignment scheme for notifications as per section 4.7 > and Appendix > > > D of RFC 4181 > > > > > > 3) Xdsl2LineEntry ::= > > > SEQUENCE { > > > xdsl2LineCnfgTemplate SnmpAdminString, > > > xdsl2LineCnfgFallbackTemplate SnmpAdminString, > > > xdsl2LineAlarmCnfgTemplate SnmpAdminString, > > > xdsl2LineCmndConfPmsf Xdsl2ConfPmsForce, > > > xdsl2LineCmndConfLdsf Xdsl2LineLdsf, > > > xdsl2LineCmndConfLdsfFailReason Xdsl2LdsfResult, > > > xdsl2LineCmndConfBpsc Xdsl2LineBpsc, > > > xdsl2LineCmndConfBpscFailReason Xdsl2BpscResult, > > > xdsl2LineCmndConfBpscReqCount Unsigned32, > > > xdsl2LineCmndAutomodeColdStart TruthValue, > > > xdsl2LineCmndConfReset Xdsl2LineReset, > > > xdsl2LineStatusActTemplate SnmpAdminString, > > > xdsl2LineStatusXtuTransSys Xdsl2TransmissionModeType, > > > xdsl2LineStatusPwrMngState Xdsl2PowerMngState, > > > xdsl2LineStatusInitResult Xdsl2InitResult, > > > xdsl2LineStatusLastStateDs Xdsl2LastTransmittedState, > > > xdsl2LineStatusLastStateUs Xdsl2LastTransmittedState, > > > xdsl2LineStatusXtur Xdsl2LineStatus, > > > xdsl2LineStatusXtuc Xdsl2LineStatus, > > > xdsl2LineStatusAttainableRateDs Unsigned32, > > > xdsl2LineStatusAttainableRateUs Unsigned32, > > > xdsl2LineStatusActPsdDs Integer32, > > > xdsl2LineStatusActPsdUs Integer32, > > > xdsl2LineStatusActAtpDs Integer32, > > > xdsl2LineStatusActAtpUs Integer32, > > > xdsl2LineStatusActProfile Xdsl2LineProfiles, > > > xdsl2LineStatusActLimitMask Xdsl2LineLimitMask, > > > xdsl2LineStatusActUs0Mask Xdsl2LineUs0Mask, > > > xdsl2LineStatusActSnrModeDs Xdsl2LineSnrMode, > > > xdsl2LineStatusActSnrModeUs Xdsl2LineSnrMode, > > > xdsl2LineStatusElectricalLength Unsigned32, > > > xdsl2LineStatusTssiDs Xdsl2Tssi, > > > xdsl2LineStatusTssiUs Xdsl2Tssi, > > > xdsl2LineStatusMrefPsdDs Xdsl2MrefPsdDs, > > > xdsl2LineStatusMrefPsdUs Xdsl2MrefPsdUs, > > > xdsl2LineStatusTrellisDs TruthValue, > > > xdsl2LineStatusTrellisUs TruthValue, > > > xdsl2LineStatusActualCe Unsigned32 > > > } > > > > > > Check out inconsistent abbreviations, such as > > > xdsl2LineCnfgFallbackTemplate which points to the > > > xdsl2LineConfTemplateTable. (cnfg and conf both mean > > > configuration) I note that RFC2662 uses "conf" consistently. > > > > > > 4)The counter xdsl2LineCmndConfBpscReqCount let's management > > > station M1 know when another management station M2 requested a > > > measurement, which caused the relevant counter to reset, > such that > > > M1's measurement is no longer valid. > > > "SNMP managers can use this attribute to check that the > > > measurement results retrieved by the manager where not > > > interupted by another measurement request." > > > > > > We discouraged resetting counters in IETF MIB modules. Can you > > > explain why this is necessary? > > > > > > 5) The naming conventions for counters are not being followed > > > - xdsl2LineCmndConfBpscReqCount should probably be > > > xdsl2LineCmndConfBpscRequests. > > > > > > 6) xdsl2LineCmndConfBpscReqCount - why is this an Unsigned32 and > > > not a Counter32? > > > > > > 7) I am a bit concerned about the table that actually > contains the > > > measurement - the xdsl2LineSegmentTable The actual > measurement is > > > in xdsl2LineSegmentBitsAlloc. It appears the value is > overloaded to > > > provide subcarrier allocation status, as well as the result of a > > > line diagnostic > test. > > > > > > 8) from security considerations "Unauthorized changes to > > > xdsl2LineCmndConfBpsc could cause an unscheduled bits per > subcarrier > > > measurement to be carried out on the line.", and "Unauthorized > > > changes to xdsl2LineCmndConfLdsf could cause an unscheduled line > > > test to be carried out on the line." Since these two measurements > > > report using the same object, and since one measurement can > > > interfere with the validity of the measurement requested by a > > > different manager, this seems to have serious issues of > information > > > reliability. > > > > > > 9) On a larger scale, I am concerned that this appears to be a > > > **competing** standard to RFC2662. This does not complement, or > > > update, or obsolete RFC2662. > > > > > > I have not yet gone into the two mib modules to determine how > > > compatible they are, but section 4 in this document makes > me really > > > uneasy as a > > > (previous) management app designer. Can a device support both mib > > > modules simultaneously? Can a management app use both MIB modules > > > simultaneously to manage the same ADSL functions on > > a device? > > > > > > I note that rfc2662 does support using the entity mib, while this > > > mib module does not. Which makes me wonder about the > compatibility > > > between the two mib modules. > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > From: mib-doctors-bounces@ietf.org > > > > > > >
- [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