Skip to main content

Prefix Delegation Support for Proxy Mobile IPv6
draft-ietf-netext-pd-pmip-14

Revision differences

Document history

Date Rev. By Action
2014-03-07
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-02-21
14 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-02-12
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-01-08
14 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-01-07
14 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-01-06
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-01-06
14 (System) IANA Action state changed to In Progress
2014-01-03
14 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2014-01-03
14 (System) RFC Editor state changed to EDIT
2014-01-03
14 (System) Announcement was received by RFC Editor
2014-01-02
14 Cindy Morgan State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2014-01-02
14 Cindy Morgan IESG has approved the document
2014-01-02
14 Cindy Morgan Closed "Approve" ballot
2013-12-30
14 Brian Haberman Ballot writeup was changed
2013-12-30
14 Brian Haberman Ballot approval text was generated
2013-12-18
14 Carlos Jesús Bernardos New version available: draft-ietf-netext-pd-pmip-14.txt
2013-12-12
13 Joel Jaeggli
[Ballot comment]
cleared my discuss having had it addressed.

was:

From the ops-dir review

I don't see these as blockers but I'd like to seem …
[Ballot comment]
cleared my discuss having had it addressed.

was:

From the ops-dir review

I don't see these as blockers but I'd like to seem some dicussion on them, thanks.

