Subject: [MIB-DOCTORS] FW: Evaluation: draft-ietf-mext-nemo-mib-04.txt to Proposed Standard

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 13 Jan 2009 14:10:21 +0100

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-mib-01.txt

Technical Summary

  This memo defines a portion of the Management Information Base (MIB),
  the network mobility support (NEMO) MIB, for use with network
  management protocols in the Internet community.  In particular, the
  NEMO MIB will be used to monitor and control a mobile ipv6 node with
  NEMO functionality.

Working Group Summary

  The WG seems to agree in the need for this document and no-one
  seems to oppose to the document. 

Document Quality

  There are some vendors like Cisco working on this MIB
  development. In addition, KAME developers who implemented
  RFC-4295 (Mobile IPv6 MIB) probably will add this support
  as well.

  Alex Petrescu did a thorough review of the MIB.

  The document still needs review by a MIB doctor.

Personnel

  The document shepherd for this document is Marcelo Bagnulo.
  The responsible AD is Jari Arkko. MIB doctor reviewer TBD.

RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)

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

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 13 Jan 2009 22:57:18 +0100

Oh well... the same comment have to be made over and over agin all the time
That is disappointing when I see that one of the editors/authors has
received similar comments from me (and others ) in the past.

SMICng (strict checing) tells me:

   C:\bw\smicng\work>smicng nemo.inc
   W: f(nemo.mi2), (489,6) Row "nemoHomeNetworkPrefixEntry" has indexing
that may
        create variables with more than 128 sub-ids
    E: f(nemo.mi2), (587,39) Index item "nemoEgressIfPriority" must be
defined with
        syntax that includes a range
    W: f(nemo.mi2), (657,5) Row "nemoHaListEntry" has indexing that may
create
          variables with more than 128 sub-ids
    W: f(nemo.mi2), (703,5) Row "nemoMrBLEntry" has indexing that may create
          variables with more than 128 sub-ids
    W: f(nemo.mi2), (769,5) Row "nemoBindingCacheEntry" has indexing that
may
         create variables with more than 128 sub-ids
    W: f(nemo.mi2), (830,5) Row "nemoHaPrefixEntry" has indexing that may
create
         variables with more than 128 sub-ids

For the first and last occurence of the warning, there is a comment in the
DESCRIPTION clauses warning implementers about this fact.
For the occurences at lines 657,703,769. there is no warning at all.

For the Error at line 587, I see:
     nemoEgressIfPriority   OBJECT-TYPE
          SYNTAX      Unsigned32
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
                  "The priority configured to the interface.
                   This value will be configured between 0 and 255.
                  "
          ::= { nemoEgressIfEntry 2 }

So the DESCRIPTION clause does have the RANGE specified. So it seems
easy to use Unsigned32 (0..255)

I see a whole set of writable objects without any description of the
expected
persistency behaviour

I wonder why

      nemoNotifications        OBJECT IDENTIFIER ::= { nemoMIB 0 }
      nemoObjects              OBJECT IDENTIFIER ::= { nemoMIB 1 }
      nemoConformance          OBJECT IDENTIFIER ::= { nemoMIB 3 }

the Conformance is not under { nemoMIB 2 } as recommended by RFC4181.

The following leaves me confused as to what the 5th (of the 5) primary group
is:

      -- The NEMO MIB has the following 5 primary groups

      nemoNotifications        OBJECT IDENTIFIER ::= { nemoMIB 0 }
      nemoObjects              OBJECT IDENTIFIER ::= { nemoMIB 1 }
      nemoConformance          OBJECT IDENTIFIER ::= { nemoMIB 3 }
      nemoCore                 OBJECT IDENTIFIER ::= { nemoObjects 1 }
      nemoMr                   OBJECT IDENTIFIER ::= { nemoObjects 2 }
      nemoCn                   OBJECT IDENTIFIER ::= { nemoObjects 3 }
      nemoHa                   OBJECT IDENTIFIER ::= { nemoObjects 4 }

I wonder if several of the Gaug32 SYNTAXes would not be better a Unsigned32.
I can see that the values of various of these go from 0 to a large number
and
then they can possibly latch there till it starts anew from zero. But is
that what
we normally consider a Gauge?

