Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-18

[Ballot discuss]
(The ATT part of the DISCUSS was taken out following discussions and clarification with the editors and shepherds)

I like Section 9 which describes the protocol configuration parameters in a clear and detailed manner. I believe though that it is missing two details which I suggest to add:

- how are the local mobility anchor and the mobile access gateway configured? is local configuration by CLI considered enough, or is there a need for remote configuration? Will a MIB module including configuration objects be defined (there is none chartered by now in the NETLMM WG as far as I can see) or something else?

- what is the persistency and the behavior of the configured parameters in a reboot event?

[Ballot discuss]
(The ATT part of the discuss was taken out following discussions and clarification with the editors and shepherds)

I like Section 9 which describes the protocol configuration parameters in a clear and detailed manner. I believe though that it is missing two details which I suggest to add:

- how are the local mobility anchor and the mobile access gateway configured? is local configuration by CLI considered enough, or is there a need for remote configuration? Will a MIB module including configuration objects be defined (there is none chartered by now in the NETLMM WG as far as I can see) or something else?

- what is the persistency and the behavior of the configured parameters in a reboot event?

[Ballot discuss]
1. I like Section 9 which describes the protocol configuration parameters in a clear and detailed manner. I believe though that it is missing two details which I suggest to add:

- how are the local mobility anchor and the mobile access gateway configured? is local configuration by CLI considered enough, or is there a need for remote configuration? Will a MIB module including configuration objects be defined (there is none chartered by now in the NETLMM WG as far as I can see) or something else?

- what is the persistency and the behavior of the configured parameters in a reboot event?

2. In Section 10 - IANA considerations:

  The Access Technology Type option defined in Section 8.5 of this
  document introduces a new Access Technology type (ATT) numbering
  space, where the values from 0 to 5 have been reserved by this
  document.  Approval of new Access Technology type values are to be
  made through IANA Expert Review.

There is no need for the new registry. The registry at http://www.iana.org/assignments/ianaiftype-mib already covers all the values mentioned in section 8.5, and future access technologies may be registered as ifTypes - actually need to be registered inorder to be manageable

[Ballot discuss]
1. I like Section 9 which describes the protocol configuration parameters in a clear and detailed manner. I believe though that it is missing two details which I suggest to add:

- how are the local mobility anchor and the mobile access gateway configured? is local configuration by CLI considered enough, or is there a need for remote configuration? Will a MIB module including configuration objects be defined (there is none chartered by now in the NETLMM WG as far as I can see) or something else?

- what is the persistency and the behavior of the configured parameters in a reboot event?

10. In Section 10 - IANA considerations:

  The Access Technology Type option defined in Section 8.5 of this
  document introduces a new Access Technology type (ATT) numbering
  space, where the values from 0 to 5 have been reserved by this
  document.  Approval of new Access Technology type values are to be
  made through IANA Expert Review.

There is no need for the new registry. The registry at http://www.iana.org/assignments/ianaiftype-mib already covers all the values mentioned in section 8.5, and future access technologies may be registered as ifTypes - actually need to be registered inorder to be manageable

[Ballot comment]
Section 4., paragraph 2:
> The mobile access gateway and the local mobility anchor MUST
> implement IPsec for protecting the Proxy Mobile IPv6 signaling
> messages [RFC-4301].  That is, IPsec is mandatory to implement
> security mechanism.  However, additional documents may specify
> alternative mechanisms.

  Is there a mechanism by which the MAG and the LMA can detect if the
  other side is using one of the to-be-defined mechanisms, i.e., not
  IPsec? Or is this supposed to be up to configuration?


Section 5.3.6., paragraph 0:
> 5.3.6.  Constructing the Proxy Binding Acknowledgement Message

  This section has several "option X MUST be present, if..." constructs.
  Please say something about whether option X MAY or MUST NOT be present
  when the conditional is false.


Section 3., paragraph 0:
>    Alternatively, if there is mobile
>    node generated timestamp that is increasing at every attachment
>    to the access link and if that timestamp is available to the
>    mobile access gateway (Ex: The timestamp option in the SEND
>    messages that the mobile node sends), the mobile access gateway
>    can use this timestamp or sequence number in the Proxy Binding
>    Update messages and does not have to depend on any external clock
>    source.  However, the specific details on how this is achieved is
>    outside the scope of this document.

  The MN link-attach "timestamp" here might as well be a sequence
  number, so it's not quite accurate to characterize this a
  timestamps-based approach. The magic bits from the MN are carried
  inside the timestamp fields, but that's about as much as can be said.
  Essentially, this scheme is a third approach that depends on the side
  effects of certain link layer technologies implemented at the MN, and
  I'm not extremely thrilled to see this suggested in an IETF document.


