Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt

[Edward Beili <[e-mail]>]

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 Monitoring":

"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'."

2. Adding two new values for the gBondPortStatFltStatus object to provide additional G.Bond-specific GBS operational states, extending the ifOperStatus from IF-MIB (note that EFM-CU-MIB relied on the ifMauMediaAvailable object 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:[e-mail]] 
Sent: Monday, February 13, 2012 15:50
To: Edward Beili; Romascanu, Dan (Dan)
Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] On Behalf Of Edward Beili
Sent: Monday, February 13, 2012 3:25 PM
To: Romascanu, Dan (Dan)
Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Romascanu, Dan (Dan)
>Sent: Tuesday, November 08, 2011 16:56
>To: [e-mail]
>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

[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, repeating 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 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.

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 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'."

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=mib-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 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 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.
       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-MIB:

         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 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. 

[EB] Corrected.

>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. 

[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 "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 '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.

>T8. In the DESCRIPTION clause of gBondEthPortPerf15MinIntervalIndex I see:
>'This object partially maps to the TR-159 attribute aGroupPerf15MinIntervalNumber'.
>What does 'partially maps' mean?

[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.

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 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."

>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 [ADSLMIB] will no longer be available.
> Acknowledging the contributions of the WG participants is sufficient, no reference 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, 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.

>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)'

[EB] Inhibiting means that the accumulation performance counters is inhibited so the counters actually freeze during the unavailability period.

Added the following clarification paragraph at the end of "Performance Monitoring" 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.ietf.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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/adslmib
_______________________________________________
Adslmib mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/adslmib


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.