From internet-drafts@ietf.org Wed Feb 1 15:21:32 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840D511E8086; Wed, 1 Feb 2012 15:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H6rdZu2xTub; Wed, 1 Feb 2012 15:21:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE50E11E80A1; Wed, 1 Feb 2012 15:21:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120201232130.32088.81781.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 15:21:30 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] I-D Action: draft-ietf-adslmib-gbond-mib-08.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 23:21:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : xDSL multi-pair bonding (G.Bond) MIB Author(s) : Edward Beili Moti Morgenstern Filename : draft-ietf-adslmib-gbond-mib-08.txt Pages : 67 Date : 2012-02-01 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-mib-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-mib-08.txt From EdwardB@actelis.com Wed Feb 1 15:23:00 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605E711E8086 for ; Wed, 1 Feb 2012 15:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwbTPN6lPDKt for ; Wed, 1 Feb 2012 15:22:59 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5408511E80B7 for ; Wed, 1 Feb 2012 15:22:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,605,1320616800"; d="scan'208";a="63031" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 02 Feb 2012 01:22:56 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Thu, 2 Feb 2012 01:22:56 +0200 From: Edward Beili To: "Romascanu, Dan (Dan)" Date: Thu, 2 Feb 2012 01:22:54 +0200 Thread-Topic: AD review of draft-ietf-adslmib-gbond-mib-07.txt Thread-Index: AcyH8Ca1oiAJ51NQQbWKBQVZIp7DzRXVtIRQ Message-ID: <4087887712E5C648B9F72BB9D912FD4601FD571DA398@il-mail07.actelis.net> References: In-Reply-To: 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" , Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-mib-07.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 23:23:00 -0000 Dan, Thank you for your comments. Please see the clarifications/actions inline below (my comments are marked = with [EB], Moti Morgenstern's ones are with [MM]): I have just submitted the next draft (08) of the gbond-mib. I'll submit the rest of gbond-*-mib drafts within a day or two. Regards, -E. >-----Original Message----- >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf= Of Romascanu, Dan (Dan) >Sent: Tuesday, October 11, 2011 10:31 >To: adslmib@ietf.org >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-mib-07.txt > >Please find below the AD review of draft-ietf-adslmib-gbond-mib-07.txt. >This document is in a good shape, and thank you for writing a clear docume= nt despite the complexity of the technology, >but a new version is needed in order to clarify and fix some of the issues= raised in the review.=20 > >The comments below are marked T (Technical) and E (Editorial) > >T1. Runing smicng in strict mode results in the following warning:=20 > >W: f(gbond.mi2), (1900,8) Duplicate item "gBondOperScheme" in object-group= "gBondBasicGroup " OBJECTS list [EB] Corrected - the duplicate item is removed. >T2. In the pseudocode for the discovery and automatic BCE assignment how a= re selected the MAC addresses that >may represent the 6-octets local discovery code to the GBS? Do devices nee= d to have such unique MAC addresses >pre-allocated for this scope, or are they using real addresses on the devi= ce for this purpose. [EB] The 6-octets local discovery code can be either a unique number specif= ically allocated for the BCE discovery purpose or a real MAC address of the= associated port, which is unique among other MAC addresses by definition. = I've added the clarification to the text. >T3. In Section 4.1.3:=20 > > It is RECOMMENDED that a removal of the last operationally 'up' BCE > from an operationally 'up' GBS would be rejected by the > implementation, as this action would completely drop the link. > >It would be good to explain what does 'rejected by the implementation' >means. In the case of an SNMP agent should the SetRequest command that bri= ngs the ifAdminStatus to 'down' be >rejected with an error (what error)?=20 [EB] I've modified the sentence to be more clear: It is RECOMMENDED that a removal of the last operationally 'up' BCE from an operationally 'up' GBS, i.e. modification of a respective entry= =20 in ifStackTable and a corresponding entry in ifInvStackTable, would be rejected by the implementation (in case of SNMP with the error inconsistentValue), as this action would completely drop the link. >T4. In table 1 at 4.1.5 for ifType s/ g9981, g9982 or g9982/ g9981, g9982 = or g9983/ > >Also I suggest that you refer to the future values for g9981, g9982, >g9983 as g9981(xxx), g9982(yyy), g9983(zzz) and in the IANA considerations= section you ask for the allocation of the >values xxx,yyy,zzz and their replacement in the final RFC version of the d= ocument, after the IANA actions were=20 >performed.=20 [EB] I've already asked IANA to allocate the numbers for g9981, g9982 and g= 9983. IANA has allocated the following numbers:=20 263 g9981 G.998.1 bonded interface=20 264 g9982 G.998.2 bonded interface 265 g9983 G.998.3 bonded interface See: http://www.iana.org/assignments/smi-numbers http://www.iana.org/assignments/ianaiftype-mib =20 I've added the allocated numbers in parentheses whenever g998* is mentioned= and modified IANA consideration section to acknowledge the allocation. >T5. Also in table 1 at 4.15 the explanation of ifOperStatus needs some cla= rification:=20 > >'a relevant *Status object from a particular line MIB supplements the 'dow= n' value of ifOperStatus for BCEs.' =20 > >I THINK that this means that the ifOperStatus is to be determined by readi= ng the value of a *status object in the >technology specific MIB module for the particular line. This will be true = however not only for 'down' but also for 'up' >values, right? [EB] You are right. I've corrected the ifOperStatus explanation in 4.15 as = follows: A relevant *Status object from a particular line MIB supplements the value = of ifOperStatus for BCEs. gBondFltStatus supplements the value of ifOperStatus for GBS. Note that bot= h relevant objects shall be inspected to determine the real operational sta= tus of a BCE/GBS port, e.g. a GBS port may be operationally 'up' with gBond= FltStatus indicating lowRate(4) fault condition, or 'down' with no faults. >T6. In Section 5.2:=20 > > The agent SHOULD align the beginning of each interval to a fifteen > minute boundary of a wall clock. Likewise, the beginning of each one > day intervals SHOULD be aligned with the start of a day. > >What about different time zones? Does it matter if a manager deals with ag= ents that are located in different time zones >with different hours for 'the start of the day'? Maybe it does not, but I = would like to see some discussion about this.=20 [MM] The issue of time-zones is usually neglected as a single management sy= stem normally does not manage network elements in multiple time zones. Anyh= ow, the issue was never discussed in any management models and there's no r= eason to expect the bonding specific MIB to address that. [EB] There is a HOST-RESOURCES-MIB (RFC 2790) which defines hrSystemDate ob= ject, specifying local date and time. By consulting this object a managemen= t system may determine a specific time zone offset for each agent, correlat= ing between the performance counters from different systems. Alternatively, each agent could be configured to align the beginning of the= one-day PM counters with some agreed UTC hour (say 00:00 UTC). I'm not sure if we should add this clarification in the text, as this is so= mething common to all MIB modules using PM-related objects and yet none of = them addressed this issue. >T7. Also in Section 5.2:=20 > > Counters are not reset when a GBS is reinitialized, but rather only > when the agent is reset or reinitialized (or under specific request > outside the scope of this MIB module). > >The text in brackets is problematic. How does the agent know about a 'spec= ific request outside the scope of this MIB >module'? Maybe you need an object for counters discontinuity? See section = 4.6.1.2 in RFC 4181.=20 [EB] Corrected - I have removed the text in parentheses.=20 >T8. Mapping of aLineUpDownEnable:=20 > >Note: Currently IF-MIB does not provide a control object for the linkUp/l= inkDown notifications. > >You can control notifications using the mechanisms defined in [RFC3413]. [EB] You are right. Added an informative reference to RFC 3413 and modified= the note as follows: The linkUp/linkDown notifications of IF-MIB can be controlled using the mec= hanisms defined in RFC 3413 . >T9. The object names in the MIB tables (e.g. gBondPortConfTable, gBondPort= CapabilityTable, gBondPortStatusTable, >gBondPortPerfCurrTable) do not respect the recommended convention for nami= ng objects in tables - see Annex C in >RFC 4181.=20 [EB] Corrected. >T10. In several DESCRIPTION clauses of counter objects the following >appears: 'read-only count of ...'. In SMIv2 a counter can be ONLY read-onl= y, so these statements are redundant.=20 [EB] This is a copy-paste from TR-159. Corrected. >T11. 'This object is inhibited during Unavailable Seconds (UAS).'. >Please clarify what 'inhibited' means. Is this that counting is stopped, o= r the object is not available (which would be >a bad design choice), or something else?=20 [MM] Inhibiting means that the accumulation is inhibited so the counter act= ually freezes during the unavailability period. Added the following clarification paragraph at the end of "Performance Moni= toring" section: Note that the accumulation of certain performance events for a monitored entity is inhibited (counting stops) during periods of service unavailability on that monitored entity. The DESCRIPTION clause of performance monitoring counters in this MIB module specifies which of the counters are inhibited during periods of service unavailability. >T12. The Security Considerations section does not use the standard boilerp= late text recommended at >https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security. Please use the= standard text, you may add things specific >to the MIB modules in the document, but the standard boilerplate text need= s to be present in the document.=20 [EB] Corrected. Added also gBondPortStatusTable to the sensitive readable o= bjects.=20 >T13. There is no need to capitalize the MAY statements in the list of obje= cts in the Security Considerations section,=20 >as they describe behavior and risks and not requirements.=20 [EB] Corrected. >E1. Please explain in a few words what is a gamma-interface (referred in t= he Introduction section).=20 [EB] gamma interface is a standard term defined in the ITU-T xDSL specs, re= ferring to the interface between the TPS-TC and the user data interface blo= ck, e.g. see G.993.2, section 5.1 "VTU functional model" for example. I removed the word "gamma" from the text to avoid confusion. >E2. In section 4.1.2:=20 > >' The agent is REQUIRED to report on the Bonding > capability for all types of G.Bond ports (ATM, Ethernet and TDIM). ' > >It is not clear what 'report' means here. If this is about presenting the = MIB information, what is so special?=20 [EB] I have replaced the words 'report on' with 'indicate'. The meaning her= e is that even if the port does not support fragmentation and re-assembly (= e.g. a single pair port) it still has to provide gBondSchemesSupported obje= ct. >E3. In table 1 at 4.1.5 s/assymetrical/asymetrical/ [EB] Corrected. >E4. In section 4.2 s/ This MIB module defined in this document/ The MIB mo= dule defined in this document/ [EB] Corrected. >E5. In section 4.2.3 s/ These MIBs/ These MIB modules/ [EB] Corrected. >E6. In the DESCRIPTION clause of the GBondScheme TC:=20 > >OLD:=20 > >g9982(2) - G.998.2 (G.Bond/Ethernt) > >NEW:=20 > >g9982(2) - G.998.2 (G.Bond/Ethernet [EB] Corrected. >E7. There is no need to repeat for each individual object in the gBondPort= ConfTable that the entry must be kept >in a persistent manner if this statement was already made generically for = the whole table.=20 [EB] Corrected. >Thanks and Regards, > >Dan > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www.ietf.org/mailman/listinfo/adslmib From dromasca@avaya.com Thu Feb 2 04:09:06 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D383B21F8A9C for ; Thu, 2 Feb 2012 04:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0hXnbevlGGR for ; Thu, 2 Feb 2012 04:09:05 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC6721F8A6B for ; Thu, 2 Feb 2012 04:09:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMAAGt6Kk/GmAcF/2dsb2JhbABDniuQW4EFgXIBAQEBAwEBAQ8eCjQLDAQCAQgNBAQBAQsGDAsBBgEmHwkIAQEEEwgBGYdjnF+bd4tJLAYBg2YBgQaCdWMEmxyMXA X-IronPort-AV: E=Sophos;i="4.71,608,1320642000"; d="scan'208";a="229772173" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Feb 2012 07:09:03 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Feb 2012 07:03:27 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: F/EO HxhK Macc M9z7 PspK SvVT UAoA WB0L YKPC goAZ o++K pEc+ sJ4S zF3I 1ihu 1u2c; 5; YQBkAHMAbABtAGkAYgBAAGkAZQB0AGYALgBvAHIAZwA7AGIAYwBsAGEAaQBzAGUAQABjAGkAcwBjAG8ALgBjAG8AbQA7AGUAZAB3AGEAcgBkAGIAQABhAGMAdABlAGwAaQBzAC4AYwBvAG0AOwBtAGUAbgBhAGMAaABlAG0ALgBkAG8AZABnAGUAQABlAGMAaQB0AGUAbABlAC4AYwBvAG0AOwBtAG8AdABpAC4AbQBvAHIAZwBlAG4AcwB0AGUAcgBuAEAAZQBjAGkAdABlAGwAZQAuAGMAbwBtAA==; Sosha1_v1; 7; {092DB4FA-CB5E-4A4F-99DB-77D8771BC860}; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0A; Thu, 02 Feb 2012 12:08:50 GMT; UgBFADoAIABBAEQAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBhAGQAcwBsAG0AaQBiAC0AZwBiAG8AbgBkAC0AbQBpAGIALQAwADcALgB0AHgAdAA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {092DB4FA-CB5E-4A4F-99DB-77D8771BC860} Content-class: urn:content-classes:message Date: Thu, 2 Feb 2012 13:08:50 +0100 Message-ID: In-Reply-To: <4087887712E5C648B9F72BB9D912FD4601FD571DA398@il-mail07.actelis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-adslmib-gbond-mib-07.txt Thread-Index: AcyH8Ca1oiAJ51NQQbWKBQVZIp7DzRXVtIRQAJcGa4A= References: <4087887712E5C648B9F72BB9D912FD4601FD571DA398@il-mail07.actelis.net> From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: Benoit Claise , adslmib@ietf.org, Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-mib-07.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 12:09:07 -0000 Thanks! I am waiting for the other three documents to be submitted, and then will send the whole package to IETF Last Call. Hopefully we can have the documents discussed and approved by the IESG before the ADs transition in Paris.=20 Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: Thursday, February 02, 2012 1:23 AM > To: Romascanu, Dan (Dan) > Cc: Moti Morgenstern; Menachem Dodge; adslmib@ietf.org > Subject: RE: AD review of draft-ietf-adslmib-gbond-mib-07.txt >=20 > Dan, > Thank you for your comments. >=20 > Please see the clarifications/actions inline below (my comments are > marked with [EB], Moti Morgenstern's ones are with [MM]): >=20 > I have just submitted the next draft (08) of the gbond-mib. > I'll submit the rest of gbond-*-mib drafts within a day or two. >=20 > Regards, > -E. >=20 > >-----Original Message----- > >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > Behalf Of Romascanu, Dan (Dan) > >Sent: Tuesday, October 11, 2011 10:31 > >To: adslmib@ietf.org > >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-mib-07.txt > > > >Please find below the AD review of draft-ietf-adslmib-gbond-mib- > 07.txt. > >This document is in a good shape, and thank you for writing a clear > document despite the complexity of the technology, > >but a new version is needed in order to clarify and fix some of the > issues raised in the review. > > > >The comments below are marked T (Technical) and E (Editorial) > > > >T1. Runing smicng in strict mode results in the following warning: > > > >W: f(gbond.mi2), (1900,8) Duplicate item "gBondOperScheme" in object- > group "gBondBasicGroup " OBJECTS list >=20 > [EB] Corrected - the duplicate item is removed. >=20 > >T2. In the pseudocode for the discovery and automatic BCE assignment > how are selected the MAC addresses that > >may represent the 6-octets local discovery code to the GBS? Do devices > need to have such unique MAC addresses > >pre-allocated for this scope, or are they using real addresses on the > device for this purpose. >=20 > [EB] The 6-octets local discovery code can be either a unique number > specifically allocated for the BCE discovery purpose or a real MAC > address of the associated port, which is unique among other MAC > addresses by definition. I've added the clarification to the text. >=20 > >T3. In Section 4.1.3: > > > > It is RECOMMENDED that a removal of the last operationally 'up' BCE > > from an operationally 'up' GBS would be rejected by the > > implementation, as this action would completely drop the link. > > > >It would be good to explain what does 'rejected by the implementation' > >means. In the case of an SNMP agent should the SetRequest command that > brings the ifAdminStatus to 'down' be > >rejected with an error (what error)? >=20 > [EB] I've modified the sentence to be more clear: >=20 > It is RECOMMENDED that a removal of the last operationally 'up' BCE > from an operationally 'up' GBS, i.e. modification of a respective > entry > in ifStackTable and a corresponding entry in ifInvStackTable, > would be rejected by the implementation > (in case of SNMP with the error inconsistentValue), > as this action would completely drop the link. >=20 > >T4. In table 1 at 4.1.5 for ifType s/ g9981, g9982 or g9982/ g9981, > g9982 or g9983/ > > > >Also I suggest that you refer to the future values for g9981, g9982, > >g9983 as g9981(xxx), g9982(yyy), g9983(zzz) and in the IANA > considerations section you ask for the allocation of the > >values xxx,yyy,zzz and their replacement in the final RFC version of > the document, after the IANA actions were > >performed. >=20 > [EB] I've already asked IANA to allocate the numbers for g9981, g9982 > and g9983. IANA has allocated the following numbers: > 263 g9981 G.998.1 bonded interface > 264 g9982 G.998.2 bonded interface > 265 g9983 G.998.3 bonded interface >=20 > See: > http://www.iana.org/assignments/smi-numbers > http://www.iana.org/assignments/ianaiftype-mib >=20 > I've added the allocated numbers in parentheses whenever g998* is > mentioned and modified IANA consideration section to acknowledge the > allocation. >=20 > >T5. Also in table 1 at 4.15 the explanation of ifOperStatus needs some > clarification: > > > >'a relevant *Status object from a particular line MIB supplements the > 'down' value of ifOperStatus for BCEs.' > > > >I THINK that this means that the ifOperStatus is to be determined by > reading the value of a *status object in the > >technology specific MIB module for the particular line. This will be > true however not only for 'down' but also for 'up' > >values, right? >=20 > [EB] You are right. I've corrected the ifOperStatus explanation in 4.15 > as follows: >=20 > A relevant *Status object from a particular line MIB supplements the > value of ifOperStatus for BCEs. > gBondFltStatus supplements the value of ifOperStatus for GBS. Note that > both relevant objects shall be inspected to determine the real > operational status of a BCE/GBS port, e.g. a GBS port may be > operationally 'up' with gBondFltStatus indicating lowRate(4) fault > condition, or 'down' with no faults. >=20 > >T6. In Section 5.2: > > > > The agent SHOULD align the beginning of each interval to a fifteen > > minute boundary of a wall clock. Likewise, the beginning of each > one > > day intervals SHOULD be aligned with the start of a day. > > > >What about different time zones? Does it matter if a manager deals > with agents that are located in different time zones > >with different hours for 'the start of the day'? Maybe it does not, > but I would like to see some discussion about this. >=20 > [MM] The issue of time-zones is usually neglected as a single > management system normally does not manage network elements in multiple > time zones. Anyhow, the issue was never discussed in any management > models and there's no reason to expect the bonding specific MIB to > address that. >=20 > [EB] There is a HOST-RESOURCES-MIB (RFC 2790) which defines > hrSystemDate object, specifying local date and time. By consulting this > object a management system may determine a specific time zone offset > for each agent, correlating between the performance counters from > different systems. >=20 > Alternatively, each agent could be configured to align the beginning of > the one-day PM counters with some agreed UTC hour (say 00:00 UTC). >=20 > I'm not sure if we should add this clarification in the text, as this > is something common to all MIB modules using PM-related objects and yet > none of them addressed this issue. >=20 > >T7. Also in Section 5.2: > > > > Counters are not reset when a GBS is reinitialized, but rather only > > when the agent is reset or reinitialized (or under specific request > > outside the scope of this MIB module). > > > >The text in brackets is problematic. How does the agent know about a > 'specific request outside the scope of this MIB > >module'? Maybe you need an object for counters discontinuity? See > section 4.6.1.2 in RFC 4181. >=20 > [EB] Corrected - I have removed the text in parentheses. >=20 > >T8. Mapping of aLineUpDownEnable: > > > >Note: Currently IF-MIB does not provide a control object for the > linkUp/linkDown notifications. > > > >You can control notifications using the mechanisms defined in > [RFC3413]. >=20 > [EB] You are right. Added an informative reference to RFC 3413 and > modified the note as follows: >=20 > The linkUp/linkDown notifications of IF-MIB can be controlled using the > mechanisms defined in RFC 3413 . >=20 > >T9. The object names in the MIB tables (e.g. gBondPortConfTable, > gBondPortCapabilityTable, gBondPortStatusTable, > >gBondPortPerfCurrTable) do not respect the recommended convention for > naming objects in tables - see Annex C in > >RFC 4181. >=20 > [EB] Corrected. >=20 > >T10. In several DESCRIPTION clauses of counter objects the following > >appears: 'read-only count of ...'. In SMIv2 a counter can be ONLY > read-only, so these statements are redundant. >=20 > [EB] This is a copy-paste from TR-159. > Corrected. >=20 > >T11. 'This object is inhibited during Unavailable Seconds (UAS).'. > >Please clarify what 'inhibited' means. Is this that counting is > stopped, or the object is not available (which would be > >a bad design choice), or something else? >=20 > [MM] Inhibiting means that the accumulation is inhibited so the counter > actually freezes during the unavailability period. >=20 > Added the following clarification paragraph at the end of "Performance > Monitoring" section: >=20 > Note that the accumulation of certain performance events for a > monitored entity is inhibited (counting stops) during periods of > service unavailability on that monitored entity. The DESCRIPTION > clause of performance monitoring counters in this MIB module > specifies which of the counters are inhibited during periods of > service unavailability. >=20 > >T12. The Security Considerations section does not use the standard > boilerplate text recommended at > >https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security. Please use > the standard text, you may add things specific > >to the MIB modules in the document, but the standard boilerplate text > needs to be present in the document. >=20 > [EB] Corrected. Added also gBondPortStatusTable to the sensitive > readable objects. >=20 > >T13. There is no need to capitalize the MAY statements in the list of > objects in the Security Considerations section, > >as they describe behavior and risks and not requirements. >=20 > [EB] Corrected. >=20 > >E1. Please explain in a few words what is a gamma-interface (referred > in the Introduction section). >=20 > [EB] gamma interface is a standard term defined in the ITU-T xDSL > specs, referring to the interface between the TPS-TC and the user data > interface block, e.g. see G.993.2, section 5.1 "VTU functional model" > for example. >=20 > I removed the word "gamma" from the text to avoid confusion. >=20 > >E2. In section 4.1.2: > > > >' The agent is REQUIRED to report on the Bonding > > capability for all types of G.Bond ports (ATM, Ethernet and TDIM). > ' > > > >It is not clear what 'report' means here. If this is about presenting > the MIB information, what is so special? >=20 > [EB] I have replaced the words 'report on' with 'indicate'. The meaning > here is that even if the port does not support fragmentation and re- > assembly (e.g. a single pair port) it still has to provide > gBondSchemesSupported object. >=20 > >E3. In table 1 at 4.1.5 s/assymetrical/asymetrical/ >=20 > [EB] Corrected. >=20 > >E4. In section 4.2 s/ This MIB module defined in this document/ The > MIB module defined in this document/ >=20 > [EB] Corrected. >=20 > >E5. In section 4.2.3 s/ These MIBs/ These MIB modules/ >=20 > [EB] Corrected. >=20 > >E6. In the DESCRIPTION clause of the GBondScheme TC: > > > >OLD: > > > >g9982(2) - G.998.2 (G.Bond/Ethernt) > > > >NEW: > > > >g9982(2) - G.998.2 (G.Bond/Ethernet >=20 > [EB] Corrected. >=20 > >E7. There is no need to repeat for each individual object in the > gBondPortConfTable that the entry must be kept > >in a persistent manner if this statement was already made generically > for the whole table. >=20 > [EB] Corrected. >=20 > >Thanks and Regards, > > > >Dan > > > >_______________________________________________ > >Adslmib mailing list > >Adslmib@ietf.org > >https://www.ietf.org/mailman/listinfo/adslmib From internet-drafts@ietf.org Thu Feb 2 16:00:31 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB0F21F8646; Thu, 2 Feb 2012 16:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJK7F7Dg-qpu; Thu, 2 Feb 2012 16:00:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A907621F85FF; Thu, 2 Feb 2012 16:00:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120203000030.31067.32941.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2012 16:00:30 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] I-D Action: draft-ietf-adslmib-gbond-atm-mib-05.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:00:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : ATM-Based xDSL Bonded Interfaces MIB Author(s) : Edward Beili Filename : draft-ietf-adslmib-gbond-atm-mib-05.txt Pages : 33 Date : 2012-02-02 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-atm-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-atm-mib-05.txt From EdwardB@actelis.com Thu Feb 2 16:04:47 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92421F8681 for ; Thu, 2 Feb 2012 16:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7PtMQBrfTCY for ; Thu, 2 Feb 2012 16:04:46 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDD21F8670 for ; Thu, 2 Feb 2012 16:04:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,349,1325455200"; d="scan'208";a="67978" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 03 Feb 2012 02:04:43 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Fri, 3 Feb 2012 02:04:43 +0200 From: Edward Beili To: "Romascanu, Dan (Dan)" Date: Fri, 3 Feb 2012 02:04:40 +0200 Thread-Topic: AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt Thread-Index: AcyeNcT+dePg4gidSueJRBXzS+MhQhDA6CDw Message-ID: <4087887712E5C648B9F72BB9D912FD4601FD571DA44B@il-mail07.actelis.net> References: In-Reply-To: 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" , Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:04:47 -0000 Dan, Thank you for your comments. Please see the clarifications/actions inline below (my comments are marked = with [EB], Moti Morgenstern's ones are with [MM]): I have just submitted the next draft (05) of the gbond-atm-mib. Regards, -E. >-----Original Message----- >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf= Of Romascanu, Dan (Dan) >Sent: Tuesday, November 08, 2011 18:45 >To: adslmib@ietf.org >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt > >Hi, > >Please find below the AD review of >draft-ietf-adslmib-gbond-atm-mib-04.txt. >This document is in a good shape, but a new version is needed in order to = clarify and fix some of the issues raised in the review.=20 > >The comments below are marked T (Technical) and E (Editorial) > >T1. In section 5.2:=20 > > The agent SHOULD align the beginning of each interval to a fifteen > minute boundary of a wall clock. Likewise, the beginning of each one > day intervals SHOULD be aligned with the start of a day. > >Where does this requirement come from? If the source is another standard I= suggest to provide it. What is the rationale? >What happens if this requi= rement is not / cannot be met because for example the agent does not have a= ccess to a 'wall clock'? [EB] This particular wording is from the TR-159 section 4.2.5, which is a n= ormative reference for the document, I didn't see a reason to explain this = recommendation in more details than is provided in TR-159. Note that this i= s a standard recommendation for the historical performance monitoring (PM) = based on 15-min & 1-day accumulation periods, see for example ANSI T1.231 = section 9.1.2.1 and 9.1.5.1. However, since this is the second time you are asking about PM intervals al= ignment with the wall clock boundaries I've decided to add the following te= xt to the GBOND-MIB draft 0.9 (unsubmitted yet), under 5.2 "Performance Mon= itoring": "The rationale behind it is to simplify collection and analysis of the PM f= rom multiple agents by a network management system (NMS) - each PM interval= can be 'time-stamped' using the interval index object, the fact that 1-day= interval starts at 00:00 and 15-min intervals are aligned with 1/4 hour an= d the network-wide 'wall clock', typically distributed via NTP or SNTP. If = the agent does not have an access to the 'wall clock', a local clock can be= used. In this case, as well as when coping with multiple time zones, the N= MS would have to correlate for the difference between the agent's local clo= ck (available for example via hrSystemDate object from HOST-RESOURCES-MIB [= RFC2790]) and the 'wall clock'." I have also removed the bracketed text from the following sentence in "Perf= ormance Monitoring" section, according to your T7 comment to the draft-ietf= -adslmib-gbond=3Dmib-07.txt: OLD> Counters are not reset when a GBS is reinitialized, but rather only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module). NEW> Counters are not reset when a GBS is reinitialized, but rather only when the agent is reset or reinitialized. >T2. The tables in this MIB module do not respect the naming convention rec= ommended in Annex C of RFC 4181:=20 > > - The descriptor associated with a conceptual table should be of the > form xxxZzzTable; the descriptor associated with the corresponding > conceptual row should be of the form xxxZzzEntry; the name of the > associated SEQUENCE type should be of the form XxxZzzEntry; and the > descriptors associated with the subordinate columnar objects should > be of the form xxxZzzSomeotherName. [EB] Corrected. >T3. In the DESCRIPTION clause of a couple of objects I found the following= :=20 > > This object is read-only for the GBS-C and irrelevant for > the GBS-R ports. > >What does 'irrelevant' mean? What should the agent do with these objects f= or the GBS-R ports?=20 [EB] 'Irrelevant' means that the object in question does not have any meani= ngful value in this particular case (e.g. for GBS-R port) and any operation= on it (GET/SET) would not have any effect on the management entity. I've added the following text in each case where the word irrelevant is use= d in the MIB module: "This object is irrelevant for the GBS-R ports - an attempt to read [or cha= nge] this object MUST be rejected (in case of SNMP with the error inconsistentValue).= " >T4. Although not mandatory it is considered good practice to include optio= nal UNITS clauses in objects that define performance counts.=20 [EB] Corrected. I've placed UNITS of "seconds" or "days" in the relevant pl= aces. The same was done to the GBOND-MIB (v09). >T5. In the DESCRIPTION clause of gBondAtmPortPerfCurr15MinTimeElapsed I fo= und:=20 > > This object partially maps to the TR-159 attribute > aGroupPerfCurr15MinTimeElapsed. > >What does 'partially maps' mean? [EB] The TR-159 PM attributes aGroupPerf* map to the corresponding gBondPor= tPm* objects of GBOND-MIB module, for example gBondPortPmCur15MinTimeElapse= maps to aGroupPerfCurr15MinTimeElapsed (see draft-ietf-adslmib-gbond-mib= -08.txt). TR-159 does not specify the additional dedicated PM attributes for the gBon= dAtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* objects = introduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB modules respe= ctively. However the definitions of these objects are identical to the gBon= dPortPm* objects of GBOND-MIB module. Therefore I use the term 'partial map= ping' to denote the fact that the mapping of gBondAtmPortPmCur15MinTimeElap= se (as well as gBondEthPortPmCur15MinTimeElapse and gBondTdimPortPmCur15Min= TimeElapse) to aGroupPerfCurr15MinTimeElapsed is not 1:1. >T6. In several DESCRIPTION clauses I found:=20 > > This object is inhibited during Unavailable Seconds (UAS).=20 > >Please explain what 'inhibited' means.=20 [EB] Inhibiting means that the accumulation performance counters is inhibit= ed so the counters actually freeze during the unavailability period. Added the following clarification paragraph at the end of "Performance Moni= toring" section: "Note that the accumulation of certain performance events for a monitored entity is inhibited (counting stops) during periods of service unavailability on that entity. The DESCRIPTION clause of performance monitoring counters in this MIB module specifies which of the counters are inhibited during periods of service unavailability." I've also used the Security Consideration boiler plate https://svn.tools.ie= tf.org/area/ops/trac/wiki/mib-security according to your T12 comment from AD review of draft-ietf-adslmib-gbond-mi= b-07.txt. >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www.ietf.org/mailman/listinfo/adslmib From dromasca@avaya.com Sun Feb 5 08:55:55 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4E21F8584 for ; Sun, 5 Feb 2012 08:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+3tH0gR0Wvr for ; Sun, 5 Feb 2012 08:55:54 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 703FE21F84A2 for ; Sun, 5 Feb 2012 08:55:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroAANyzLk+HCzI1/2dsb2JhbABEnkqQaoEFgXIBAQEBAwEBAQ8eCjQLDAQCAQgNBAQBAQsGDAsBBgEmHwkIAQEEEwgah2OdSJpvBItjLAYBg2YBgQaCdWMEmyKMYg X-IronPort-AV: E=Sophos;i="4.73,365,1325480400"; d="scan'208";a="289715133" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2012 11:55:46 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Feb 2012 11:41:42 -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: Sun, 5 Feb 2012 17:55:42 +0100 Message-ID: In-Reply-To: <4087887712E5C648B9F72BB9D912FD4601FD571DA44B@il-mail07.actelis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt Thread-Index: AcyeNcT+dePg4gidSueJRBXzS+MhQhDA6CDwALtJUAA= References: <4087887712E5C648B9F72BB9D912FD4601FD571DA44B@il-mail07.actelis.net> From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: bclaise@cisco.com, adslmib@ietf.org, Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 16:55:55 -0000 Hi Edward, I am copying Benoit Claise who will take over as OPS AD in March. Hopefully this set of documents will be done by then, but it's good to have him in the loop, so please add his name to further mails.=20 Thank you for the response and for the new version. All edits are fine with me, with the only observation that I would have preferred to have also 'partial map' explained some place. This is not however a blocking issue before IETF Last Call.=20 Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: Friday, February 03, 2012 2:05 AM > To: Romascanu, Dan (Dan) > Cc: Menachem Dodge; Moti Morgenstern; adslmib@ietf.org > Subject: RE: AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt >=20 > Dan, > Thank you for your comments. >=20 > Please see the clarifications/actions inline below (my comments are > marked with [EB], Moti Morgenstern's ones are with [MM]): >=20 > I have just submitted the next draft (05) of the gbond-atm-mib. >=20 > Regards, > -E. >=20 > >-----Original Message----- > >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > Behalf Of Romascanu, Dan (Dan) > >Sent: Tuesday, November 08, 2011 18:45 > >To: adslmib@ietf.org > >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-atm-mib- > 04.txt > > > >Hi, > > > >Please find below the AD review of > >draft-ietf-adslmib-gbond-atm-mib-04.txt. > >This document is in a good shape, but a new version is needed in order > to clarify and fix some of the issues raised in the review. > > > >The comments below are marked T (Technical) and E (Editorial) > > > >T1. In section 5.2: > > > > The agent SHOULD align the beginning of each interval to a fifteen > > minute boundary of a wall clock. Likewise, the beginning of each > one > > day intervals SHOULD be aligned with the start of a day. > > > >Where does this requirement come from? If the source is another > standard I suggest to provide it. What is the rationale? >What happens > if this requirement is not / cannot be met because for example the > agent does not have access to a 'wall clock'? >=20 > [EB] This particular wording is from the TR-159 section 4.2.5, which is > a normative reference for the document, I didn't see a reason to > explain this recommendation in more details than is provided in TR-159. > Note that this is a standard recommendation for the historical > performance monitoring (PM) based on 15-min & 1-day accumulation > periods, see for example ANSI T1.231 section 9.1.2.1 and 9.1.5.1. >=20 > However, since this is the second time you are asking about PM > intervals alignment with the wall clock boundaries I've decided to add > the following text to the GBOND-MIB draft 0.9 (unsubmitted yet), under > 5.2 "Performance Monitoring": >=20 > "The rationale behind it is to simplify collection and analysis of the > PM from multiple agents by a network management system (NMS) - each PM > interval can be 'time-stamped' using the interval index object, the > fact that 1-day interval starts at 00:00 and 15-min intervals are > aligned with 1/4 hour and the network-wide 'wall clock', typically > distributed via NTP or SNTP. If the agent does not have an access to > the 'wall clock', a local clock can be used. In this case, as well as > when coping with multiple time zones, the NMS would have to correlate > for the difference between the agent's local clock (available for > example via hrSystemDate object from HOST-RESOURCES-MIB [RFC2790]) and > the 'wall clock'." >=20 > I have also removed the bracketed text from the following sentence in > "Performance Monitoring" section, according to your T7 comment to the > draft-ietf-adslmib-gbond=3Dmib-07.txt: >=20 > OLD> > Counters are not reset when a GBS is reinitialized, but rather only > when the agent is reset or reinitialized (or under specific request > outside the scope of this MIB module). >=20 > NEW> > Counters are not reset when a GBS is reinitialized, but rather only > when the agent is reset or reinitialized. >=20 > >T2. The tables in this MIB module do not respect the naming convention > recommended in Annex C of RFC 4181: > > > > - The descriptor associated with a conceptual table should be of > the > > form xxxZzzTable; the descriptor associated with the > corresponding > > conceptual row should be of the form xxxZzzEntry; the name of the > > associated SEQUENCE type should be of the form XxxZzzEntry; and > the > > descriptors associated with the subordinate columnar objects > should > > be of the form xxxZzzSomeotherName. >=20 > [EB] Corrected. >=20 > >T3. In the DESCRIPTION clause of a couple of objects I found the > following: > > > > This object is read-only for the GBS-C and irrelevant for > > the GBS-R ports. > > > >What does 'irrelevant' mean? What should the agent do with these > objects for the GBS-R ports? >=20 > [EB] 'Irrelevant' means that the object in question does not have any > meaningful value in this particular case (e.g. for GBS-R port) and any > operation on it (GET/SET) would not have any effect on the management > entity. >=20 > I've added the following text in each case where the word irrelevant is > used in the MIB module: >=20 > "This object is irrelevant for the GBS-R ports - an attempt to read [or > change] this > object MUST be rejected (in case of SNMP with the error > inconsistentValue)." >=20 > >T4. Although not mandatory it is considered good practice to include > optional UNITS clauses in objects that define performance counts. >=20 > [EB] Corrected. I've placed UNITS of "seconds" or "days" in the > relevant places. The same was done to the GBOND-MIB (v09). >=20 > >T5. In the DESCRIPTION clause of gBondAtmPortPerfCurr15MinTimeElapsed > I found: > > > > This object partially maps to the TR-159 attribute > > aGroupPerfCurr15MinTimeElapsed. > > > >What does 'partially maps' mean? >=20 > [EB] The TR-159 PM attributes aGroupPerf* map to the corresponding > gBondPortPm* objects of GBOND-MIB module, for example > gBondPortPmCur15MinTimeElapse maps to aGroupPerfCurr15MinTimeElapsed > (see draft-ietf-adslmib-gbond-mib-08.txt). > TR-159 does not specify the additional dedicated PM attributes for the > gBondAtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* > objects introduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB > modules respectively. However the definitions of these objects are > identical to the gBondPortPm* objects of GBOND-MIB module. Therefore I > use the term 'partial mapping' to denote the fact that the mapping of > gBondAtmPortPmCur15MinTimeElapse (as well as > gBondEthPortPmCur15MinTimeElapse and gBondTdimPortPmCur15MinTimeElapse) > to aGroupPerfCurr15MinTimeElapsed is not 1:1. >=20 > >T6. In several DESCRIPTION clauses I found: > > > > This object is inhibited during Unavailable Seconds (UAS). > > > >Please explain what 'inhibited' means. >=20 > [EB] Inhibiting means that the accumulation performance counters is > inhibited so the counters actually freeze during the unavailability > period. >=20 > Added the following clarification paragraph at the end of "Performance > Monitoring" section: >=20 > "Note that the accumulation of certain performance events for a > monitored entity is inhibited (counting stops) during periods of > service unavailability on that entity. The DESCRIPTION > clause of performance monitoring counters in this MIB module > specifies which of the counters are inhibited during periods of > service unavailability." >=20 > I've also used the Security Consideration boiler plate > https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security > according to your T12 comment from AD review of draft-ietf-adslmib- > gbond-mib-07.txt. >=20 > >_______________________________________________ > >Adslmib mailing list > >Adslmib@ietf.org > >https://www.ietf.org/mailman/listinfo/adslmib From internet-drafts@ietf.org Thu Feb 9 11:42:32 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6474521F8484; Thu, 9 Feb 2012 11:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Bie+WN4P0XI; Thu, 9 Feb 2012 11:42:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBFE21F86C4; Thu, 9 Feb 2012 11:42:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209194208.2758.88203.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 11:42:08 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] I-D Action: draft-ietf-adslmib-gbond-tdim-mib-07.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:42:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : xDSL multi-pair bonding using Time-Division Inverse Mult= iplexing (G.Bond/TDIM) MIB Author(s) : Edward Beili Filename : draft-ietf-adslmib-gbond-tdim-mib-07.txt Pages : 54 Date : 2012-02-09 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-tdim-mib-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-tdim-mib-07.txt From EdwardB@actelis.com Thu Feb 9 11:44:19 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC821F86FA for ; Thu, 9 Feb 2012 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qa4hSWYhyoo for ; Thu, 9 Feb 2012 11:44:18 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 327B021F85E3 for ; Thu, 9 Feb 2012 11:44:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,391,1325455200"; d="scan'208";a="93532" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 09 Feb 2012 21:44:03 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Thu, 9 Feb 2012 21:44:03 +0200 From: Edward Beili To: "Romascanu, Dan (Dan)" Date: Thu, 9 Feb 2012 21:44:02 +0200 Thread-Topic: AD review of draft-ietf-adslmib-gbond-tdim-mib-06.txt Thread-Index: Acye+NFb9QcO5LgZQgGzoiPvzSMKzRF/xUXQ Message-ID: <4087887712E5C648B9F72BB9D912FD4601FD571DA833@il-mail07.actelis.net> References: In-Reply-To: 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" , Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-tdim-mib-06.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:44:19 -0000 Dan, Thank you for your comments. Please see the clarifications/actions inline below (my comments are marked = with [EB]): I have just submitted the next draft (07) of the gbond-tdim-mib. Regards, -E. >-----Original Message----- >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf= Of Romascanu, Dan (Dan) >Sent: Wednesday, November 09, 2011 18:01 >To: adslmib@ietf.org >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-tdim-mib-06.txt > >Hi, > >Please find below the AD review of >draft-ietf-adslmib-gbond-tdim-mib-06.txt. > >This document is in a good shape, but a new version is needed in order to = clarify and fix some of the issues raised in the review.=20 > >The comments below are marked T (Technical) and E (Editorial) > >T1. smicng in relaxed checking reports one compilation error:=20 > >C:\bw\smicng\work>smicng gbond-tdim.inc >E: f(gbond-tdim.mi2), (820,4) Row "gBondTdimServiceEntry" may not have col= umns with MAX-ACCESS of read-write if any column is read-create > >*** 1 error and 0 warnings in parsing [EB] Corrected - modified all columns of gBondTdimServiceEntry MAX-ACCESS o= f read-write to be read-create. >T2. In section 5.4:=20 > > The agent SHOULD align the beginning of each interval to a fifteen > minute boundary of a wall clock. Likewise, the beginning of each one > day intervals SHOULD be aligned with the start of a day. > >Where does this requirement come from? If the source is another standard I= suggest to provide it. What is the rationale? >What happens if this requi= rement is not / cannot be met because for example the agent does not have a= ccess to a 'wall clock'? [EB] This particular wording is from the TR-159 section 4.2.5, which is a n= ormative reference for the document, I didn't see a reason to explain this = recommendation in more details than is provided in TR-159. Note that this i= s a standard recommendation for the historical performance monitoring (PM) = based on 15-min & 1-day accumulation periods, see for example ANSI T1.231 = section 9.1.2.1 and 9.1.5.1. Note that the following text was added to the GBOND-MIB draft 0.9 (unsubmit= ted yet), under 5.2 "Performance Monitoring": "The rationale behind it is to simplify collection and analysis of the PM f= rom multiple agents by a network management system (NMS) - each PM interval= can be 'time-stamped' using the interval index object, the fact that 1-day= interval starts at 00:00 and 15-min intervals are aligned with 1/4 hour an= d the network-wide 'wall clock', typically distributed via NTP or SNTP. If = the agent does not have an access to the 'wall clock', a local clock can be= used. In this case, as well as when coping with multiple time zones, the N= MS would have to correlate for the difference between the agent's local clo= ck (available for example via hrSystemDate object from HOST-RESOURCES-MIB [= RFC2790]) and the 'wall clock'." I have also removed the bracketed text from the following sentence in "Perf= ormance Monitoring" section, according to your T7 comment to the draft-ietf= -adslmib-gbond=3Dmib-07.txt: OLD> Counters are not reset when a GBS is reinitialized, but rather only when = the agent is reset or reinitialized (or under specific request outside the= scope of this MIB module). NEW> Counters are not reset when a GBS is reinitialized, but rather only when = the agent is reset or reinitialized. >T3. In the DESCRIPTION of the GBondTdimServiceIndex TC:=20 > > The value for each Service MUST remain > constant at least from one re-initialization of the entity's > network management system to the next re-initialization. > >I think the term 'network management system' is not appropriate here, as i= t designates in many other documents the >management application. The entit= y cannot know whether a NMS exists, or how many NMSs manage the agent at a = given >moment, and when they re-initialize. What you mean (I think) is the = re-initialization of the management entity.=20 [EB] Corrected to 'local management subsystem' as in the description of the= ifCounterDiscontinuityTime (IF-MIB). >T4. I do not understand the MAY in the DESCRIPTION clause of the gBondTdim= ServiceUp and gBondTdimServiceDown notifications.=20 > > This notification MAY be send for the G.Bond/TDIM port, while > the port is Up, when the gBondTdimServiceOperState object has > left the Down state. > >Respectively > > This notification MAY be send for the G.Bond/TDIM port, while > the port is Up, when the gBondTdimServiceOperState object has > entered the Down state. > >If the notifications enable switches are up, then the notification must be= sent, so I understand. So why the MAY?=20 [EB] My thinking was that since the notifications maybe disabled by gBondTd= imPortConfSvcUpDownEnable object or rate limited (implementation specific t= hrottling, to prevent notification flooding in case gBondTdimServiceOperSta= te oscillates between Up and Down states) I would use the word MAY to denot= e the fact that these notifications are may not be sent in the event of gBo= ndTdimServiceOperState change. I have seen examples of such use in other IETF RFC documents, see section 2= .9 "Notifications" in RFC 4706 for example: " A linkDown notification MAY be generated whenever any of ES, SES, CRC Anomaly, LOS, LOF, or UAS event occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared." However, since MAY according to RFC2119 means that the item is _truly optio= nal_ which is clearly not the case here, I've changed the corresponding DES= CRIPTION as follows: OLD> This notification MAY be send for the G.Bond/TDIM port, while the port is Up, when the gBondTdimOperSvcState object has left[entered] the Down state. NEW>This notification is generated (unless disabled or dropped by the rate limiting mechanism), when the gBondTdimOperSvcState object has left[entered] the Down state, while the G.Bond/TDIM=20 port state (ifOperStatus of IF-MIB) is Up. I also added the following paragraph at the end of "Service Notifications" = section in the document: "Notifications SHOULD be rate-limited (throttled) such that there is= an implementation-specific gap between the generation of consecutive notifications of the same event. This mechanism prevents notificatio= n flooding in case gBondTdimServiceOperState oscillates between Up and Down states. When notifications are rate-limited, they are dropped and not queued for sending at a future time. This is intended to be a general rate-limiting statement for notifications that otherwise have no explicit rate-limiting assertions in this document." >T5. The tables in this MIB module do not respect the naming convention rec= ommended in Annex C of RFC 4181:=20 > > - The descriptor associated with a conceptual table should be of the > form xxxZzzTable; the descriptor associated with the corresponding > conceptual row should be of the form xxxZzzEntry; the name of the > associated SEQUENCE type should be of the form XxxZzzEntry; and the > descriptors associated with the subordinate columnar objects should > be of the form xxxZzzSomeotherName. [EB] Corrected. >T6. The DESCRIPTION clause of gBondTdimPortConfTable says that "Entries in= this table MUST be maintained in a persistent >manner". There is not need = to specify this again in the DESCRIPTION clauses of other objects in the sa= me table (e.g. >gBondTdimFecAdminState) [EB] Corrected. >T7. In the DESCRIPTION clause of gBondTdimFecMaxInterleaverDepth (and othe= r objects) I found the following:=20 > > This object partially maps to TR-159 attribute > aFECMaxInterleaverDepth. > >What does 'partially maps' mean?=20 [EB] Actually for gBondTdimPortCapFecMaxWordSize object with aFECWordSize TR-159 attribute, gBondTdimPortCapFecInterleaverTypeSupported with aFECInterleaverTypesSuppor= ted and gBondTdimPortCapFecMaxInterleaverDepth with aFECMaxInterleaverDep= th the mapping is one-to-one, so I removed the word partially from the relevan= t DESCRIPTION. The TR-159 PM attributes aGroupPerf* map to the corresponding gBondPortPm* = objects of GBOND-MIB module, for example gBondPortPmCur15MinTimeElapse maps= to aGroupPerfCurr15MinTimeElapsed (see draft-ietf-adslmib-gbond-mib-08.t= xt). TR-159 does not specify the additional dedicated PM attributes for the gBon= dAtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* objects = introduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB modules respe= ctively. However the definitions of these objects are identical to the gBon= dPortPm* objects of GBOND-MIB module. Therefore I use the term 'partial map= ping' to denote the fact that the mapping of gBondTdimPortPm* to aGroupPerf= * is not one-to-one. I've added the following text explaining this partial mapping in the end of= "Mapping of Broadband Forum TR-159 and ITU-T G.998.3 Managed Objects" sect= ion as follows: "Note that some of the mapping between the objects defined in TR-159 and the ones defined in this MIB module is not one-to-one, for example= , while TR-159 PM attributes aGroupPerf* map to the corresponding gBondPortPm* objects of the GBOND-MIB module, there are no dedicated PM attributes for the gBondTdimPortPm* and gBondTdimSvcPm* objects introduced in this MIB module. However, since their definition is identical to the definition of gBondPortPm* objects of the GBOND-MI= B module, we can map gBondTdimPortPm* and gBondTdimSvcPm* to the relevant aGroupPerf* attributes of TR-159 and use the term 'partial mapping' to denote the fact that this mapping is not one-to-o= ne." >T8. Although not mandatory it is considered good practice to include optio= nal UNITS clauses in objects that define >performance counts. [EB] Corrected. I've placed UNITS of "seconds" or "days" in the relevant pl= aces. >T9. In several DESCRIPTION clauses I found:=20 > > This object is inhibited during Unavailable Seconds (UAS).=20 > >Please explain what 'inhibited' means. [EB] Inhibiting means that the accumulation performance counters is inhibit= ed so the counters actually freeze during the unavailability period. Added the following clarification paragraph at the end of "Performance Moni= toring" section: "Note that the accumulation of certain performance events for a monitored entity is inhibited (counting stops) during periods of service unavailability on that entity. The DESCRIPTION clause of performance monitoring counters in this MIB module specifies which of the counters are inhibited during periods of service unavailability." >E1. Section 5.3:=20 > >s/listing the active services in order of their position in the G.Bond/lis= ting the active services in the order of their position in the G.Bond/ > >s/The actual list of services is provided via read-only gBondTdimOperServi= ceTable/ The actual list of services is provided via the read-only gBondTdi= mOperServiceTable/ [EB] Corrected. >E2. Please expand BTU-C at first occurrence.=20 [EB] Corrected. >E3. There is no need to capitalize the MAYs in the Security Consideration = section when describing the vulnerabilities of the >objects. These are no r= equirements placed on the agent.=20 [EB] Corrected. I've also used the Security Consideration boiler plate http= s://svn.tools.ietf.org/area/ops/trac/wiki/mib-security according to your T12 comment from AD review of draft-ietf-adslmib-gbond-mi= b-07.txt. >Thanks and Regards, > >Dan > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www.ietf.org/mailman/listinfo/adslmib From internet-drafts@ietf.org Mon Feb 13 05:23:38 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB6B21F8573; Mon, 13 Feb 2012 05:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU0F7mPkqy9H; Mon, 13 Feb 2012 05:23:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F7021F8581; Mon, 13 Feb 2012 05:23:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120213132337.29598.42046.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 05:23:37 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] I-D Action: draft-ietf-adslmib-gbond-eth-mib-05.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:23:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet)= MIB Author(s) : Edward Beili Moti Morgenstern Filename : draft-ietf-adslmib-gbond-eth-mib-05.txt Pages : 53 Date : 2012-02-13 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-eth-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-eth-mib-05.txt From EdwardB@actelis.com Mon Feb 13 05:25:22 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721F221F85AA for ; Mon, 13 Feb 2012 05:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBv5jRKxDxiY for ; Mon, 13 Feb 2012 05:25:21 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 012E921F85B9 for ; Mon, 13 Feb 2012 05:25:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,412,1325455200"; d="scan'208";a="103400" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 13 Feb 2012 15:25:16 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Mon, 13 Feb 2012 15:25:16 +0200 From: Edward Beili To: "Romascanu, Dan (Dan)" Date: Mon, 13 Feb 2012 15:25:15 +0200 Thread-Topic: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Thread-Index: AcyeJnmD2elwHemxQsGKVQd5DXQBsBJ85XJA Message-ID: <4087887712E5C648B9F72BB9D912FD4601FD571DA9A2@il-mail07.actelis.net> References: In-Reply-To: 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" , Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:25:22 -0000 Dan, Thank you for your comments. Please see the clarifications/actions inline below (my comments are marked = with [EB): I have just submitted the next draft (05) of the gbond-eth-mib. Regards, -E. >-----Original Message----- >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf= Of Romascanu, Dan (Dan) >Sent: Tuesday, November 08, 2011 16:56 >To: adslmib@ietf.org >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt > >Hi, > >Please find below the AD review of >draft-ietf-adslmib-gbond-eth-mib-04.txt. >This document is in a good shape, but a new version is needed in order to = clarify and fix some of the issues raised in the review.=20 > >The comments below are marked T (Technical) and E (Editorial) > >T1. Running smicng in strict mode results in one error and one warning:=20 > >C:\bw\smicng\work>smicng gbond-eth.inc >E: f(gbond-eth.mi2), (260,15) Default value for "gBondEthAdminCp" must be = a name and not a number >W: f(gbond-eth.mi2), (1825,20) For "gBondEthTcTypesSupported", syntax is i= dentical > >*** 1 error and 1 warning in parsing [EB] I corrected the error with the default value, using a name instead of = a number. As for the warning I don't think anything needs to be corrected, since none= of the possible values (BIT positions) of gBondEthPortCapTcTypesSupported = is preferred, I must list all of them in the MODULE-COMPLIANCE section, rep= eating the same SYNTAX, as in the object's definition. >T2. In section 5.2:=20 > > The agent SHOULD align the beginning of each interval to a fifteen > minute boundary of a wall clock. Likewise, the beginning of each one > day intervals SHOULD be aligned with the start of a day. > >Where does this requirement come from? If the source is another standard I= suggest to provide it. >What is the rationale? What happens if this requirement is not / cannot be= met because >for example the agent does not have access to a 'wall clock'?=20 [EB] This particular wording is from the TR-159 section 4.2.5, which is a n= ormative reference for the document, I didn't see a reason to explain this = recommendation in more details than is provided in TR-159. Note that this i= s a standard recommendation for the historical performance monitoring (PM) = based on 15-min & 1-day accumulation periods, see for example ANSI T1.231 = section 9.1.2.1 and 9.1.5.1. I've added the following text to the GBOND-MIB draft 0.9 (unsubmitted yet),= under 5.2 "Performance Monitoring": "The rationale behind it is to simplify collection and analysis of the PM f= rom multiple agents by a network management system (NMS) - each PM interval= can be 'time-stamped' using the interval index object, the fact that 1-day= interval starts at 00:00 and 15-min intervals are aligned with 1/4 hour an= d the network-wide 'wall clock', typically distributed via NTP or SNTP. If = the agent does not have an access to the 'wall clock', a local clock can be= used. In this case, as well as when coping with multiple time zones, the N= MS would have to correlate for the difference between the agent's local clo= ck (available for example via hrSystemDate object from HOST-RESOURCES-MIB [= RFC2790]) and the 'wall clock'." I have also removed the bracketed text from the following sentence in "Perf= ormance Monitoring" section, according to your T7 comment to the draft-ietf= -adslmib-gbond=3Dmib-07.txt: OLD> Counters are not reset when a GBS is reinitialized, but rather only when = the agent is reset or reinitialized (or under specific request outside the= scope of this MIB module). NEW> Counters are not reset when a GBS is reinitialized, but rather only when = the agent is reset or reinitialized. >T3. In the DESCRIPTION clause of gBondEthTcAdminType the following shows u= p:=20 > > Changing gBondEthTcAdminType is a traffic disruptive > operation and as such SHALL be done when the link is Down. > Attempts to change this object SHALL be rejected if the link > is Up or Initializing. =20 > >It would be good to point specifically what object needs to be examined in= order to determine the state of the link (Down, Up or Initializing).=20 > >Similar text appears in the DESCRIPTION clause of other MIB objects.=20 [EB] Modified the description clause for gBondEthPortConf* objects as follo= ws: OLD> ... SHALL be done when the link is Down. NEW> ... SHALL be done when the link (GBS) is administratively 'down', as indicated by the ifAdminStatus object in IF-MIB. Attempts to change this object SHALL be rejected (with the error inconsistentValue) if the link is Up or Initializing. I also added two new values to the gBondPortStatFltStatus object in GBOND-M= IB: init(5) - The link is Initializing, as a result of ifAdminStatus being set to 'up' for a particular BCE or a GBS to which the BCE is connected. ready(6) - at least one BCE in the aggregation group is detecting handshake tones. >T4. There is no need to specify for individual objects that 'This object M= UST be maintained in a persistent manner.' If a generic declaration >was al= ready made for the whole table. For example for the gBondEthTcAdminType obj= ect in the gBondEthPortConfTable.=20 [EB] Corrected. >T5. Objects in the MIB tables do not respect the naming convention for a c= ommon prefix of the table name and of the objects in the table. >The first = such example is gBondEthPortConfTable with gBondEthTcAdminType and gBondEth= AdminCp as columns. There are more. Please >check this and make sure that t= he recommendations in Annex C of RFC 4181 for the naming of objects in conc= eptual tables are being followed.=20 [EB] Corrected. >T6. It would be useful to provide UNIX clauses for the counter objects. >The first example is gBondEthRxErrors, but there are more.=20 [EB] I assume you meant UNITS clauses - I've provided them where appropriat= e. >T7. It would be good to explain the semantics of 'fragments' in this docum= ent which is different from what is customary in the IP world, maybe provid= e a reference for the definition of the term (from TE-159?) [EB] The fragment in the bonding context was originally defined in the IEEE= 802.3ah (section 61.1.4), now part of 802.3. All the other documents (ITU-= T G.998.2 and BBF TR-159) reference 802.3 in this respect. Section 4.1.2 "= xDSL Bonding" in the draft-ietf-adslmib-gbond-mib-08.txt mentions Ethernet = frame fragmentation and reassembly in the bonding context. I've changed the 1st occurrence of 'fragment' in the GBOND-ETH-MIB to 'Ethe= rnet frame fragment' and also replaced the reference to the gamma-interface= (defined in IEEE 802.3 section 61.1.4) with a more generic bonding functio= n interface. >T8. In the DESCRIPTION clause of gBondEthPortPerf15MinIntervalIndex I see: >'This object partially maps to the TR-159 attribute aGroupPerf15MinInterva= lNumber'. >What does 'partially maps' mean? [EB] The TR-159 PM attributes aGroupPerf* map to the corresponding gBondPor= tPm* objects of GBOND-MIB module, for example gBondPortPmCur15MinTimeElapse= maps to aGroupPerfCurr15MinTimeElapsed (see draft-ietf-adslmib-gbond-mib= -08.txt). TR-159 does not specify the additional dedicated PM attributes for the gBon= dAtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* objects = introduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB modules respe= ctively. However the definitions of these objects are identical to the gBon= dPortPm* objects of GBOND-MIB module. Therefore I use the term 'partial map= ping' to denote the fact that the mapping of gBondEthPortPm* to aGroupPerf*= is not one-to-one. I've added the following text explaining this partial mapping in the end of= "Mapping of Broadband Forum TR-159" section as follows: "Note that some of the mapping between the objects defined in TR-159 and the ones defined in this MIB module is not one-to-one, for example= , while TR-159 PM attributes aGroupPerf* map to the corresponding gBondPortPm* objects of the GBOND-MIB module, there are no dedicated PM attributes for the gBondEthPortPm* objects introduced in this MIB m= odule. However, since their definition is identical to the definition of gBon= dPortPm*=20 objects of the GBOND-MIB module, we can map gBondEthPortPm* to the relevant aGroupPerf* attributes of TR-159 and use the term 'partial mapping' to denote the fact that this mapping is not one-to-o= ne." >E1. The acronym Generic Bonded Sub-layer (GBS) is expanded much later than= the first occurrence.=20 [EB] Corrected. >E2. At some point in time the WG will be shut down, and the reference [ADS= LMIB] will no longer be available. > Acknowledging the contributions of the WG participants is sufficient, no = reference is necessary.=20 [EB] I've checked a number of MIB documents, in particular all *DSL-LINE-MI= B documents reference the ADSLMIB workgroup charter in the CONTACT-INFO, li= kewise the documents produced by the HUBMIB group (shut down already) refer= ence its charter as well. As you can see the link to the HUBMIB charter is = still available: http://www.ietf.org/html.charters/hubmib-charter.html I see no reason why the IETF would change its policy towards the concluded = work groups with respect to their published charters. >E3. The following phrase which appears in the DESCRIPTION clause of severa= l counts object should be rephrased or at least explained at first >occurre= nce, as this terminology is not clear for the non-initiated: ' >This object is inhibited during Unavailable Seconds (UAS)' [EB] Inhibiting means that the accumulation performance counters is inhibit= ed so the counters actually freeze during the unavailability period. Added the following clarification paragraph at the end of "Performance Moni= toring" section: "Note that the accumulation of certain performance events for a monitored entity is inhibited (counting stops) during periods of service unavailability on that entity. The DESCRIPTION clause of performance monitoring counters in this MIB module specifies which of the counters are inhibited during periods of service unavailability." I've also used the Security Consideration boiler plate https://svn.tools.ie= tf.org/area/ops/trac/wiki/mib-security according to your T12 comment from AD review of draft-ietf-adslmib-gbond-mi= b-07.txt. >Dan > >_______________________________________________ >Adslmib mailing list >Adslmib@ietf.org >https://www.ietf.org/mailman/listinfo/adslmib From Menachem.Dodge@ecitele.com Mon Feb 13 05:50:51 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50821F857F for ; Mon, 13 Feb 2012 05:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.203 X-Spam-Level: X-Spam-Status: No, score=-104.203 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvtQLjZpTKza for ; Mon, 13 Feb 2012 05:50:48 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 9BD7121F8592 for ; Mon, 13 Feb 2012 05:50:47 -0800 (PST) X-Env-Sender: Menachem.Dodge@ecitele.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1329140968!52680444!24 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.5.5; banners=-,-,- Received: (qmail 7739 invoked from network); 13 Feb 2012 13:49:54 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-11.tower-27.messagelabs.com with SMTP; 13 Feb 2012 13:49:54 -0000 X-AuditID: 93eaf2e7-b7fb46d000005f52-ca-4f3920f175a1 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id CF.1E.24402.1F0293F4; Mon, 13 Feb 2012 16:40:49 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 13 Feb 2012 15:50:16 +0200 From: Menachem Dodge To: Edward Beili , "Romascanu, Dan (Dan)" Date: Mon, 13 Feb 2012 15:50:16 +0200 Thread-Topic: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Thread-Index: AcyeJnmD2elwHemxQsGKVQd5DXQBsBJ85XJAAI7Y2xA= Message-ID: <283DD79798619346BF9B17D7B5035A1901601DDEBAF9@ILPTMAIL02.ecitele.com> References: <4087887712E5C648B9F72BB9D912FD4601FD571DA9A2@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4601FD571DA9A2@il-mail07.actelis.net> 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 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfWwLYRzO27t2t9rJrev03QiX85H46LIaSTe6jEhWCTrBPzLs2r7ao702 vRuKsEZiIUFtItTXxMI+JBMfIaFiixQjzMcfM2ySzcdqiCGbj63udszE/fX83ud5fs/7Xn4/ AtN91GQSHC+iAM96GI0Wr4z3fjF+onNt2bdu5JjbY/fV5q/f+tXmO+Xvkwow69UXMY21sfZo krW6+puqCFtZBuayPO8TWRHRTiQ4LExRgNvAOoIMzTktjImh/R7WgbyIFy0M6/cj3snka+n/ vrmSjONpxDt8To53WZiFy2xGs3l2rtHE5E+ZaMqZo13u5gQaGb0s56G9SBBYF6Klk5KLmLu2 sgP3X1q5qaqjU1MGuq27QTIBqVkwlKhXK3gMbGlv0OwGWkJHRQHsPz6AK8UBAG+/2iEVBKGh TLCrYpRs0FMr4MMf8SEzRhXDnkOtGhnj1GT4tvx2kozTqHnw2eAptaKfD6P7OpIUnAfDu24M YZJaCh+23PudFQHwWFslJhPJEnGz8eJQUyDdrq/5rEoJM8C2rhMq5dYUrL72AFNwOuzuHFQr +nT4vLwBKPoZsOpqr0bB0+Hpk+8wJTgV3jnchSveDNhY04qHgSEyIiIywh4ZYY+MsFcBvA6k cx6/aPe6sk1ZyMGJyIOyHD7veaCMy5sr4PuJSU2AIgCTQpaEzDadmt0gBL1NIINQMelkX1qu TTfa7nMG3azgXhMo9SChCUACY/RkVrEkJ51scDMK+P5QZuk378cyRzl80mDy4pqc7Ox/CsZA vnL0LNZRLmnq1iPkR4E/1nEEwUByo15KTA0gF9q0lvOIf2kVkSwnp0jJe2UNKfhZr8C5FL4Z GInYy/oWoMN5H48yDWSFLKJkkbuUH+4j78n2RCIRBwbpzWnkKlmVIm3RcKe4FKKSQi7flZ8n SNsxTGWWgUsN1MboogtbK81R+0E4zWrpOb6usDijsO761DO4++bok0WXny44Vfr4ZyIcQnt6 QwOrKpYQfu2+Qn1ByBacsLT4PRgfTaUHH71ojaYt2WbaXpAfe3P3yMdzn8P2nW0xe1T3vLFj aol+bJyKiudfL/zQ/GT169nhPTO7j23Js8+qYXDBzZqmYQGB/QUMWiaVAgQAAA== Cc: "adslmib@ietf.org" , Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:50:51 -0000 Hi Edward, Thank you for your great work. All the drafts have now been updated. Dan please check whether the documents can be forwarded to IETF Last Call. Thank you kindly. Menachem -----Original Message----- From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf O= f Edward Beili Sent: Monday, February 13, 2012 3:25 PM To: Romascanu, Dan (Dan) Cc: adslmib@ietf.org; Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Dan, Thank you for your comments. Please see the clarifications/actions inline below (my comments are marked w= ith [EB): I have just submitted the next draft (05) of the gbond-eth-mib. Regards, -E. >-----Original Message----- >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On >Behalf Of Romascanu, Dan (Dan) >Sent: Tuesday, November 08, 2011 16:56 >To: adslmib@ietf.org >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt > >Hi, > >Please find below the AD review of >draft-ietf-adslmib-gbond-eth-mib-04.txt. >This document is in a good shape, but a new version is needed in order to c= larify and fix some of the issues raised in the review. > >The comments below are marked T (Technical) and E (Editorial) > >T1. Running smicng in strict mode results in one error and one warning: > >C:\bw\smicng\work>smicng gbond-eth.inc >E: f(gbond-eth.mi2), (260,15) Default value for "gBondEthAdminCp" must >be a name and not a number >W: f(gbond-eth.mi2), (1825,20) For "gBondEthTcTypesSupported", syntax >is identical > >*** 1 error and 1 warning in parsing [EB] I corrected the error with the default value, using a name instead of a= number. As for the warning I don't think anything needs to be corrected, since none= of the possible values (BIT positions) of gBondEthPortCapTcTypesSupported i= s preferred, I must list all of them in the MODULE-COMPLIANCE section, repea= ting the same SYNTAX, as in the object's definition. >T2. In section 5.2: > > The agent SHOULD align the beginning of each interval to a fifteen > minute boundary of a wall clock. Likewise, the beginning of each one > day intervals SHOULD be aligned with the start of a day. > >Where does this requirement come from? If the source is another standard I= suggest to provide it. >What is the rationale? What happens if this requirement is not / cannot >be met because for example the agent does not have access to a 'wall clock'= ? [EB] This particular wording is from the TR-159 section 4.2.5, which is a no= rmative reference for the document, I didn't see a reason to explain this re= commendation in more details than is provided in TR-159. Note that this is a= standard recommendation for the historical performance monitoring (PM) base= d on 15-min & 1-day accumulation periods, see for example ANSI T1.231 secti= on 9.1.2.1 and 9.1.5.1. I've added the following text to the GBOND-MIB draft 0.9 (unsubmitted yet),= under 5.2 "Performance Monitoring": "The rationale behind it is to simplify collection and analysis of the PM fr= om multiple agents by a network management system (NMS) - each PM interval c= an be 'time-stamped' using the interval index object, the fact that 1-day in= terval starts at 00:00 and 15-min intervals are aligned with 1/4 hour and th= e network-wide 'wall clock', typically distributed via NTP or SNTP. If the a= gent does not have an access to the 'wall clock', a local clock can be used.= In this case, as well as when coping with multiple time zones, the NMS woul= d have to correlate for the difference between the agent's local clock (avai= lable for example via hrSystemDate object from HOST-RESOURCES-MIB [RFC2790])= and the 'wall clock'." I have also removed the bracketed text from the following sentence in "Perfo= rmance Monitoring" section, according to your T7 comment to the draft-ietf-a= dslmib-gbond=3Dmib-07.txt: OLD> Counters are not reset when a GBS is reinitialized, but rather only when t= he agent is reset or reinitialized (or under specific request outside the s= cope of this MIB module). NEW> Counters are not reset when a GBS is reinitialized, but rather only when t= he agent is reset or reinitialized. >T3. In the DESCRIPTION clause of gBondEthTcAdminType the following shows up= : > > Changing gBondEthTcAdminType is a traffic disruptive > operation and as such SHALL be done when the link is Down. > Attempts to change this object SHALL be rejected if the link > is Up or Initializing. > >It would be good to point specifically what object needs to be examined in= order to determine the state of the link (Down, Up or Initializing). > >Similar text appears in the DESCRIPTION clause of other MIB objects. [EB] Modified the description clause for gBondEthPortConf* objects as follow= s: OLD> ... SHALL be done when the link is Down. NEW> ... SHALL be done when the link (GBS) is administratively 'down', as indicated by the ifAdminStatus object in IF-MIB. Attempts to change this object SHALL be rejected (with the error inconsistentValue) if the link is Up or Initializing. I also added two new values to the gBondPortStatFltStatus object in GBOND-MI= B: init(5) - The link is Initializing, as a result of ifAdminStatus being set to 'up' for a particular BCE or a GBS to which the BCE is connected. ready(6) - at least one BCE in the aggregation group is detecting handshake tones. >T4. There is no need to specify for individual objects that 'This object MU= ST be maintained in a persistent manner.' If a generic declaration >was alre= ady made for the whole table. For example for the gBondEthTcAdminType object= in the gBondEthPortConfTable. [EB] Corrected. >T5. Objects in the MIB tables do not respect the naming convention for a co= mmon prefix of the table name and of the objects in the table. >The first su= ch example is gBondEthPortConfTable with gBondEthTcAdminType and gBondEthAdm= inCp as columns. There are more. Please >check this and make sure that the r= ecommendations in Annex C of RFC 4181 for the naming of objects in conceptua= l tables are being followed. [EB] Corrected. >T6. It would be useful to provide UNIX clauses for the counter objects. >The first example is gBondEthRxErrors, but there are more. [EB] I assume you meant UNITS clauses - I've provided them where appropriate= . >T7. It would be good to explain the semantics of 'fragments' in this >document which is different from what is customary in the IP world, >maybe provide a reference for the definition of the term (from TE-159?) [EB] The fragment in the bonding context was originally defined in the IEEE= 802.3ah (section 61.1.4), now part of 802.3. All the other documents (ITU-T= G.998.2 and BBF TR-159) reference 802.3 in this respect. Section 4.1.2 "xD= SL Bonding" in the draft-ietf-adslmib-gbond-mib-08.txt mentions Ethernet fra= me fragmentation and reassembly in the bonding context. I've changed the 1st occurrence of 'fragment' in the GBOND-ETH-MIB to 'Ether= net frame fragment' and also replaced the reference to the gamma-interface (= defined in IEEE 802.3 section 61.1.4) with a more generic bonding function i= nterface. >T8. In the DESCRIPTION clause of gBondEthPortPerf15MinIntervalIndex I see: >'This object partially maps to the TR-159 attribute aGroupPerf15MinInterval= Number'. >What does 'partially maps' mean? [EB] The TR-159 PM attributes aGroupPerf* map to the corresponding gBondPort= Pm* objects of GBOND-MIB module, for example gBondPortPmCur15MinTimeElapse m= aps to aGroupPerfCurr15MinTimeElapsed (see draft-ietf-adslmib-gbond-mib-08= .txt). TR-159 does not specify the additional dedicated PM attributes for the gBond= AtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* objects in= troduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB modules respecti= vely. However the definitions of these objects are identical to the gBondPor= tPm* objects of GBOND-MIB module. Therefore I use the term 'partial mapping'= to denote the fact that the mapping of gBondEthPortPm* to aGroupPerf* is no= t one-to-one. I've added the following text explaining this partial mapping in the end of= "Mapping of Broadband Forum TR-159" section as follows: "Note that some of the mapping between the objects defined in TR-159 and the ones defined in this MIB module is not one-to-one, for example, while TR-159 PM attributes aGroupPerf* map to the corresponding gBondPortPm* objects of the GBOND-MIB module, there are no dedicated PM attributes for the gBondEthPortPm* objects introduced in this MIB mo= dule. However, since their definition is identical to the definition of gBond= PortPm* objects of the GBOND-MIB module, we can map gBondEthPortPm* to the relevant aGroupPerf* attributes of TR-159 and use the term 'partial mapping' to denote the fact that this mapping is not one-to-on= e." >E1. The acronym Generic Bonded Sub-layer (GBS) is expanded much later than= the first occurrence. [EB] Corrected. >E2. At some point in time the WG will be shut down, and the reference [ADSL= MIB] will no longer be available. > Acknowledging the contributions of the WG participants is sufficient, no r= eference is necessary. [EB] I've checked a number of MIB documents, in particular all *DSL-LINE-MIB= documents reference the ADSLMIB workgroup charter in the CONTACT-INFO, like= wise the documents produced by the HUBMIB group (shut down already) referenc= e its charter as well. As you can see the link to the HUBMIB charter is stil= l available: http://www.ietf.org/html.charters/hubmib-charter.html I see no reason why the IETF would change its policy towards the concluded w= ork groups with respect to their published charters. >E3. The following phrase which appears in the DESCRIPTION clause of several= counts object should be rephrased or at least explained at first >occurrenc= e, as this terminology is not clear for the non-initiated: ' >This object is inhibited during Unavailable Seconds (UAS)' [EB] Inhibiting means that the accumulation performance counters is inhibite= d so the counters actually freeze during the unavailability period. Added the following clarification paragraph at the end of "Performance Monit= oring" section: "Note that the accumulation of certain performance events for a monitored entity is inhibited (counting stops) during periods of service unavailability on that entity. The DESCRIPTION clause of performance monitoring counters in this MIB module specifies which of the counters are inhibited during periods of service unavailability." I've also used the Security Consideration boiler plate https://svn.tools.iet= f.org/area/ops/trac/wiki/mib-security according to your T12 comment from AD review of draft-ietf-adslmib-gbond-mib= -07.txt. >Dan > >_______________________________________________ >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 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From internet-drafts@ietf.org Mon Feb 13 06:16:35 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C10221F85A0; Mon, 13 Feb 2012 06:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL4lUnDjjTlx; Mon, 13 Feb 2012 06:16:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722A421F8594; Mon, 13 Feb 2012 06:16:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120213141634.13347.21629.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 06:16:34 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] I-D Action: draft-ietf-adslmib-gbond-mib-09.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:16:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ADSL MIB Working Group of the IETF. Title : xDSL multi-pair bonding (G.Bond) MIB Author(s) : Edward Beili Moti Morgenstern Filename : draft-ietf-adslmib-gbond-mib-09.txt Pages : 69 Date : 2012-02-13 This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-mib-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-adslmib-gbond-mib-09.txt From EdwardB@actelis.com Mon Feb 13 06:18:10 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78721F856A for ; Mon, 13 Feb 2012 06:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUPm3xVltu99 for ; Mon, 13 Feb 2012 06:18:09 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3A521F8569 for ; Mon, 13 Feb 2012 06:18:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,412,1325455200"; d="scan'208";a="103680" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 13 Feb 2012 16:18:05 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Mon, 13 Feb 2012 16:18:05 +0200 From: Edward Beili To: Menachem Dodge , "Romascanu, Dan (Dan)" Date: Mon, 13 Feb 2012 16:18:04 +0200 Thread-Topic: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Thread-Index: AcyeJnmD2elwHemxQsGKVQd5DXQBsBJ85XJAAI7Y2xAAAIM00A== Message-ID: <4087887712E5C648B9F72BB9D912FD4601FD571DA9BA@il-mail07.actelis.net> References: <4087887712E5C648B9F72BB9D912FD4601FD571DA9A2@il-mail07.actelis.net> <283DD79798619346BF9B17D7B5035A1901601DDEBAF9@ILPTMAIL02.ecitele.com> In-Reply-To: <283DD79798619346BF9B17D7B5035A1901601DDEBAF9@ILPTMAIL02.ecitele.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adslmib@ietf.org" , Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:18:10 -0000 Menachem, Dan, I have just submitted the next draft (09) of the gbond-mib. The main changes are: 1. Adding the rationale for the PM alignment in section 5.2 "Performance Mo= nitoring": "The rationale behind it is to simplify collection and analysis of the PM f= rom multiple agents by a network management system (NMS) - each PM interval= can be 'time-stamped' using the interval index object, the fact that 1-day= interval starts at 00:00 and 15-min intervals are aligned with 1/4 hour an= d the network-wide 'wall clock', typically distributed via NTP or SNTP. If = the agent does not have an access to the 'wall clock', a local clock can be= used. In this case, as well as when coping with multiple time zones, the N= MS would have to correlate for the difference between the agent's local clo= ck (available for example via hrSystemDate object from HOST-RESOURCES-MIB [= RFC2790]) and the 'wall clock'." 2. Adding two new values for the gBondPortStatFltStatus object to provide a= dditional G.Bond-specific GBS operational states, extending the ifOperStatu= s from IF-MIB (note that EFM-CU-MIB relied on the ifMauMediaAvailable objec= t from MAU-MIB for those additional states, since G.Bond ports, especially = 998.1 and 998.3, are not EtherLike interfaces, we must provide those states= ): init(5) - The link is Initializing, as a result of ifAdminStatus being set to 'up' for a particular BCE or a GBS to which the BCE is connected. ready(6) - at least one BCE in the aggregation group is detecting handshake tones. 3. Modified the description clause for gBondPortConf* objects as follows: OLD> ... SHALL be done when the link is Down. NEW> ... SHALL be done when the link (GBS) is administratively 'down', as indicated by the ifAdminStatus object in IF-MIB. Regards, -E. -----Original Message----- From: Menachem Dodge [mailto:Menachem.Dodge@ecitele.com]=20 Sent: Monday, February 13, 2012 15:50 To: Edward Beili; Romascanu, Dan (Dan) Cc: adslmib@ietf.org; Moti Morgenstern Subject: RE: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Hi Edward, Thank you for your great work. All the drafts have now been updated. Dan please check whether the documents can be forwarded to IETF Last Call. Thank you kindly. Menachem -----Original Message----- From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On Behalf = Of Edward Beili Sent: Monday, February 13, 2012 3:25 PM To: Romascanu, Dan (Dan) Cc: adslmib@ietf.org; Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Dan, Thank you for your comments. Please see the clarifications/actions inline below (my comments are marked = with [EB): I have just submitted the next draft (05) of the gbond-eth-mib. Regards, -E. >-----Original Message----- >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On=20 >Behalf Of Romascanu, Dan (Dan) >Sent: Tuesday, November 08, 2011 16:56 >To: adslmib@ietf.org >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt > >Hi, > >Please find below the AD review of >draft-ietf-adslmib-gbond-eth-mib-04.txt. >This document is in a good shape, but a new version is needed in order to = clarify and fix some of the issues raised in the review.=20 > >The comments below are marked T (Technical) and E (Editorial) > >T1. Running smicng in strict mode results in one error and one warning:=20 > >C:\bw\smicng\work>smicng gbond-eth.inc >E: f(gbond-eth.mi2), (260,15) Default value for "gBondEthAdminCp" must=20 >be a name and not a number >W: f(gbond-eth.mi2), (1825,20) For "gBondEthTcTypesSupported", syntax=20 >is identical > >*** 1 error and 1 warning in parsing [EB] I corrected the error with the default value, using a name instead of = a number. As for the warning I don't think anything needs to be corrected, since none= of the possible values (BIT positions) of gBondEthPortCapTcTypesSupported = is preferred, I must list all of them in the MODULE-COMPLIANCE section, rep= eating the same SYNTAX, as in the object's definition. >T2. In section 5.2:=20 > > The agent SHOULD align the beginning of each interval to a fifteen > minute boundary of a wall clock. Likewise, the beginning of each one > day intervals SHOULD be aligned with the start of a day. > >Where does this requirement come from? If the source is another standard I= suggest to provide it. >What is the rationale? What happens if this requirement is not / cannot=20 >be met because for example the agent does not have access to a 'wall clock= '? [EB] This particular wording is from the TR-159 section 4.2.5, which is a n= ormative reference for the document, I didn't see a reason to explain this = recommendation in more details than is provided in TR-159. Note that this i= s a standard recommendation for the historical performance monitoring (PM) = based on 15-min & 1-day accumulation periods, see for example ANSI T1.231 = section 9.1.2.1 and 9.1.5.1. I've added the following text to the GBOND-MIB draft 0.9 (unsubmitted yet),= under 5.2 "Performance Monitoring": "The rationale behind it is to simplify collection and analysis of the PM f= rom multiple agents by a network management system (NMS) - each PM interval= can be 'time-stamped' using the interval index object, the fact that 1-day= interval starts at 00:00 and 15-min intervals are aligned with 1/4 hour an= d the network-wide 'wall clock', typically distributed via NTP or SNTP. If = the agent does not have an access to the 'wall clock', a local clock can be= used. In this case, as well as when coping with multiple time zones, the N= MS would have to correlate for the difference between the agent's local clo= ck (available for example via hrSystemDate object from HOST-RESOURCES-MIB [= RFC2790]) and the 'wall clock'." I have also removed the bracketed text from the following sentence in "Perf= ormance Monitoring" section, according to your T7 comment to the draft-ietf= -adslmib-gbond=3Dmib-07.txt: OLD> Counters are not reset when a GBS is reinitialized, but rather only when = the agent is reset or reinitialized (or under specific request outside the= scope of this MIB module). NEW> Counters are not reset when a GBS is reinitialized, but rather only when = the agent is reset or reinitialized. >T3. In the DESCRIPTION clause of gBondEthTcAdminType the following shows u= p:=20 > > Changing gBondEthTcAdminType is a traffic disruptive > operation and as such SHALL be done when the link is Down. > Attempts to change this object SHALL be rejected if the link > is Up or Initializing. =20 > >It would be good to point specifically what object needs to be examined in= order to determine the state of the link (Down, Up or Initializing).=20 > >Similar text appears in the DESCRIPTION clause of other MIB objects.=20 [EB] Modified the description clause for gBondEthPortConf* objects as follo= ws: OLD> ... SHALL be done when the link is Down. NEW> ... SHALL be done when the link (GBS) is administratively 'down', as indicated by the ifAdminStatus object in IF-MIB. Attempts to change this object SHALL be rejected (with the error inconsistentValue) if the link is Up or Initializing. I also added two new values to the gBondPortStatFltStatus object in GBOND-M= IB: init(5) - The link is Initializing, as a result of ifAdminStatus being set to 'up' for a particular BCE or a GBS to which the BCE is connected. ready(6) - at least one BCE in the aggregation group is detecting handshake tones. >T4. There is no need to specify for individual objects that 'This object M= UST be maintained in a persistent manner.' If a generic declaration >was al= ready made for the whole table. For example for the gBondEthTcAdminType obj= ect in the gBondEthPortConfTable.=20 [EB] Corrected. >T5. Objects in the MIB tables do not respect the naming convention for a c= ommon prefix of the table name and of the objects in the table. >The first = such example is gBondEthPortConfTable with gBondEthTcAdminType and gBondEth= AdminCp as columns. There are more. Please >check this and make sure that t= he recommendations in Annex C of RFC 4181 for the naming of objects in conc= eptual tables are being followed.=20 [EB] Corrected. >T6. It would be useful to provide UNIX clauses for the counter objects. >The first example is gBondEthRxErrors, but there are more.=20 [EB] I assume you meant UNITS clauses - I've provided them where appropriat= e. >T7. It would be good to explain the semantics of 'fragments' in this=20 >document which is different from what is customary in the IP world,=20 >maybe provide a reference for the definition of the term (from TE-159?) [EB] The fragment in the bonding context was originally defined in the IEEE= 802.3ah (section 61.1.4), now part of 802.3. All the other documents (ITU-= T G.998.2 and BBF TR-159) reference 802.3 in this respect. Section 4.1.2 "= xDSL Bonding" in the draft-ietf-adslmib-gbond-mib-08.txt mentions Ethernet = frame fragmentation and reassembly in the bonding context. I've changed the 1st occurrence of 'fragment' in the GBOND-ETH-MIB to 'Ethe= rnet frame fragment' and also replaced the reference to the gamma-interface= (defined in IEEE 802.3 section 61.1.4) with a more generic bonding functio= n interface. >T8. In the DESCRIPTION clause of gBondEthPortPerf15MinIntervalIndex I see: >'This object partially maps to the TR-159 attribute aGroupPerf15MinInterva= lNumber'. >What does 'partially maps' mean? [EB] The TR-159 PM attributes aGroupPerf* map to the corresponding gBondPor= tPm* objects of GBOND-MIB module, for example gBondPortPmCur15MinTimeElapse= maps to aGroupPerfCurr15MinTimeElapsed (see draft-ietf-adslmib-gbond-mib= -08.txt). TR-159 does not specify the additional dedicated PM attributes for the gBon= dAtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* objects = introduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB modules respe= ctively. However the definitions of these objects are identical to the gBon= dPortPm* objects of GBOND-MIB module. Therefore I use the term 'partial map= ping' to denote the fact that the mapping of gBondEthPortPm* to aGroupPerf*= is not one-to-one. I've added the following text explaining this partial mapping in the end of= "Mapping of Broadband Forum TR-159" section as follows: "Note that some of the mapping between the objects defined in TR-159 and the ones defined in this MIB module is not one-to-one, for example= , while TR-159 PM attributes aGroupPerf* map to the corresponding gBondPortPm* objects of the GBOND-MIB module, there are no dedicated PM attributes for the gBondEthPortPm* objects introduced in this MIB m= odule. However, since their definition is identical to the definition of gBon= dPortPm*=20 objects of the GBOND-MIB module, we can map gBondEthPortPm* to the relevant aGroupPerf* attributes of TR-159 and use the term 'partial mapping' to denote the fact that this mapping is not one-to-o= ne." >E1. The acronym Generic Bonded Sub-layer (GBS) is expanded much later than= the first occurrence.=20 [EB] Corrected. >E2. At some point in time the WG will be shut down, and the reference [ADS= LMIB] will no longer be available. > Acknowledging the contributions of the WG participants is sufficient, no = reference is necessary.=20 [EB] I've checked a number of MIB documents, in particular all *DSL-LINE-MI= B documents reference the ADSLMIB workgroup charter in the CONTACT-INFO, li= kewise the documents produced by the HUBMIB group (shut down already) refer= ence its charter as well. As you can see the link to the HUBMIB charter is = still available: http://www.ietf.org/html.charters/hubmib-charter.html I see no reason why the IETF would change its policy towards the concluded = work groups with respect to their published charters. >E3. The following phrase which appears in the DESCRIPTION clause of severa= l counts object should be rephrased or at least explained at first >occurre= nce, as this terminology is not clear for the non-initiated: ' >This object is inhibited during Unavailable Seconds (UAS)' [EB] Inhibiting means that the accumulation performance counters is inhibit= ed so the counters actually freeze during the unavailability period. Added the following clarification paragraph at the end of "Performance Moni= toring" section: "Note that the accumulation of certain performance events for a monitored entity is inhibited (counting stops) during periods of service unavailability on that entity. The DESCRIPTION clause of performance monitoring counters in this MIB module specifies which of the counters are inhibited during periods of service unavailability." I've also used the Security Consideration boiler plate https://svn.tools.ie= tf.org/area/ops/trac/wiki/mib-security according to your T12 comment from AD review of draft-ietf-adslmib-gbond-mi= b-07.txt. >Dan > >_______________________________________________ >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 This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From dromasca@avaya.com Mon Feb 13 16:21:22 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAA421E802D for ; Mon, 13 Feb 2012 16:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwo7UyJcCKFW for ; Mon, 13 Feb 2012 16:21:20 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1879121E8010 for ; Mon, 13 Feb 2012 16:21:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYAAMCoOU/GmAcF/2dsb2JhbABDnxORFYEHgXIBAQEBAwEBAQ8eCjQLDAQCAQgNBAQBAQsGDAsBBgEmHwkIAQEEARIIARmHY6BXlCmLQwUFAQQLBgUGBgMCBQQBBj0Bg0U/WweCWWMEmy6MaQ X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="231711729" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Feb 2012 19:20:51 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Feb 2012 19:14:35 -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: Tue, 14 Feb 2012 01:20:48 +0100 Message-ID: In-Reply-To: <283DD79798619346BF9B17D7B5035A1901601DDEBAF9@ILPTMAIL02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt Thread-Index: AcyeJnmD2elwHemxQsGKVQd5DXQBsBJ85XJAAI7Y2xAAFj4SgA== References: <4087887712E5C648B9F72BB9D912FD4601FD571DA9A2@il-mail07.actelis.net> <283DD79798619346BF9B17D7B5035A1901601DDEBAF9@ILPTMAIL02.ecitele.com> From: "Romascanu, Dan (Dan)" To: "Menachem Dodge" , "Edward Beili" Cc: adslmib@ietf.org, Moti Morgenstern Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:21:22 -0000 Thanks for the good work. I will send the documents to IETF Last Call.=20 Regards, Dan > -----Original Message----- > From: Menachem Dodge [mailto:Menachem.Dodge@ecitele.com] > Sent: Monday, February 13, 2012 3:50 PM > To: Edward Beili; Romascanu, Dan (Dan) > Cc: adslmib@ietf.org; Moti Morgenstern > Subject: RE: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt >=20 > Hi Edward, >=20 > Thank you for your great work. >=20 > All the drafts have now been updated. >=20 > Dan please check whether the documents can be forwarded to IETF Last > Call. >=20 > Thank you kindly. >=20 > Menachem >=20 > -----Original Message----- > From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > Behalf Of Edward Beili > Sent: Monday, February 13, 2012 3:25 PM > To: Romascanu, Dan (Dan) > Cc: adslmib@ietf.org; Moti Morgenstern > Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib- > 04.txt >=20 > Dan, > Thank you for your comments. >=20 > Please see the clarifications/actions inline below (my comments are > marked with [EB): >=20 > I have just submitted the next draft (05) of the gbond-eth-mib. >=20 > Regards, > -E. >=20 > >-----Original Message----- > >From: adslmib-bounces@ietf.org [mailto:adslmib-bounces@ietf.org] On > >Behalf Of Romascanu, Dan (Dan) > >Sent: Tuesday, November 08, 2011 16:56 > >To: adslmib@ietf.org > >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib- > 04.txt > > > >Hi, > > > >Please find below the AD review of > >draft-ietf-adslmib-gbond-eth-mib-04.txt. > >This document is in a good shape, but a new version is needed in order > to clarify and fix some of the issues raised in the review. > > > >The comments below are marked T (Technical) and E (Editorial) > > > >T1. Running smicng in strict mode results in one error and one > warning: > > > >C:\bw\smicng\work>smicng gbond-eth.inc > >E: f(gbond-eth.mi2), (260,15) Default value for "gBondEthAdminCp" must > >be a name and not a number > >W: f(gbond-eth.mi2), (1825,20) For "gBondEthTcTypesSupported", syntax > >is identical > > > >*** 1 error and 1 warning in parsing >=20 > [EB] I corrected the error with the default value, using a name instead > of a number. >=20 > As for the warning I don't think anything needs to be corrected, since > none of the possible values (BIT positions) of > gBondEthPortCapTcTypesSupported is preferred, I must list all of them > in the MODULE-COMPLIANCE section, repeating the same SYNTAX, as in the > object's definition. >=20 > >T2. In section 5.2: > > > > The agent SHOULD align the beginning of each interval to a fifteen > > minute boundary of a wall clock. Likewise, the beginning of each > one > > day intervals SHOULD be aligned with the start of a day. > > > >Where does this requirement come from? If the source is another > standard I suggest to provide it. > >What is the rationale? What happens if this requirement is not / > cannot > >be met because for example the agent does not have access to a 'wall > clock'? >=20 > [EB] This particular wording is from the TR-159 section 4.2.5, which is > a normative reference for the document, I didn't see a reason to > explain this recommendation in more details than is provided in TR-159. > Note that this is a standard recommendation for the historical > performance monitoring (PM) based on 15-min & 1-day accumulation > periods, see for example ANSI T1.231 section 9.1.2.1 and 9.1.5.1. >=20 > I've added the following text to the GBOND-MIB draft 0.9 (unsubmitted > yet), under 5.2 "Performance Monitoring": >=20 > "The rationale behind it is to simplify collection and analysis of the > PM from multiple agents by a network management system (NMS) - each PM > interval can be 'time-stamped' using the interval index object, the > fact that 1-day interval starts at 00:00 and 15-min intervals are > aligned with 1/4 hour and the network-wide 'wall clock', typically > distributed via NTP or SNTP. If the agent does not have an access to > the 'wall clock', a local clock can be used. In this case, as well as > when coping with multiple time zones, the NMS would have to correlate > for the difference between the agent's local clock (available for > example via hrSystemDate object from HOST-RESOURCES-MIB [RFC2790]) and > the 'wall clock'." >=20 > I have also removed the bracketed text from the following sentence in > "Performance Monitoring" section, according to your T7 comment to the > draft-ietf-adslmib-gbond=3Dmib-07.txt: >=20 > OLD> > Counters are not reset when a GBS is reinitialized, but rather only > when the agent is reset or reinitialized (or under specific request > outside the scope of this MIB module). >=20 > NEW> > Counters are not reset when a GBS is reinitialized, but rather only > when the agent is reset or reinitialized. >=20 > >T3. In the DESCRIPTION clause of gBondEthTcAdminType the following > shows up: > > > > Changing gBondEthTcAdminType is a traffic disruptive > > operation and as such SHALL be done when the link is Down. > > Attempts to change this object SHALL be rejected if the link > > is Up or Initializing. > > > >It would be good to point specifically what object needs to be > examined in order to determine the state of the link (Down, Up or > Initializing). > > > >Similar text appears in the DESCRIPTION clause of other MIB objects. >=20 > [EB] Modified the description clause for gBondEthPortConf* objects as > follows: > OLD> > ... SHALL be done when the link is Down. >=20 > NEW> > ... SHALL be done when the link (GBS) is > administratively 'down', as indicated by the ifAdminStatus > object > in IF-MIB. > Attempts to change this object SHALL be rejected (with the error > inconsistentValue) if the link is Up or Initializing. >=20 > I also added two new values to the gBondPortStatFltStatus object in > GBOND-MIB: >=20 > init(5) - The link is Initializing, as a result of > ifAdminStatus being set to 'up' for a > particular BCE or a GBS to which the BCE > is connected. > ready(6) - at least one BCE in the aggregation > group is detecting handshake tones. >=20 > >T4. There is no need to specify for individual objects that 'This > object MUST be maintained in a persistent manner.' If a generic > declaration >was already made for the whole table. For example for the > gBondEthTcAdminType object in the gBondEthPortConfTable. >=20 > [EB] Corrected. >=20 > >T5. Objects in the MIB tables do not respect the naming convention for > a common prefix of the table name and of the objects in the table. >The > first such example is gBondEthPortConfTable with gBondEthTcAdminType > and gBondEthAdminCp as columns. There are more. Please >check this and > make sure that the recommendations in Annex C of RFC 4181 for the > naming of objects in conceptual tables are being followed. >=20 > [EB] Corrected. >=20 > >T6. It would be useful to provide UNIX clauses for the counter > objects. > >The first example is gBondEthRxErrors, but there are more. >=20 > [EB] I assume you meant UNITS clauses - I've provided them where > appropriate. >=20 > >T7. It would be good to explain the semantics of 'fragments' in this > >document which is different from what is customary in the IP world, > >maybe provide a reference for the definition of the term (from TE- > 159?) >=20 > [EB] The fragment in the bonding context was originally defined in the > IEEE 802.3ah (section 61.1.4), now part of 802.3. All the other > documents (ITU-T G.998.2 and BBF TR-159) reference 802.3 in this > respect. Section 4.1.2 "xDSL Bonding" in the draft-ietf-adslmib-gbond- > mib-08.txt mentions Ethernet frame fragmentation and reassembly in the > bonding context. >=20 > I've changed the 1st occurrence of 'fragment' in the GBOND-ETH-MIB to > 'Ethernet frame fragment' and also replaced the reference to the gamma- > interface (defined in IEEE 802.3 section 61.1.4) with a more generic > bonding function interface. >=20 > >T8. In the DESCRIPTION clause of gBondEthPortPerf15MinIntervalIndex I > see: > >'This object partially maps to the TR-159 attribute > aGroupPerf15MinIntervalNumber'. > >What does 'partially maps' mean? >=20 > [EB] The TR-159 PM attributes aGroupPerf* map to the corresponding > gBondPortPm* objects of GBOND-MIB module, for example > gBondPortPmCur15MinTimeElapse maps to aGroupPerfCurr15MinTimeElapsed > (see draft-ietf-adslmib-gbond-mib-08.txt). > TR-159 does not specify the additional dedicated PM attributes for the > gBondAtmPortPm*, gBondEthPortPm*, gBondTdimPortPm* and gBondTdimSvcPm* > objects introduced in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB > modules respectively. However the definitions of these objects are > identical to the gBondPortPm* objects of GBOND-MIB module. Therefore I > use the term 'partial mapping' to denote the fact that the mapping of > gBondEthPortPm* to aGroupPerf* is not one-to-one. >=20 > I've added the following text explaining this partial mapping in the > end of "Mapping of Broadband Forum TR-159" section as follows: >=20 > "Note that some of the mapping between the objects defined in TR- > 159 > and the ones defined in this MIB module is not one-to-one, for > example, > while TR-159 PM attributes aGroupPerf* map to the corresponding > gBondPortPm* objects of the GBOND-MIB module, there are no > dedicated > PM attributes for the gBondEthPortPm* objects introduced in this > MIB module. > However, since their definition is identical to the definition of > gBondPortPm* > objects of the GBOND-MIB module, we can map gBondEthPortPm* to the > relevant aGroupPerf* attributes of TR-159 and use the term > 'partial mapping' to denote the fact that this mapping is not one- > to-one." >=20 > >E1. The acronym Generic Bonded Sub-layer (GBS) is expanded much later > than the first occurrence. >=20 > [EB] Corrected. >=20 > >E2. At some point in time the WG will be shut down, and the reference > [ADSLMIB] will no longer be available. > > Acknowledging the contributions of the WG participants is sufficient, > no reference is necessary. >=20 > [EB] I've checked a number of MIB documents, in particular all *DSL- > LINE-MIB documents reference the ADSLMIB workgroup charter in the > CONTACT-INFO, likewise the documents produced by the HUBMIB group (shut > down already) reference its charter as well. As you can see the link to > the HUBMIB charter is still available: > http://www.ietf.org/html.charters/hubmib-charter.html > I see no reason why the IETF would change its policy towards the > concluded work groups with respect to their published charters. >=20 > >E3. The following phrase which appears in the DESCRIPTION clause of > several counts object should be rephrased or at least explained at > first >occurrence, as this terminology is not clear for the non- > initiated: ' > >This object is inhibited during Unavailable Seconds (UAS)' >=20 > [EB] Inhibiting means that the accumulation performance counters is > inhibited so the counters actually freeze during the unavailability > period. >=20 > Added the following clarification paragraph at the end of "Performance > Monitoring" section: >=20 > "Note that the accumulation of certain performance events for a > monitored entity is inhibited (counting stops) during periods of > service unavailability on that entity. The DESCRIPTION > clause of performance monitoring counters in this MIB module > specifies which of the counters are inhibited during periods of > service unavailability." >=20 > I've also used the Security Consideration boiler plate > https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security > according to your T12 comment from AD review of draft-ietf-adslmib- > gbond-mib-07.txt. >=20 > >Dan > > > >_______________________________________________ > >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 >=20 >=20 > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. From iesg-secretary@ietf.org Tue Feb 14 15:35:35 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F99F21E8139; Tue, 14 Feb 2012 15:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95pfe7-QdsHv; Tue, 14 Feb 2012 15:35:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0582521E8117; Tue, 14 Feb 2012 15:35:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214233535.9332.4317.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 15:35:35 -0800 X-Mailman-Approved-At: Wed, 15 Feb 2012 08:23:25 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] Last Call: (xDSL multi-pair bonding (G.Bond) MIB) to Proposed Standard X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:35:35 -0000 The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'xDSL multi-pair bonding (G.Bond) MIB' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-mib/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Feb 14 15:36:03 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF65F21E8143; Tue, 14 Feb 2012 15:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZYtu3LNVnHO; Tue, 14 Feb 2012 15:36:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4339121E8122; Tue, 14 Feb 2012 15:36:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214233603.9500.55019.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 15:36:03 -0800 X-Mailman-Approved-At: Wed, 15 Feb 2012 08:23:25 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] Last Call: (ATM-Based xDSL Bonded Interfaces MIB) to Proposed Standard X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:36:03 -0000 The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'ATM-Based xDSL Bonded Interfaces MIB' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-atm-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-atm-mib/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Feb 14 15:36:30 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63B21E814C; Tue, 14 Feb 2012 15:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asJ6Thjw63eL; Tue, 14 Feb 2012 15:36:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15DF21E8122; Tue, 14 Feb 2012 15:36:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214233629.10317.4752.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 15:36:29 -0800 X-Mailman-Approved-At: Wed, 15 Feb 2012 08:23:25 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] Last Call: (xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB) to Proposed Standard X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:36:30 -0000 The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-tdim-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-tdim-mib/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Feb 14 15:36:59 2012 Return-Path: X-Original-To: adslmib@ietfa.amsl.com Delivered-To: adslmib@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADF21E8130; Tue, 14 Feb 2012 15:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNmzy0Ab4UdE; Tue, 14 Feb 2012 15:36:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FB621E8139; Tue, 14 Feb 2012 15:36:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214233658.10275.62110.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 15:36:58 -0800 X-Mailman-Approved-At: Wed, 15 Feb 2012 08:23:25 -0800 Cc: adslmib@ietf.org Subject: [Adslmib] Last Call: (Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB) to Proposed Standard X-BeenThere: adslmib@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: ADSLMIB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:36:59 -0000 The IESG has received a request from the ADSL MIB WG (adslmib) to consider the following document: - 'Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-eth-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-eth-mib/ No IPR declarations have been submitted directly on this I-D.