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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 26 Aug 2003 23:06:50 +0200

> Hi Bert.
> 
> I'll make the changes you suggested (along with Randy's earlier
> comments) and will (hopefully) have two new drafts in after the
> weekend.  
> 
great thank you.

> On one of your questions:
> 
> - 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?
> 
> are you suggesting that I just put 'transmission 97' instead of
> 'transmission XXXX' along with the note to the RFC Editor?
> 
I think, assuming that we (as a WG) think that 97 is the best
value to assign, then we should ask IANA to assign value 97.

So the best way to do so is:

  ::= { transmissing XXXX }  -- To be assigned by IANA
  -- we suggest to put it under { transmission 97 } because
  -- 97 is the value of the main ifType for the MIB objects defined
  -- in this MIB module.

Bert
> If so, no problem, but will anyone else have a problem with that?
> 
> Bob Ray
> 

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 25 Sep 2003 11:03:17 +0200

Thanks, Arguments and changes accepted.

Bert 

> -----Original Message-----
> From: Bob Ray [mailto:[email-masked]]
> Sent: woensdag 24 september 2003 21:32
> To: Wijnen, Bert (Bert)
> Cc: Mike Sneed (E-mail); Rajesh Abbi; Randy Presuhn (E-mail); Adslmib
> (E-mail)
> Subject: Re: AD review of draft-ietf-adslmib-vdsl-10.txt
> 
> 
> On Tue, 2003-08-26 at 10:15, Wijnen, Bert (Bert) wrote:
> 
> Hi.
> 
> > - 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.
> 
> 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.
> 
> > - 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?
> 
> Yes, they are counting seconds.  However, vdslPerfCurr15MinLofs is
> bound by the textual conventions found in the hc-tc while vdslPerfLofs
> is not.
> 
> >   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.
> 
> 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.  
> 
> > - 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?
> 
> 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]>
>