Re: Challenges for the BGP MIBv2

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Jeffrey Haas" <jhaas@nexthop.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <ietfmibs@ops.ietf.org>
> Sent: Tuesday, September 28, 2004 12:23 PM
> Subject: Re: Challenges for the BGP MIBv2
...
> The objects in question would be read-only for the most part.
>
> The "nicety" that I'm trying to create is that when the MIB walk
> is done, one can fetch a human-readable object and not have to
> construct it from the data.

Based on this, and your other comments, I'd suggest that
the "human-readable" representation be strictly read-only,
and that the algorithm for generating it be fully specified in
its description clause.  I'd suggest that this representation
make it trivial to determine whether a given value is "truncated",
so that management applications will be able to do the right
thing.  (I suspect that lazy implementors will just use the
"exploded" representation, since that would need just one
retrieval / display algorithm rather than two, since an implementation
that used the "human-readable" one would need to be able to
fall back to the complete representation in cases of truncation.)

...
> > According to RFC 2578 (page 38), one of the things that may be done is:
> > (7)  A conceptual row may be augmented by adding new columnar objects at
> >      the end of the row, and making the corresponding update to the
> >      SEQUENCE definition.
>
> This must be done by re-issuing the existing MIB module, correct?

yes.

...
> > For applications (or scripts) doing MIB walks, there's really no difference in
> > code size or complexitity between doing
> >      get-next(T1.a.i, T1.b.i, T1.c.i, T1.x.i)
> > and
> >      get-next(T1.a.i, T1.b.i, T1.c.i, T2.x.i)
>
> I'd agree.  However, this presumes that you know that T2 is there.
...

This is a problem for all objects, not just tables.  Some work (e.g. RMON)
uses "capability" objects to allow management system to quickly identify
what is supported by an implementation.  AGENT-CAPABILITIES
is another (theoretical) alternative.   However, even if an implementation
supports a particular table / object, there's still no guarantee that a manager
will be able to access it.  Think VACM.  Consequently, a robust management
application will be written to deal with the possibility that any of the pieces
of information that it tries to access might be unavailable.

Randy