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

["Romascanu, Dan (Dan)" <[e-mail]>]

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. 

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. 

Regards,

Dan




> -----Original Message-----
> From: Edward Beili [mailto:[e-mail]]
> Sent: Friday, February 03, 2012 2:05 AM
> To: Romascanu, Dan (Dan)
> Cc: Menachem Dodge; Moti Morgenstern; [e-mail]
> Subject: RE: AD review of draft-ietf-adslmib-gbond-atm-mib-04.txt
> 
> 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