Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)
draft-ietf-adslmib-vdsl-12

[Ballot discuss]
DISCUSS comments on draft-ietf-adslmib-hc-tc-06.txt:

>  This document presents a set of High Capacity Textual Conventions
>  for use in MIB modules which require performance history based upon
>  15 minute intervals.  The Textual Conventions defined in this
>  document extend the conventions presented in RFC 3593 to 64 bit
>  resolution using the conventions presented in RFC 2856.

This isn't really true.  This document takes an entirely
different approach from RFC 3593, which only specifies two
TCs, and provides a template for three variables that
every MIB must contain that uses the RFC 3593 TCs.  I
believe that the 32-bit and 64-bit mechanisms for handling
15-minute counters should be consistent.

IMO, both this document and RFC 3593 are overly restrictive.
Why are "15 minutes" or "96 intervals" magic numbers?  Do
they come from some telecommunications requirements?

>    hcPerfHistTCMIB MODULE-IDENTITY
[...]
>          In certain cases (e.g., in the case where the agent is a
>          proxy) it is possible that some intervals are unavailable. 
>          In this case, this interval is the maximum interval number
>          for which data is available."

There is no explanation for why the use of a proxy would
cause information for some intervals to be unavailable
and/or how the agent would know that a proxy was in use,
so that it could report a different value.  Please explain.

EDITORIAL COMMENTS on draft-ietf-adslmib-hc-tc-06.txt:

>Since RFC 3593 was only published in Sept 2003, I wonder
>the authors of this document decided to depart so far from
>it.
>
>    HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
>        STATUS  current
>        DESCRIPTION
>          "The number of near end intervals for which no data is

The term "near end intervals" isn't meaningful to me.  Is
this a technical term from another context?  If so, a reference
might be helpful.

>            This count represents a non-negative integer, which
>            may increase or decrease, but shall never exceed 2^64-1
>            (18446744073709551615 decimal), nor fall below 0.

It seems unnecessary to define the range that an unsigned
64-bit integer can assume, and it is especially wordy to
do this in three separate places in this MIB.

[Ballot discuss]
>  This document presents a set of High Capacity Textual Conventions
>  for use in MIB modules which require performance history based upon
>  15 minute intervals.  The Textual Conventions defined in this
>  document extend the conventions presented in RFC 3593 to 64 bit
>  resolution using the conventions presented in RFC 2856.

This isn't really true.  This document takes an entirely
different approach from RFC 3593, which only specifies two
TCs, and provides a template for three variables that
every MIB must contain that uses the RFC 3593 TCs.  I
believe that the 32-bit and 64-bit mechanisms for handling
15-minute counters should be consistent.

IMO, both this document and RFC 3593 are overly restrictive.
Why are "15 minutes" or "96 intervals" magic numbers?  Do
they come from some telecommunications requirements?

>    hcPerfHistTCMIB MODULE-IDENTITY
[...]
>          In certain cases (e.g., in the case where the agent is a
>          proxy) it is possible that some intervals are unavailable. 
>          In this case, this interval is the maximum interval number
>          for which data is available."

There is no explanation for why the use of a proxy would
cause information for some intervals to be unavailable
and/or how the agent would know that a proxy was in use,
so that it could report a different value.  Please explain.

EDITORIAL COMMENTS:
>Since RFC 3593 was only published in Sept 2003, I wonder
>the authors of this document decided to depart so far from
>it.
>
>    HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION
>        STATUS  current
>        DESCRIPTION
>          "The number of near end intervals for which no data is

The term "near end intervals" isn't meaningful to me.  Is
this a technical term from another context?  If so, a reference
might be helpful.

>            This count represents a non-negative integer, which
>            may increase or decrease, but shall never exceed 2^64-1
>            (18446744073709551615 decimal), nor fall below 0.

It seems unnecessary to define the range that an unsigned
64-bit integer can assume, and it is especially wordy to
do this in three separate places in this MIB.

New revisions are available.
But the AD (Bert) still has a few nits.
We can start IETF Last Call though and incorporate changes after the Last Call finishes.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: maandag 22 september 2003 14:35
To: 'rray@pesa.com'; adslmib mail list
Subject: RE: [Adslmib] draft updates


Inline.... sorry I took a while to re-check.

Thanks,
Bert

> -----Original Message-----
> From: Bob Ray [mailto:rray@pesa.com]
> Sent: maandag 8 september 2003 18:30
> To: adslmib mail list
> Subject: [Adslmib] draft updates
>
>
> All:
>
> Per input from Bert Wijnen and Randy Presuhn (and belatedly, Felix
> Flemisch), I updated the vdsl and hc-tc drafts (producing -11 and -05
> respectively).
>
> Here is a list of changes done:
>
> 1.  Fixed the problems noted by Felix in his email of June 17, 2003.
> 2.  Added "MUST, SHOULD, MAY" sentence to both drafts.
> 3.  Changed "counter are" to "counters are", page 8.
> 4.  Changed reference to RFC2575 to RFC2415, page 10.

