Subject: [Adslmib] AD review of draft-ietf-adslmib-vdsl-10.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 26 Aug 2003 17:15:11 +0200

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:[email-masked]]
> 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)" <[email-masked]>
> > To: "Randy Presuhn (E-mail)" <[email-masked]>
> > Cc: "Mike Sneed (E-mail)" <[email-masked]>; "Wijnen, 
> Bert (Bert)" <[email-masked]>
> > 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
> <draft-ietf-ops-mib-review-guidelines-02a.txt>, 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
> 
> 

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: Bob Ray <[email-masked]>
Date: 24 Sep 2003 14:31:32 -0500

On Tue, 2003-08-26 at 10:15, Wijnen, Bert (Bert) wrote:

Hi.

>   not be much more intuitive? Just a question.

Because that's the way RFC2662 did it.  I've floated alternatives
over the past 2-3 years, but they've all been shot down.

>   a HCPerfCurrentCount. They both seem to be counting seconds, no?

Yes, they are counting seconds.  However, vdslPerfCurr15MinLofs is
bound by the textual conventions found in the hc-tc while vdslPerfLofs
is not.

>   TC is used to count seconds in a 15 minute interval.

I could have selectively used PerfCurrentCount for some of the
objects and HCPerfCurrentCount for others.  However, I preferred
(as you note) to use just one set of 15 minute textual conventions.

In earlier versions of the 'base' vdsl MIB (before the line-code
specific objects were spun off into separate documents), there was 
far more extensive use of the high capacity conventions.  

>   NM APP developer, how would I know?

I've augmented the descriptions (in an unsubmitted draft here) of the
two RowStatus objects as follows: 

        To vdslLineConfProfRowStatus, I added:

            An 'active' profile may be modified at any time.  Note
            that some changes may require that any referenced lines be
            restarted (e.g. vdslLineConfLineType)."
  
        To vdslLineAlarmConfProfRowStatus, I added 

            An 'active' profile may be modified at any time."

-- 
Bob Ray <[email-masked]>