Subject: [Mip6] MIB Doctor review for: draft-ietf-mip6-mipv6-mib-05.txt

From: "C. M. Heard" <[email-masked]>
Date: Fri, 26 Nov 2004 17:18:20 -0800 (PST)

Greetings,

This MIB Doctor review of the MOBILEIPV6-MIB document looks at
draft-ietf-mip6-mipv6-mib-05.txt.  It is a follow-up to a previous
review posted to the MIP6 mailing list on 15 October 2004 that dealt
with draft-ietf-mip6-mipv6-mib-04.txt.  While all comments in the
previous review have been addressed by the -05 draft (for which I
thank the authors), there are a number of new issues raised in this
draft because I have finally had time to do a detailed reading of
the MIB module (which I did not do before).  The new issues are for
the most part "non-mechanical" things (such as lack of clarity in
DESCRIPTION clauses) that can only be caught by a detailed reading
of the MIB module.  My apologies for not being able to do this
sooner.  Let me hasten to say that for the most part I am quite
pleased with the overall quality of this MIB module, and I believe
that all the issues that I raise here will be quite easy to correct.

One thing that I need to point out to the WG group is that while I
know a good deal about MIB design, I am _not_ an expert on the MIP6
protocol, and because of that I am not always able to determine if
the right things are being instrumented, or if something necessary
is being omitted.  It is therefore STRONGLY recommended that WG
members with that kind of knowledge carefully review the document
with an eye to those sorts of issues.

As before, the format of the review is patterned after the checklist
in Appendix A of <draft-ietf-ops-mib-review-guidelines-03.txt>.
Those who wish to comment on it are asked to post their remarks to
the MIP6 mailing list with copies to Bert Wijnen and myself.

1.) I-D Boilerplate -- OK

2.) Abstract -- OK

3.) MIB Boilerplate -- OK

4.) IPR Notice -- OK

5.) References -- OK

6.) Security Considerations Section -- OK

7.) IANA Considerations Section -- OK

8.) Copyright Notices -- OK

9.)  Other issues (e.g., from http://www.ietf.org/ID-Checklist.html)
that are not covered elsewhere:

Typos --

(a) In Section 2.1, 1st paragraph:

OLD:
   Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which allows nodes
   to remain reachable while moving around in the IPv6 Internet. An
   entity which implements the MIPv6 protocol is an MIPv6 entity. There
__________________________________________________^
   are three types of entities envisaged by the MIPv6 protocol.

NEW:
   Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which allows nodes
   to remain reachable while moving around in the IPv6 Internet. An
   entity which implements the MIPv6 protocol is an MIPv6 entity. There
   are three types of entities envisaged by the MIPv6 protocol.

(b) In Section 4:

s/mip6HaGlobalAddrTable/mip6HaGlAddrTable/

(c) In the MIB module, mip6BindingHistoryEntry definition:

OLD:
        mip6BindingHistoryEntry OBJECT-TYPE
           SYNTAX      Mip6BindingHistoryEntry
           MAX-ACCESS  not-accessible
           STATUS      current
           DESCRIPTION
                   "The record of a binding .
___________________________________________^

NEW:
        mip6BindingHistoryEntry OBJECT-TYPE
           SYNTAX      Mip6BindingHistoryEntry
           MAX-ACCESS  not-accessible
           STATUS      current
           DESCRIPTION
                   "The record of a binding.

(d) In the REFERENCE clauses of mip6CnSeqNumberOutOfWindow,
mip6CnExpiredHomeNonceIndex, mip6CnExpiredCareOfNonceIndex,
mip6CnExpiredNonce, and mip6CnRegTypeChangeDisallowed:

OLD:
                   "RFC3775 : Section 6.1.8 9.5.1"
NEW:
                   "RFC3775 : Section 6.1.8, 9.5.1"

(e) In the DESCRIPTION clause of mip6CnRegTypeChangeDisallowed:

OLD:
                   "The total number of Binding Updates rejected by
                    correspondent node with status code in the Binding
                    Acknowledgment message indicating 'registration
                    type change disallowed' (Code 139 i.e. a binding
_____________________________________________________^____^
                    already exists for the given home address and the
                    home registration flag has a different value than
                    the Home Registration (H) bit in the Binding Update.
_______________________________________________________________________^
NEW:
                   "The total number of Binding Updates rejected by
                    correspondent node with status code in the Binding
                    Acknowledgment message indicating 'registration
                    type change disallowed' (Code 139, i.e., a binding
                    already exists for the given home address and the
                    home registration flag has a different value than
                    the Home Registration (H) bit in the Binding
                    Update).

10.) Technical content -- review of actual technical content for
compliance with <draft-ietf-ops-mib-review-guidelines-03.txt>:

(a) MIB compilation using smilint --

The program smilint 0.4.3, as of Wed Aug 18 15:45:50 2004
has been used to process your request as follows:

smilint -m -s -e -l 9 -i namelength-32 MOBILEIPV6-MIB

