Sent a request for the authors to make an update of the draft. We only need to solve Dan's issues and we could approve the document.

[Ballot comment]
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.

[Ballot discuss]
(revised after the publication of draft-7)

The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel

1. (cleared)

2. The definition of the TC is not in the document, but yet it needs being fixed as the semantics of objects here depends upon it.

>    Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
>        DISPLAY-HINT "255a"
>        STATUS  current
>        DESCRIPTION
>            "An identifier that identifies the attached interface of a
>            mobile node.  For those interfaces that have a link-layer
>            identifier, this identifier can be based on that.  The
>            link-layer identifier, in some cases, is generated by the

>            mobile node and conveyed to the mobile access gateway.  This

>            identifier of the attached interface must be stable as seen

>            by any of the mobile access gateways in a given Proxy Mobile

>            IPv6 domain.  In some other cases, there might not be any

>            link-layer identifier associated with the mobile node's

>            interface. An identifier value of all zeroes is not

>          considered a valid identifier and cannot be used as an

>          interface identifier."
>            "

>        REFERENCE

>            "RFC 5213: Section 8.6"

>        SYNTAX  OCTET STRING (SIZE (0..255))

What is an all zeroes value for a string identifier of a variable size. Does this mean a string of any size where each character is 0x? or only maximal size? What about the null string?

3. Is the Pmip6MnInterfaceATT TC supposed to be updated, as IANA maintains the mobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. Now this TC is imported from a future RFC which will need to be approved and published in order for this document to be published. Why is not the MIB module defining the TC part of this document? Similar for another 3 TCs imported from the  same MIB

4.  (cleared)

5. In the DESCRIPTION clause of pmip6Status:

                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.

Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases?

[Ballot discuss]
(revised after the publication of draft-7)

The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel

1. (cleared)

2. The definition of the TC is not in the document, but yet it needs being fixed as the semantics of objects here depends upon it.

>    Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
>        DISPLAY-HINT "255a"
>        STATUS  current
>        DESCRIPTION
>            "An identifier that identifies the attached interface of a
>            mobile node.  For those interfaces that have a link-layer
>            identifier, this identifier can be based on that.  The
>            link-layer identifier, in some cases, is generated by the
>            mobile node and conveyed to the mobile access gateway.  This
>            identifier of the attached interface must be stable as seen
>            by any of the mobile access gateways in a given Proxy Mobile

>            IPv6 domain.  In some other cases, there might not be any

>            link-layer identifier associated with the mobile node's

>            interface. An identifier value of all zeroes is not

>          considered a valid identifier and cannot be used as an

>          interface identifier."
>            "

>        REFERENCE

>            "RFC 5213: Section 8.6"

>        SYNTAX  OCTET STRING (SIZE (0..255))

What is an all zeroes value for a string identifier of a variable size. Does this mean a string of any size where each character is 0x? or only maximal size? What about the null string?

3. Is the Pmip6MnInterfaceATT TC supposed to be updated, as IANA maintains the mobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. Now this TC is imported from a future RFC which will need to be approved and published in order for this document to be published. Why is not the MIB module defining the TC part of this document? Similar for another 3 TCs imported from the  same MIB

4.  (cleared)

5. In the DESCRIPTION clause of pmip6Status:

                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.

Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases?

[Ballot comment]
1. Some of the DESCRIPTION clauses of enumerated or BITS objects or TCs do not explain the significance of each enumerated value or bit. For example Pmip6PBUAccessTechnologyType, pmip6Capabilities, etc.

2. (cleared)

[Ballot discuss]
(revised after the publication of draft-7)

The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel

1. (cleared)

2. The following comment in the MIB review does not seem to have been addressed:

>    Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
>        DISPLAY-HINT "255a"
>        STATUS  current
>        DESCRIPTION
>            "An identifier that identifies the attached interface of a
>            mobile node.  For those interfaces that have a link-layer
>            identifier, this identifier can be based on that.  The
>            link-layer identifier, in some cases, is generated by the
>            mobile node and conveyed to the mobile access gateway.  This
>            identifier of the attached interface must be stable as seen
>            by any of the mobile access gateways in a given Proxy Mobile
>            IPv6 domain.  In some other cases, there might not be any
>            link-layer identifier associated with the mobile node's
>            interface. An identifier value of all zeroes is not
>          considered a valid identifier and cannot be used as an
>          interface identifier."
>            "
>        REFERENCE
>            "RFC 5213: Section 8.6"
>        SYNTAX  OCTET STRING (SIZE (0..255))

