Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


Globally, the "Security Considerations" section is well
written and provides details for the associated risks.
It clearly RECOMMENDs the use of SNMPv3, which should not come
as a surprise given the risks associated to previous versions.
This "Security Considerations" section is globally similar
to that of RFC4295 (MIPv6 MIB).

A few comments:

** What about the completeness of the two lists provided in
section 6?
For instance the MIB defines the pmip6Capabilities object with
attribute MAX-ACCESS read-only (see p. 13). However this object
is not listed in the security considerations sections. Is it
a mistake? If yes, then does anything miss (I didn't check)?


** Clarification needed:
It is said:
  "Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module."
I'm rather surprised that no ACL (or similar) functionality
be available. If IPsec is enabled, then hosts are authenticated
(using one of several techniques) and it's no longer a big deal
to check the authorizations associated to the peer. So that's
surprising.

BTW, you can maybe remove the redundant "even then," in above
sentence.


** Wrong reference:
It is said:
  "It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8) [...]"
Section  is not the section of interest as it only focuses
on the standardization status. More interesting sections in RFC3410
are:
- section 6.3 "SNMPv3 security and administration", and in particular
- section 7, in particular section 7.8 "user based security model".

NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an
issue, now it is. The last sentence of RFC3410/section 7.8 mentions
on-going work on using AES in the user-based security model. If this
work gave birth to an RFC, that's probably a good document to refer
too.


** Obscur:
The last sentence of this section:
  "It is then a customer/operator... them."
could easily be improved (split the sentence, please). As such it
remains rather obscure.


I hope this is useful.
Cheers,

   Vincent