RE: Help/guidance on L2TPv3 MIB draft

["Natale, Robert C (Bob)" <bnatale@lucent.com>]

Hi Andy,

I think you have missed the point of the
discussion around AgentX at the time it
was developed concerning MIB design.  There
are some MIB design approaches that are
preferable for (open standard) extensible
agent implementation in general.  Enabling
multi-sub-agent support of sub-agent-specific
configuration (or similar) attributes --
normally represented as scalar objects in
monolithic agent designs -- via the tabular
approach that you seem to consider "more
complicated" (?) is one of those straight-
forward (my assertion) approaches.  Our hope
was to promote such MIB design choices going
forward.  Improving MIB designs along these
lines *might* become more important if the
SNMP community decides to extend the scope
of MIB functionality as part of an attempt
to rejuvenate SNMP[v3] as the management
protocol of choice in ever-wider arenas.

As per its original design intent -- and
the Applicability statements in section 4.2
of RFC2741 -- AgentX can certainly support
MIB designs that implement a monolithic
agent approach to scalar objects...in which
case a single-sub-agent handles such objects
(which might or might not be a limitation
for any given application...and wouldn't be
for any MIB that is expected to be implemented
only by a single sub-agent with a given
master agent scope).

Cheers,

BobN
- - - - -
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Sunday, September 29, 2002 4:18 PM
> To: Natale, Robert C (Bob)
> Cc: Jed Lau; mibs@ops.ietf.org; agentx@dorothy.bmc.com
> Subject: Re: Help/guidance on L2TPv3 MIB draft
> 
> 
> At 03:46 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote:
> >At 8/19/2002:08:26 PM, Jed Lau <jedlau@cisco.com> wrote:
> 
> I have a strong objection to this suggestion to change
> a MIB design solely to make AgentX implementations easier.
> When AgentX was chartered, there was an understanding that 
> sub-agents would be transparent to NMS applications (command 
> generators).  Asking MIB writers to use a more complicated
> design is a hack. It makes the MIB more complicated
> for everybody, for the sake of a corner case. That's not
> good engineering.
> 
> Andy
> 
> 
> 
> >Hi Jed,
> >
> >Please review this MIB for compatibility with the
> >IETF standard SNMP agent extensibility protocol,
> >AgentX (RFC2741...and RFC2742 can also give you
> >some additional insight into AgentX operations).
> >
> >The fundamental issue is that scalar objects are
> >potentially problematic for AgentX. They should be
> >avoided by putting them into a table indexed by
> >some form of "AgentEntityID" object (an exercise
> >left to the implementer for now :-().
> >
> >Note that the issue of AgentX compatibility for
> >MIB writers will be addressed in a forthcoming
> >Internet Draft that I will submit...perhaps with
> >an extended applicability statement for AgentX
> >(Sections 4.2, 4.3, and 4.4 of RFC2741 do a good
> >job of the basics already)...for consideration by
> >the relevant IETF WGs. My hope is that consideration
> >of this Draft will lead to adding a statement or two
> >to the standard "SNMP Framework" boilerplate to
> >document these requirements for MIB writers.
> >
> >Guidance from Bert re where to discuss this
> >issue -- AgentX compatibility guidelines for
> >SNMP MIBs -- will be appreciated. (The AgentX
> >e-mail list is still operative, but the WG is
> >closed pending further work when its time to
> >move to Full Standard status.)
> >
> >Cheers,
> >
> >BobN
> >- - - - -
> >>Hi,
> >>
> >>I am one of three co-authors of the L2TPv3 MIB draft. I 
> attended the IETF
> >in
> >>Yokohama in July, and I got this e-mail address during one of the
> >plenaries. I
> >>understand that somebody behind this e-mail address might be able to
> >provide us
> >>with some guidance in developing our MIB.
> >>
> >>The first draft of the MIB is 
> <draft-ietf-l2tpext-l2tpmib-base-00.txt>.
> >We'd
> >>like to get some feedback regarding our organization of the 
> MIB tables. The
> >>L2TPv3 (Layer Two Tunneling Protocol, Version 3) MIB 
> borrows a lot from its
> >>predecessor, <draft-ietf-l2tpext-l2tp-mib-04.txt>. However, 
> it introduces a
> >>new framework that, we hope, allows us to better modularize 
> the various
> >>components of the tunneling protocol (e.g. pseudowire, 
> payload, transport,
> >>etc.). The intention is to allow future enhancements to the 
> protocol (e.g.
> >>additions to the list of supported payloads or transport 
> types) to occur in
> >>scalable and modular manner.
> >>
> >>I intend to go into further details and ask some specific 
> questions in a
> >>subsequent e-mail. Should I send follow-up e-mails to this 
> address, or
> >should
> >>I interface with a specific individual?
> >>
> >>Thanks in advance.
> >>
> >>Jed Lau 
>