RE: Comments on draft-ietf-disman-conditionmib-10.txt

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

Is your substantive comment not addressed by the RFC-Editor
note I have also proposed to Russ:

In security section, page 13, replace this text:

   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.

with this text:

   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.

The RFC-Editor has responded to your TOC concern.

Not sure if we would remove "redundant" text as long as both
texts are in sync with each other, but I have asked WG to
consider the issue.

Thanks,
Bert 

> -----Original Message-----
> From: Margaret.Wasserman@nokia.com 
> [mailto:Margaret.Wasserman@nokia.com]
> Sent: woensdag 1 oktober 2003 23:16
> To: iesg@ietf.org
> Subject: Comments on draft-ietf-disman-conditionmib-10.txt
> 
> 
> 
> I've reviewed draft-ietf-disman-conditionmib-10.txt, and
> I have a few comments (below).  I registered a DISCUSS
> for my one substantive comment below, but I could probably
> be talked out of this if others don't think it is a
> concern.  The rest of my comments are editorial.
> 
> Margaret
> 
> 
> SUBSTANTIVE
> 
> IMO, the security considerations section should indicate
> something about the fact that turning off alarms for 
> particular conditions could be used to prevent detection 
> of some types of attacks.  For instance, turning off 
> threshold alarms might be used to prevent one possible 
> means of detecting a DoS attack that involved sending a 
> large number of packets to/through an interface.
> 
> EDITORIAL
> 
> TOC does not have page numbers.  Will the RFC editor fix
> this later?
> 
> There are two semi-redundant descriptions of the values
> for ARC state -- one in the description of the arcTable
> object, and the other in the description of arcState.
> They don't seem to conflict, but it would be clearer if
> they were combined in one location.
>