Re: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt

Thanks for the good work. I will send the documents to IETF Last Call. 

Regards,

Dan




> -----Original Message-----
> From: Menachem Dodge [mailto:[email protected]]
> Sent: Monday, February 13, 2012 3:50 PM
> To: Edward Beili; Romascanu, Dan (Dan)
> Cc: [email protected]; Moti Morgenstern
> Subject: RE: AD review of draft-ietf-adslmib-gbond-eth-mib-04.txt
> 
> Hi Edward,
> 
> Thank you for your great work.
> 
> All the drafts have now been updated.
> 
> Dan please check whether the documents can be forwarded to IETF Last
> Call.
> 
> Thank you kindly.
> 
> Menachem
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Edward Beili
> Sent: Monday, February 13, 2012 3:25 PM
> To: Romascanu, Dan (Dan)
> Cc: [email protected]; Moti Morgenstern
> Subject: Re: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-
> 04.txt
> 
> 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 (05) of the gbond-eth-mib.
> 
> Regards,
> -E.
> 
> >-----Original Message-----
> >From: [email protected] [mailto:[email protected]] On
> >Behalf Of Romascanu, Dan (Dan)
> >Sent: Tuesday, November 08, 2011 16:56
> >To: [email protected]
> >Subject: [Adslmib] AD review of draft-ietf-adslmib-gbond-eth-mib-
> 04.txt
> >
> >Hi,
> >
> >Please find below the AD review of
> >draft-ietf-adslmib-gbond-eth-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. Running smicng in strict mode results in one error and one
> warning:
> >
> >C:\bw\smicng\work>smicng gbond-eth.inc
> >E: f(gbond-eth.mi2), (260,15) Default value for "gBondEthAdminCp"
must
> >be a name and not a number
> >W: f(gbond-eth.mi2), (1825,20) For "gBondEthTcTypesSupported", syntax
> >is identical
> >
> >*** 1 error and 1 warning in parsing
> 
> [EB] I corrected the error with the default value, using a name
instead
> of a number.
> 
> As for the warning I don't think anything needs to be corrected, since
> none of the possible values (BIT positions) of
> gBondEthPortCapTcTypesSupported is preferred, I must list all of them
> in the MODULE-COMPLIANCE section, repeating the same SYNTAX, as in the
> object's definition.
> 
> >T2. 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.
> 
> I've added 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.
> 
> >T3. In the DESCRIPTION clause of gBondEthTcAdminType the following
> shows up:
> >
> >       Changing gBondEthTcAdminType is a traffic disruptive
> >       operation and as such SHALL be done when the link is Down.
> >       Attempts to change this object SHALL be rejected if the link
> >       is Up or Initializing.
> >
> >It would be good to point specifically what object needs to be
> examined in order to determine the state of the link (Down, Up or
> Initializing).
> >
> >Similar text appears in the DESCRIPTION clause of other MIB objects.
> 
> [EB] Modified the description clause for gBondEthPortConf* objects as
> follows:
> OLD>
>    ... SHALL be done when the link is Down.
> 
> NEW>
>    ... SHALL be done when the link (GBS) is
>        administratively 'down', as indicated by the ifAdminStatus
> object
>        in IF-MIB.
>        Attempts to change this object SHALL be rejected (with the
error
>        inconsistentValue) if the link is Up or Initializing.
> 
> I also added two new values to the gBondPortStatFltStatus object in
> GBOND-MIB:
> 
>          init(5)             - The link is Initializing, as a result
of
> 	                     ifAdminStatus being set to 'up' for a
> 		       particular BCE or a GBS to which the BCE
> 		       is connected.
>         ready(6)         - at least one BCE in the aggregation
>  	                    group is detecting handshake tones.
> 
> >T4. There is no need to specify for individual objects that 'This
> object MUST be maintained in a persistent manner.' If a generic
> declaration >was already made for the whole table. For example for the
> gBondEthTcAdminType object in the gBondEthPortConfTable.
> 
> [EB] Corrected.
> 
> >T5. Objects in the MIB tables do not respect the naming convention
for
> a common prefix of the table name and of the objects in the table.
>The
> first such example is gBondEthPortConfTable with gBondEthTcAdminType
> and gBondEthAdminCp as columns. There are more. Please >check this and
> make sure that the recommendations in Annex C of RFC 4181 for the
> naming of objects in conceptual tables are being followed.
> 
> [EB] Corrected.
> 
> >T6. It would be useful to provide UNIX clauses for the counter
> objects.
> >The first example is gBondEthRxErrors, but there are more.
> 
> [EB] I assume you meant UNITS clauses - I've provided them where
> appropriate.
> 
> >T7. It would be good to explain the semantics of 'fragments' in this
> >document which is different from what is customary in the IP world,
> >maybe provide a reference for the definition of the term (from TE-
> 159?)
> 
> [EB] The fragment in the bonding context was originally defined in the
> IEEE 802.3ah (section 61.1.4), now part of 802.3. All the other
> documents (ITU-T G.998.2 and BBF TR-159) reference 802.3 in this
> respect.  Section 4.1.2 "xDSL Bonding" in the
draft-ietf-adslmib-gbond-
> mib-08.txt mentions Ethernet frame fragmentation and reassembly in the
> bonding context.
> 
> I've changed the 1st occurrence of 'fragment' in the GBOND-ETH-MIB to
> 'Ethernet frame fragment' and also replaced the reference to the
gamma-
> interface (defined in IEEE 802.3 section 61.1.4) with a more generic
> bonding function interface.
> 
> >T8. In the DESCRIPTION clause of gBondEthPortPerf15MinIntervalIndex I
> see:
> >'This object partially maps to the TR-159 attribute
> aGroupPerf15MinIntervalNumber'.
> >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
> gBondEthPortPm* 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" 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 gBondEthPortPm* 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 gBondEthPortPm* 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."
> 
> >E1. The acronym Generic Bonded Sub-layer (GBS) is expanded much later
> than the first occurrence.
> 
> [EB] Corrected.
> 
> >E2. At some point in time the WG will be shut down, and the reference
> [ADSLMIB] will no longer be available.
> > Acknowledging the contributions of the WG participants is
sufficient,
> no reference is necessary.
> 
> [EB] I've checked a number of MIB documents, in particular all *DSL-
> LINE-MIB documents reference the ADSLMIB workgroup charter in the
> CONTACT-INFO, likewise the documents produced by the HUBMIB group
(shut
> down already) reference its charter as well. As you can see the link
to
> the HUBMIB charter is still available:
> http://www.ietf.org/html.charters/hubmib-charter.html
> I see no reason why the IETF would change its policy towards the
> concluded work groups with respect to their published charters.
> 
> >E3. The following phrase which appears in the DESCRIPTION clause of
> several counts object should be rephrased or at least explained at
> first >occurrence, as this terminology is not clear for the non-
> initiated: '
> >This object is inhibited during Unavailable Seconds (UAS)'
> 
> [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.
> 
> >Dan
> >
> >_______________________________________________
> >Adslmib mailing list
> >[email protected]
> >https://www.ietf.org/mailman/listinfo/adslmib
> _______________________________________________
> Adslmib mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/adslmib
> 
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please
inform
> us by e-mail, phone or fax, and then delete the original and all
copies
> thereof.