...
However, the document doesn't provide much guidance in general in terms of logging/reporting. For e.g., in Section 5.1.2 Signaling Considerations - Is there a mechanism to inform the mobile router with some status in the event that the MAG receives a REQUESTED_DMNP_IN_USE or NOT_AUTHORIZED_FOR_DELEGATED_MNP message?
...
Also, in some cases  it is not clear if packets should be silently discarded (e.g. section 5.1.4 Packet Forwarding) or logged and discarded. I'd imagine that the latter might be beneficial from an operational point of view. Not sure if there was any discussion regarding this.
...
2013-12-12
13 Joel Jaeggli [Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from Discuss
2013-12-11
13 Ted Lemon
[Ballot comment]
In Section 1, paragraph 1, this isn't a complete sentence:

  In this context, the mobility management support that
  is enabled for …
[Ballot comment]
In Section 1, paragraph 1, this isn't a complete sentence:

  In this context, the mobility management support that
  is enabled for an individual IP host, which is the mobile node.

I don't know what was intended here, but please figure it out and fix it. :)

The use of the term "mobile network" to mean the network that is moving around is _really_ confusing. I get why you chose this terminology, but every time I see "mobile network" I think of the upstream network, rather than the downstream network.

In 3.2.1:
  The Advertise and Request messages are optional, and they
  are not used if a two message client-server exchange is used.

This is a really vague way of saying something that is sort of true.  The right way to say this is:
  If the requesting router includes a Rapid Commit option in its
  Solicit message, it is preferable that the MAG respond directly
  with a Reply rather than with an Advertise message, as described
  in RFC 3315, Section 17.2.3.

In 3.2.2 paragraph 2, the relay agent behavior is described in RFC 3315, not RFC 3633.

In 4.1, given that at least 8 of the sixteen bits of the DMNP are going to be zero, wouldn't it make sense to only include the bits that are included in the prefix length, and default the rest to zero?

In 5.1.3.1:

  o  In case the Proxy Binding Update signaling with the local mobility
      anchor is not completed successfully, for example because the
      local mobility anchor is not authorized for delegated mobile
      network prefix or the requested prefix is in use, the DHCPv6
      Delegating Router will send a Reply message to the Requesting
      Router containing the IA_PD with the lifetimes of the prefixes in
      the IA_PD set to zero.

This text only makes sense after the MR has successfully gotten a prefix delegation.  Before that, there won't be any prefixes in the IA_PD.  You would do better to just defer to RFC 3633:

  o  In case the Proxy Binding Update signaling with the local mobility
      anchor is not completed successfully, for example because the
      local mobility anchor is not authorized for delegated mobile
      network prefix or the requested prefix is in use, the DHCPv6
      Delegating Router will send a Reply message to the Requesting
      Router with no IA_PREFIX suboptions and with a Status Code
      option as described in RFC 3633, section 11.2.

The same advice applies to the equivalent paragraph in 5.1.3.2.

Next paragraph:

  The standard DHCPv6 considerations will be applied with respect to
  the interactions between the Delegating Router and the Requesting
  Router.  The Delegating Router is provided with the delegated
  prefix(es), which can then be then advertised in the mobile network,
  and therefore used by the locally fixed nodes to auto configure IP
  addresses allowing to gain access to the Internet.

The last sentence should probably start with "The Requesting Router," since it's the requesting router that's in the MR, not the delegating router.

Former DISCUSS:

DISCUSS item 1:

In 3.2.2, paragraph 2, the text doesn't really describe what's happening in the diagram. Not only is this a usability issue for vision-challenged readers, you're glossing over some very weird behavior here.  I would suggest the following change:
OLD:
  Once the mobile access gateway gets the set of
  delegated prefixes from the delegating router function running on the
  local mobility anchor, it conveys it in a proxy binding update.  This
  ensures that the local mobility anchor properly routes the traffic
  addressed to the delegated prefixes via the PMIPv6 tunnel established
  with the mobile access gateway, and that mobility is provided to
  these prefixes while the mobile router roams within the PMIPv6
  domain.
NEW:
  If the client did not request Rapid Commit, or the LMA doesn't
  support it, the relay agent on the MAG will behave normally in
  accordance with RFC 3315 in handling the Advertise message
  from the DR and the Request message from the RR.  However,
  the MAG does not strictly follow RFC3315 in its handling of the
  Reply message.

  When the MAG receives the DHCPv6 Reply message from the
  LMA, it extracts the DMNP from the Reply message and
  sends a PBU to the LMA containing the DMNP from the
  Reply message.  When the PBA comes back from the
  LMA containing the DMNP, the Reply message is forwarded
  to the client.

I realize that the intention here was to gloss over this and leave it for the interworking stuff that isn't specified in this document, but what you are doing to the relay function in the MAG here is sufficiently weird that I think you need to call it out explicitly.


You can resolve this DISCUSS item by making the change I've proposed above, or explaining why that's not the right thing to do.

I am also concerned that you haven't accounted for any of the things that can go awry during this process, but I am reluctant to demand that you fully flesh out the interworking, and that is what you would have to do to address this problem.  You do not need to address this point to clear the DISCUSS, but I'm mentioning it here because it concerns me and is related to the first DISCUSS item.

DISCUSS item 2:

I'm noticing in 5.1.3.2 that you are talking about IPv4 prefixes, but of course RFC3633 does not support IPv4 prefixes.  What's the intention here?  To resolve this DISCUSS item you need to explain what was intended here and possibly negotiate a fix.

DISCUSS item 3:

You never talk about how the identity of the MR that is presented over DHCPv6 will be correlated with the identity of the MR that is presented over PMIPv6.  This seems like an important detail.  Have you thought about it?  Why isn't it described here?  To resolve this DISCUSS item, you need to answer these questions and possibly add some text, with which I will be happy to help.
2013-12-11
13 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2013-12-08
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-12-08
13 Carlos Jesús Bernardos IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-12-08
13 Carlos Jesús Bernardos New version available: draft-ietf-netext-pd-pmip-13.txt
2013-11-28
12 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2013-11-21
12 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-11-21
12 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-11-21
12 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-11-21
12 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-11-21
12 Stephen Farrell
[Ballot comment]

I'd like to be able to use an MR that can do this, so
thanks for working on this.

I expected to see …
[Ballot comment]

I'd like to be able to use an MR that can do this, so
thanks for working on this.

I expected to see a security consideration to the effect
that there could be DoS issues e.g. for the LMA caused
by a large set of LFNs being behind an MR. Doesn't
something like that warrant a mention?
2013-11-21
12 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-11-20
12 Ted Lemon
[Ballot discuss]
DISCUSS item 1:

In 3.2.2, paragraph 2, the text doesn't really describe what's happening in the diagram. Not only is this a usability …
[Ballot discuss]
DISCUSS item 1:

In 3.2.2, paragraph 2, the text doesn't really describe what's happening in the diagram. Not only is this a usability issue for vision-challenged readers, you're glossing over some very weird behavior here.  I would suggest the following change:
OLD:
  Once the mobile access gateway gets the set of
  delegated prefixes from the delegating router function running on the
  local mobility anchor, it conveys it in a proxy binding update.  This
  ensures that the local mobility anchor properly routes the traffic
  addressed to the delegated prefixes via the PMIPv6 tunnel established
  with the mobile access gateway, and that mobility is provided to
  these prefixes while the mobile router roams within the PMIPv6
  domain.
NEW:
  If the client did not request Rapid Commit, or the LMA doesn't
  support it, the relay agent on the MAG will behave normally in
  accordance with RFC 3315 in handling the Advertise message
  from the DR and the Request message from the RR.  However,
  the MAG does not strictly follow RFC3315 in its handling of the
  Reply message.

  When the MAG receives the DHCPv6 Reply message from the
  LMA, it extracts the DMNP from the Reply message and
  sends a PBU to the LMA containing the DMNP from the
  Reply message.  When the PBA comes back from the
  LMA containing the DMNP, the Reply message is forwarded
  to the client.

I realize that the intention here was to gloss over this and leave it for the interworking stuff that isn't specified in this document, but what you are doing to the relay function in the MAG here is sufficiently weird that I think you need to call it out explicitly.


You can resolve this DISCUSS item by making the change I've proposed above, or explaining why that's not the right thing to do.

I am also concerned that you haven't accounted for any of the things that can go awry during this process, but I am reluctant to demand that you fully flesh out the interworking, and that is what you would have to do to address this problem.  You do not need to address this point to clear the DISCUSS, but I'm mentioning it here because it concerns me and is related to the first DISCUSS item.

DISCUSS item 2:

I'm noticing in 5.1.3.2 that you are talking about IPv4 prefixes, but of course RFC3633 does not support IPv4 prefixes.  What's the intention here?  To resolve this DISCUSS item you need to explain what was intended here and possibly negotiate a fix.

DISCUSS item 3:

You never talk about how the identity of the MR that is presented over DHCPv6 will be correlated with the identity of the MR that is presented over PMIPv6.  This seems like an important detail.  Have you thought about it?  Why isn't it described here?  To resolve this DISCUSS item, you need to answer these questions and possibly add some text, with which I will be happy to help.
2013-11-20
12 Ted Lemon
[Ballot comment]
In Section 1, paragraph 1, this isn't a complete sentence:

  In this context, the mobility management support that
  is enabled for …
[Ballot comment]
In Section 1, paragraph 1, this isn't a complete sentence:

  In this context, the mobility management support that
  is enabled for an individual IP host, which is the mobile node.

I don't know what was intended here, but please figure it out and fix it. :)

The use of the term "mobile network" to mean the network that is moving around is _really_ confusing. I get why you chose this terminology, but every time I see "mobile network" I think of the upstream network, rather than the downstream network.

In 3.2.1:
  The Advertise and Request messages are optional, and they
  are not used if a two message client-server exchange is used.

This is a really vague way of saying something that is sort of true.  The right way to say this is:
  If the requesting router includes a Rapid Commit option in its
  Solicit message, it is preferable that the MAG respond directly
  with a Reply rather than with an Advertise message, as described
  in RFC 3315, Section 17.2.3.

In 3.2.2 paragraph 2, the relay agent behavior is described in RFC 3315, not RFC 3633.

In 4.1, given that at least 8 of the sixteen bits of the DMNP are going to be zero, wouldn't it make sense to only include the bits that are included in the prefix length, and default the rest to zero?

In 5.1.3.1:

  o  In case the Proxy Binding Update signaling with the local mobility
      anchor is not completed successfully, for example because the
      local mobility anchor is not authorized for delegated mobile
      network prefix or the requested prefix is in use, the DHCPv6
      Delegating Router will send a Reply message to the Requesting
      Router containing the IA_PD with the lifetimes of the prefixes in
      the IA_PD set to zero.

This text only makes sense after the MR has successfully gotten a prefix delegation.  Before that, there won't be any prefixes in the IA_PD.  You would do better to just defer to RFC 3633:

  o  In case the Proxy Binding Update signaling with the local mobility
      anchor is not completed successfully, for example because the
      local mobility anchor is not authorized for delegated mobile
      network prefix or the requested prefix is in use, the DHCPv6
      Delegating Router will send a Reply message to the Requesting
      Router with no IA_PREFIX suboptions and with a Status Code
      option as described in RFC 3633, section 11.2.

The same advice applies to the equivalent paragraph in 5.1.3.2.

Next paragraph:

  The standard DHCPv6 considerations will be applied with respect to
  the interactions between the Delegating Router and the Requesting
  Router.  The Delegating Router is provided with the delegated
  prefix(es), which can then be then advertised in the mobile network,
  and therefore used by the locally fixed nodes to auto configure IP
  addresses allowing to gain access to the Internet.

The last sentence should probably start with "The Requesting Router," since it's the requesting router that's in the MR, not the delegating router.
2013-11-20
12 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2013-11-20
12 Gunter Van de Velde Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Kiran Chittimaneni.
2013-11-20
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-11-20
12 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-11-19
12 Joel Jaeggli
[Ballot discuss]
From the ops-dir review

I don't see these as blockers but I'd like to seem some dicussion on them, thanks.

...
However, the …
[Ballot discuss]
From the ops-dir review

I don't see these as blockers but I'd like to seem some dicussion on them, thanks.

...
However, the document doesn't provide much guidance in general in terms of logging/reporting. For e.g., in Section 5.1.2 Signaling Considerations - Is there a mechanism to inform the mobile router with some status in the event that the MAG receives a REQUESTED_DMNP_IN_USE or NOT_AUTHORIZED_FOR_DELEGATED_MNP message?
...
Also, in some cases  it is not clear if packets should be silently discarded (e.g. section 5.1.4 Packet Forwarding) or logged and discarded. I'd imagine that the latter might be beneficial from an operational point of view. Not sure if there was any discussion regarding this.
...
2013-11-19
12 Joel Jaeggli [Ballot Position Update] New position, Discuss, has been recorded for Joel Jaeggli
2013-11-19
12 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-11-19
12 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-11-18
12 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-11-15
12 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-11-15
12 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Kiran Chittimaneni
2013-11-15
12 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Kiran Chittimaneni
2013-11-14
12 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2013-11-14
12 Jean Mahoney Request for Telechat review by GENART is assigned to Martin Thomson
2013-11-08
12 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-11-08
12 Brian Haberman State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-11-08
12 Brian Haberman Placed on agenda for telechat - 2013-11-21
2013-11-08
12 Brian Haberman State changed to Waiting for AD Go-Ahead from Waiting for Writeup
2013-11-08
12 Brian Haberman Ballot has been issued
2013-11-08
12 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2013-11-08
12 Brian Haberman Created "Approve" ballot
2013-11-08
12 Brian Haberman Ballot writeup was changed
2013-11-04
12 Carlos Jesús Bernardos IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-11-04
12 Carlos Jesús Bernardos New version available: draft-ietf-netext-pd-pmip-12.txt
2013-10-31
11 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-10-31)
2013-10-29
11 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-10-29
11 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-netext-pd-pmip-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-netext-pd-pmip-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Mobility Header Types - for the MH Type field in the Mobility Header registry in the Mobile IPv6 parameters page at

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

