Transient Binding for Proxy Mobile IPv6
draft-ietf-mipshop-transient-bce-pmipv6-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
2011-02-25
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-02-24
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-02-24
|
07 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
2011-02-23
|
07 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-02-22
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-02-22
|
07 | Amy Vezza | IESG has approved the document |
2011-02-22
|
07 | Amy Vezza | Closed "Approve" ballot |
2011-02-17
|
07 | Cindy Morgan | Removed from agenda for telechat |
2011-02-17
|
07 | Cindy Morgan | State changed to Approved-announcement to be sent from IESG Evaluation. |
2011-02-17
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-17
|
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-16
|
07 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-02-15
|
07 | Russ Housley | [Ballot comment] Do either of the IPR statements related to this document cause pause? |
2011-02-15
|
07 | Russ Housley | Created "Approve" ballot |
2011-02-08
|
07 | Jari Arkko | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-02-08
|
07 | Jari Arkko | Placed on agenda for telechat - 2011-02-17 |
2011-01-24
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-01-10
|
07 | Amy Vezza | Last call sent |
2011-01-10
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Transient Binding for Proxy Mobile IPv6) to Experimental RFC The IESG has received a request from the Mobility for IP: Performance, Signaling and Handoff Optimization WG (mipshop) to consider the following document: - 'Transient Binding for Proxy Mobile IPv6' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-01-24. 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. This draft is being re-last called due to new IPR information. Information about the IPR can be found from: https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=17935 The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mipshop-transient-bce-pmipv6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mipshop-transient-bce-pmipv6/ |
2011-01-10
|
07 | Amy Vezza | Last Call text changed |
2011-01-09
|
07 | Jari Arkko | Last Call was requested |
2011-01-09
|
07 | Jari Arkko | State changed to Last Call Requested from AD Evaluation. |
2011-01-09
|
07 | Jari Arkko | Last Call text changed |
2011-01-09
|
07 | Jari Arkko | Last Call text changed |
2011-01-09
|
07 | Jari Arkko | State changed to AD Evaluation from RFC Ed Queue. Have to go back to WGLC because a new IPR disclosure was filed. |
2010-11-23
|
(System) | Posted related IPR disclosure: Qualcomm Incorporated's Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-07 | |
2010-09-13
|
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-09-13
|
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-09-13
|
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-09-13
|
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-09-13
|
07 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2010-09-13
|
07 | (System) | IANA Action state changed to In Progress |
2010-09-13
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-09-13
|
07 | Amy Vezza | IESG has approved the document |
2010-09-13
|
07 | Amy Vezza | Closed "Approve" ballot |
2010-09-08
|
07 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-07.txt |
2010-09-08
|
07 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko |
2010-09-08
|
07 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss by Sean Turner |
2010-09-07
|
07 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2010-09-07
|
07 | Jari Arkko | RFC Editor note updated. Waiting for Sean to clear his discuss and the authors to tell me if there is something else that they want … RFC Editor note updated. Waiting for Sean to clear his discuss and the authors to tell me if there is something else that they want to change before the document is approved. |
2010-09-01
|
07 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup by Cindy Morgan |
2010-08-26
|
07 | Cindy Morgan | State changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead by Cindy Morgan |
2010-08-26
|
07 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2010-08-26
|
07 | Sean Turner | [Ballot discuss] The security considerations section needs to indicate whether there are any new security considerations introduced in addition to those in RFC 5213. |
2010-08-26
|
07 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded by Sean Turner |
2010-08-26
|
07 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel |
2010-08-26
|
07 | Adrian Farrel | [Ballot comment] Clearing my Discuss on the basis of Jari's answer: "That's a good question to ask. The answer is yes." |
2010-08-26
|
07 | Adrian Farrel | [Ballot discuss] This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG … [Ballot discuss] This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG is aware of for discussion on the telechat if necessary. This I-D is Experimental. It requests IANA to allocate some code points from registries that are marked as "Standards Action or IESG Approval" Obviously, "Standards Action" does not apply to this Experimental I-D. RFC 5226 is quite wordy wrt to "IESG Approval" saying: IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis. IESG Approval is not intended to be used often or as a "common case"; indeed, it has seldom been used in practice during the period RFC 2434 was in effect. Rather, it is intended to be available in conjunction with other policies as a fall-back mechanism in the case where one of the other allowable approval mechanisms cannot be employed in a timely fashion or for some other compelling reason. IESG Approval is not intended to circumvent the public review processes implied by other policies that could have been employed for a particular assignment. IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus). The following guidelines are suggested for any evaluation under IESG Approval: - The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason to use that path. - Before approving a request, the community should be consulted, via a "call for comments" that provides as much information as is reasonably possible about the request. Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and Option values [RFC3775]. I wanted to check with the responsible AD that this I-D falls into this category. |
2010-08-26
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-08-26
|
07 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2010-08-26
|
07 | Alexey Melnikov | [Ballot comment] 6. IANA Considerations This specification also adds one status code value to the Proxy Binding Acknowledge message, the PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status … [Ballot comment] 6. IANA Considerations This specification also adds one status code value to the Proxy Binding Acknowledge message, the PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code. The PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in Section 4.7. Its value must be assigned from the same number space used for the Mobile IPv6 Binding Acknowledgement status values, as defined in [RFC3775], and must be smaller 128. I am looking at and I am not finding "Binding Acknowledgement status" sub-registry. Am I looking in a wrong place, or is it named differently? |
2010-08-26
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2010-08-26
|
07 | Adrian Farrel | [Ballot discuss] This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG … [Ballot discuss] This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG is aware of for discussion on the telechat if necessary. This I-D is Experimental. It requests IANA to allocate some code points from registries that are marked as "Standards Action or IESG Approval" Obviously, "Standards Action" does not apply to this Experimental I-D. RFC 5226 is quite wordy wrt to "IESG Approval" saying: IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis. IESG Approval is not intended to be used often or as a "common case"; indeed, it has seldom been used in practice during the period RFC 2434 was in effect. Rather, it is intended to be available in conjunction with other policies as a fall-back mechanism in the case where one of the other allowable approval mechanisms cannot be employed in a timely fashion or for some other compelling reason. IESG Approval is not intended to circumvent the public review processes implied by other policies that could have been employed for a particular assignment. IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus). The following guidelines are suggested for any evaluation under IESG Approval: - The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason to use that path. - Before approving a request, the community should be consulted, via a "call for comments" that provides as much information as is reasonably possible about the request. Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and Option values [RFC3775]. I wanted to check with the responsible AD that this I-D falls into this category. |
2010-08-26
|
07 | Adrian Farrel | [Ballot discuss] This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG … [Ballot discuss] This is a Discuss-Discuss (i.e., no action is required by the authors). It is a point I want to make sure the IESG is aware of for discussion on the telechat if necessary. This I-D is Experimental. It requests IANA to allocate some code points from registries that are marked as "Standards Action or IESG Approval" Obviously, "Standards Action" does not apply to this Experimental I-D. RFC 5226 is quite wordy wrt to "IESG Approval" saying: IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis. IESG Approval is not intended to be used often or as a "common case"; indeed, it has seldom been used in practice during the period RFC 2434 was in effect. Rather, it is intended to be available in conjunction with other policies as a fall-back mechanism in the case where one of the other allowable approval mechanisms cannot be employed in a timely fashion or for some other compelling reason. IESG Approval is not intended to circumvent the public review processes implied by other policies that could have been employed for a particular assignment. IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus). I wanted to check with the responsible AD that this I-D falls into this category. |
2010-08-26
|
07 | Russ Housley | [Ballot comment] Please consider the editorial comments in the Gen-ART Review from Spencer dawkins on 25-Aug-2010. |
2010-08-26
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-08-26
|
07 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel |
2010-08-25
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2010-08-25
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-08-24
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
2010-08-23
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2010-08-16
|
07 | Amanda Baber | IANA understands that, upon approval of this document, there are two actions that it needs to complete. First, in the Mobility Options subregistry of the … IANA understands that, upon approval of this document, there are two actions that it needs to complete. First, in the Mobility Options subregistry of the Mobile IPv6 parameters registry located at http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml a single value is to be added. Value Description Reference -------- -------------------------------------- --------------- TBD Transient Binding Second, in the Status Codes subregistry of the Mobile IPv6 parameters registry at http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml a single value is to be added. Value Description Reference -------- -------------------------------------- --------------- TBD PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH IANA understands that these are the only actions that need to be completed upon approval of the document. |
2010-08-16
|
07 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2010-08-16
|
07 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2010-08-09
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2010-08-09
|
07 | Jari Arkko | Placed on agenda for telechat - 2010-08-26 by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | Last Call was requested by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2010-08-09
|
07 | Jari Arkko | Ballot has been issued by Jari Arkko |
2010-08-09
|
07 | Jari Arkko | Created "Approve" ballot |
2010-08-09
|
07 | (System) | Ballot writeup text was added |
2010-08-09
|
07 | (System) | Last call text was added |
2010-08-09
|
07 | (System) | Ballot approval text was added |
2010-08-09
|
07 | Jari Arkko | I talked to Marco at the IETF and we came up with a way forward. The new text is in the I-D that is in … I talked to Marco at the IETF and we came up with a way forward. The new text is in the I-D that is in the directories, here are the changes: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mipshop-transient-bce-pmipv6-06.txt This satisfies, in principle, my earlier complaints. I would ask though the following text to be changed: OLD: Where no support from the link layer exists and no such indication can be provided to the nMAG by the network, the host and the network may need to inform each other about the intended movement. The method by which this is accomplished is outside the scope of this specification. NEW: Where no support from the link layer exists and no such indication can be provided to the nMAG by the network, the nMAG MUST assume that the host is incapable of this mode of operation, and employ standard behaviour as specified in RFC 5213. In other words, provide a new attachment rather than move an existing attachment to a new point or interface. I have asked for IETF last call to be initiated. |
2010-07-26
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-07-26
|
06 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-06.txt |
2010-04-26
|
07 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Jari Arkko |
2010-04-26
|
07 | Jari Arkko | I think the host issue requires at least a document change (if not something more drastic) |
2010-04-21
|
07 | Jari Arkko | State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Jari Arkko |
2010-04-21
|
07 | Jari Arkko | Still waiting on authors/WG to discuss the host modification issue. |
2010-01-26
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-01-26
|
05 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-05.txt |
2009-12-15
|
(System) | Posted related IPR disclosure: NEC Europe Ltd.'s Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-04 | |
2009-12-08
|
07 | Jari Arkko | I have reviewed this draft. The draft is generally well written and easy to read. With the exception of two major issues and a number … I have reviewed this draft. The draft is generally well written and easy to read. With the exception of two major issues and a number of smaller issues its in very good shape. I need to hear your explanation first for the two major issues before I can say anything about how we should move forward. Hopefully the fix, if needed, is small. Please respond to the issues below and revise the document accordingly. Technical: *Host effect*: I failed to understand what the effect to hosts is, and what is expected from the host implementation when two interfaces are active at the same time. Or do you assume this can happen? Are the requirements the same as those in RFC 5213 or do they go beyond it? For instance, presumably the host could be switching interface 1 to interface 2 in an atomic fashion, but some packets could still be in flight from the first MAG to the LMA, so the ability to accept those packets is important. But it would be a very different situation if you assumed the host should be able to keep alive two different interfaces, using the same IP address on both, and be able to accept traffic to them and/or send traffic to the right outgoing interface. Please explain this to me first and then we can see if the document needs changes because of this. *Corner cases*: The specification needs to include a description of what happens in cases where you move on from the nMAG to a (n+1)MAG while in the transient states. There may be other corner cases as well; the loss of PBUs is well handled already, but I'm concerned about other sequences of events that the orderly movement from one place to another. You move from A to B and while that movement is still in progress, you move back to A. And so on. *Single HNP*: > The aforementioned problem is illustrated in Figure 1, which assumes > that the HNP will be assigned under control of the LMA. Please go through the specification and ensure that it does not assume there's a single HNP -- RFC 5213 assumes a set. *Inconsistency*: > 4.6.2. Activation of a transient BCE > > > When the LMA receives a PBU from an MN's nMAG which has no Transient > Binding option included, the LMA should check whether the MN's BCE is > in any of the specified transient states. If the MN's BCE is not > transient, the LMA processes the PBU and updates the MN's BCE > according to the PMIPv6 protocol [RFC5213]. Isn't this in conflict with Figure 4, which allowed the LMA to decide that it wants to set up a transient BCE even if no transient option was included? *Alignment*: > The format of the Transient Binding option is as follows. Please specify alignment rules, too. *References*: > [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, > "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, > September 2007. > > [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless > Address Autoconfiguration", RFC 4862, September 2007. In my opinion, these references do not need to be normative. They form a part of the rationale and explanation of the environment, but they are not required reading for implementing this in proxy MIP nodes. *Editorial*: > In order to eliminate the risk of lost packets, this > document specifies an extension to PMIPv6 that utilizes a new > mobility option in the Proxy Binding Update (PBU) and the Proxy > Binding Acknowledgement (PBA) between nMAG and LMA. You need to expand references to nMAG and LMA on first use. Please go over the other abbreviations from the document as well. > > The aforementioned problem is illustrated in Figure 1, which assumes > that the HNP will be assigned under control of the LMA. > I don't think HNP term has appeared before in the document. > the > forwarding entry of the pMAG is removed from the MN's BCE, the > Transient-L state is left and the BCE state changes to active. Maybe ".... MN's BCE, the BCE state changes to active." > nMAG enters the MN's data, such as the assigned HNP, into its BUL and BUL term has not appeared before > experienced by MNs, which have multiple network interfaces MN term has not appeared before > AAA messages. This document specifies advanced binding cache control AAA term has not appeared before > the PBA, such as the MN's HNP and the link local address to be used HNP term has not appeared before > Thus it is not possible that due to the loss of > signaling or due to a failure of the nMAG to initiate turning a > transient BCE into an active BCE the transient state may not get > terminated, i.e. stable operation of the PMIPv6 protocol [RFC5213] > has reliably recovered. Lengthy sentence. Please see if you can make it clearer. > TIMEOUT_1 expires. . After TIMEOUT_1 seconds, the protocol Two dots. Jari |
2009-12-08
|
07 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2009-10-30
|
07 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2009-10-08
|
07 | Cindy Morgan | Document shepherd writeup revised to address IPR disclosure #973 (https://datatracker.ietf.org/ipr/973/), which may apply to this document. ------------------------------------------------------------------- (1.a) Who is the Document … Document shepherd writeup revised to address IPR disclosure #973 (https://datatracker.ietf.org/ipr/973/), which may apply to this document. ------------------------------------------------------------------- (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? Vijay Devarapalli is the Document Shepherd for this document. I have reviewed the document and it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had adequate reviews from the members in the MIPSHOP WG. I have no concerns about the depth or breadth of the reviews that have been performed. (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? None. (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. There was extensive discussions on whether the problem can be met with just implementation techniques on the LMA. But that issue has been addressed. Appendix B describes the limitations of such implementation techniques. IPR disclosure #973 (https://datatracker.ietf.org/ipr/973/) may apply to this draft since some of the content in draft-liebsch-netlmm-intertech-proxymip6ho-01 has been adopted in draft-ietf-mipshop-transient-bce-pmipv6. I have aksed the NEC folks to update their disclosure if their IPR is also applicable to draft-ietf-mipshop-transient-bce-pmipv6. (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 WG consensus in advancing this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.) No. (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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. No ID nits were found. The document meets all the requirements. (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]. The document splits the references into normative and informative references. There are no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations 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 the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section exists and is consistent with the body of the document. The document requests reservations in the appropriate IANA registries. The IANA registries that need to be modified/created are clearly identified. (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? Does not apply. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies a mechanism which enhances Proxy Mobile IPv6 to support the creation of a transient binding cache entry during a handover. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. It ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? None. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? There are no known implementations or vendor plans to implement the specification. However a mechanism similar to this is already used in 3GPP when PMIPv6 is use for handovers between two different access technologies. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Vijay Devarapalli Responsible AD: Jari Arkko |
2009-10-01
|
07 | Cindy Morgan | [Note]: 'Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd' added by Cindy Morgan |
2009-10-01
|
07 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (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? Vijay Devarapalli is the Document Shepherd for this document. I have reviewed the document and it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has had adequate reviews from the members in the MIPSHOP WG. I have no concerns about the depth or breadth of the reviews that have been performed. (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? None. (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. There was extensive discussions on whether the problem can be met with just implementation techniques on the LMA. But that issue has been addressed. Appendix B describes the limitations of such implementation techniques. No other concerns. (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 WG consensus in advancing this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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.) No. (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? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. No ID nits were found. The document meets all the requirements. (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]. The document splits the references into normative and informative references. There are no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations 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 the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section exists and is consistent with the body of the document. The document requests reservations in the appropriate IANA registries. The IANA registries that need to be modified/created are clearly identified. (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? Does not apply. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies a mechanism which enhances Proxy Mobile IPv6 to support the creation of a transient binding cache entry during a handover. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. It ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? None. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? There are no known implementations or vendor plans to implement the specification. However a mechanism similar to this is already used in 3GPP when PMIPv6 is use for handovers between two different access technologies. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Vijay Devarapalli Responsible AD: Jari Arkko |
2009-10-01
|
07 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2009-09-21
|
04 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-04.txt |
2009-06-08
|
03 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-03.txt |
2009-03-09
|
02 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-02.txt |
2009-02-11
|
01 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-01.txt |
2008-10-27
|
00 | (System) | New version available: draft-ietf-mipshop-transient-bce-pmipv6-00.txt |