Mobile IPv6 Management Information Base
draft-ietf-mip6-mipv6-mib-07

[Ballot comment]
W.r.t. Ted's comment on mip6BindingAdminStatus, I think it says that
an operator can remove an entry by setting the status to 'inactive'.
Once a row is 'inactive', the operator cannot set it back to active.
For that a new row needs to get created by some internal or other means.

Bert

[Ballot comment]
W.r.t. Ted's comment on mip6BindingAdminStatus, I think the answer is: yes.
And in fact the best way to specify it in machine-readable format is to add
(at the proper places) to the MODULE-COMPLIANCE statements a

      OBJECT        mip6BindingAdminStatus
      WRITE-SYNTAX  { inactive(2) }
      DESCRIPTION  "A chnage from inactive to active is not permitted."

[Ballot comment]
The document says:

  mip6BindingAdminStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          active    (1),
                          inactive  (2)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION
                  "This is an administrative object used to control
                    the status of a binding cache entry. By default
                    the value will be 'active'(1).
                    A value of 'inactive'(2) will indicate that the
                    validity of the entry is suspended. It does not
                    exist in the binding cache for all practical
                    purposes.
                    The state can be changed from 'active' to
                    'inactive' by operator intervention.
                    Causing the state to change to 'inactive' results
                    in the entry being deleted from the cache.
                    Attempts to change the status from 'inactive'
                    to 'active' will be rejected.
                  "


Does the last statement imply that operator intervention can't change
the status from active to inactive?  Is this accomplished by creating
a new entry?

[Ballot comment]
Comments from review by Mary Barnes

- Boilerplate out of date
- Dates within the MIB need updating.  Also, is the LAST UPDATED date on
page 7 (October 2004) still valid given the doc was last updated in March?
- page 5: change the phrase "It comprises of..." to "It is comprised of" OR
remove the "of" after "comprises" (3 occurrences)

AD submission questionnaire:

Title: Mobile IPv6 Management Information Base
I-D: draft-ietf-mip6-mipv6-mib-07.txt

Status: Porposed Standard

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

The chairs have reviewed the I-D and suggested changes/corrections to
the authors which have been incorporated in the above revision of the
I-D. There has been a good deal of discussion as a result of the WG LC
and prior to it as well on the WG mailing list. The I-D is
sufficiently baked for IESG consideration and publication.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

The I-D has been reviewed sufficiently by key WG members. Several
people from other WGs such as MIB Doctor C.M. Heard reviewed the I-D
as well. We (Chairs) are satisfied with the degree of review in terms of
depth and breadth.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No. This Document has been reviewed from a broad perspetive.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.


No specific concerns/issues with any part of this I-D.

5) 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?

It has strong consensus from the WG.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

a) Yes. There is one informative reference and the I-D split references into
normative/informative.

b) No. all the Normative references are RFCs


9) For Standards Track and BCP documents, the IESG approval
  announcement includes a write-up section with the following
  sections:



      Technical Summary

      This document defines a portion of the Management Information Base (MIB),
      the Mobile-IPv6 MIB , for use with network management protocols in the Internet
      community. In particular, the Mobile-IPv6 MIB will be used to monitor and control
      the mobile node, home agent and correspondent node functions of a
      Mobile IPv6 (MIPv6) entity.


    Working Group Summary

The working group had consensus to advance the draft to Proposed
Standard.

  Protocol Quality

An implementation  of the specification is done in BSD as part of the Kame-MIP6 stack.

Review of this specification was done by MIB Doctor C. M. Heard.


  Please provide such a writeup. (We will hopefully use it as is, but
  may make some changes.) For recent examples, have a look at the
  "protocol action" announcements for approved documents.

  Note:

  - When doing the technical summary, one would expect that the
    relevant information is in the abstract and/or introduction of
    the document. It turns out that the step of producing the writeup
    sometimes points out deficiencies in the introduction/abstract
    that are also worthy of rectifying.

  - For the Working Group Summary, was there anything in WG process
    that is worth noting? (E.g., controversy about particular points,
    decisions where concensus was particularly rough, etc.)

  - For the protocol quality, useful information could include:


    - is the protocol already being implemented?

Yes.  There is an implementation on the Kame-MIP6 stack


    - have a significant number of vendors indicated they plan to
      implement the spec?

Yes. Since the implementation is necessary for Managebility, almost everyone is planning to implement it.
  A new implementation based on WIDE's MIP6 stack is planned also Cisco is planning to implement it

    - are there any reviewers (during the end stages) that merit
      explicit mention as having done a thorough review that resulted
      in important changes or a conclusion that the document was fine
      (except for maybe some nits?)

MIB Doctor C.M. Heard reviewed the document suggested minor changes to it and approved as fine.