I see sequences of this:

     nemoRegHomeAgentAddressType OBJECT-TYPE
          SYNTAX      InetAddressType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION

                  "The address type of the nemoRegHomeAgentAddress
                   that follows.
                  "
          REFERENCE
              "RFC3963 : Section 3"
          ::= { nemoSystem 6 }

     nemoRegHomeAgentAddress OBJECT-TYPE
          SYNTAX      InetAddress
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
                  "The home agent address of the mobile router which
                   was used in the last accepted registration.
                  "
          REFERENCE
              "RFC3963 : Section 3"
          ::= { nemoSystem 7 }

Now, according to RFC4001, the DESCRIPTION clause of an object with
SYNTAX InetAddress MUST specify which object of SYNTAX InetAddressType
controls the format of this object.

Besides, since it seems that type of DNS is allowed, the DESCRIPTION clause
MUST describe when such a DNS name will get resolved in an IP address.

Please not that that issues of InetAddress DESCRIPTION clause occurrs
many times. There are also some that do include some of the required text.

I see various Counter32 objects that do properly point to a discontinuity
timer,
like for example:
   nemoMrDiscoveryReplies OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "Total number of Modified Dynamic Home Agent Address
                Discovery Replies with Mobile Router Flag is set to 1
                received by the mobile router.
                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.
               "

I also see quite a few that have a DESCRIPTION of:
                   Discontinuities in the value of this counter can
                   occur at re-initialization of the mobile router.

For example this one:

      nemoBindingRegTypeChanged  OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
                  "The total number of Binding Update requests
                   rejected by the home agent with status code
                   in the Binding Acknowledgement indicating
                   'Registration type change disallowed' (Code 139).

                   Discontinuities in the value of this counter can
                   occur at re-initialization of the mobile router.
                  "

Now...  which dsicontinuity timer object show me if such
re-initialization has occured. Possibly this is susUpTime,
but that is not clear.

In the following:

    nemoHaPrefixSource OBJECT-TYPE
        SYNTAX      BITS{
                 configured    (0),
                 bindingUpdate (1)
                 }

        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
                "The information source of the mobile network prefix
                 configured with the binding update.
                 Configured(1) represents that the information is
                 introduced to the home agent without binding update.
                 Binding Update(2) represents that the information is
                 introduced to the home agent by the mobile network
                 prefix option in the binding update and verified
                 by the Prefix Table that the home agent maintains
                 for each home addresses of the mobile router.
                "

The actual bit valuies do not correspond to the values listed in the
DESCRIPTION clause. DeSCRIPTION clause to be fixed.
I further wonder if a BITS syntax is correct. Can both methods
be active in the same instance?

I see:
      nemoCoreCompliance MODULE-COMPLIANCE
           STATUS  current
           DESCRIPTION
                  "The compliance statement for SNMP entities
                   which implement the MOBILEIPV6-MIB.
                   There are a number of INDEX objects that cannot be
                   represented in the form of OBJECT clauses in
                   SMIv2, but for which there are compliance
                   requirements, expressed in OBJECT clause form in
                   this
                   description:
                   -- OBJECT      nemoBindingHomeAddressType
                   -- SYNTAX      InetAddressType { ipv6(2) }
                   -- DESCRIPTION
                   --   This MIB module requires support for global
                   --   ipv6 addresses for the nemoBindingHomeAddress
                   --   object.
                   --
                   "

