RE: use of OBJECT-IDENTITY

["Harrington, David" <dbh@enterasys.com>]

Hi Dave,

I'm reviewing the document and there are a bunch of things I have not
yet identified as needing correction. Some things Bert and I have
already caught. Some comments inline. 

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Wednesday, March 17, 2004 2:45 PM
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: Re: use of OBJECT-IDENTITY
> 
> HI,
> 
> The use of the OBJECT-IDENTITY construct doesn't bother me.
> 
> However, there are several other design choices that do bother
> me, including:
>   1) "relaxed" usage of the term MIB (it's just sloppy).
>      Term "MIB tree" is just wrong.
Bert pointed this on out already
>   2) use of counter64 instead of counter32, or is the current
>      approach changed to always use counter64 so you do not
>      have to be concerned of counter rollover?
There has been substantial discussion about counter sizes. I think it is
unclear how high the values could go in what time frame. The mib
guidelines say the one-hour rollover guideline is no longer of interest,
since snmpv1 is "not recommended".
>   3) use of "accessible-for-notify". There should be little, if
>      any, use of this max-access value. The problem is that
>      notifications cannot be guaranteed to be delivered,
>      and if the MIB model design is based-on management info
>      being available only via notifications, then there will
>      be times when needed info is not available.
Responses also canot be guaranteed to be delivered, but there are
methods to determine whether it was delivered or not, and Informs allow
for acknowledgements. Traps must always be recognized an no-guarantee. 
>   4) indexing, number of instances, and relationships between
>      tables is not immediately obvious nor fully described.
>      In each table description, there MUST be a sentence or
>      two that provides the reader a clue to the number of
>      instances in the table. This could be as simple as
>      saying the number corresponded to the number of a
>      specific type of physical components. Or this could
>      correspond to the number of instances in another table.
>      Or it could be the number of "provisioned" entries of
>      some logical resource. In addition, the DESCRIPTION
>      clause for rows MUST indicate if row creation is allow
>      or not, if so, then details.
Does the description clause need to identify when rows can be created by
the agent only? 
>   5) There are no objects with access of read-create or read-write.
>      This seems VERY strange.
Agreed, and concern expressed on this point. I think the MIB is
following the AD/IESG guidelines that a WG does NOT have to produce
writable mibs. For data that looks like it is meant to be
user-configurable, I think making configuration objects read-only is
questionable practice.
>      
> PS  Have you looked at 
> http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-
00.txt. It does some creative (not quite valid) things.
> 
> At 04:44 PM 3/17/2004 +0100, Wijnen, Bert (Bert) wrote:
> >In draft-ietf-dhc-server-mib-10.txt I see the use of
> >OBJECT-IDENTITY that I think was not intended.
> >
> >Comments?
> >
> >Thanks,
> >Bert 
> Regards,
> /david t. perkins  
> 
> 
>