Section 2., paragraph 0:
> 2.  An implementation MUST support Sequence Number based scheme, as
>    per [RFC-3775].

  It would be good to repeat the requirement from above that to use this
  scheme, a mechanisms that synchronizes the last sequence number sent
  across all MAGs is REQUIRED.


Section 10., paragraph 0:
> 10.  IANA Considerations

  Who are the proposed IANA Experts for the registries requiring expert
  review? (Question to the AD.)


Nits:

Section 4.1., paragraph 2:
>          and authorize CHILD_SA for remote address lma_addres_1

  Nit: s/lma_addres_1/lma_address_1/


Section 9., paragraph 12:
>    EnableMAGLocalrouting

  Nit: s/EnableMAGLocalrouting/EnableMAGLocalRouting/

[Ballot discuss]
DISCUSS: What happens with packets destined for the MN arriving at the
  LMA during the time a handoff is ongoing? Are they dropped? Are they
  buffered?


Section 5.5., paragraph 5:
> As an alternative to the Timestamp based approach, the specification
> also allows the use of Sequence Number based scheme, as per [RFC-
> 3775].  However, for this scheme to work, the serving mobile access
> gateways in a Proxy Mobile IPv6 domain MUST have the ability to
> obtain the last sequence number that was sent in a binding
> registration message for updating a given mobile node's binding.  The
> sequence number MUST be maintained on a per mobile node basis and
> MUST be synchronized between the serving mobile access gateways.

  DISCUSS: Although the document doesn't describe the mechanism for
  synchronizing the last sequence number sent, it needs to discuss the
  timing and reliability requirements of such synchronization protocols,
  because this introduces an upper bound on the frequency of binding
  updates that can be served.


Section 2., paragraph 0:
> 2.  All the mobility entities in a Proxy Mobile IPv6 domain that are
>    exchanging binding registration messages using the Timestamp
>    option must have adequately synchronized time-of-day clocks.
>    This is the essential requirement for this solution to work.  If
>    this requirement is not met, the solution will not predictably
>    work in all cases.

  DISCUSS: The requirement for clock synchronization deserves a capital
  MUST, and if it can't be guaranteed, the document should clearly
  require that it MUST NOT be used. Also, the document needs to describe
  what it considers "adequate" to be, because the maximum possible clock
  drift between different MAGs establishes an upper bound on the
  supportable frequency of binding updates.


Section 6., paragraph 0:
> 6.  Upon receipt of a Proxy Binding Update message with the Timestamp
>    option, the local mobility anchor MUST check the timestamp field
>    for validity.  In order for it to be considered valid, the
>    timestamp value contained in the Timestamp option MUST be close
>    enough (within TimestampValidityWindow amount of time difference)
>    to the local mobility anchor's time-of-day clock and the
>    timestamp MUST be greater than all previously accepted timestamps
>    in the Proxy Binding Update messages sent for that mobile node.

  DISCUSS: If an MN-provided timestamp is used, as described under point
  3 above, this validity-checking isn't possible, because there is no
  requirement that the MN clock is synchronized to the LMA clock.


Section 6.3., paragraph 1:
> This specification supports only point-to-point access link types and
> thus it assumes that the mobile node and the mobile access gateway
> are the only two nodes on the access link.  The link is assumed to
> have multicast capability.  This protocol may also be used on other
> link types, as long as the link is configured in such a way that it
> guarantees a point-to-point delivery between the mobile node and the
> mobile access gateway for all the protocol traffic.

  DISCUSS: I find the concept of a point-to-point link that supports
  multicast strange, because unicast = multicast for such links. Also, I
  don't quite understand what the requirement "guarantees a
  point-to-point delivery" means - surely this isn't meant to require
  reliable delivery? For example, is a switched Ethernet a link type
  supported by NETLMM? Finally, I also don't understand why NETLMM is
  restricted to certain link types - that seems to be a pretty
  fundamental restriction compared to non-proxy MIPv6. Could all this be
  explained in a bit more detail?

[Ballot discuss]
In section 5.9 it is mentioned that Return Routability procedures in 3775 cannot be used. What impact on the chosen path through the routing topology is expected from the LMA to the home prefix and between the LMA and the mobile node? It appears that the addresses being passed around are very close to being routing protocols.

Later in 5.2 there is mention that this is a per-MN-prefix model and does not support a shared-prefix model. What about aggregate prefixes?

[Ballot discuss]
I like Section 9 which describes the protocol configuration parameters in a clear and detailed manner. I believe though that it is missing two details which I suggest to add:

