Alarm Reporting Control Management Information Base (MIB)
draft-ietf-disman-conditionmib-10

[Ballot discuss]
Comments on draft-ietf-disman-conditionmib-10.txt:

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.

[Ballot comment]
The ToC needs to have numbers added.

Buried in the ARCState description is:

" Note that the state alm (alarm reporting is allowed) is not listed
    in the enumeration of the value of this object.  However, this
    state is implicitly supported by the mib.
    Once a resource enters the normal reporting mode (i.e., in the alm
    state) for the specified alarm type, the corresponding
    row will be automatically deleted from the arc table.
    Also the manual setting of arcState to alm can be achieved through
    setting the RowStatus object to 'destroy'.

This seems a major enough design decision on how to accomplish
the work to move it into the text of the document or repeat it there.


The second "even then" in the following text from the Security Considerations
seems spurious

Even if the network itself is secure (for example by using IPSec),
  even then, there is no control as to who on the secure network
  is allowed to access and GET/SET (read/change/create/delete) the
  objects in this MIB module.

[Ballot comment]
The ability to remotely shut off alarms seems to have a slightly different security consideration that the usual MIB document, yet this document has the typical boilerplate.  I do not feel strong enough to register a DISCUSS, but there is something unsettling.  Part of the reason that I do not want to register a DISCUSS is because the alarms themselves are not described in this document.  The context of the alarms needs to be understood to determine the security consequences of masking them.

The IETF Last Call did not receive any comments.
Some comments from WG chair needed some editorial updates which have been made in revision 10.

Now ready for IESG evaluation

Final review by WG chair revealed a few editorial nits (see below). We have decided to consider these IETF Last Call comments and to incorporate fixes for those after IETF Last Call Completes.

-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]
Sent: dinsdag 2 september 2003 22:54
To: Wijnen, Bert (Bert)
Cc: Disman (E-mail)
Subject: Re: Conditionmib version 09


Hi Bert -

I checked through http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-09.txt
and found a couple of really minor nits that could probably be  handled
in the 48-hour review, if the RFC editor doesn't fix them as a matter of course.

The technical issues are really minor.  One is no different from
an existing problem with ifIndex and ifIndexOrZero.  Specifically, automated
tools will be able to generate human-readable labels for the possible
values of IANAItuProbableCause, but not for IANAItuProbableCauseOrZero.
I recommend no action on this item.

The other is that arcRowStatus should specify what objects need to be
set for a row to go active, in accordance with page 21 of
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt
I believe the intent is that all *except* arcNalmTimeRemaining must be set.
I think arcNalmTimeRemaining *may* be set at create time, but this would
have no effect given the current wording of the third paragraph of its DESCRIPTION.

Purely editorial:

indentation of (a) in section 4's first paragraph is odd.

section 4.2 isn't really needed; one would expect to find it in an IANA
considerations section if it were retained.

arcTITimeInterval needs UNITS.  (already in DESCRIPTION, so editorial)

arcCDTimeInterval needs a UNITS clause.  (already in DESCRIPTION, so editorial)

arcNalmTimeRemaining needs a UNITS clause.  (It's already in the DESCRIPTION,
so this is editorial.)

Section 6: isn't fully aligned with section 3.6 of
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt
or the latest boilerplate at http://www.ops.ietf.org/mib-security.html
However, it *does* cover some interesting threats not addressed by the
boilerplate, and I think it meets the spirit of the requirement.

Section 8.1: the year for reference "zzzz" won't be 2002.

Randy

Checking with WG chair if we want another rev now or if we want to do an IETF Last Call first

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: vrijdag 6 juni 2003 15:32
To: Lam, Hing-Kam (Kam); 'a_n_huynh@yahoo.com'; 'David Perkins'
Cc: Disman (E-mail) (E-mail)
Subject: AD review of: draft-ietf-disman-conditionmib-08.txt


Here is my review of rev 8.

If you want, we can issue IETF Last Call, and then you may
consider these comments as IETF Last Call Comments, that you
better address rigth after such an IETF Last Call.

More or less serious:

- I see
    IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION
      STATUS  current
      DESCRIPTION
      "This TC can take any value of IANAItuProbableCause or 0.
        IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC
        module in the Alarm MIB document (see RFC zzzz)."
      REFERENCE
        "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, mmm 2002."
    -- RFC Ed.: replace zzzz with the RFC number of the Alarm MIB document,
    --          replace mmm with the actual month, and remove this notice.
  And so I wonder. That IANA mantained MIB module will be extracted from
  the document, and after that, the authoritative version will be at
  the iana web site as follows:
      http://www.iana.org/assignments/ianaitualarmtc-mib 
  Now putting a url into the REF clause is not good either, but maybe
  something aka:
      REFERENCE
        "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site.
        The initial module was also published in RFC zzzz."
  However, you do want to add that
        http://www.iana.org/assignments/ianaitualarmtc-mib
  in the normative references section, cause one must understand it in
  order to udnerstand your TC and how it is used.

- I believe that the arcEntry should include in its DESCRIPTION clause
  some text about the fact that the indexing can cause OIDs of more
  than 128 sub-IDs (which are not supported bu SNMPv1, SNMPv2c or SNMPv3).
  This is caused by OIDs for ResourceId syntax of arcIndex and for
  arcNotificationId. So some text as to how people can/should avoid
  an OID of more than 128 sub-IDs shoiuld be added.

- arcRowStatus OBJECT-TYPE
  In the DESCRIPTION clause, pls describe if any objedcts in a row can
  or cannot be updated while the row is in active state. Such is required
  as per RFC2579.

Questions:
- I see
      arcTITimeInterval OBJECT-TYPE
        SYNTAX  Gauge32
  and
      arcCDTimeInterval OBJECT-TYPE
        SYNTAX  Gauge32
  is that a proper syntax for an interval ??
  there are a few more of these.

- I see two informative references (RFC1213 and RFC2863), but I do not
  see any citations to it. So are they needed or useful?

NITS:

- Can you do real pagination?

- I see " This document defines the SNMP objects..."
  I think they are "MIB  objects" rather than "SNMP objects"

- I see "  The ARC MIB defined in" a few times.
  I think it is better to write "The ARC MIB module ....."

- I see:
      DESCRIPTION
        "The MIB module describes the objects for controlling a resource
          in reporting alarm conditions that it detects.

            Copyright (C) The Internet Society (2003).  This version
            of this MIB module is part of RFC yyyy;  see the RFC
            itself for full legal notices."
  -- RFC Ed.: replace yyyy with actual RFC number & remove this note
      REVISION  "200304160000Z"
      DESCRIPTION
        "Initial version, published as RFC xxxx."
  -- RFC Ed.: replace xxxx with actual RFC number & remove this note
      ::={ mib-2 yy }  --  to be assigned by IANA
  -- RFC Ed.: replace yy with IANA-assigned number & remove this note
  It might be easier if you used xxxx instead of yyyy, After all,
  these are both going to be the same RFC number, no?

bert

Based on my review of the alarm mib, the author/editor
stated in the WG that he will do another rev to address those comments that also apply to this document.