Bulk Binding Update Support for Proxy Mobile IPv6
draft-ietf-netext-bulk-re-registration-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-04-13
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-04-13
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2012-04-13
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2012-03-01
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-02-22
|
12 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2012-02-22
|
12 | (System) | IANA Action state changed to In Progress |
2012-02-21
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2012-02-21
|
12 | Amy Vezza | IESG has approved the document |
2012-02-21
|
12 | Amy Vezza | Closed "Approve" ballot |
2012-02-21
|
12 | Amy Vezza | Approval announcement text regenerated |
2012-02-21
|
12 | Amy Vezza | Ballot writeup text changed |
2012-02-21
|
12 | Jari Arkko | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed. I think we've exhausted the discussion the authors had … State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed. I think we've exhausted the discussion the authors had with Pete. There's a new version, any remaining issues can be dealt with in AUTH48. |
2012-02-14
|
12 | (System) | New version available: draft-ietf-netext-bulk-re-registration-12.txt |
2012-02-13
|
11 | (System) | New version available: draft-ietf-netext-bulk-re-registration-11.txt |
2012-02-13
|
12 | Jari Arkko | Made an RFC Editor note and responded to IANA's concern. This should be clear now, but waiting for IANA to respond. I also asked Sri … Made an RFC Editor note and responded to IANA's concern. This should be clear now, but waiting for IANA to respond. I also asked Sri if he wants to revise per Pete Resnick's comments. I will also wait for that answer, as well as the possible draft update, before approving the document for good. |
2012-02-13
|
12 | Jari Arkko | Ballot writeup text changed |
2012-01-19
|
12 | Cindy Morgan | Removed from agenda for telechat |
2012-01-19
|
12 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead. |
2012-01-19
|
12 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
12 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
12 | Pete Resnick | [Ballot comment] There are several uses of 2119 language in section 5 and 6 that are inappropriate: 5.1: I have no idea why "The following … [Ballot comment] There are several uses of 2119 language in section 5 and 6 that are inappropriate: 5.1: I have no idea why "The following considerations MUST be applied by the mobile access gateway when supporting this specification" is at all useful. The entire sentence should be deleted. 5.1.1: This is worded oddly. It's not that the data structure "MUST be extended", it's that the new fields MUST be included. I think what you probably mean is, "The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to include the following REQUIRED additional fields." Of course I assume that they are now "required for interoperation" [2119] or that not having them "has potential for causing harm". [2119] If not, then there shouldn't be 2119 language at all. 5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the following considerations" adds. The requirements are in the paragraphs below. If you don't want to strike the sentence, sufficient would be, "The following are considerations for the mobile access gateway for requesting bulk binding update support for a mobility session." I think the "MAY" in the first bullet should be "can". In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise, what you're saying is "You MUST do everything in section 6.9.1 that says MUST", which seems silly and redundant. 5.1.3: In the first and second bullet, s/MAY/can Also, the last sentence of the first and second bullets have the same problem as the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps instead, say something like "The requirement of section 5.3.3 of [RFC5213] is amended to allow a Mobile Node Group Identifier in place of the individual session identifiers." In the third bullet, the MUST seems useless. How could the gateway not "consider the request as a bulk revocation request"? 5.2: Similar to 5.1. 5.2.1: First sentence similar to 5.1.1. 5.2.2: First sentence similar to 5.1.2. But I would simply move the first bullet up into that first sentence so it says: 5.2.2. Enabling Bulk Binding Update Support for a Mobility Session The local mobility anchor will process a received Proxy Binding Update message as specified in [RFC5213]. However if the (B) flag in the received Proxy Binding Update message is set to a value of (1) and if it includes a Mobile Node Group Identifier option with sub-type value of (1) (bulk binding update group), the following processing takes place: In sections 6.1 and 6.2, I am concerned about the statements containing "MUST allow the following variables to be configured by the system management" since that seems to go against 2119 where it says that the terms "must not be used to try to impose a particular method on implementors where the method is not required for interoperability." Is there an interoperability reason that these variables MUST be configurable? Also, the SHOULD and MUSTs in the definition of the variables doesn't seem right. These are not protocol requirements; they are descriptions of the meaning of the variables. |
2012-01-18
|
12 | Pete Resnick | [Ballot comment] There are several uses of 2119 language in section 5 that are inappropriate: 5.1: I have no idea why "The following considerations MUST … [Ballot comment] There are several uses of 2119 language in section 5 that are inappropriate: 5.1: I have no idea why "The following considerations MUST be applied by the mobile access gateway when supporting this specification" is at all useful. The entire sentence should be deleted. 5.1.1: This is worded oddly. It's not that the data structure "MUST be extended", it's that the new fields MUST be included. I think what you probably mean is, "The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to include the following REQUIRED additional fields." Of course I assume that they are now "required for interoperation" [2119] or that not having them "has potential for causing harm". [2119] If not, then there shouldn't be 2119 language at all. 5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the following considerations" adds. The requirements are in the paragraphs below. If you don't want to strike the sentence, sufficient would be, "The following are considerations for the mobile access gateway for requesting bulk binding update support for a mobility session." I think the "MAY" in the first bullet should be "can". In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise, what you're saying is "You MUST do everything in section 6.9.1 that says MUST", which seems silly and redundant. 5.1.3: In the first and second bullet, s/MAY/can Also, the last sentence of the first and second bullets have the same problem as the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps instead, say something like "The requirement of section 5.3.3 of [RFC5213] is amended to allow a Mobile Node Group Identifier in place of the individual session identifiers." |
2012-01-18
|
12 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
12 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
12 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
12 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
12 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
12 | Amanda Baber | QUESTION: What is the range of possible values for the new registry? Should any values be marked "Reserved" (i.e. unavailable for assignment)? Upon approval of … QUESTION: What is the range of possible values for the new registry? Should any values be marked "Reserved" (i.e. unavailable for assignment)? Upon approval of this document, IANA will complete the following actions: ACTION 1: IANA will register the following Binding Update Flag at http://www.iana.org/assignments/mobility-parameters B TBD [RFC-to-be] ACTION 2: IANA will register the following Binding Acknowledgment Flag at http://www.iana.org/assignments/mobility-parameters B TBD [RFC-to-be] ACTION 3: IANA will register the following Mobility Option at http://www.iana.org/assignments/mobility-parameters TBD Mobile Node Group Identifier [RFC-to-be] ACTION 4: IANA will create the following registry at http://www.iana.org/assignments/mobility-parameters Registry Name: Mobile Node Group Identifier Type Registry Registration Procedure: Expert Review Reference: [RFC-to-be] Value Description Reference ----- ----------- --------- 0? ? 1 Bulk Binding Update Group [RFC-to-be] 2-? ? ACTION 5: IANA will register the following Status Code at http://www.iana.org/assignments/mobility-parameters TBD (>128) INVALID_MOBILE_NODE_GROUP_IDENTIFIER [RFC-to-be] |
2012-01-17
|
12 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
12 | Robert Sparks | [Ballot comment] Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request … [Ballot comment] Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request is rejected. One place to do this is 5.2.3 bullet 4, where you could say "for any reason (including administrative)" instead of "for any administrative reason". |
2012-01-17
|
12 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
12 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
12 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
12 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2012-01-16
|
12 | Christer Holmberg | Request for Last Call review by GENART Completed. Reviewer: Christer Holmberg. |
2012-01-16
|
12 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-10
|
10 | (System) | New version available: draft-ietf-netext-bulk-re-registration-10.txt |
2012-01-10
|
12 | Jari Arkko | Placed on agenda for telechat - 2012-01-19 |
2012-01-06
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2012-01-06
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2012-01-05
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2012-01-05
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2012-01-03
|
12 | Amy Vezza | Last call sent |
2012-01-03
|
12 | 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: (Bulk Binding Update 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: - 'Bulk Binding Update Support for Proxy Mobile IPv6' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-17. 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 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-bulk-re-registration/ No IPR declarations have been submitted directly on this I-D. |
2012-01-03
|
12 | Jari Arkko | Last Call was requested |
2012-01-03
|
12 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2012-01-03
|
12 | Jari Arkko | Last Call text changed |
2012-01-03
|
12 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2012-01-03
|
12 | Jari Arkko | Ballot has been issued |
2012-01-03
|
12 | Jari Arkko | Created "Approve" ballot |
2012-01-03
|
12 | (System) | Ballot writeup text was added |
2012-01-03
|
12 | (System) | Last call text was added |
2012-01-03
|
12 | (System) | Ballot approval text was added |
2012-01-03
|
12 | Jari Arkko | Sri: Thanks for the update! I have reviewed the changes and they look good to me with one exception (below). I have in any case … Sri: Thanks for the update! I have reviewed the changes and they look good to me with one exception (below). I have in any case requested an IETF Last Call to be initiated and expect that you fix the remaining issues by issuing yet another draft quickly. But the changes are pretty big -- it would also be useful if members of the WG reviewed the document while it is in the Last Call. > o When sending the Mobile Node Group Identifier option in the > binding update messages related to the individual session > establishment, the Bulk-Binding-Update (B) flag in the request > MUST be set to a value of (1). However, when initiating any > binding update operations with group specific scope, the Bulk- > Binding-Update (B) flag in the request MUST always be set to a > value of (0), with the Mobile Node Group Identifier option present > in the request. There is something wrong with the above text. B must be set in the session establishment, but not with "binding update operations with group specific scope"? (And what are those?) Jari |
2012-01-02
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2012-01-02
|
09 | (System) | New version available: draft-ietf-netext-bulk-re-registration-09.txt |
2012-01-02
|
12 | Jari Arkko | Sent a reminder to the authors. Waiting on them. |
2011-11-22
|
12 | Jari Arkko | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. |
2011-11-22
|
12 | Jari Arkko | I have reviewed this draft. The draft is almost ready to move forward. Please make a quick revision based on the comments below: > For … I have reviewed this draft. The draft is almost ready to move forward. Please make a quick revision based on the comments below: > For an hypothetical scenario, with 500,000 mobility sessions and with > binding lifetime of 30 minutes, it results in: 500,000 / 1,800 sec = > 277 transactions/sec > > For the above hypothetical scenario, based on the computation, it is > apparent that the base Proxy Mobile IPv6 re-registration process > where the mobile access gateway sends a unique binding refresh > message for each mobility session is inefficient or sub-optimal. > These re-registration messages consume significant amount of network > resources, both in terms of processing power and in terms of network > bandwidth at both the peers. Therefore it is the intent of this > specification to optimize the signaling procedures. These > optimizations allow the local mobility anchor and the mobile access > gateway to perform bulk binding update and revocation operations. This seems a little bit overselling the idea. A 500,000 node gateway will also have some traffic, e.g., if one node out of 100 is doing a 50 packets per second (a voip call), then the entire box does 250,000 packets per second. The network traffic impact part of the signaling is not that big. Anyway, this is just a comment and not critical in anyway to progressing the draft. But I would add a sentence that the actual impacts depend on capacity required to deal with other issues, such as worst-case movement signalling or payload traffic load. > The mobile access gateway can also assign a local group identifier > for the mobility session and include that in the initial request. > This group identifier may be different from the group identifier that > the local mobility assigns. Subsequently, both the peers can perform > bulk operations on those groups. > The mobile > access gateway MAY also choose to request the group identifier > based on its own grouping consideration, by sending the Mobile > Node Group Identifier option with the proposed group identifier. > Upon receiving the Proxy Binding Acknowledgment message with > status code value set to (0) (Proxy Binding Update accepted), the > bulk binding update flag (B) in the reply is set to a value of (1) > and if there is a mobile node group identifier option present, the > message serves as a hint that the local mobility anchor has > enabled bulk binding update support for the mobility session and > that the mobile access gateway MAY use the group identifier when > requesting binding update or binding revocation operation with > group specific scope. The group identifier value in Binding > Update List entry MUST also be updated to include the assigned > group identifier. > o For enabling the bulk binding update support for the mobility > session, the local mobility anchor MAY choose to associate the > mobility session to a specific group. The specific details on how > the local mobility anchor associates the given mobility session to > a specific bulk binding update group is outside the scope of this > document. The local mobility anchor MAY choose to assign a > default group identifier value of (255), indicating that all the > mobility sessions from that mobile access gateway are part of that > group. If there is a request from the mobile access gateway to > assign a specific group identifier, the local mobility anchor may > choose to honor that request. The assigned group identifier field > in the Binding Cache entry is updated with the identifier of the > group to which the mobility session is associated. The first quoted paragraph seems to claim that both sides can group devices per their own desires. This does not seem to be supported by the rest of the specification, as the LMA will override whatever suggestion was made by the MAG. This may be fine, but I would change the first paragraph as follows: OLD: The mobile access gateway can also assign a local group identifier for the mobility session and include that in the initial request. This group identifier may be different from the group identifier that the local mobility assigns. Subsequently, both the peers can perform bulk operations on those groups. NEW: The mobile access gateway can also suggest a local group identifier for the mobility session and include that in the initial request. This group identifier may be different from the group identifier that the local mobility anchor assigns. Subsequently, both the peers can perform bulk operations on the group identifier confirmed by the local mobility anchor. > the > bulk binding update flag (B) in the reply is set to a value of (1) > and if there is a mobile node group identifier option present, the > message serves as a hint that the local mobility anchor has > enabled bulk binding update support for the mobility session and > that the mobile access gateway MAY use the group identifier when > requesting binding update or binding revocation operation with > group specific scope. AFAICT, this is not a "hint" -- it is a fact. Whether you use it for something is up to you, but the LMA *has* enabled the support. Or am I missing something? Suggested edit: s/serves as hint/informs the receiver/ > o If the (B) flag in the received Proxy Binding Update message is > set to a value of (1) and if the Mobile Node Group Identifier > option is not present in the request, the message serves as a > request to the local mobility anchor to include the mobile node's > session to the bulk binding update group. ... to *the* bulk binding update group. I think you mean "... to *a* bulk binding update group." In This case there is ID specified, so the LMA has to find a suitable group based on its own preferences. Similarly, in the next paragraph I would change: OLD: o If the (B) flag in the received Proxy Binding Update message is set to a value of (1) and if the Mobile Node Group Identifier option is present in the request, the message serves as a request to the local mobility anchor to include the mobile node's session to the bulk binding update group, with the proposed group identifier present in the Mobile Node Group Identifier option. NEW: o If the (B) flag in the received Proxy Binding Update message is set to a value of (1) and if the Mobile Node Group Identifier option is present in the request, the message serves as a request to the local mobility anchor to include the mobile node's session to a bulk binding update group, with the proposed group identifier present in the Mobile Node Group Identifier option. > Mobile Node Group Identifier A 32-bit field containing the mobile > node's group identifier. The group identifier value of (255) is > reserved for the group, all the mobility sessions for a given > mobile access gateway hosted on a given local mobility anchor, > this is a preassigned group. Some strange wording. I would also suggest that the value 255 needs to be discussed in the IANA considerations. Also, the value zero seems to be used: > The value of the group > identifier in the Binding Cache entry must be set to the value of > (0). Please talk about this in the IANA considerations, too. Perhaps you could leave values 1-254 as Reserved for IETF, and then values 256-(2^32-1) as freely usable by implementations. Or something... the current situation is confusing because I don't know how to generate group IDs that do not collide with the ones needed for some special purpose. E.g, on some implementation I might want to use line card ID as the group ID. But then I have to worry about 0. Missing things: 1) You should specify what to do if the LMA returns a group identifier and sets the B bit without the MAG requesting it to do so. The right action is to ignore this, I think, but you should specify it. 2) You should specify what to do if client MIP operations set the B bit. Some kind of error should be returned, or the flag and option ignored, I think. 3) I think you should add "Updates: RFC 5213, 5846" to the header of the draft. You are changing the procedures for identifying nodes. Jari |
2011-11-22
|
12 | Jari Arkko | State changed to AD Evaluation from Publication Requested. |
2011-10-20
|
12 | Cindy Morgan | (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 … (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? I (Basavaraj Patil) will be the document shepherd for this I-D. I have reviewed the I-D and believe it is ready to be forwarded 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? The document has been reviewed sufficiently by key WG members. I have no concerns regarding the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns with the current set of reviews and do not believe any further broader reviews are needed. Reviews by the various directorates during the IETF last call process will anyway help. The I-D does not have any XML code or internationalization aspects and hence does not need reviews from experts in that quarter. (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 are no concerns or issues with this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is sufficient WG consensus behind this document. It has been discussed within the working group for over 2 years now. The norm has been that a few WG members are active while most are passive. The active WG members understand and agree with this I-D. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. There have been no threats of appeals or otherwise w.r.t this I-D. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. I have run the I-D through the ID nits tool and no issues exist. (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]. Yes, the document has split the references into normative and informative ones. All references are to published RFCs. There are no pending dependencies. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document contains an IANA considerations section with clear instructions of the actions required by IANA. The specification does not require a new registry but uses the existing registry and adds new attributes to that registry. (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? The document does not contain any XML code or BNF rules. It does not contain any MIB definitions either. (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 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility agent on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope using of a group identifier. Working Group Summary There is WG consensus regarding this proposal. The I-D has been presented and discussed at several WG meetings. It has also been sufficiently reviewed and the document quality improved over multiple revisions. Document Quality There are no known implementations of this protocol at the present time. WG members who helped with the reviews have been acknowledged in the I-D. The document quality is good and can serve as the basis for an implementation. Clear guidelines for processing by the Mobile Access Gateway and the Local Mobility Agent have been specified. |
2011-10-20
|
12 | Cindy Morgan | Draft added in state Publication Requested |
2011-10-20
|
12 | Cindy Morgan | [Note]: 'Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.' added |
2011-10-20
|
12 | Basavaraj Patil | Changed protocol writeup |
2011-10-20
|
12 | Basavaraj Patil | Document submitted to IESG. |
2011-10-20
|
12 | Basavaraj Patil | Annotation tag Doc Shepherd Follow-up Underway cleared. |
2011-10-20
|
12 | Basavaraj Patil | Hello, The Netext working group I-D: "Bulk Re-registration Support for Proxy Mobile IPv6", has completed working group last call and is ready to be progressed. … Hello, The Netext working group I-D: "Bulk Re-registration Support for Proxy Mobile IPv6", has completed working group last call and is ready to be progressed. Please consider this as a request for review and approval for publication this I-D by the IESG. The I-D is to be progressed on standards track. -Basavaraj (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? I (Basavaraj Patil) will be the document shepherd for this I-D. I have reviewed the I-D and believe it is ready to be forwarded 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? The document has been reviewed sufficiently by key WG members. I have no concerns regarding the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I have no concerns with the current set of reviews and do not believe any further broader reviews are needed. Reviews by the various directorates during the IETF last call process will anyway help. The I-D does not have any XML code or internationalization aspects and hence does not need reviews from experts in that quarter. (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 are no concerns or issues with this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is sufficient WG consensus behind this document. It has been discussed within the working group for over 2 years now. The norm has been that a few WG members are active while most are passive. The active WG members understand and agree with this I-D. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. There have been no threats of appeals or otherwise w.r.t this I-D. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. I have run the I-D through the ID nits tool and no issues exist. (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]. Yes, the document has split the references into normative and informative ones. All references are to published RFCs. There are no pending dependencies. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document contains an IANA considerations section with clear instructions of the actions required by IANA. The specification does not require a new registry but uses the existing registry and adds new attributes to that registry. (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? The document does not contain any XML code or BNF rules. It does not contain any MIB definitions either. (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 For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility agent on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines an optimization to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope using of a group identifier. Working Group Summary There is WG consensus regarding this proposal. The I-D has been presented and discussed at several WG meetings. It has also been sufficiently reviewed and the document quality improved over multiple revisions. Document Quality There are no known implementations of this protocol at the present time. WG members who helped with the reviews have been acknowledged in the I-D. The document quality is good and can serve as the basis for an implementation. Clear guidelines for processing by the Mobile Access Gateway and the Local Mobility Agent have been specified. |
2011-10-20
|
12 | Basavaraj Patil | IETF state changed to Submitted to IESG for Publication from Adopted by a WG |
2011-10-20
|
08 | (System) | New version available: draft-ietf-netext-bulk-re-registration-08.txt |
2011-10-18
|
12 | Basavaraj Patil | IETF state changed to Adopted by a WG from In WG Last Call |
2011-10-18
|
12 | Basavaraj Patil | WG last call has been completed. Proto writeup in progress. |
2011-10-18
|
12 | Basavaraj Patil | Annotation tag Doc Shepherd Follow-Up Underway set. |
2011-10-17
|
07 | (System) | New version available: draft-ietf-netext-bulk-re-registration-07.txt |
2011-09-29
|
06 | (System) | New version available: draft-ietf-netext-bulk-re-registration-06.txt |
2011-09-29
|
05 | (System) | New version available: draft-ietf-netext-bulk-re-registration-05.txt |
2011-07-11
|
12 | Basavaraj Patil | WG last call issues on July 11th on Rev 4 of the I-D. |
2011-07-11
|
12 | Basavaraj Patil | IETF state changed to In WG Last Call from WG Document |
2011-07-02
|
04 | (System) | New version available: draft-ietf-netext-bulk-re-registration-04.txt |
2011-04-26
|
03 | (System) | New version available: draft-ietf-netext-bulk-re-registration-03.txt |
2010-10-25
|
02 | (System) | New version available: draft-ietf-netext-bulk-re-registration-02.txt |
2010-07-10
|
01 | (System) | New version available: draft-ietf-netext-bulk-re-registration-01.txt |
2010-01-26
|
00 | (System) | New version available: draft-ietf-netext-bulk-re-registration-00.txt |