- how are the local mobility anchor and the mobile access gateway configured? is local configuration by CLI considered enough, or is there a need for remote configuration? Will a MIB module including configuration objects be defined (there is none chartered by now in the NETLMM WG as far as I can see) or something else?

- what is the persistency and the behavior of the configured parameters in a reboot event?

[Ballot comment]
Current specs about Mobile IPv6/IPsec interaction specify also
payload packet protection (which is optional to use). Section 4
about Proxy Mobile IPv6/IPsec interaction seems to ignore this
topic entirely.  At least a statement that no payload packet
protection is provided (possibly with short rationale why not)
should be there.

Section 5.3.2, step 3, is unclear about whether the LMA is allowed
to ignore the prefix "hint" or not. The text seems to say that if
the hint cannot be respected, the LMA must return an error -- but
then calling it "hint" is slightly misleading.

Section 4 would have been lot easier to understand if it had said
in the beginning that PBUs don't have the Home Address destination
option (and PBAs don't have the Type 2 RH with home address).

[Ballot discuss]
Early 3GPP specifications attempted to give phones just an IPv6
address from a single prefix. RFC 3314 describes why this isn't a
good idea, and in particular, why compliance with current and
future IPv6 standards really requires allowing multiple
prefixes. 3GPP fixed their specs based on this. It seems that if
3GPP starts using Proxy Mobile IPv6, this part would break again?
(At least it seems the document assumes that MN gets a single home
network prefix, not multiple.)

The specification seems to assume that MN has just _the_ link-local
address. This restriction is not present in the IPv6 Addressing
Architecture (or many common link layers for IPv6, such as 802.11),
and might not be true in e.g. some SEND configurations. Thus, it
seems enabling Proxy Mobile IPv6 here could break functionality
that would work without it? At the very least, the document should
explain what happens if the client (not knowing that Proxy Mobile
IPv6 is in use) configures more than one link-local address.

The specification is vague on what entity the MN-Identifier
identifies, or is required to identify. Section 6.6 suggests that
it could correspond to Chargeable-User-Identity RADIUS attribute --
but that attribute does not identify a node, it identifies a user
account that could be used from multiple nodes simultaneously.
(Some deployments may of course prohibit using the same user
account from multiple nodes, but in other cases, it's common:
consider an enterprise user with two laptops, but just a single
user account.)  The spec needs to say what the uniqueness
requirements for MN-Identifier are: in particular, is it OK to have
multiple MNs, connecting via the same MAGs/LMAs, with the same
MN-Identifier?  (And if this is OK, perhaps the name
"MN-Identifier" should be changed.)

I couldn't find text saying whether the MAG decrements the Hop
Limit field or not (for packets it forward to the LMA, from the
LMA, or between directly connected nodes if EnableMAGLocalrouting
is enabled). (I'm not sure whether LMA behavior is specified,
either?)

The spec seems to use the word "Interface Identifier" to describe
two completely separate things. First, there's the IPv6 Interface
Identifier, which is used as the lower N bits (usually 64) of some
IPv6 address. Second, there's the "Mobile Node Interface
Identifier", which -- it seems -- is not necessarily used in any
IPv6 address, and could be of any length (even longer than 128
bits). I'd strongly suggest using some other word for the latter
(maybe "link-layer identifier"?), as this is almost certain to
confusion (and possibly interoperability problems when implementors
assume that they're the same -- and in some networks, they actually
could be).

The statement "This specification [...] does not support Shared-Prefix
model" seems false, as Appendix B specifies how to support it.  (And
given that both LMA and MAG require code changes to support it in
interoperable fashion, I don't quite see how this appendix could be
called non-normative, either.) I'd suggest moving the specification
of Shared-Prefix model to a separate document.

[Ballot discuss]
Section 4, Proxy Mobile IPv6 Security, provides some guidelines for the application of
IPsec, but lacks the specificity in several aspects to ensure interoperability. Specifically:

(1) Section 4 specifies that IKEv2 SHOULD be used to setup security associations between
the MAG and LMA, but to my reading IKEv2 is not mandatory to implement.
(2) Section 4 permits the MAG and LMA to use any of the authentication options
specified in IKEv2 for authentication, which is reinforced in section 4.1 which notes
that the peer authentication mechanisms in the PAD examples (shared secrets,
certificates, or EAP) are not exhaustive.  No authentication mechanism is mandatory
to implement.

Did the wg consider specifying IKEv2 as mandatory to implement?  What about
specifying a mandatory to implement authentication mechanism?  If this was
considered and rejected, I would like to understand why mandatory to implement
mechanisms are not required/desirable.