And that is the only InetAddressType/InetAddress/InetAddressPrefixLength
that is listed, while there are MANY MORE (several as INDEX objects,
but also some as non-index, and some even as writable objects.
It would be very good to list those as well in an OBJECT clause.

Since mip6CounterDiscontinuityTime is used as a discontinuity timer, it
seems
that at least that object MUST also be mandatoryly implemented. One could
state so in the DESCRIPTION clause of the MODULE-COMPLIANCE
or better (since machine readable) one could import some OBJECT-GROUP
from the MOBILEIPV6-MIB and include that as a mandatory GROUP.
The latter seems prudent anyway, since there is an

       AUGMENTS {mip6BindingCacheEntry}

in this MIB module as well.

Similarly I assume that the base functionailty of the IF-MIB must be
implemented, since InterfaceIndex is imported.

I think that the list NORMATIVE REFERENCES are not complete.
At least the documents from which IMPORTS are taken MUST be
inclued as NORMATIVE references. So that means

    RFC2863  (IF-MIB)
    RFC3411  (SNMP-FRAMEWORK-MIB)
    RFC4001  (INET-ADDRESS-MIB)

It seems that the security template has not been picked up at the latest
version. I see:
   Even if the network itself is secure (for example by using IPSec),
And that has been fixed into:  IPsec  (lowercase "sec").
There were possibly other small things in the latest (several years old
already) template.

Bert

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 20 Jan 2009 13:17:47 +0100

So I now reviewed the one that is part of revision 4 (instead of revision 1).
So here are my comments on that version.

W: f(nemo.mi2), (221,5) Row "nemoMrBLEntry" has indexing that may create variables with more than 128
 sub-ids
W: f(nemo.mi2), (404,5) Row "nemoHaMobileNetworkPrefixEntry" has indexing that may create variables w
ith more than 128 sub-ids
W: f(nemo.mi2), (540,5) Row "nemoBindingCacheEntry" has indexing that may create variables with more
than 128 sub-ids
W: f(nemo.mi2), (1092,5) Row "nemoHaCounterEntry" has indexing that may create variables with more th
an 128 sub-ids

2 are AUGEMENTS the other 2 do have a warning in the DESCIRPITON clauses, so OK.

I still see:
      nemoNotifications        OBJECT IDENTIFIER ::= { nemoMIB 0 }
      nemoObjects              OBJECT IDENTIFIER ::= { nemoMIB 1 }
      nemoConformance          OBJECT IDENTIFIER ::= { nemoMIB 3 }
And wonder why Conformance is not:  {nemoMIB 3 }
as recommened by RFC4181

For read-write object nemoStatus I see:
                   The value of this object SHOULD remain unchanged
                   across reboots of the managed entity.
A SHOULD does not really help a management station.
But at least there is some text about the persistency.

I see a few times:
        SYNTAX INTEGER {
                  implicitMode       (1),
                  explicitMode       (2)
               }
Candidate for a TC. But not a fatal flaw of course

For read-write object nemoMrPrefixRegMode I see noting about expected persistency behaviour

I think that according the guidelines in RFC4181, this one

    nemoHaMobileNetworkPrefixSeqNo OBJECT-TYPE
        SYNTAX      Integer32 (1..1024)

would better be an Unsigned32. Again, not a fatal flaw.

I see:

    nemoBindingMrFlag OBJECT-TYPE
        SYNTAX      TruthValue
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
                "true(1) indicates that the binding cache entry is from
                 an entity acting as a mobile router.
                 false(0) implies that the binding cache entry is from
                 an entity acting as a mobile node.
                "

But the TC in RFC2579 says:
TruthValue ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Represents a boolean value."
    SYNTAX       INTEGER { true(1), false(2) }

so 'false' is not (0) but is (2)!!!

The set of MODULE-COMPLIANCES seems extensive. Did not have time to deeply analyze.
But if the WG checked it, then I guess it is OK.

Bert

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 20 Jan 2009 13:22:36 +0100

Oops... and the NORMATIVE references to RFC2863 en RFC4001 seem still to
be missing as well!

Bert
  ----- Original Message ----- 
  From: Bert Wijnen (IETF) 
  To: Bert Wijnen (IETF) ; Romascanu, Dan (Dan) 
  Cc: MIB Doctors (E-mail) 
  Sent: Tuesday, January 20, 2009 1:17 PM
  Subject: Re: [MIB-DOCTORS] FW: Evaluation: draft-ietf-mext-nemo-mib-04.txttoProposed Standard

  I still see:

  I see a few times:
          SYNTAX INTEGER {
                    implicitMode       (1),
                    explicitMode       (2)
                 }

  I see:

  Bert