Network Mobility (NEMO) Management Information Base
RFC 5488

[Ballot discuss]
The DateAndTime textual convention for SNMPv2 does not require the use of
an interoperable format that includes a timezone offset.  Some uses of
the DateAndTime textual convention remedy this problem with specific
language. For example, RFC 2591 states the following when using the
DateAndTime textual convention:

        DESCRIPTION
            "... An implementation MUST return all 11 bytes
            of the DateAndTime textual-convention so that a manager
            may retrieve the offset from GMT time."

Would such text be appropriate for this usage?  Or is this usage a case
where an up-to-25 hour skew between client and server interpretation
of the time will not be a problem?

I'll clear my discuss if such text is added or if the authors assert the
25-hour skew is not a problem for this usage.

[Ballot comment]
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 it should be false(2) and not false(0) in the DESCRIPTION clause.

IANA comments:

Upon approval of this document, IANA will make the following
assignment at
http://www.iana.org/assignments/smi-numbers
in the "iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)" registry

Decimal Name Description References
------- ---- ----------- ----------
[tbd] nemoMIB NEMO monitoring [RFC-mext-nemo-mib-04]

We understand the above to be the only IANA Action for this document.

[Ballot comment]
It would be nice if the following issues from the MIB review would be discussed and fixed:

1. Section 2.2 (implementation guidance) is incomplete. It should mention the need to support ifTable from IF-MIB as InterfaceIndex is IMPORTed. Also better rename it 'Relationship to other MIB modules'.

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

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

4. No need to carry commented objects in the IMPORTS section.

[Ballot discuss]
The following issues from the MIB Doctor review must be clarified and fixed before this document is approved:

1. The Object nemoMrPrefixRegMode is writable but there is no description of the expected persistency behavior.

For read-write object nemoStatus:
                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.
A SHOULD does not really help a management station as it cannot count for sure on persistency.

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

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

3.      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 it should be false(2) and not false(0) in the DESCRIPTION clause.

4. The document must have normative references to RFC 2863 and RFC 4001 as the MIB module defined in this document IMPORTs objects from the MIB modules defined in these RFCs.