What is an all zeroes value for a string identifier of a variable size. Does this mean a string of any size where each character is 0x? or only maximal size? What about the null string?

3. Is the Pmip6MnInterfaceATT TC supposed to be updated, as IANA maintains the mobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. Now this TC is imported from a future RFC which will need to be approved and published in order for this document to be published. Why is not the MIB module defining the TC part of this document?

4.  (cleared)

5. In the DESCRIPTION clause of pmip6Status:

                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.

Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases?

[Ballot comment]
I'm hoping to change the boiler plate text, but don't want to hold this document up for that discussion.  I've copied my DISCUSS here, though there is NOTHING for the authors do with it.

With the addition of the Transport Security Model (RFC 5590/5591) to SNMPv3 I'd like to see the following paragraph from the Security Considerations aligned with the one in RFC 5591:

OLD:

  It is RECOMMENDED that implementers consider the security features as
  provided by the SNMPv3 framework (see [RFC3410], section 8),
  including full support for the SNMPv3 cryptographic mechanisms (for
  authentication and privacy).

NEW:

  It is RECOMMENDED that implementers consider the security features as
  provided by the SNMPv3 framework (see [RFC3410], section 8),
  including full support for the USM and Transport Security Model
  cryptographic mechanisms (for authentication and privacy).

Can we work in references for RFC 3414 (USM) and RFC 5591 (Transport Security Model).

[Ballot comment]
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?

[Ballot discuss]
I have only done a very cursory review of this document. It seems to me
that there may be a large number of nits related to how the MIB module
is written, and the Responsible AD may want to ensure that the document
has been updated after MIB Doctor review *before* it is presented for
IESG review.

I am entering a Discuss because of the volume of minor Comments I have
generated. None of the Comments stands on its own as a point worthy of
a Discuss, but there are so many that I feel the document cannot be
described as ready for publication.

In order to make this Discuss actionable, I ask that the authors make
an attempt to address a serious percentage of my Comments.

[Ballot comment]
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>

[Ballot discuss]
With the addition of the Transport Security Model (RFC 5590/5591) to SNMPv3 I'd like to see the following paragraph from the Security Considerations aligned with the one in RFC 5591:

OLD:

  It is RECOMMENDED that implementers consider the security features as
  provided by the SNMPv3 framework (see [RFC3410], section 8),
  including full support for the SNMPv3 cryptographic mechanisms (for
  authentication and privacy).

NEW:

  It is RECOMMENDED that implementers consider the security features as
  provided by the SNMPv3 framework (see [RFC3410], section 8),
  including full support for the USM and Transport Security Model
  cryptographic mechanisms (for authentication and privacy).

Can we work in references for RFC 3414 (USM) and RFC 5591 (Transport Security Model).

[Ballot comment]
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.

[Ballot discuss]
(1) Pmip6MNIdentifier and Pmip6MNLlIdentifier - these can contain identifiers
for the MN and so can (I believe) identify people, so I don't understand why
they are not in the list of sensitive read-only objects?

(2) starting from 1 with Pmip6MNIndex would imply that one can guess
values - is that a potential problem, if so, perhaps this also needs to be in
the list of sensitive objects?

[Ballot discuss]
(1) Pmip6MNIdentifier and Pmip6MNLlIdentifier - these can contain identifiers
for the MN and so can (I believe) identify people, so I don't understand why
they are not in the list of sensitive read-only objects?

(2) starting from 1 with Pmip6MNIndex would imply that one can guess
values - is that a potential problem, if so, perhaps this also needs to be in
the list of sensitive objects?

(3) 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 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? ;-)"

[Ballot comment]
1. Some of the DESCRIPTION clauses of enumerated or BITS objects or TCs do not explain the significance of each enumerated value or bit. For example Pmip6PBUAccessTechnologyType, pmip6Capabilities, etc.

2. Objects like pmip6Status could use TruthValue SYNTAX

[Ballot discuss]
The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel

1. The following comment in the MIB review does not seem to have been addressed:

>    The PMIPV6-MIB is composed of the following groups of definitions:

The groups do not align with the object groups defined in the MIB itself.
IMO, the rest of the section would need some rewriting as it does not
reflect the MIB definition.

>        - pmip6Core: a generic group containing objects that are
>          common to all the Proxy Mobile IPv6 entities. Objects
>          belonging to this group will be implemented on the
>          corresponding Proxy Mobile IPv6 entity. pmip6BindingCacheTable
>          belongs to this group.

