Subject: [MIB-DOCTORS] MIB doctor review of draft-ietf-forces-mib-04

From: John Flick <[email-masked]>
Date: Thu, 07 Dec 2006 16:37:43 -0800

Hi,

I have completed my review of draft-ietf-forces-mib-04, as
requested by Dan Romascanu.

The following comments are structured according to the MIB
Review Checklist in Appendix A of RFC 4181.

1. I-D Boilerplate OK.  Note that if this document is updated,
the copyright statement needs to be updated to The IETF Trust
instead of The Internet Society.

2. Abstract - the final sentence seems unnecessary.  An RFC
published from this document is likely to outlive the ForCES
working group.

3. MIB Boilerplate - should appear as a standalone section
with a verbatim copy of the approved text, not intermingled
with the specific introduction text for this document.  Also, the
MIB module definition should be in its own section.  The narrative
text in section three should be in a separate "Overview" or
"Structure of this MIB" section.

4. Security Considerations - should follow the approved
boilerplate at http://www.ops.ietf.org/mib-security.html.
In particular, the following is missing:

    There are no management objects defined in this MIB module that have
    a MAX-ACCESS clause of read-write and/or read-create.  So, if this
    MIB module is implemented correctly, then there is no risk that an
    intruder can alter or create any management objects of this MIB
    module via direct SNMP SET operations.

    ...

                                              It is thus important to
    control even GET and/or NOTIFY access to these objects and possibly
    to even encrypt the values of these objects when sending them over
    the network via SNMP.  These are the tables and objects and their
    sensitivity/vulnerability:

     <list the tables and objects and state why they are sensitive>

This section should list the objects or classes of objects (for example,
saying "statistics" is acceptable) and talk about whether they have
any vulnerablities.  If there are none, that should be explicitly
stated.  The IESG does not take no listed vulnerablities as meaning
there are none.  They treat it as an omission, and bounce the document
back to the WG for correction.

5. IANA Considerations Section - OK

6. References - OK

7. Copyright Notices - There needs to be a copyright notice in the
DESCRIPTION clause of the MODULE-IDENTITY.  See RFC 4181, Section 3.7.
If this document is updated for other reasons, the Full Copyright
Statement needs to be updated to The IETF Trust.

8. IPR Notice - OK

9. ID-Checklist issues - OK

10. Technical content

10.1  smilint returns the following warning:

mibs/FORCES-MIB:47: [5] {type-without-format} warning: type
`ForcesProtocolVersion' has no format specification

10.2  smicng: no errors or warnings

10.3  MODULE-IDENTITY missing copyright

10.4  MODULE-IDENTITY ORGANIZATION should probably mention IETF, e.g.:

     ORGANIZATION "IETF Forwarding and Control Element Separation
                  (ForCES) Working Group"

10.5  MODULE-IDENTITY CONTACT-INFO typically includes information on how
to reach the working group.  See RFC 4711 for a recent example.  See
RFC 4181 Section 4.5, first bullet.

10.6  forcesAssociationEntryUp and forcesAssociationEntryDown: should
these notifications be throttled?  If so, the DESCRIPTION needs to
say so.

10.7   Not sure if including counters in the forcesAssociationEntryDown
notification makes sense - counters normally only have meaning as a
delta between two samples, not as an absolute value.  Note that
counters have no defined initial value, so cannot be assumed to
start at zero.

10.8   forcesAssocationTimeDown - in the narrative text, you state that 
this is only here for inclusion in notifications.  Should the MAX-ACCESS
be accessible-for-notify?

10.9  Counters which can become discontinuous need to indicate how
a management station can detect discontinuities.  I would assume that
if an association dies and is later re-created (e.g. on a hot swap)
that the agent is not required to maintain counters across this
event.  If the new association would have the same
forcesAssociationCEID and forcesAssociationFEID as the old one, the
management station needs to be able to detect that this is a new
association, and it cannot delta this counter sample from the previous
one.  I assume that forcesAssociationTimeUp would be the correct
object to use to detect this, but the counter DESCRIPTION clauses
need to say so.

10.10  forcesibCompliance - there appears to be a dependency issue
between your mandatory and optional groups.  forcesStatsGroup is
optional in this compliance statement, and forcesNotificationGroup is
mandatory, but the forcesAssociationEntryDown notification, which
is in the mandatory forcesNotificationGroup, includes objects from
the optional forcesStatsGroup.  I don't think you can have a
mandatory notification that includes optional objects in its OBJECTS
clause.

Hope this helps,
John

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Patrick Droz <[email-masked]>
Date: Fri, 08 Dec 2006 14:09:08 +0100

Hi John,

I would like to thank you for review this is definitely
helpful move forward with the draft.

Regards,
Patrick

-- 
   Dr. Patrick Droz                  | [email-masked]
   IBM Zurich Research Laboratory    | http://www.zurich.ibm.com/~dro
   Saumerstrasse 4                   | Tel. +41-44-724-85-25
   CH-8803 Rueschlikon/Switzerland   | Fax. +41-44-724-85-78
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors