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

From: Robert Haas <[email-masked]>
Date: Thu, 22 Feb 2007 17:46:51 +0100

John,
Thanks for the detailed review. Please see below for two questions. I 
have resolved all the other issues.

John Flick wrote:
> 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.

In the description we state that the counters have an absolute value. Do 
we need to specify sth additional to make sure they start from zero ? 
See for instance the description of forcesAssociationHBMsgSent :

                  "A counter of how many heartbeat messages have
                   have been sent by the CE on this association
                   since the association entered the UP state.
                   If this association started prior to the last
                   initialization of the network subsystem, then
                   this object contains the value since the
                   initialization."

> 
> 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.

I am not sure about this. The forcesAssociationEntryDown notification 
must at least contain the forcesAssociationRunningProtocolVersion 
object, whereas the other objects are optional. Is there another way to 
express this ?

Thanks,
-Robert

> Hope this helps,
> John

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha

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

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 22 Feb 2007 15:46:49 -0500

Hi,

Comments inline.

> -----Original Message-----
> From: Robert Haas [mailto:[email-masked]] 
> Sent: Thursday, February 22, 2007 11:47 AM
> To: John Flick
> Cc: [email-masked]; [email-masked];
[email-masked]
> Subject: [MIB-DOCTORS] Re: MIB doctor review of 
> draft-ietf-forces-mib-04
> 
I agree with John.

>From RFC2578 section 7.1.6:
"   Counters have no defined "initial" value, and thus, a single value
of
   a Counter has (in general) no information content."

from RFC4181 section 4.6.1.2
   - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
     that there is a requirement that on a discontinuity the counter
     MUST reset to zero or to any other specific value.

If I remember correctly, this rule exists because setting the
value to an indeterminate starting value forces an NMS to use counters
the way counters are designed to be used in SNMP - as relative values
over time, not definite values; you take two readings and calculate
the delta between the relative values (and usually you also read
something like sysUpTime to calculate the corresponding time delta
between readings).

By resetting to zero and counting from there, this gives the
impression the value of the counter on one device can be compared to
the value of the counter on another device. This is not true because
the start of the epoch may not be comparable, so using a zero-based
counter is misleading.

> object, whereas the other objects are optional. Is there 

I am not sure it is legal to have optional objects in a notification's
OBJECTS clause. From rfc2578 section 8.1:
"One and only one object instance for each occurrence of each object
type must be present, and in the specified order, in every instance of
the notification. "
Doesn't this mean that every instance of the notification MUST have an
object present for each object in the OBJECTS clause?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: John Flick <[email-masked]>
Date: Thu, 22 Feb 2007 14:41:29 -0800

Hi,

see inline

> the start of the epoch may not be comparable, so using a zero-based

If you really need the initial zero semantics, you might consider
using the ZeroBasedCounter32 defined in the RMON-2 MIB (RFC 4502).
It is a TC based on the Gauge32 type.

> object present for each object in the OBJECTS clause?

Yes.  There doesn't seem to be a way to express what you want in the
SMI.  However, maybe you could consider defining two different
notifications, one with the optional objects and one without.

John

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 22 Feb 2007 18:11:33 -0500

Hi,
 
> notifications, one with the optional objects and one without.
An alternative, that seems awfully sloppy to me, is to define a
notification without the optional objects, and then suggest in text
(possibly in the Description) that they can be added to the
notification if they exist. This would be consistent with the rules
that allow implementers to add extra objects onto the end of the
defined notification objects. The OBJECTS clause would not guarantee
the presence or ordering of such additional objects.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 23 Feb 2007 12:11:40 +0100

I think I would like/prefer John's alternative over that from 
David Harrington. But both could work I guess.

Bert 

> From: David B Harrington [mailto:[email-masked]] 
> Sent: vrijdag 23 februari 2007 0:12
> To: 'John Flick'
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 'Robert Haas'
> Subject: RE: [MIB-DOCTORS] Re: MIB doctor review of 
> draft-ietf-forces-mib-04
> 
> Hi,
>  
> An alternative, that seems awfully sloppy to me, is to define 
> a notification without the optional objects, and then suggest 
> in text (possibly in the Description) that they can be added 
> to the notification if they exist. This would be consistent 
> with the rules that allow implementers to add extra objects 
> onto the end of the defined notification objects. The OBJECTS 
> clause would not guarantee the presence or ordering of such 
> additional objects.
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> 
> 
> 
> 
>