[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-ietf-disman-conditionmib



Fine with me.

It is obvious to you because you deal with MIBs all of the time. I do not think that all readers will have the background.

Russ

At 04:06 PM 10/1/2003 +0200, Wijnen, Bert (Bert) wrote:
Seems pretty obvious to me. But what I propose to do
is that we make an RFC-Editor note for that change.
I will check with WG if they have any issues with
your proposed text.

Thanks,
Bert

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: woensdag 1 oktober 2003 15:57
> To: bwijnen@lucent.com; iesg@ietf.org
> Subject: RE: draft-ietf-disman-conditionmib
>
>
> Bert:
>
> No, that is not my point.  I propose:
>
>     Setting these objects may have disruptive effects on network
>     operation that range from omission of alarm notifications to
>     flooding of unwanted alarm notifications from the network.
>     The consequence of suppressing or deferring the reporting
>     of an alarm can prevent the timely delivery of important
>     diagnostic information, including information that can help
>     identify an attack.
>
> Russ
>
>
> At 03:45 PM 10/1/2003 +0200, Wijnen, Bert (Bert) wrote:
> > > >But... it is not JUST Boilerplate !!!
> > > >I did (and normally always do) ask them to be specific
> and explain
> > > >what the vulnerabilities are and I think they did. They
> have in the
> > > >security section:
> > > >
> > > >   network operations.  These are the tables and objects
> and their
> > > >   sensitivity/vulnerability:
> > > >
> > > >      arcTITimeInterval,
> > > >      arcCDTimeInterval,
> > > >      arcState,
> > > >      arcNalmTimeRemaining,
> > > >      arcRowStatus,
> > > >      arcStorageType.
> > > >
> > > >   Setting these objects may have disruptive effects on network
> > > >   operation that range from omission of alarm notifications
> > > >   to flooding of unwanted alarm notifications from the netowrk.
> > > >
> > > >Maybe you do not find that detailed/speciifc enough?
> > > >But I am not sure we want them to go into detail about specific
> > > >alarms, cause this table is a generic table.
> > >
> > > You are right about the boilerplate.  But, it is quite generic.
> > > I realize that is because the alarms are not defined here.
> > > However, the "omission of alarm notifications" is obvious.
> > > That is what the whole document is describing.  The consequence of
> > > masking the alarms is that important
> > > diagnostic information is suppressed.  And, that is not said.
> > >
> >Not sure I am getting you. WOuld you consider this better:
> >
> >    Setting these objects may have disruptive effects on network
> >    operation that range from omission of alarm notifications,
> >    to masking of alarm notifications to flooding of unwanted
> >    alarm notifications from the network.
> >
> >Not sure the WG agrees, but I can check.
> >Or do you have a better wording proposal.
> >
> >Bert
> > > Russ
> > >
>