For instance, the pmip6BindingCacheTable has an object that is pmip6BindingTimeRecentlyAccepted
and that is part of the pmip6BindingCacheGroup.

Also I am not finding a core group in the object group definitions, but there is a
core complaince (pmip6CoreCompliance)

2. The following comment in the MIB review does not seem to have been addressed:

>    Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
>        DISPLAY-HINT "255a"
>        STATUS  current
>        DESCRIPTION
>            "An identifier that identifies the attached interface of a
>            mobile node.  For those interfaces that have a link-layer
>            identifier, this identifier can be based on that.  The
>            link-layer identifier, in some cases, is generated by the
>            mobile node and conveyed to the mobile access gateway.  This
>            identifier of the attached interface must be stable as seen
>            by any of the mobile access gateways in a given Proxy Mobile
>            IPv6 domain.  In some other cases, there might not be any
>            link-layer identifier associated with the mobile node's
>            interface. An identifier value of ALL_ZERO is not considered
>            a valid identifier and cannot be used as an interface
>            identifier.
>            "
>        REFERENCE
>            "RFC 5213: Section 8.6"
>        SYNTAX  OCTET STRING (SIZE (0..255))

What is the ALL_ZERO value?

3. Is the  Pmip6PBUAccessTechnologyType TC supposed to be updated, as IANA maintains th emobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA.

4. I do not see the relation between the DESCRIPTION clause of pmip6Compliance2 and the included compliance clauses themselves.

5. In the DESCRIPTION clause of pmip6Status:

                  The value of this object SHOULD remain unchanged
                  across reboots of the managed entity.

Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases? Default on disabled(2) or it does not matter?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-netlmm-pmipv6-mib-05.txt> (Proxy Mobile IPv6 Management Information Base) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Proxy Mobile IPv6 Management Information Base'
  <draft-ietf-netlmm-pmipv6-mib-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netlmm-pmipv6-mib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netlmm-pmipv6-mib/

Upon approval of this document, IANA understands that a single action
needs to be completed.

In the SMI Network Management MGMT Codes with prefix
(iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)) located at:

http://www.iana.org/assignments/smi-numbers

a new MIB should be registered as follows:

Decimal: tbd
Name: pmip6MIB
Description: PMIPV6-MIB
References: [ RFC-to-be ]

IANA understands that this is the only action required to be completed
upon approval of this document.

MIB doctor reviewer has a review, but we're still waiting for it (he was asking for format in which we desire it). Send it now... deadline is soon!

Dear doctors,

I would like to get your review of this document. The document has been revised once to address my AD review concerns. The new document looks good to me. When I compile it with my tools (replacing YYY with a number), I get only the warnings below that seem consistent with what the document itself says. In other words, I think it is ready to be looked at by you.

> Your request has been processed by the command
>
> smistrip -d mibs docs/netlmmmib.txt
> smilint -s -e -l 6 mibs/PMIPV6-MIB 2>report.txt
>
> You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory <http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/tmp/4Pxr6k/> for approx. 24 hours.
>
> While processing your request the following errors and/or warnings have been found:
>
> mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 142 subidentifier(s)
> mibs/PMIPV6-MIB:540: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s)
> mibs/PMIPV6-MIB:1473: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 142 subidentifier(s)
> mibs/PMIPV6-MIB:1646: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s)
>

Checking with smilint:

Your request has been processed by the command

smistrip -d mibs docs/netlmmmib.txt
smilint -s -e -l 6 mibs/PMIPV6-MIB 2>report.txt

You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours.

While processing your request the following errors and/or warnings have been found:

mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 142 subidentifier(s)
mibs/PMIPV6-MIB:540: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s)
mibs/PMIPV6-MIB:1473: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 142 subidentifier(s)
mibs/PMIPV6-MIB:1646: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s)

I have reviewed this draft. Overall, I think it is in good shape, but I did see a number of issues. Please issue a new draft that corrects them and/or adds more clarifying text. The main issues were:

- at times the document was unclear about where a particular piece of MIB information is held (at the MAG vs. LMA)
- in several places the document needs to be more explicit
- some IP address issues
- not sure I understood the OID limit issue

> - pmip6MagProxyCOATable          : models the Proxy Care-of
>                                    Addresses configured on the
>                                    egress interfaces of the
>                                    mobile access gateway.
From this description it is unclear where this table is. Is this a MAG or a LMA table?