a new Mobility Header option will be registered as follows:

Value: [ TBD-at-registration ]
Description: Delegated Mobile Network Prefix
Reference: [ RFC-to-be ]

Second, in the Status Codes subregistry of the Mobility Header registry in the Mobile IPv6 parameters page at

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

two new Status Codes will be registered as follows:

Value: [ TBD-at-registration ]
Description: NOT_AUTHORIZED_FOR_DELEGATED_MNP
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: REQUESTED_DMNP_IN_USE
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-10-27
11 Martin Thomson Request for Last Call review by GENART Completed: Ready. Reviewer: Martin Thomson.
2013-10-24
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2013-10-24
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sandra Murphy
2013-10-21
11 Carlos Jesús Bernardos New version available: draft-ietf-netext-pd-pmip-11.txt
2013-10-17
10 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2013-10-17
10 Jean Mahoney Request for Last Call review by GENART is assigned to Martin Thomson
2013-10-17
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-10-17
10 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Prefix Delegation Support for Proxy …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Prefix Delegation Support for Proxy Mobile IPv6) to Proposed Standard


The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Prefix Delegation Support for Proxy Mobile IPv6'
  as 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 2013-10-31. 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.

Abstract


  This specification defines extensions to the Proxy Mobile IPv6
  protocol for allowing a mobile router in a Proxy Mobile IPv6 domain
  to obtain IP prefixes for its attached mobile networks using DHCPv6
  prefix delegation.  Network-based mobility management support is
  provided for those delegated IP prefixes just as it is provided for
  the mobile node's home address.  Even if the mobile router performs a
  handoff and changes its network point of attachment, mobility support
  is ensured for all the delegated IP prefixes and for all the IP nodes
  in the mobile network that use IP address configuration from those
  delegated IP prefixes.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-pd-pmip/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2121/