MOBILEIPV6-MIB:187: [5] {index-exceeds-too-large} warning: index of
row `mip6BindingCacheEntry' can exceed OID size limit by 142
subidentifier(s)
MOBILEIPV6-MIB:401: [5] {index-exceeds-too-large} warning: index of
row `mip6BindingHistoryEntry' can exceed OID size limit by 143
subidentifier(s)
MOBILEIPV6-MIB:765: [5] {index-exceeds-too-large} warning: index of
row `mip6NodeTrafficEntry' can exceed OID size limit by 142
subidentifier(s)
MOBILEIPV6-MIB:994: [5] {index-exceeds-too-large} warning: index of
row `mip6MnHomeAddressEntry' can exceed OID size limit by 142
subidentifier(s)
MOBILEIPV6-MIB:1232: [5] {index-exceeds-too-large} warning: index of
row `mip6MnBLEntry' can exceed OID size limit by 399
subidentifier(s)
MOBILEIPV6-MIB:1897: [5] {index-exceeds-too-large} warning: index of
row `mip6CnCounterEntry' can exceed OID size limit by 142
subidentifier(s)
MOBILEIPV6-MIB:2503: [5] {index-exceeds-too-large} warning: index of
row `mip6HaCounterEntry' can exceed OID size limit by 142
subidentifier(s)
MOBILEIPV6-MIB:2641: [5] {index-exceeds-too-large} warning: index of
row `mip6HaListEntry' can exceed OID size limit by 143
subidentifier(s)
MOBILEIPV6-MIB:2756: [5] {index-exceeds-too-large} warning: index of
row `mip6HaGlAddrEntry' can exceed OID size limit by 144
subidentifier(s)

These warnings are an expected result of using InetAddress objects in
the INDEX clauses, and simply serve to indicate that certain size
restrictions have to be observed in order for the MIB module to be
useable with SNMPv1, SNMPv2c, or SNMPv3.  In each case the conceptual
row DESCRIPTION clause documents those restrictions and thus complies
with the MIB review guidelines.  No corrective action is required.

Compilation with SMICng and mosy resulted in no errors or warnings.

(b) Persistence of read-write values -- Section 4.6.2 of
draft-ietf-ops-mib-review-guidelines-03.txt makes the following
recommendation:

   For read-write objects (other than columns in read-create tables that
   have well-defined persistence properties) it is RECOMMENDED that the
   DESCRIPTION clause specify what happens to the value after an agent
   reboot.  Among the possibilities are that the value remains
   unchanged, that it reverts to a well-defined default value, or that
   the result is implementation-dependent.

There are seven read-write objects in the MOBILEIPV6-MIB:  mip6Status
(a scalar), mip6BindingAdminStatus (a member of mip6BindingCacheEntry),
and mip6HaAdvPreference, mip6HaAdvLifetime, mip6HaPrefixAdv,
mip6HaPrefixSolicitation, and mip6HaMCastCtlMsgSupport (all members of
mip6HaConfEntry).  For none of these objects does the DESCRIPTION
clause specify what happens to the value after an agent reboot.

For mip6Status I would suggest that the DESCRIPTION clause say at
least that the last value set SHOULD survive an agent reboot.

For mip6BindingAdminStatus it seems the value should share fate with
the other members of the corresponsing mip6BindingCacheEntry row
instance.  I would expect that the rows in this table would not
survive a reboot, but I am not a MIP6 protocol expert and as such
I don't actually know what is expected of an implementation.  If
I am correct in assuming that the mip6BindingCacheTable is flushed
after a reboot, then a statement to that effect in the
mip6BindingCacheTable or mip6BindingCacheEntry DESCRIPTION clause
would suffice.

For mip6HaAdvPreference and the other members of the mip6HaConfEntry
object it would seem that the ideal policy would be for the last-
written values to survice a reboot, at least when the agent does not
renumber interfaces (i.e., assign new ifIndex/ipv6InterfaceIfIndex
values) after a reboot.  Subject to this proviso, I would suggest
that it be RECOMMENDED that last-written values survive an agent
reboot.  It would be acceptable to have a statement to that effect
in the DESCRIPTION clause of mip6HaConfTable or mip6HaConfEntry.

(c) The REFERENCE clause for mip6Capabilities points to RFC 3775
Section 6.1.8, which does not seem to be appropriate for this
object.  This should be corrected.

(d) There probably should be a REFERENCE clause for mip6BindingMaxSeq
that points to RFC 3775 Section 9.1 (and possibly also Section 9.5.1),
and its SYNTAX value probably should be Unsigned32 (0..65536).

(e) The SYNTAX values for mip6BindingUsageCount and
mip6BindingHstUsageCount are inconsistent:  one is Counter32, and
the other is Unsigned32.  Both should probably be Gauge32, since
that type stops at 2^32-1 (rather than rolling over) if it hits
the maximum value.  Counter32 is not appropriate here since its
behaviour is inconsistent with the DESCRIPTION.

(f) The mip6TotalTraffic HC counter definitions use an incorrect
SYNTAX value (Counter32 instead of Counter64).  Corrections follow.

OLD:
        mip6HCInOctets  OBJECT-TYPE
           SYNTAX      Counter32
______________________________^^
NEW:
        mip6HCInOctets  OBJECT-TYPE
           SYNTAX      Counter64

OLD:
        mip6HCInPkts    OBJECT-TYPE
           SYNTAX      Counter32
______________________________^^
NEW:
        mip6HCInPkts    OBJECT-TYPE
           SYNTAX      Counter64

OLD:
        mip6HCOutOctets  OBJECT-TYPE
           SYNTAX      Counter32
______________________________^^
NEW:
        mip6HCOutOctets  OBJECT-TYPE
           SYNTAX      Counter64

OLD:
        mip6HCOutPkts    OBJECT-TYPE
           SYNTAX      Counter32
______________________________^^
NEW:
        mip6HCOutPkts    OBJECT-TYPE
           SYNTAX      Counter64

(g) As in (d) above, it seem that the SYNTAX value for
mip6MnBLMaxSeq probably should be Unsigned32 (0..65536).

(h) RFC 3775 specifies that the following piece of information
should be available in the conceptual Binding Update List:

 o  A flag specifying whether or not future Binding Updates should be
    sent to this destination.  The mobile node sets this flag in the
    Binding Update List entry when it receives an ICMP Parameter
    Problem, Code 1, error message in response to a return routability
    message or Binding Update sent to that destination, as described
    in Section 11.3.5.

However, it was not clear to me that this information was available
from the objects in the mip6MnBLTable.  If it can be inferred from
the value of mip6MnBLAccepted perhaps some text explaining how that
is done would be in order.

(i) It might be a good idea to change the SYNTAX value of
mip6MnBLRetransmissions to Gauge32 to ensure that it stops
at 2^32-1 rather than rolling over.

(j) It seems that mip6MnBUAcksFromHA should probably have a REFERENCE
clause pointing to RFC 3775 Section 11.7.3 (as does mip6MnBUAcksFromCN).

(k) It seems that mip6CnBUsAccepted and mip6CnBUsRejected should both
have a REFERENCE clause that points to RFC 3775 Sections 9.5.1 and
9.5.4.  The former has no reference clause;  the latter has one, but
it points only to Section 9.5.1.

(l) The DESCRIPTION clauses for mip6HaAdvsRecd and mip6HaAdvsSent do
not refer to a discontinuity counter.  Since these are global counters,
mip6CounterDiscontinuityTime could be used, i.e., it would be
appropriate to add the following text to the end of the DESCRIPTION
clause:
                    Discontinuities in the value of this counter can
                    occur at re-initialization of the management system,
                    and at other times as indicated by the value of
                    mip6CounterDiscontinuityTime.

(m) The REFERENCE clauses for mip6HaAdvsRecd and mip6HaAdvsSent point
to REF 3775 Sections 6.1.8 and 9.5.1, which do not appear to be
relevant.  These clauses should be corrected (or removed).

(n) The DESCRIPTION clauses of mip6HaPrefixAdv, mip6HaPrefixSolicitation,
and mip6HaMCastCtlMsgSupport COULD be interpreted to mean that a
SetRequest can only change the value from enabled(1) to disabled(2) but
not vice-versa.  I don't believe that was the intent.  Some wordsmithing
is probably in order to clarify this point.  See the DESCRIPTION clause
for mip6Status for a possible template.

(o) The SYNTAX clause for mip6HaGaAddrSeqNo reads:
           SYNTAX      Integer32 (1..1024)    -- put the max value GYM
I was not able to figure out what "max value GYM" means, either from
the draft (since the acronym GYM is not defined anywhere) nor from the
target of the REFERENCE clause (RFC 3775 Section 10.1).  I assume that
this is intended to motivate the range 1..1024, which would be a good
thing to do;  some clarification would probably be a good idea.

(p) It was not entirely clear to me whether the notifications
mip6MnRegistered, mip6MnDeRegistered, and mip6MnMoved are to be
sent by a Mobile Node only or both by a Mobile Node and by a Home
Agent.  Clarification would be appreciated.  Also, it is not clear
why mip6MnDeRegistered has a reference clause while the other two
do not.

(q) mip6CoreCompliance lists the minimum conformance requirements
for all InetAddressType/InetAddress INDEX objects in its DESCRIPTION
clause, but the only conformance GROUP mentioned is the mip6SystemGroup,
which includes only the two scalars mip6Capabilities and mip6Status.
Hence a statements about minimum conformance requirements for INDEX
objects is out of place in this compliance statement.  My recommendation
would be to remove the INDEX-related text from the DESCRIPTION clause of
this compliance statement, and then to cut-and-past the appropriate
parts into the DESCRIPTION clauses of the other compliance statements.

This completes the review of draft-ietf-mip6-mipv6-mib-05.txt.

Regards,

Mike Heard

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 27 Nov 2004 15:01:00 +0100

Thanks for your thourough review Mike!

Bert

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: Saturday, November 27, 2004 02:18
> To: MIP6
> Cc: Wijnen, Bert (Bert)
> Subject: MIB Doctor review for: draft-ietf-mip6-mipv6-mib-05.txt
> 
> 
> Greetings,
>