Re: AD review: draft-ietf-adslmib-adsl2-05.txt

Hello Bert,

      Referring to your email of 29/1/:



The last point in your email was:



- Maybe I am missing something, but in:
   Adsl2PMLineCurrEntry  ::=
      SEQUENCE {
         adsl2PMLCurrUnit                    Adsl2Unit,
         adsl2PMLCurrValidIntervals          Unsigned32,
         adsl2PMLCurrInvalidIntervals        Unsigned32,
         adsl2PMLCurr15MTimeElapsed          HCPerfTimeElapsed,
         adsl2PMLCurr15MFecs                 Counter32,
         adsl2PMLCurr15MEs                   Counter32,
         adsl2PMLCurr15MSes                  Counter32,
         adsl2PMLCurr15MLoss                 Counter32,
         adsl2PMLCurr15MUas                  Counter32,
         adsl2PMLCurr1DayValidIntervals      Unsigned32,
         adsl2PMLCurr1DayInvalidIntervals    Unsigned32,
         adsl2PMLCurr1DayTimeElapsed         HCPerfTimeElapsed,
         adsl2PMLCurr1DayFecs                Counter32,
         adsl2PMLCurr1DayEs                  Counter32,
         adsl2PMLCurr1DaySes                 Counter32,
         adsl2PMLCurr1DayLoss                Counter32,
         adsl2PMLCurr1DayUas                 Counter32
      }
  This seems to be (to me) a table of 15 minute current intervals.
  So why are the TCs and scheme from RFC3593 not used?
  The HCPerfTimeElapsed also confuses me a bit as it makes me think
  we talk about high-perfromance counters, i.e. 64 bit based?

                  The approach that has been adopted in the Adsl2 draft is
explained in paragraph 2.7.4 of the draft, see below, and differs from the
approach in
RFC3593. In RFC3593, an interval which is only partially valid is declared
invalid and all data that has been collected in this interval is
discarded. Any attempt to retrieve this information results in a error
returned.

      The approach in the Adsl2 draft is to indicate via a "valid" field
and "monitored" time field how much of the interval is valid and not to
discard the collected data of a partially valid interval.



2.7.4.  Interval Buckets Validity

   As in RFC 3593 [RFC3593] and RFC 2662 [RFC2662], in case the data for
   an interval is suspect or known to be invalid, the agent MUST report
   the interval as invalid.  If the current 15-minute event bucket is
   determined to be invalid, the element management system SHOULD ignore
   its content and the agent MUST NOT generate notifications based upon
   the value of the event bucket.

   A valid 15-minute event bucket SHOULD usually count the events for
   exactly 15 minutes.  Similarly, a valid 1-day event bucket SHOULD
   usually count the events for exactly 24 hours.  However, the
   following scenarios are exceptional:
   1) For implementations that align the 15-minute intervals with
      quarter hours, and the 1-day intervals with start of a day, the
      management system may still start the PM process not aligned with
      the wall clock.  Such a management system may wish to retrieve
      even partial information for the first event buckets, rather than
      declaring them all as invalid.
   2) For an event bucket that suffered relatively short outages, the
      management system may wish to retrieve the available PM outcomes,
      rather than declaring the whole event bucket as invalid.  This is
      more important for 1-day event buckets.
   3) An event bucket may be shorter or longer than the formal duration
      if a clock adjustment was performed during the interval.

   This MIB allows supporting the exceptional scenarios described above
   by reporting the actual Monitoring Time of a monitoring interval.
   This parameter is relevant only for Valid intervals, but is useful
   for these exceptional scenarios:
   a) The management system MAY still declare a partial PM interval as
      Valid and report the actual number of seconds the interval lasted.
   b) If the interval was shortened or extended due to clock
      corrections, the management system SHOULD report the actual number
      of seconds the interval lasted, beside reporting that the interval
      is Valid.




Best Regards,
Menachem.