> - pmip6MagHomeNetworkPrefixTable : contains the Home Network
>                                    Prefixes assigned to the
>                                    mobile node's connected
>                                    interfaces.

Is this "the mobile node"? or all mobile nodes currently attached to this mag? Same issue in pmip6LmaHomeNetworkPrefixTable.

>        - pmip6LmaLMAATable              : contains the LMA Addresses
>                                          that are configured on the
>                                          local mobility anchor. Each
>                                          LMA Address acts as a
>                                          transport endpoint of the
>                                          tunnel between the local
>                                          mobility anchor and the mobile
>                                          access gateway.
From this desccription it is unclear from whose point of view this information is presented. Does this table exist at the MAGs or the LMAs?

>    Pmip6MNIdentifier  ::=  TEXTUAL-CONVENTION
>        STATUS  current
>        DESCRIPTION
>            "The identity of a mobile node in the Proxy Mobile IPv6
>            domain. This is the stable identifier of a mobile node
>            that the mobility entities in a Proxy Mobile IPv6 domain
>            can always acquire and use it for predictably identifying
>            a mobile node. This is typically an identifier such as
>            Network Access Identifier (NAI) [RFC4282] or other
>            identifier such as a Media Access Control (MAC) address.
>            "
>        REFERENCE
>            "RFC 5213: Section 2.2"
>        SYNTAX  OCTET STRING (SIZE (0..255))
>
This description should be more accurate about the encoding of the identifier. Do you mean that its the same encoding as in RFC 4283? Are there other alternatives than NAIs? Please be more precise. Section 2.2 is not a very good reference in this sense, because it too lacks specificity.

>    Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
>        STATUS  current
>        DESCRIPTION
>            "An identifier that identifies the attached interface of a
>            mobile node.  For those interfaces that have a link-layer
>            identifier, this identifier can be based on that.  The
>            link-layer identifier in some cases is generated by the
>            mobile node and conveyed to the mobile access gateway.  This
>            identifier of the attached interface must be stable as seen
>            by any of the mobile access gateways in a given Proxy Mobile
>            IPv6 domain.  In some other cases, there might not be any
>            link-layer identifier associated with the mobile node's
>            interface. An identifier value of ALL_ZERO is not considered
>            a valid identifier and cannot be used as an interface
>            identifier.
>            "
>        REFERENCE
>            "RFC 5213: Section 2.2"
>        SYNTAX  OCTET STRING (SIZE (0..255))
As above, what is the encoding? Should the reference be Section 8.6 instead?

>    Pmip6MNIndex ::= TEXTUAL-CONVENTION
>        DISPLAY-HINT "d"
>        STATUS      current
>        DESCRIPTION
>            "A unique integer value, greater than zero, assigned to each
>            mobile node in a PMIPv6-Domain by the management system.
>            It is recommended that values are assigned contiguously
>            starting from 1.  The value for each mobile node must remain
>            constant at least from one re-initialization of the entity's
>            network management system to the next re-initialization.
>            "
>        SYNTAX      Integer32 (1..2147483647)
>


Due to roaming, there is an infinite number of potential visited mobile nodes. Are these indexes for the *current* mobile nodes, i.e., those currently attached to the domain? Or something else? Please specify.

>    Pmip6PBUAccessTechnologyType ::=  TEXTUAL-CONVENTION
>        STATUS  current
>        DESCRIPTION
>            "This specifies the access technology which connects the
>            mobile node to the access link on the mobile access gateway.
>            "
>        REFERENCE
>            "RFC 5213: Section 8.5"
>        SYNTAX INTEGER
>        {
>                  reserved              (0),
>                  logicalNetworkInterface(1),
>                  pointToPointInterface  (2),
>                  ethernet              (3),
>                  wirelessLan            (4),
>                  wimax                  (5)
>        }

Perhaps you should explicitly state that the namespace from RFC 5213 should be used:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt

note the 3GPP etc items that do not appear in your list above...

