Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-mib-07.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 (08) of the gbond-mib.
I'll submit the rest of gbond-*-mib drafts within a day or two.

Regards,
-E.

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Romascanu, Dan (Dan)
>Sent: Tuesday, October 11, 2011 10:31
>To: [e-mail]
>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

[EB] Corrected - the duplicate item is removed.

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

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

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

[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 
   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 document, after the IANA actions were 
>performed. 

[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

See:
http://www.iana.org/assignments/smi-numbers
http://www.iana.org/assignments/ianaiftype-mib
 
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 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?

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

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

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

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

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 something common to all MIB modules using PM-related objects and yet none of them addressed this issue.

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

[EB] Corrected - I have removed the text in parentheses. 

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

[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 mechanisms defined in RFC 3413 <xref target="RFC3413"/>.

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

[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-only, so these statements are redundant. 

[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, or the object is not available (which would be
>a bad design choice), or something else? 

[MM] Inhibiting means that the accumulation is inhibited so the counter actually freezes 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 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 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. 

[EB] Corrected. Added also gBondPortStatusTable to the sensitive readable objects. 

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

[EB]  Corrected.

>E1. Please explain in a few words what is a gamma-interface (referred in the Introduction section). 

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

I removed the word "gamma" from the text to avoid confusion.

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

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

>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 module 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: 
>
>OLD: 
>
>g9982(2)   - G.998.2 (G.Bond/Ethernt)
>
>NEW: 
>
>g9982(2)   - G.998.2 (G.Bond/Ethernet

[EB] Corrected.

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

[EB] Corrected.

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