2013-10-17
10 Amy Vezza State changed to In Last Call from Last Call Requested
2013-10-17
10 Brian Haberman Last call was requested
2013-10-17
10 Brian Haberman Last call announcement was generated
2013-10-17
10 Brian Haberman Ballot approval text was generated
2013-10-17
10 Brian Haberman Ballot writeup was generated
2013-10-17
10 Brian Haberman State changed to Last Call Requested from AD Evaluation::External Party
2013-10-09
10 Brian Haberman State changed to AD Evaluation::External Party from AD Evaluation::AD Followup
2013-10-08
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-10-08
10 Carlos Jesús Bernardos New version available: draft-ietf-netext-pd-pmip-10.txt
2013-08-14
09 Brian Haberman State changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2013-08-14
09 Brian Haberman

All,
    I have performed my AD review of draft-ietf-netext-pd-pmip.  I apologize for it taking as long as it did.  Overall, I am supportive …

All,
    I have performed my AD review of draft-ietf-netext-pd-pmip.  I apologize for it taking as long as it did.  Overall, I am supportive of this work, but I have some concerns.  I *think* most of my concerns have to do with a lack of clarity in the spec caused by the layout of the draft.  Of particular concern is the overabundance of bullet lists in sections 5.1.2.

    Please let me know if you need additional detail on any of these comments.  Otherwise, I will await a revised version that the WG is happy with.


