Re: Management Requirements

----- Original Message -----
From: "Dave Thaler" <[email protected]>
To: "Juergen Schoenwaelder" <[email protected]>
Sent: Wednesday, August 08, 2012 12:22 AM
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> > university.de]
> > Sent: Tuesday, August 07, 2012 3:43 PM
> > To: Dave Thaler
> > On Tue, Aug 07, 2012 at 09:51:44PM +0000, Dave Thaler wrote:
> > >
> > > The data instances can have a larger volume and may need to travel
over
> > > shaky links.   Also there's an existing MIB that is outdated and
we want
> > > to obsolete.   So the WG is currently using SNMP for retrieving
> > > operational state and debugging, by doing an update that is
intended
> > > to obsolete the existing MIB RFC.
> >
> > Out of curiosity, is there meanwhile a clear description you can
point to
> > explaining why the old NAT-MIB is broken?
>
> The current text by the authors of the update is at
> http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1

Which worries me.  Section 2 makes a very brief summary of all the
new facilities that have been introduced, eliminates all the much more
detailed description of what is there but is now deprecated.

I did not at first see the new objects and tables since they have been
placed in the I-D after the conformance clauses, not wrong but unusual.

Since almost all of RFC4008 has been deprecated and much new introduced,
to carry on using
natMIB MODULE-IDENTITY
::= { mib-2 123 }
seems inappropriate.

More fundamentally, the considerable amount of detailed work on the
OBJECT-TYPEs and the lack of an explanation in section 2 suggests
that this work has embarked on detailed design before defining the
requirements, an approach which does not always lead to a successful
outcome.

Tom Petch

>
> > > > Perhaps these thoughts help to make a suitable decision. One
could
> > > > of course also ask what the contributors prefer to implement,
e.g.
> > > > what they expect to ease integration into management systems
> > > > relevant for the protocol domain.
> > >
> > > Answered above.   Looking to OPS for clear guidance on what
eventing
> > > protocol to use (or what criteria we should use to decide).   I
don't want
> > > multiple ones.
> >
> > What are the events considered? How frequent will they occur? How
> > stringent are the requirements to deliver them (almost) all or is
the even
> > source designed to throttle notifications? How much data is needed
to
> > describe the events?
>
> One example would be creation/deletion of a mapping table entry.
> Depending on the exact techniques used by the instrumented
implementation
> it may range from extremely frequent and large volume, to infrequent
and
> small volume.   There is no discussion of throttling, only of
techniques
> that one could use to reduce the volume (independent of the protocol
> used to report events).   How much data?   Probably tens of bytes per
event.
>
> > If all that is rather "standard" (in terms of notification
> > volume and individual notification size), then SNMP might just do
fine.
>
> Looking not for what "might do fine" per se, as that might be a large
number of
> protocols, but rather for what single protocol is recommended or
alternatively,
> a set of guidance on how a WG should choose among various protocols.
>
> -Dave
>
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>