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

[Edward Beili <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Romascanu, Dan (Dan)
>Sent: Wednesday, November 09, 2011 18:01
>To: [e-mail]
>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. 
>
>The comments below are marked T (Technical) and E (Editorial)
>
>T1. smicng in relaxed checking reports one compilation error: 
>
>C:\bw\smicng\work>smicng gbond-tdim.inc
>E: f(gbond-tdim.mi2), (820,4) Row "gBondTdimServiceEntry" may not have columns 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 of read-write to be read-create.

>T2. In section 5.4: 
>
>   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.

Note that the following text was added 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 of the GBondTdimServiceIndex TC: 
>
>       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 it designates in many other documents the >management application. The entity 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. 

[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 gBondTdimServiceUp and gBondTdimServiceDown notifications. 
>
>       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? 

[EB] My thinking was that since the notifications maybe disabled by gBondTdimPortConfSvcUpDownEnable object or rate limited (implementation specific throttling, to prevent notification flooding in case gBondTdimServiceOperState oscillates between Up and Down states) I would use the word MAY to denote the fact that these notifications are may not be sent in the event of gBondTdimServiceOperState 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 optional_ which is clearly not the case here, I've changed the corresponding DESCRIPTION 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 
       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 notification
       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 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.

>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 same table (e.g. >gBondTdimFecAdminState)

[EB] Corrected.

>T7. In the DESCRIPTION clause of gBondTdimFecMaxInterleaverDepth (and other objects) I found the following: 
>
>       This object partially maps to TR-159 attribute
>       aFECMaxInterleaverDepth.
>
>What does 'partially maps' mean? 

[EB] Actually for
gBondTdimPortCapFecMaxWordSize object with aFECWordSize TR-159 attribute,
gBondTdimPortCapFecInterleaverTypeSupported with aFECInterleaverTypesSupported  and gBondTdimPortCapFecMaxInterleaverDepth  with aFECMaxInterleaverDepth
the mapping is one-to-one, so I removed the word partially from the relevant 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.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 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" 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 gBondTdimPortPm* and gBondTdimSvcPm*
     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 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-one."

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

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

>E1. Section 5.3: 
>
>s/listing the active services in order of their position in the G.Bond/listing the active services in the order of their position in the G.Bond/
>
>s/The actual list of services is provided via read-only gBondTdimOperServiceTable/ The actual list of services is provided via the read-only gBondTdimOperServiceTable/

[EB] Corrected.

>E2. Please expand BTU-C at first occurrence. 

[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 requirements placed on the agent. 

[EB] Corrected. 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.

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