1. In the Abstract, mention that prefix delegation is being described in relation to DHCPv6-PD

2. The Introduction says prefix delegation via DHCPv6 or through other mechanisms.  Later, the draft says DHCPv6 or static configuration.  I can see how both of those could be made to work, but I am leery of mentioning some future PD protocol.  How would that work?  How would you know which mechanism is being used?  Will the same PMIPv6
signaling suffice for a future PD protocol?  I think it makes sense to stick to what we know how to do today.

3. Figures 2-4 are never referenced in the text.

4. Intro uses MAG without expansion or definition.

5. Introduction defines egress and ingress interfaces, but should explicitly state these terms are defined from the perspective of the mobile network.  I would actually move these definitions to section 2 and describe the MR function in relation to the mobile network and the point-of-attachment.

6. How do the definitions in section 2 relate to the definitions in RFC 4885?

7. Section 3.1 - any additional assumptions about how an MR knows which interface to use when making DHCPv6 requests?

8. Sections 3.2.1 and 3.2.2 are rather sparse in descriptive text.  It would be good to briefly describe the steps outlined in the corresponding figures.

9. Section 5.1.2 - Fourth bullet says the MAG MAY choose to send PBA after getting a DMNP_IN_USE return code.  Why would it (or not) do that?

10. The bullet lists in 5.1.2/5.2.2 (and child sections) are confusing.  The high-level bullets read like they should just be paragraphs.  The sub-list in bullet two and five are items that need to
be considered if stated conditions are met, correct?.  And am I correct in that there must be 3 instances of the DMNP option in the PBU?

11. Structure of 5.1.2.1 is confusing.  Can DHCP-MAG Interactions be promoted to 5.1.3 and then have 5.1.3.1 describe when MAG is DR and 5.1.3.2 describe when LMA is DR?

12. Bullet 2 of the DR at the MAG scenario is confusing. If the DR and MAG are co-located, what interactions are beyond the scope of this document?  Or is this more of the interactions between two processes running on the same platform?

13. If the MR roams to a MAG that does not support PD, is there specific behavior the MR needs to exhibit wrt the LFNs?

14. Is there a preference (operational issues) for running the DR at the LMA rather than the MAG, or vice versa?  If so, should that be noted?


Regards,
Brian
2013-07-25
09 Brian Haberman State changed to AD Evaluation from Publication Requested
2013-07-24
09 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard. Type of RFC is indicated in the title page header.


(2) 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 specification defines extensions to Proxy Mobile IPv6 protocol
  for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain
  delegated IP prefixes for its attached mobile networks.  The mobility
  entities in the network will provide network-based mobility
  management support for those delegated IP prefixes just as how IP
  mobility support is provided for the mobile node's home address.
  Even as the mobile router performs a handoff and changes its network
  point of attachment, mobility support is ensured for all the
  delegated IP prefixes and for all the IP nodes in the mobile network
  that use IP address configuration from those delegated IP prefixes.

