Proxy Mobile IPv6 Management Information Base
RFC 6475

Note: This ballot was opened for revision 08 and is now closed.

(Jari Arkko) Yes

(Dan Romascanu) (was Discuss) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-05-12)
No email
send info
I really would prefer it if documents didn't show up for AD review with
unresilved idnits.

---
                                                                                                         
I would find it helpful if the IMPORTS clause was enhanced to indicate
which documents the imports come from. An example of this can be seen
in Section 7 of RFC 4803.

---

The copyright issue in the MIB module itself must be resolved before
the I-D progresses.

---

It would be nice to include a DISPLAY-HINT for Pmip6TimeStamp64.

---

There is something wrong in the DESCRIPTION of Pmip6TimeStamp64
   "A 64-bit unsigned integer field containing a timestamp.
    The value indicates the number of seconds since January
    1, 1970, 00:00 UTC, by using a fixed point format.  In
    this format, the integer number of seconds is contained
    in the first 48 bits of the field, and the remaining 16
    bits indicate the number of 1/65536 fractions of a
    second.
   "
The second line says the value indicates the number of seconds, but
the description goes on to say it indicates the number of fractions
of a second.
How about:
s/the number of seconds since/the elapsed time since/

---

Please do not include sitations (such as [RFC1234]) within the MIB
module itself as this is standalone text. The REFERENCE clause should
be enough.

---

Please don't include unstable URLs (e.g. pointers to Internet-Drafts)
in REFERENCE clauses.

---

I think there is dubious utility to using RFC 2119 language within
DESCRIPTION clauses.

---

I'm surprised pmip6Status doesn't have a DEFVAL

---

Did I miss something? This module is for IPv6 proxy mobile, right? So
all addresses will be IPv6?

So why use InetAddressType? Surely the use of that SYNTAX only means
that you have to write restriction clauses and have error handling?

Or is the point that you also want to allow zone indexes?

---

I want to check that pmip6MagBLEntry is really intended to augment 
mip6MnBLEntry. The alternative is that you really wanted a sparse
augmentation.

Similarly for pmip6BindingCacheEntry augmenting mip6BindingCacheEntry.

---

         -- pmip6Stats:pmip6BindingRegcounters

s/counters/Counters/

---

I think the use of counter and gauge is not completely right.
Counter should be used for counts of events (i.e. increasing counts).
Gauge should be used to show the number of things that exist (i.e. a
count that can go up or down).
Integer should be used for fixed (although changeable through
configuration) value.
So, I would have thuught (a MIB Doctor may disagree)...

Pmip6TimeStamp64 is an integer
pmip6LmaHomeNetworkPrefixLifeTime is an integer

---

Should Pmip6PBUAccessTechnologyType be in an IANA MIB module so that
it gets updated in lockstep with the IANA registry?

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-05-09)
No email
send info
The secdir review identified that we might want to update
the boilerplate security considerations a bit - do we want to
do that now? (This is really for the OAM^h^h^hOPS ADs:-)

   "RFC 3826 details how to use AES with SNMPv3. Again, this never made it
   into the boilerplate. Perhaps some new enthusiastic ADs get engaged to
   revise the boilerplate? ;-)"

The SEC and OPS ADs should come back to this.

(David Harrington) No Objection

Comment (2011-05-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the discusses filed by Dan 
I support the first discuss by Stephen.

(Pete Resnick) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

Comment (2011-05-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The document currently contains:

         -- Authors' note:
         --    It is not clear if the Copyright notice should be a part
         --    of above description. It was a requirement sometime ago
         --    but the submission tool at ietf.org complained so it is
         --    removed for now.


That should be removed before approving the document.
Guidance on where to include the copyright notice can be found at
<http://www.ietf.org/iesg/statement/copyright.html>

(Sean Turner) (was Discuss) No Objection