>        pmip6FixedMagLinkLocalAddressOnAllAccessLinksType OBJECT-TYPE
>            SYNTAX      InetAddressType
>            MAX-ACCESS  read-write
>            STATUS      current
>            DESCRIPTION
>                "The InetAddressType of the
>                pmip6FixedMagLinkLocalAddressOnAllAccessLinks
>                that follows.
>                "
>              ::= { pmip6Conf 2 }
>        pmip6FixedMagLinkLocalAddressOnAllAccessLinks OBJECT-TYPE
>            SYNTAX      InetAddress
>            MAX-ACCESS  read-write
>            STATUS      current
>            DESCRIPTION
>                "This variable indicates the link-local address value
>                that all the mobile access gateways should use on
>                any of the access links shared with any of the
>                mobile nodes in that Proxy Mobile IPv6 domain.  If
>                this variable is initialized to ALL_ZERO value, it
>                implies the use of fixed link-local address mode is
>                not enabled for that Proxy Mobile IPv6 domain."
>            REFERENCE
>                "RFC 5213: Section 2.2, 6.8, 6.9.1.1, 6.9.3, 9.3"
>              ::= { pmip6Conf 3 }

I'm not sure I understand this. There's an IPv6 link local address, but is there an IPv4 one? If not, why do we need the -Type object? And where is the IPv4 default router and DHCP server address stored in? Here there is room for just one address, not two as would expect to require in a dual stack environment... but maybe I'm missing something.

(Same issue in pmip6Binding table)

>        pmip6MagProxyCOAState  OBJECT-TYPE
>            SYNTAX      INTEGER {
>                                  unknown(1),
>                                  activated(2),
>                                  tunneled(3)
>                          }
>            MAX-ACCESS  read-only
>            STATUS      current
>            DESCRIPTION
>                "This object indicates the state of the Proxy-CoA:
>                    unknown    -- The state of the Proxy-CoA
>                                  cannot be determined.
>                    activated  -- The Proxy-CoA is ready to establish
>                                  tunnel
>                    tunneled    -- The Proxy-CoA is used to set up the
>                                  bi-directional tunnel.
>                "
>            ::= { pmip6MagProxyCOAEntry 3 }

Do we use activated or tunneled, if the system is otherwise up but the MAG has no mobile nodes, and has not had to send a Proxy Binding Update yet?

>        pmip6MagHomeNetworkPrefixTable  OBJECT-TYPE
>            SYNTAX      SEQUENCE OF PMip6MagHomeNetworkPrefixEntry
>            MAX-ACCESS  not-accessible
>            STATUS      current
>            DESCRIPTION
>                "A table representing the Home Network Prefixes
>                  assigned to the mobile node's connected interfaces.
>                  This table shows the prefixes registered in the
>                  binding update list entry.
>                "
>            REFERENCE
>                "RFC 5213: Section 2, 6.1, 6.2"
>            ::= { pmip6MagConf 2 }

The description has been written as if there was just one mobile node and one BUL entry. Please update the specification, I presume that you meant that this table contains ALL prefixes of ALL mobile nodes for which there exists ANY BUL in this MAG?

>        pmip6MagHomeNetworkPrefixEntry OBJECT-TYPE
>            SYNTAX      PMip6MagHomeNetworkPrefixEntry
>            MAX-ACCESS  not-accessible
>            STATUS      current
>            DESCRIPTION
>                "An entry in the Home Network Prefixes table.
>
>                  Implementers need to be aware that if the total
>                  number of octets in pmip6MagHomeNetworkPrefix
>                  exceeds 114 then OIDs of column
>                  instances in this row will have more than 128
>                  sub-identifiers and cannot be accessed using
>                  SNMPv1, SNMPv2c, or SNMPv3.

I do not understand this. The pmip6MagHomeNetworkPrefix is of type InetAddress, so in this case its length would always be 16, no?

(Same issue in pmip6LmaLMAAEntry and pmip6LmaHomeNetworkPrefixEntry)

>        pmip6MagHomeNetworkPrefixLifeTime  OBJECT-TYPE
>            SYNTAX      Gauge32
>            UNITS      "seconds"
>            MAX-ACCESS  read-only
>            STATUS      current
>            DESCRIPTION
>                "The lifetime (in seconds) granted to the mobile
>                  node for this registration.
>                "
>            REFERENCE
>                "RFC 5213: Section 6.2, 6.7"
>            ::= { pmip6MagHomeNetworkPrefixEntry 4 }
>
>
The lifetime in the PBA? The lifetime in the last RA sent out to the mobile node? The remaining lifetime? Please specify...

>        pmip6MagBLTable OBJECT-TYPE
>            SYNTAX      SEQUENCE OF Pmip6MagBLEntry
>            MAX-ACCESS  not-accessible
>            STATUS      current
>            DESCRIPTION
>                "This table corresponds to the Binding Update List(BL)
Is there a particular reason to drop the U from the abbreviation?

