Re: [Disman] draft-ietf-disman-event-mib-v2-06.txt: Issue-1 ->"MAY not"

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Dave Shield" <[e-mail]>
> To: "Randy Presuhn" <[e-mail]>
> Cc: "Disman (E-mail)" <[e-mail]>
> Sent: Tuesday, July 19, 2005 4:04 AM
> Subject: Re: [Disman] draft-ietf-disman-event-mib-v2-06.txt: Issue-1 ->"MAY not"
...
> > I would hope that the changes to mteEventEntryStatus would be similar.
> > My guess is that the first one was probably what was intended.
>
> Can I ask why?

Because the second interpretation makes things even more complicated for
management applications.  My personal preference would have been to
require implementations to support modification while active, but I
don't recall that we had consensus for that.

> There does seem to be a general tendency in a lot of MIBs to forbid
> *any* alteration to existing rows, and I've never really understood
> this.

Yup.  Back in my days as an implementor, I couldn't understand it either.
Folks seem to think it makes things simpler, but in general I haven't
found it to be true.  A case where it *does* make sense is where a
row can be thought of as a marshalling area for the parameters of an
action invocation (remote procedure call).  But for the most part,
I think it simpler and more robust to define the behaviour when
dependencies aren't satisfied than it is to define a creation / deletion
hierarchy.

>   What is the fundamental objection to being able to tweak the
> notification that is sent in response to some event, or the list
> of varbinds that should be included?
...

Personally, I don't have any.  I get the feeling that it may be
at least in part a question of how the different phases in the
validation of set requests are handled in various SNMP toolkits.

Looking ahead, it will be most interesting to see how netconf and
netconf data models deal with configuring things like this.

Randy