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

[Edward Beili <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Romascanu, Dan (Dan)
>Sent: Tuesday, November 08, 2011 18:45
>To: [e-mail]
>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'?

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

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

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

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

[EB] Corrected.

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

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

I've added the following text in each case where the word irrelevant is used in the MIB module:

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

>T4. Although not mandatory it is considered good practice to include optional UNITS clauses in objects that define performance counts. 

[EB] Corrected. I've placed UNITS of "seconds" or "days" in the relevant places. The same was done to the GBOND-MIB (v09).

>T5. In the DESCRIPTION clause of gBondAtmPortPerfCurr15MinTimeElapsed I found: 
>
>       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 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.

>T6. In several DESCRIPTION clauses I found: 
>
>      This object is inhibited during Unavailable Seconds (UAS). 
>
>Please explain what 'inhibited' means. 

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

>_______________________________________________
>Adslmib mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/adslmib