>        pmip6MagBLTimeRecentlyAccepted OBJECT-TYPE
>            SYNTAX      DateAndTime
>            MAX-ACCESS  read-only
>            STATUS      current
>            DESCRIPTION
>                "The 64-bit timestamp value of the most recently
>                accepted Proxy Binding Update message sent for this
>                mobile node.  This is the time-of-day on the mobile
>                access gateway, when the proxy binding acknowledgement
>                message with the Status field set to 0
>                was received.  If the Timestamp option is not present
>                in the Proxy Binding Update message (i.e., when the
>                sequence number based scheme is in use), the value MUST
>                be set to ALL_ZERO.
>                "
>            REFERENCE
>                "RFC 5213: Section 5.1, 8.1"
>            ::= { pmip6MagBLEntry 9 }

I'm curious why the last timestamp is in this table, but the last sequence number is not. Sequence numbers and timestamps are equal alternatives in RFC 5213.

(Same issue in pmip6Binding table)

>        pmip6BindingPBUFlag OBJECT-TYPE
>            SYNTAX      TruthValue
>            MAX-ACCESS  read-only
>            STATUS      current
>            DESCRIPTION
>                "true(1) if the local mobility anchor accepted the
>                binding update with Proxy Registration Flag from a
>                mobile access gateway.
>                false(0) implies that the binding cache is from a
>                mobile node.
>                "
>            REFERENCE
>                "RFC 5213: Section 5.1, 8.1"
>            ::= { pmip6BindingCacheEntry 1 }

Please specify what is expected to happen for Flag=0 entries otherwise. Do they even show up in this table, and if they do, how do the values in the entries get filled? Or would a client Mobile IP host simply lead to the creation of another entry in a Mobile IPv6 MIB table, not here?

>    sensitivity/vulnerability:
>      nemoStatus: The value of this object is used to enable or disable
>          the PMIPv6 functionality on a PMIPv6 entity. Access to this MO
>          may be abused to disrupt the communication that depends on

This is the first time that nemoStatus appears in the document.

When using http://www.ibr.cs.tu-bs.de/bin/smitools.cgi I got these errors:

> mibs/PMIPV6-MIB:88: [2] {bad-identifier-case} `YYY' should start with a lower case letter
> mibs/PMIPV6-MIB:88: [2] {object-identifier-not-prefix} Object identifier element `YYY' name only allowed as first element
> mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 136 subidentifier(s)
> mibs/PMIPV6-MIB:537: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s)
> mibs/PMIPV6-MIB:1462: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 136 subidentifier(s)
> mibs/PMIPV6-MIB:1640: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s)
> mibs/PMIPV6-MIB:145: [5] {type-without-format} warning: type `Pmip6MNIdentifier' has no format specification
> mibs/PMIPV6-MIB:160: [5] {type-without-format} warning: type `Pmip6MNLlIdentifier' has no format specification

At least some of these seem real problems. Please fix.

# (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?

Document Shepherd is Jonne Soininen (WG co-Chair for NETLMM). I have
personally
processed and reviewed the document and I do believe - as much as I
understand the MIB - the document is ready to be
forwarded 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?

This document has had as much review as we could get for a MIB. I have no
personal concerns about the reviews.


# (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?

This document needs to be reviewed by the MIB doctors.


# (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.

I have no concerns on the document.

# (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 consensus is behind this document.


# (1.f) Has anyone threatened an appeal or otherwise indicated extreme
# discontent? If so, please summarise 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.)

Nobody has threatened to 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?

Yes, I run the nits script on the draft and it gave no warnings or errors


# (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].

There is a split to normative and informative references.
There is no normative document that would be in a dubious state.


# (1.i) Has the Document Shepherd verified that the document IANA
# consideration 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 Shepherd conferred with the Responsible Area Director so that
# the IESG can appoint the needed Expert during the IESG Evaluation?

Yes, IANA considerations section does exist and seems to be in line with the
rest of the document.


# (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?

This is a MIB. I used http://www.simpleweb.org/ietf/mibs/validate/ and I
think everything went ok. It complained on some parts of the descriptions.
(Mostly "'" within description or a reserved word word within the
description texts). However, I thought this would be an error of the tool
rather than the MIB.

I might be wrong, though.


# (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
This is the MIB for Proxy Mobile IPv6.

Working Group Summary
There is a consensus in Netlmm WG that this specification is ready to be
published as a proposed standard.

Document Quality
The document has gone through reviews and a successful WGLC.

Personel
Responsible AD is Jari Arkko and the document shepherd is Jonne Soininen.