[Ballot comment]
The security considerations provide a nice description of how the Proxy Mobile IPv6 protocol
defends itself against most of the threats listed in RFC 4382, but does not address threats
from the Internet (Section 4 of RFC 4382).  For completeness, please note how the Proxy Mobile
IPv6 protocol does (or does not) defend against these threats.

[Ballot discuss]
This discuss is based on TSV-dir review by Allison Mankin.

1. MTU issues with PMIP. As raised by Allison Mankin in her review there exist a MTU issue here. Both from the general problem of tunnels, but secondly also from the potential for changed access technology in the access link and the path between the MAG and LMA. Both needs to be discussed in the document.

2. ECN. I expect that one at least raise the issue of ECN with tunnel and point at RFC 3168.

We seem to be lacking that generic document that contains all known issues and recommended practices with IP tunnels.

[Ballot comment]
The Gen-ART Review by Elwyn Davies raises two things that might
  deserve some attention.  He previously reviewed -10, and this
  is from his subsequent review of -11.  Elwyn said:

  An editorial update added to s3, para 4 (just after fig 1) to
  emphasize the pivotal role of the MN-Identity would be helpful.
  Something like:
    'The authenticated, stable identifier of the mobile node
    (MN-Identifier) uniquely identifies the mobile node to the
    LMA(s) as the node roams through the Proxy Mobile Domain.'

  Outstanding query: s6.1, bullet 2:  This bullet refers to '*the*
  interface identifier' and suggests that it might be retrieved
  from a Router Solicitation.  My original point was that the IID
  for IPv6 addresses is not necessarily common between the addresses
  configured on an interface.  My comment was a little glib and the
  authors glossed over the point in their reply.  I think this bullet
  may require clarification to indicate which of the IIDs would be
  implied here.  Particularly if SEND is in use, the IID used for the
  link local address (that would typically be found in the
  solicitation) will a.s. differ from the IID used with the address
  assigned out of the prefix allocated by Proxy MIP.  My original
  point was to ask the authors to clarify whether ProxyMIP actually
  cares which IID is used and, accordingly, state either that 'it
  doesn't matter' or specifically which IID should be transmitted.

[Ballot comment]
The Gen-ART Review by Elwyn Davies raises tow things that might
  deserve some attention.  He previously reviewed -10, and this
  is from his subsequent review of -11.  Elwyn said:

  An editorial update added to s3, para 4 (just after fig 1) to
  emphasize the pivotal role of the MN-Identity would be helpful.
  Something like:
    'The authenticated, stable identifier of the mobile node
    (MN-Identifier) uniquely identifies the mobile node to the
    LMA(s) as the node roams through the Proxy Mobile Domain.'

  Outstanding query: s6.1, bullet 2:  This bullet refers to '*the*
  interface identifier' and suggests that it might be retrieved
  from a Router Solicitation.  My original point was that the IID
  for IPv6 addresses is not necessarily common between the addresses
  configured on an interface.  My comment was a little glib and the
  authors glossed over the point in their reply.  I think this bullet
  may require clarification to indicate which of the IIDs would be
  implied here.  Particularly if SEND is in use, the IID used for the
  link local address (that would typically be found in the
  solicitation) will a.s. differ from the IID used with the address
  assigned out of the prefix allocated by Proxy MIP.  My original
  point was to ask the authors to clarify whether ProxyMIP actually
  cares which IID is used and, accordingly, state either that 'it
  doesn't matter' or specifically which IID should be transmitted.

IANA Last Call comments:

[ NOTE TO AUTHOR: It would be useful if you had a table of
registrations rather than requiring IANA to pick them out of the
text.

Also, the document has a bunch of bit fields that don't have
registries. Do you want registries of those bit fields so that the bits
can be assigned? ]

IESG NOTE: Expert Assignment Required

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "Mobile IPv6 parameters" registry located at
http://www.iana.org/assignments/mobility-parameters
sub-registry "Mobility Options"

Value Description Reference
----- ----------------------------------------- ---------
[tbd] Home Network Prefix option [RFC-netlmm-proxymip6-09]
[tbd] Handoff Indicator option [RFC-netlmm-proxymip6-09]
[tbd] Access Technology Type option [RFC-netlmm-proxymip6-09]
[tbd] Timestamp option [RFC-netlmm-proxymip6-09]
[tbd] Mobile Node Interface Identifier option [RFC-netlmm-proxymip6-09]
[tbd] Link-local Address option [RFC-netlmm-proxymip6-09]


Action 2:

[ Expert Assignment Required ]