you mean 3415, but the doc is correct now

> 5.  Changed RFC editor note to use Bert's suggestion that we use
>    "transmission 97".
> 6.  Added persistence statement to tables that should be treated
>    as persistent.
> 7.  Changed names of objects in vdslPhysTable to have a consistent
>    prefix of vdslPhys.
> 8.  Changed names of objects in vdslPerfDataTable to have a consistent
>    prefix of vdslPerfData.
> 9.  Changed names of objects in vdslPerfIntervalTable to have a
>    consistent prefix of vdslPerfInterval.

Sofar so good. What a pitty that you did not also change the
descriptors for vdslLineAlarmConfProfileTable to be more
consistent in their prefix (I guess I should have pointed that
one out specifically as well?). They now are:

  1.3.6.1.2.1.10.97.1.1.20      vdslLineAlarmConfProfileTablex
  1.3.6.1.2.1.10.97.1.1.20.1    vdslLineAlarmConfProfileEntry x
  1.3.6.1.2.1.10.97.1.1.20.1.1  vdslLineAlarmConfProfileName
  1.3.6.1.2.1.10.97.1.1.20.1.2  vdslThresh15MinLofs
  1.3.6.1.2.1.10.97.1.1.20.1.3  vdslThresh15MinLoss
  1.3.6.1.2.1.10.97.1.1.20.1.4  vdslThresh15MinLprs
  1.3.6.1.2.1.10.97.1.1.20.1.5  vdslThresh15MinLols
  1.3.6.1.2.1.10.97.1.1.20.1.6  vdslThresh15MinESs 
  1.3.6.1.2.1.10.97.1.1.20.1.7  vdslThresh15MinSESs
  1.3.6.1.2.1.10.97.1.1.20.1.8  vdslThresh15MinUASs
  1.3.6.1.2.1.10.97.1.1.20.1.9  vdslInitFailureNotifyEnable
  1.3.6.1.2.1.10.97.1.1.20.1.10  vdslLineAlarmConfProfRowStatus

I can live with it... but possibly you may still want to improve this
somehwat after we finish IETF Last Call.

> 10. Changed "portion of the" to "", page 1
> 11. Changed "its" to "their", page 7
> 12. Changed "SHOULD" to "should", page 10
> 13. Fixed indentation in bibliographic section
> 14. Updated security boilerplate per
>      www.ops.ietf.org/mib-security.html
>      (I hope!) in vdsl mib.
> 15. Replaced security section with Bert's text in hc-tc mib.

I also believe that the ref to RFC2493 should be updated to RFC3593.
Can do that after IETF last call (via RFC-Editor note if no other
changes are needed)

And there are now new RFCs for RFC2558 (RFC3592)

Bob, I also had a number of questions in my AD review posting.
You made no changes for some of the questions raised.
That is OK, after all they were just questions.
Would still appreaciate an answer (to the list) though.

And this question MUST be answered and the doc fixed:
- The xxxRowStatus objects do not specify if any (or all, or none)
  of the columnar objects in a column can be changed/modified if
  the RowStatus value is 'active'. So as an implementer or as an
  NM APP developer, how would I know?

Can do so after IETF Last Call.

I have requested IETF Last Call now. Should show up soon.

I expect a new rev for the vdsl mib to address some of the above
Certainly the rowstatus issue.

Bert

AD review posted to WG mailing list.
Bob already promised a new rev over the weekend.


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: dinsdag 26 augustus 2003 17:15
To: Mike Sneed (E-mail); Bob Ray; Rajesh Abbi
Cc: Randy Presuhn (E-mail); Adslmib (E-mail)
Subject: [Adslmib] AD review of draft-ietf-adslmib-vdsl-10.txt


In addition to the MIB-Technical Advisor comments below,
I have the following comments. I appologize for not have seen
and reported these earlier.

Depending on what your answers are to these, we can keep these
as "todo" items while we do IETF Last Call, or we can do another
revision first.

In general, this document looks pretty good. But...

- somehwere in the beginning of the document we should explain
  the use of MUST, SHOULD, MAY and such and make a normative
  reference to RFC2119. See bottom of page 4 of RFC3411 for
  an example.
- Page 7 references RFC2493. It will soon be obsoleted by
  RFC2493bis (may want to inform RFC-Editor of that)
- On page 8, towards the bottom:
        Since the current 15-minute counter are reset to 0 every
  s/counter are/counters are/
- Page 10 has a refrence to [RFC2575] which has been obsolted
  by RFC3415 (dec 2002)
