RE: draft-ietf-disman-conditionmib

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Ack. that is why I go along with and support the change.
Thanks for keeping me (us) honest

Thanks,
Bert 

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: woensdag 1 oktober 2003 16:31
> To: Wijnen, Bert (Bert); iesg@ietf.org
> Subject: 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
> > > > >
> > >
>