Upon approval of this document, the IANA will in the following
registry "Mobile IPv6 parameters " located at
http://www.iana.org/assignments/mobility-parameters
create a new sub-registry "Access Technology Type Option Subtypes"

Registration Procedures: Expert Review
Initial contents of this sub-registry will be:


Value Description Reference
----- ----------------------------------------- ---------
0 Reserved [RFC-netlmm-proxymip6-09]
1 Virtual [RFC-netlmm-proxymip6-09]
2 PPP [RFC-netlmm-proxymip6-09]
3 802.3 (Ethernet) [RFC-netlmm-proxymip6-09]
4 802.11a/b/g [RFC-netlmm-proxymip6-09]
5 802.16e [RFC-netlmm-proxymip6-09]
6-255 Available for assignment [RFC-netlmm-proxymip6-09]


Action 3:

Upon approval of this document, the IANA will make the following
assignments in the "Mobile IPv6 parameters " registry located at
http://www.iana.org/assignments/mobility-parameters
sub-registry "Status Codes"

[ tbd values must be greater than 128 ]

Value Description Reference
----- --------------------------- ---------
[tbd] PROXY_REG_NOT_ENABLED [RFC-netlmm-proxymip6-09]
[tbd] MAG_NOT_AUTHORIZED_FOR_PROXY_REG [RFC-netlmm-proxymip6-09]
[tbd] NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX [RFC-netlmm-proxymip6-09]
[tbd] TIMESTAMP_MISMATCH [RFC-netlmm-proxymip6-09]
[tbd] TIMESTAMP_LOWER_THAN_PREV_ACCEPTED [RFC-netlmm-proxymip6-09]
[tbd] MISSING_HOME_NETWORK_PREFIX_OPTION [RFC-netlmm-proxymip6-09]
[tbd] MISSING_MN_IDENTIFIER_OPTION [RFC-netlmm-proxymip6-09]
[tbd] MISSING_HANDOFF_INDICATOR_OPTION [RFC-netlmm-proxymip6-09]
[tbd] MISSING_ACCESS_TECH_TYPE_OPTION [RFC-netlmm-proxymip6-09]

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

PROTO Write-up

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

The document has had extensive review by the WG. An extential WGLC was
conducted.


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

As the document shepherd, I have no concerns on the extensivity of the
review of the document.


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

There have been multiple IPR disclosures on the document - both as a WG
version and as individual-draft. This area is extremely thoroughly
researched, and almost everything that relates to mobile, wireless network
mobility has been protected by IPR. Thus, it is practically impossible
to find a square inch of area in these technologies that would not
be patented somewhere.

IPR disclosures:

Two disclosures to the WG document version:
2008-01-04 911 Nokia Siemens Networks Oy's Statement about IPR related
to draft-ietf-netlmm-proxymip6-08 (https://datatracker.ietf.org/ipr/911/)
2007-08-28 881 Nortel Networks Limited's Statement about IPR
claimed in draft-ietf-netlmm-proxymip6-01.txt
(https://datatracker.ietf.org/ipr/881/)

disclosures on previous versions of the document:
2007-04-10 834 QUALCOMM Incorporated's statement about IPR
claimed in draft-sgundave-mip6-proxymip6-02.txt
(https://datatracker.ietf.org/ipr/834/)
2007-03-15 822 Samsung Electronics's statement about IPR claimed
in draft-sgundave-mip6-proxymip6-02.txt
(https://datatracker.ietf.org/ipr/822/)
2007-02-28 807 Cisco's Statement about IPR claimed in
draft-sgundave-mip6-proxymip6 (https://datatracker.ietf.org/ipr/807/)
2006-11-06 756 Nokia Corporation's statement about IPR claimed in
draft-sgundave-mipv6-proxymipv6-00.txt
(https://datatracker.ietf.org/ipr/756/)

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

There is a strong consensus behind the 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 threatned to appeal and the document is product of the whole WG
effort.

However, the WG went through an analysis of using a new protocol versus
building
on Mobile IPv6 to meet the goals of NETLMM. There were extensive
debates about the merits of each solution and the consensus eventually
was to go with a Proxy Mobile IPv6 based approach. At the time (around
Jan 2007), there were some strong objections to the decision and some
talk of a potential appeal. However, no such discussion has happened
recently and the current protocol document is a product of the WG as a
whole.


# (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 are no normative documents 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?

No formal languange segments exist.


# (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
Proxy Mobile IPv6 enables IP mobility for a host
without requiring its participation in any mobility related
signaling. Instead, the Network is responsible for managing IP mobility
on
behalf of the host.

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 various reviews and a successful WGLC.

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