5. The REVISION date is in the future - points to November 12 and not to January 12 (which was the intention I think.

[Ballot comment]
It would be nice is the following issues from the MIB review would be discussed and fixed:

1. Section 2.2 (implementation guidance) is incomplete. It should mention the need to support ifTable from IF-MIB as InterfaceIndex is IMPORTed. Also better rename it 'Relationship to other MIB modules'.

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

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

4. No need to carry commented objects in the IMPORTS section.

[Ballot discuss]
The following issues from the MIB Doctor review must be clarified and fixed before this document is approved:

1. The Object nemoMrPrefixRegMode is writable but there is no description of the expected persistency behavior.

For read-write object nemoStatus:
                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.
A SHOULD does not really help a management station as it cannot count for sure on persistency.

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

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

4.      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 it should be false(2) and not false(0) in the DESCRIPTION clause.

5. The document must have normative references to RFC 2863 and RFC 4001 as the MIB module defined in this document IMPORTs objects from the MIB modules defined in these RFCs.

6. The REVISION date is in the future - points to November 12 and not to January 12 (which was the intention I think.

There was one question on this draft when I re-re-re-reviewed it:

Why is the mode needed twice below:
    nemoMrRegistrationGroup  OBJECT-GROUP
        OBJECTS {
                  nemoMrBLMode,
                  ...
                  nemoMrPrefixRegMode,
    ...

A re-review:

So, due to the large changes in the new version, this is going back to a WGLC and is also going to require a few more reviews. In the meantime I have re-reviewed the new version and I have the following comments:

Please remove the commented out parts of the MIB (e.g.,  "-- Counter64").

The object NemoBURequestRejectionCode says "The value of the status field in the BA ..." but lists values that are in the 1-4 range as opposed to the actual values in BAs.  Please clarify which ones you actually want to use.

The object nemoHaBindingAcksOtherError seems to have a similar problem.

Otherwise the new document looks good. I do expect some additional reviews, however.

Here are the results of my review. I believe the documents needs one
additional editing round, as well as a few additional reviews to make
sure everything is right.

All the issues below are relatively small, but the fact that many
of these things were missed means that additional eyes are needed
on the document.

Here are the details:

- Remove Counter64, because it is not used

- Replace nemo@ietf.org with mext@ietf.org

- Update copyright notice to 2008

- Update revision string

- nemoRegisteredUpTime: Do you count only the current location and
  registration? Please specify.

- nemoRegHomeAgentAddress: The text says: "The home agent address of
  the mobile router which was used in the last accepted registration."
  I cannot parse this statement. Did you mean to say "The home agent
  address used in the last accepted registration sent by the mobile
  router."? A similar change would be needed for nemoRegHomeAddress,
  nemoRegCareofAddress.

- nemoRegHomeAddressPrefixLength: The text says: "The prefix length of
  the home address that the mobile router is using for roaming."
  What does roaming have to do with this? Just say "The prefix length
  of the home address for the mobile router."

- nemoActiveEgressIfIndex: s/current active/currently active/.

- nemoHomeRegRetryCount and nemoHomeRegRetryDelay appear to implement
  a BU retransmission model that is based on a maximum number of
  attempts, with fixed time between them. This is in violation of
  RFC 3775, Section 11.8.

- nemoRegisterConnectedPrefixes: The term "connected prefix" does not
  appear in RFC 3963 or RFC 4885. Please provide a reference or define
  what the semantics of this object are.

- nemoBindingCacheTable: It says: "This table models the Binding Cache
  that includes NEMO related information and is maintained by the
  mobile router." This is obviously wrong, as it is the home agent
  that maintains this information. More generally, I'm concerned that
  similar errors have crept into many of the description fields in
  the document. It needs better review.


- nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged: why is
  the naming different (BindingAck vs. BindingReg)?

- nemoBindingAckNotHomeRegn, nemoBindingRegTypeChanged, etc:
  why is there no nemoBindingAckOtherError to count the number
  of errors not classified in the MIB? Remember that we keep
  adding new error codes.

- nemoMovedFNtoFN: this object should clarify that movement
  is defined as movement in layer 3, i.e., a different
  care of address was configured. Movements at layer 2
  may result in some ND/DHCP activity, but do not always
  result in layer 3 change.

I am expecting a revised draft and information about 2-3 additional
reviews before proceeding.

Document Shepherd write-up for draft-ietf-mext-nemo-mib-01

  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

    The document shepherd is Marcelo Bagnulo, who has personally
    reviewed the document and believes the document is ready for
    publication.
      (1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

    The document has been reviewed by key WG members, including
    Alex Petrescu, Pascal Thubert, Kent Leung, T.J Kniveton and
    Thierry Ernst.

    The document is awaiting review from a MIB doctor.

  (1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization, or XML?

    The document should be reviewed by MIB doctor

  (1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.  Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

    There are no specific concerns that I am aware of.
    I think the document is needed since it specifies the MIB
    for one key protocol for mobility.
    There are no IPR issues that I am aware of.

  (1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

    The WG seems to agree in the need for this document and no-one
    seems to oppose to the document.
      (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

    No one has expressed discontent with the document nor threatened
    with an appeal.

  (1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type, and URI type reviews?  If the document
        does not already indicate its intended status at the top of
        the first page, please indicate the intended status here.

    The document gets two warnings through IDNITS:

    == Outdated reference: draft-ietf-nemo-terminology has been
    published as RFC 4885

      == Outdated reference: draft-ietf-nemo-requirements has been
    published as RFC 4886

    The document needs to be reviewed by the MIB doctor


  (1.h)  Has the document split its references into normative and
        informative?  Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion?  Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

    The document has the references split into normative and
    informative.
        All normative references are already been published as RFCs.
    There are two informative references that have been published
    as RFCs but need to be updated in the document.
    There are no normative references that are downward
    references. 
  (1.i)  Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process, has the Document
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during IESG Evaluation?

    The IANA considerations section exists and has been reviewed.
    It is consistent with the document.
    The document requests IANA to assign a base arc in the mib-2
    (standards track) OID tree for the 'nemoMIB' MODULE-IDENTITY
    defined in the NEMO MIB.

  (1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

    The MIB definition has been checked using
    http://www.ibr.cs.tu-bs.de/bin/smitools.cgi and it seems
    to be validate correctly. Still MIB doctor revision is needed

  (1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up.  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  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
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

        No. This is a MIB draft and is a non-controversial subject.

        Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

        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
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

        The document shepherd for this document is Marcelo Bagnulo.
        The responsible AD is Jari Arkko.
        The document need MIB doctor review.