Working Group Summary:

  The working group has discussed this I-D at length. Comments by
  Alexandru Petrescu
  (http://www.ietf.org/mail-archive/web/netext/current/msg02815.html)
  claimed that the proposal was similar to work being done in other
  working groups. However the working group members believe that this
  extension is essential for Proxy Mobile IPv6 and hence needs to be
  published on its own.

Document Quality:

  The document has been reviewed extensively and revised as a result
  of these reviews. The quality of the document at this time is good
  and ready for IESG review.
  No known implementations of this extension to the Proxy Mobile IPv6
  protocol exist. However a few vendors have expressed plans to
  implement it.
  All reviewers have been appropriately acknowledged in the I-D.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd: Basavaraj Patil
  Responsible AD:    Brian Haberman

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed this I-D multiple times (different versions) and
  have worked with the authors in updating and improving it. This
  version of the document is ready for IESG review and publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The I-D proposes a solution for prefix delegation by a mobile
  router. There is no necessity of a broader review from the
  perspective of security, operational complexity, DHCP, DNS or
  internationalization. This specification inherits security and
  operational aspects from the base protocol (RFC5213).

(6) Describe any specific concerns or issues that the Document
Shepherd has 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.

  As document shepherd, I do not not have any concerns with this
  document.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78
and BCP 79 have already been filed. If not, explain why?

All authors have confirmed that they are in full conformance of BCP 78
and 79.
An IPR disclosure has been provided to the WG. See:
https://datatracker.ietf.org/ipr/2121/


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes. IPR disclosure has been filed. The WG was notified about this
  IPR disclosure and a last call conducted. The WG did not have any
  comments or concerns expressed regarding the IPR disclosure.

(9) 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 strong WG consensus for publishing this I-D as a proposed
  standard. Consensus ia across the broader WG.

(10) 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 publicly available.)

  There has not been any extreme discontent by anyone w.r.t this
  I-D. There has been some opposition to this I-D, but this has been
  limited to one WG member only and does not represent the broader WG
  consensus.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

I-D nits summary:
"
  Checking nits according to http://www.ietf.org/id-info/checklist :

----------------------------------------------------------------------------

    No issues found here.

"

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document does not specify a MIB, media types of URI types and
  hence does not require a review from experts in those areas.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) 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 plan for their completion?

No. All references in this I-D are published RFCs.


(15) Are there downward normative references references (see RFC
3967
)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No. There are no downward normative references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  Publication of this document will not change the status of existing
  RFCs including the Proxy Mobile IPv6 base protocol (RFC5213).


(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226
).

  The IANA considerations section specifies two actions for IANA. As
  shepherd I have reviewed the IANA considerations section and believe
  that all relevant information has been included for IANA to act on.


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  No new IANA registries are required as a result of this I-D.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The I-D does not include any XML code, BNF rules or MIB
  definitions.
2013-07-24
09 Cindy Morgan IESG process started in state Publication Requested
2013-07-24
09 Basavaraj Patil Changed consensus to Yes from Unknown
2013-07-24
09 Basavaraj Patil Intended Status changed to Proposed Standard from None
2013-07-24
09 Basavaraj Patil Changed document writeup
2013-07-02
(System) Posted related IPR disclosure: ZTE CORPORATION's Statement about IPR related to draft-ietf-netext-pd-pmip-09
2013-06-18
09 Carlos Jesús Bernardos New version available: draft-ietf-netext-pd-pmip-09.txt
2013-05-19
08 Sri Gundavelli New version available: draft-ietf-netext-pd-pmip-08.txt
2013-05-16
07 Sri Gundavelli New version available: draft-ietf-netext-pd-pmip-07.txt
2013-02-25
06 Sri Gundavelli New version available: draft-ietf-netext-pd-pmip-06.txt
2012-10-22
05 Sri Gundavelli New version available: draft-ietf-netext-pd-pmip-05.txt
2012-10-18
04 Xingyue Zhou New version available: draft-ietf-netext-pd-pmip-04.txt
2012-07-15
03 Xingyue Zhou New version available: draft-ietf-netext-pd-pmip-03.txt
2012-03-12
02 Xingyue Zhou New version available: draft-ietf-netext-pd-pmip-02.txt
2011-10-30
01 (System) New version available: draft-ietf-netext-pd-pmip-01.txt
2011-08-22
00 (System) New version available: draft-ietf-netext-pd-pmip-00.txt