- So we ask IANA to assign a value under transmission (for the
  mib module). Is it best to use 97 (for vdsl ifType) ? or
  better not since other ifTypes seem included as well?
- I see that section 2.7 lists the persistence requirements
  for all writable objetcs. It would be good however to say
  something about that in the respective table and or
  object-type DESCRIPTION clauses as well.
- I can live with "DEFVAL" for default values for conf and
  alarm profiles. But would a value of "default" or "Default"
  not be much more intuitive? Just a question.
- When I see things like:
    VdslPhysEntry ::=
        SEQUENCE
            {
            vdslPhysSide                  VdslLineEntity,
            vdslInvSerialNumber            SnmpAdminString,
            vdslInvVendorID                SnmpAdminString,
            vdslInvVersionNumber          SnmpAdminString,
            vdslCurrSnrMgn                Integer32,
            vdslCurrAtn                    Gauge32,
            vdslCurrStatus                BITS,
            vdslCurrOutputPwr              Integer32,
            vdslCurrAttainableRate        Gauge32,
            vdslCurrLineRate              Gauge32
            }
  Then I always wonder why we do not use a naming convention that
  makes it easier on users to quickly see in which table certain
  objects belong. So I would have defined something aka
    VdslPhysEntry ::=
        SEQUENCE
            {
            vdslPhysSide                  VdslLineEntity,
            vdslPhysInvSerialNumber        SnmpAdminString,
            vdslPhysInvVendorID            SnmpAdminString,
            vdslPhysInvVersionNumber      SnmpAdminString,
            vdslPhysCurrSnrMgn            Integer32,
            vdslPhysCurrAtn                Gauge32,
            vdslPhysCurrStatus            BITS,
            vdslPhysCurrOutputPwr          Integer32,
            vdslPhysCurrAttainableRate    Gauge32,
            vdslPhysCurrLineRate          Gauge32
            }
- Similarly, I think I would have named all objects in the
  vdslPerfDataTable with aprefix of vdslPerfDataXxxx
- And smae story for vdslPerfIntervalTable
- and other tables.

- In the vdslPerfDataTable, I wonder why for example
  vdslPerfLofs is an Unsigned32, while vdslPerfCurr15MinLofs is
  a HCPerfCurrentCount. They both seem to be counting seconds, no?
  So is it then needed to have HCPerfCurrentCount for a 15
  minute interval? Would it not be just PerfCurrentCount?
  Or did you prefer to have all xxCurrentCounts in this MIB
  module to be of the same type?
- Similar question for the other places where the HCPerfCurrentCount
  TC is used to count seconds in a 15 minute interval.

- The xxxRowStatus objects do not specify if any (or all, or none)
  of the columnar objects in a column can be changed/modified if
  the RowStatus value is 'active'. So as an implementer or as an
  NM APP developer, how would I know?

Thanks,
Bert

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
> Sent: donderdag 14 augustus 2003 20:24
> To: Wijnen, Bert (Bert)
> Cc: Mike Sneed (E-mail); Bob Ray; Rajesh Abbi
> Subject: Re: VDSL MIB
>
>
> Hi -
>
> > From: "Wijnen, Bert (Bert)"
> > To: "Randy Presuhn (E-mail)"
> > Cc: "Mike Sneed (E-mail)" ; "Wijnen,
> Bert (Bert)"
> > Sent: Wednesday, August 13, 2003 11:36 AM
> > Subject: RE: VDSL MIB
> >
>
> > Randy, I never got a reply from you.
> > I did get one from Mike... and I do trust him, but I would
> > appreciate to get a go-ahead of the main Technical MIB Advisor
> > for this WG.
> ...
>
> Here's what jumped out at me from
> draft-ietf-adslmib-vdsl-10.txt.  All
> the comments *except* the last are very minor
> editorial and could easily be fixed during
> the author's 48 hours if the RFC editor doesn't
> fix them.  I believe it's ready for PS; the additions to
> the security considerations section would be almost
> mechanical given the work that's already been done.
>
> Page 1: "portion of the" -> ""
>
> Page 7: "its vdslLineConfProfile objects" ->
>        "their vdslLineConfProfile objects"
>
> Page 10: "It SHOULD also be noted" ->
>          "It should also be noted"
>
>
> Section 6: the indentation of the bibliographic entries
> changes several times.
>
> Section 8: doesn't fully comply with section 3.6 of
> , in that
> it doesn't list each of the writeable objects.  It looks
> like it (surprise!) was written with an older version of
> the boilerplate, rather than the current one at
> http://www.ops.ietf.org/mib-security.html  I *do* like
> the fact that the text mentions some of the risks
> associated with the notifications in this MIB module.
>
> Randy
>
>