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 |