[Adslmib] AD review of draft-ietf-adslmib-gbond-mib-07.txt

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

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

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. 

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

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. 

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? 
                                       

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. 

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. 


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

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. 

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. 

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? 

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. 

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. 


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

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? 


E3. In table 1 at 4.1.5 s/assymetrical/asymetrical/

E4. In section 4.2 s/ This MIB module defined in this document/ The MIB
module defined in this document/

E5. In section 4.2.3 s/ These MIBs/ These MIB modules/

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)

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. 

Thanks and Regards,

Dan