RADIUS Support for Proxy Mobile IPv6
draft-ietf-netext-radius-pmip6-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Pete Resnick |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2012-04-10
|
08 | Brian Haberman | Responsible AD changed to Brian Haberman from Jari Arkko |
2012-02-27
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-02-27
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-02-23
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-02-13
|
08 | (System) | IANA Action state changed to In Progress |
2012-02-13
|
08 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
2012-02-10
|
08 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2012-02-10
|
08 | Cindy Morgan | IESG has approved the document |
2012-02-10
|
08 | Cindy Morgan | Closed "Approve" ballot |
2012-02-10
|
08 | Cindy Morgan | Approval announcement text regenerated |
2012-02-10
|
08 | Cindy Morgan | Ballot writeup text changed |
2012-02-10
|
08 | Jari Arkko | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2012-02-10
|
08 | Russ Housley | [Ballot discuss] The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern and several editorial suggestions. The authors and Elwyn seem to … [Ballot discuss] The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern and several editorial suggestions. The authors and Elwyn seem to agree that the following text will resolve the concern, but it is not in the document yet: When this bit is set the PMIP6_SUPPORTED flag MUST also be set, and the IP4_HOA_SUPPORTED flag MUST NOT be set. |
2012-02-10
|
08 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
2012-02-09
|
08 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss |
2012-02-03
|
08 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2012-02-01
|
08 | Stephen Farrell | [Ballot comment] |
2012-02-01
|
08 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-01-30
|
08 | (System) | New version available: draft-ietf-netext-radius-pmip6-08.txt |
2012-01-29
|
08 | Stephen Farrell | [Ballot comment] How is the right policy store/profile selected? I suspect this is covered elsewhere (probably in 5213?) but it wasn't clear to me. |
2012-01-29
|
08 | Stephen Farrell | [Ballot discuss] The security considerations section refers to 2865, 2866 and 3579 which do have pretty good security considerations. However, this spec seems to me … [Ballot discuss] The security considerations section refers to 2865, 2866 and 3579 which do have pretty good security considerations. However, this spec seems to me to introduce new things, such as sending the interface ID, which I think raises at least new privacy considerations. The ones that I think may be relevant here are the Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the PMIP6-Visited-Interface-ID, Calling-Station-Id and the Chargeable-User-Identity. Since I'm not quite sure how these are intended to be used, I'm also not sure what, if anything, needs to be said about them in security considerations, so I'd like to DISCUSS that. (No change related to this in -07) |
2012-01-25
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2012-01-25
|
07 | (System) | New version available: draft-ietf-netext-radius-pmip6-07.txt |
2012-01-19
|
08 | Elwyn Davies | Request for Last Call review by GENART Completed. Reviewer: Elwyn Davies. |
2012-01-19
|
08 | Cindy Morgan | Removed from agenda for telechat |
2012-01-19
|
08 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead. |
2012-01-19
|
08 | Jari Arkko | [Ballot discuss] Holding a discuss for Bernard Aboba's review comments. |
2012-01-19
|
08 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from Yes |
2012-01-19
|
08 | Jari Arkko | [Ballot comment] Holding a discuss for Bernard Aboba's review comments. |
2012-01-19
|
08 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-19
|
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
08 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
08 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-18
|
08 | Stephen Farrell | [Ballot comment] How is the right policy store/profile selected? I suspect this is covered elsewhere (probably in 5213?) but it wasn't clear to me. |
2012-01-18
|
08 | Stephen Farrell | [Ballot discuss] The security considerations section refers to 2865, 2866 and 3579 which do have pretty good security considerations. However, this spec seems to me … [Ballot discuss] The security considerations section refers to 2865, 2866 and 3579 which do have pretty good security considerations. However, this spec seems to me to introduce new things, such as sending the interface ID, which I think raises at least new privacy considerations. The ones that I think may be relevant here are the Mobile-Node-Identifier, PMIP6-Home-Interface-ID, the PMIP6-Visited-Interface-ID, Calling-Station-Id and the Chargeable-User-Identity. Since I'm not quite sure how these are intended to be used, I'm also not sure what, if anything, needs to be said about them in security considerations, so I'd like to DISCUSS that. |
2012-01-18
|
08 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2012-01-18
|
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2012-01-17
|
08 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
08 | Amanda Baber | Upon approval, IANA will complete the following actions: ACTION 1: IANA will register the following Radius Attribute Types at http://www.iana.org/assignments/radius-types Mobile-Node-Identifier Service-Selection PMIP6-Home-LMA-IPv6-Address PMIP6-Visited-LMA-IPv6-Address PMIP6-Home-LMA-IPv4-Address … Upon approval, IANA will complete the following actions: ACTION 1: IANA will register the following Radius Attribute Types at http://www.iana.org/assignments/radius-types Mobile-Node-Identifier Service-Selection PMIP6-Home-LMA-IPv6-Address PMIP6-Visited-LMA-IPv6-Address PMIP6-Home-LMA-IPv4-Address PMIP6-Visited-LMA-IPv4-Address PMIP6-Home-HN-Prefix PMIP6-Visited-HN-Prefix PMIP6-Home-Interface-ID PMIP6-Visited-Interface-ID PMIP6-Home-IPv4-HoA PMIP6-Visited-IPv4-HoA PMIP6-Home-DHCP4-Server-Address PMIP6-Visited-DHCP4-Server-Address PMIP6-Home-DHCP6-Server-Address PMIP6-Visited-DHCP6-Server-Address ACTION 2: IANA will register the following in the Mobility Capability Registry at http://www.iana.org/assignments/aaa-parameters IP4_TRANSPORT_SUPPORTED IP4_HOA_ONLY_SUPPORTED |
2012-01-17
|
08 | Peter Saint-Andre | [Ballot comment] I concur with the DISCUSS position lodged by Pete Resnick. |
2012-01-17
|
08 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
08 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-17
|
08 | Russ Housley | [Ballot discuss] The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern and several editorial suggestions. The authors and Elwyn seem to … [Ballot discuss] The Gen-ART Review by Elwyn Davies on 16-Jan-2012 raised one concern and several editorial suggestions. The authors and Elwyn seem to agree that the following text will resolve the concern, but it is not in the document yet: When this bit is set the PMIP6_SUPPORTED flag MUST also be set, and the IP4_HOA_SUPPORTED flag MUST NOT be set. |
2012-01-17
|
08 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
2012-01-16
|
08 | Pete Resnick | [Ballot discuss] 4.3. Service-Selection The Service-Selection attribute (Type value TBD2) is of type UTF-8 text and contains the name of the service or … [Ballot discuss] 4.3. Service-Selection The Service-Selection attribute (Type value TBD2) is of type UTF-8 text and contains the name of the service or the external network that the mobility service for the particular MN SHOULD be associated with [RFC5149]. The identifier MUST be unique within the PMIPv6 Domain. I've got a question about being "unique". My understanding is that UTF-8 text is normally used in Radius for "display to the user only" text and is not compared to other pieces of text. Here you say it "MUST be unique". How "unique" does it need to be? That is, if one identifier contains an "a" followed by a combining acute accent (U+0061 U+0301), and another identifier contains the a-with-acute-accent (U+00E1), are those "unique"? I guess the main question is: What are these things being used for and will the above make a difference? I think either way, some more information is needed in this paragraph to explain. |
2012-01-16
|
08 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to Discuss from No Objection |
2012-01-16
|
08 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-16
|
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-15
|
08 | Pete Resnick | " case is a matter of local Mills & Kucherawy Expires April 24, 2014 [Page … " case is a matter of local Mills & Kucherawy Expires April 24, 2014 [Page 8] Internet-Draft Require-Recipient-Valid-Since October 2013 policy. For example, when control of a domain name is transferred, the new domain owner might be unable to determine whether the owner of the subject address has been under continuous ownership since the stated date if the mailbox history is not also transferred (or was not previously maintained). It will also be "unknown" if whatever database contains mailbox ownership data is temporarily unavailable at the time a message arrives for delivery. In this case, typical SMTP temporary failure handling is appropriate. 10. Examples In the following examples, "C:" indicates data sent by an SMTP client, and "S:" indicates responses by the SMTP server. Message content is CRLF terminated, though these are omitted here for ease of reading. 10.1. SMTP Extension Example C: [connection established] S: 220 server.example.com ESMTP ready C: EHLO client.example.net S: 250-server.example.com S: 250 RRVS C: MAIL FROM:<sender@example.net> S: 250 OK C: RCPT TO:<receiver@example.com> RRVS=1381993177 S: 550 5.7.15 receiver@example.com is no longer valid C: QUIT S: 221 So long! 10.2. Header Field Example Mills & Kucherawy Expires April 24, 2014 [Page 9] Internet-Draft Require-Recipient-Valid-Since October 2013 C: [connection established] S: 220 server.example.com ESMTP ready C: HELO client.example.net S: 250 server.example.com C: MAIL FROM:<sender@example.net> S: 250 OK C: RCPT TO:<receiver@example.com> S: 250 OK C: DATA S: 354 Ready for message content C: From: Mister Sender <sender@example.net> To: Miss Receiver <receiver@example.com> Subject: Are you still there? Date: Fri, 28 Jun 2013 18:01:01 +0200 Require-Recipient-Valid-Since: receiver@example.com; Sat, 1 Jun 2013 09:23:01 -0700 Are you still there? . S: 550 5.7.15 receiver@example.com is no longer valid C: QUIT S: 221 So long! If an authentication scheme is applied to claim the added header field is valid, but the scheme fails, a receiver might reject the message with an SMTP reply such as: S: 550-5.7.7 Use of Require-Recipient-Valid-Since header S: 550 field requires a valid signature 11. Security Considerations 11.1. Abuse Countermeasures The response of a server implementing this protocol can disclose information about the age of existing email mailbox. Implementation of countermeasures against probing attacks is advised. For example, an operator could track appearance of this field with respect to a particular mailbox and observe the timestamps being submitted for testing; if it appears a variety of timestamps is being tried against a single mailbox in short order, the field could be ignored and the message silently discarded. This concern is discussed further in Section 12. 11.2. Suggested Use Restrictions If the mailbox named in the field is known to have had only a single continuous owner since creation, or not to have existed at all (under |
2012-01-15
|
08 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-13
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-01-13
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-01-10
|
08 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-10
|
08 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2012-01-10
|
08 | Jari Arkko | Ballot has been issued |
2012-01-10
|
08 | Jari Arkko | Created "Approve" ballot |
2012-01-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-01-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-01-05
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2012-01-05
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2012-01-04
|
08 | Amy Vezza | Last call sent |
2012-01-04
|
08 | 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: (RADIUS 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: - 'RADIUS 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-18. 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 document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netext-radius-pmip6/ No IPR declarations have been submitted directly on this I-D. |
2012-01-04
|
08 | Jari Arkko | Placed on agenda for telechat - 2012-01-19 |
2012-01-04
|
08 | Jari Arkko | Last Call was requested |
2012-01-04
|
08 | (System) | Ballot writeup text was added |
2012-01-04
|
08 | (System) | Last call text was added |
2012-01-04
|
08 | (System) | Ballot approval text was added |
2012-01-04
|
08 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::AD Followup. |
2012-01-04
|
08 | Jari Arkko | Last Call text changed |
2012-01-04
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2012-01-04
|
06 | (System) | New version available: draft-ietf-netext-radius-pmip6-06.txt |
2011-12-11
|
08 | Jari Arkko | State changed to AD Evaluation::Revised ID Needed from AD Evaluation. |
2011-12-11
|
08 | Jari Arkko | I have reviewed this specification. The draft is well written. Thanks for that. I only found a couple of minor editorial issues, and one technical … I have reviewed this specification. The draft is well written. Thanks for that. I only found a couple of minor editorial issues, and one technical issue. I would like to talk about the technical issue before we send the draft forward. Please reply to this e-mail and/or revise the draft accordingly so that I can start an IETF Last Call. Section 4.9: Shouldn't this section include some text about not including this attribute, if MIP6-Home-HN-Prefix is already present? (Like Section 4.7 had for its corresponding attribute pair.) The same problem may appear in Section 4.13 and elsewhere as well. Please check. Section 4.10 & 4.11: This is the technical issue that worries me. While RFC 5213 does say that there are cases where MN-HoA is known, this is certainly an exception rather than the rule: Mobile Node's Home Address (MN-HoA) MN-HoA is an address from a mobile node's home network prefix. The mobile node will be able to use this address as long as it is attached to the access network that is in the scope of that Proxy Mobile IPv6 domain. If the mobile node uses more than one address from its home network prefix(es), any one of these addresses is referred to as mobile node's home address. Unlike in Mobile IPv6 where the home agent is aware of the home address of the mobile node, in Proxy Mobile IPv6, the mobility entities are only aware of the mobile node's home network prefix(es) and are not always aware of the exact address(es) that the mobile node configured on its interface from its home network prefix(es). However, in some configurations and based on the enabled address configuration modes on the access link, the mobility entities in the network can be certain about the exact address(es) configured by the mobile node. Sections 4.10 and 4.11 talk about IIDs without any context on how they should be derived, used, and whether they can even exist on a given deployment. One approach to fix this would be to delete the subsections. Another one would be explain how the IID values are determined, when they can be determined, and how they should be used. Yet another approach is to point me (and the reader) to another RFC that describes this (as I could of course have missed something). > 4.18. Calling-Station-Id > > The Calling-Station-Id attribute (Type value 31) is of type String > and when used for PMIPv6 it contains the link-layer identifier of the > MN as defined in [RFC5213], Sections 2.2 and 8.6. You should refer to the RFC that originally defined Calling-Station-Id. > The User-Name attribute MUST be present in the Access-Request. It > SHOULD carry a valid MN identity unless the identity is being > suppressed for policy reasons, for example, when identity hiding is > in effect. The MN identity, if available, MUST be in Network Access > Identifier (NAI) [RFC4282] format. I think there is always an identifier that is of the valid form. It just may not reveal the identity of the user (at least not in an 1-1 and stable fashion). Consider making this change: ... MUST carry a correctly formed identifier that SHOULD correspond to a MN identity unless ... Jari |
2011-12-11
|
08 | Jari Arkko | Ballot writeup text changed |
2011-12-11
|
08 | Jari Arkko | State changed to AD Evaluation from Publication Requested. |
2011-10-18
|
08 | 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) am the document shepherd for this I-D. I have reviewed this version of the document and believe that 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 by RADIUS experts as well as a few key WG members. It has been reviewed adequately. I do not have any concerns about the depth or breadth of the reviews w.r.t this I-D. (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? The document has been reviewed by RADIUS experts. There is also some implementation experience of the specification. Hence additional reviews from a specific group or broader community is not essential. However a review by the Ops area directorate on the various RADIUS attributes being specified would be useful. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns with the document. The I-D specifies several new attributes (RADIUS) which are summarized in Sec 5.2 and the AD may want to pay attention to it. There have been no IPR disclosures related to this I-D. (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 strong WG consensus behind this document. It is essential for enabling the deployment of PMIP6 (RFC5213) protocol. The WG as a whole does understand the relevance of this I-D and agrees with it. (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. (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 throigh the tool and it has passed. (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 has split references into normative and informative ones. All normative references are RFCs. (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? Yes, the I-D does include an IANA considerations section which lists the set of attributes that need IANA action. The document does not recommend any new registry to be created. New RADIUS attributes (PMIP6 specific) are specified by this I-D and IANA assignments handled accordingly. (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? I-D does not contain any XML code, BNF rules or MIB definitions. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Technical summary: This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol specified here uses RADIUS based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches to the network, authenticates and authorizes within a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. Additionally, this document specifies the baseline for the mobile access gateway and the local mobility anchor generated accounting. Working group summary: The document has been reviewed by several RADIUS protocol experts as well as key members within the working group. It has undergone two working group last calls and has been revised based on feedback from reviewers as well as implementation experience. There is strong WG consensus behind this document. Document quality: There is at least one known implementation of the protocol. Multiple vendors have indicated plans to implement this specification. All the key people who have reviewed this I-D are acknowledged in the document. |
2011-10-18
|
08 | Cindy Morgan | Draft added in state Publication Requested |
2011-10-18
|
08 | Cindy Morgan | [Note]: 'Basavaraj Patil (Basavaraj.Patil@nokia.com) is the document shepherd.' added |
2011-10-18
|
08 | Basavaraj Patil | Changed protocol writeup |
2011-10-18
|
08 | Basavaraj Patil | IETF state changed to Submitted to IESG for Publication from In WG Last Call |
2011-10-18
|
08 | Basavaraj Patil | The I-D has been submitted to the IESG for publication. Proto writeup: The Netext WG I-D: "RADIUS Support for Proxy Mobile IPv6", has completed working … The I-D has been submitted to the IESG for publication. Proto writeup: The Netext WG I-D: "RADIUS Support for Proxy Mobile IPv6", has completed working group last call and is ready to be progressed for IESG review and approval. The I-D is a standards track document. The proto writeup for this I-D is below. -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) am the document shepherd for this I-D. I have reviewed this version of the document and believe that 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 by RADIUS experts as well as a few key WG members. It has been reviewed adequately. I do not have any concerns about the depth or breadth of the reviews w.r.t this I-D. (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? The document has been reviewed by RADIUS experts. There is also some implementation experience of the specification. Hence additional reviews from a specific group or broader community is not essential. However a review by the Ops area directorate on the various RADIUS attributes being specified would be useful. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns with the document. The I-D specifies several new attributes (RADIUS) which are summarized in Sec 5.2 and the AD may want to pay attention to it. There have been no IPR disclosures related to this I-D. (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 strong WG consensus behind this document. It is essential for enabling the deployment of PMIP6 (RFC5213) protocol. The WG as a whole does understand the relevance of this I-D and agrees with it. (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. (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 throigh the tool and it has passed. (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 has split references into normative and informative ones. All normative references are RFCs. (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? Yes, the I-D does include an IANA considerations section which lists the set of attributes that need IANA action. The document does not recommend any new registry to be created. New RADIUS attributes (PMIP6 specific) are specified by this I-D and IANA assignments handled accordingly. (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? I-D does not contain any XML code, BNF rules or MIB definitions. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Technical summary: This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol specified here uses RADIUS based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches to the network, authenticates and authorizes within a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. Additionally, this document specifies the baseline for the mobile access gateway and the local mobility anchor generated accounting. Working group summary: The document has been reviewed by several RADIUS protocol experts as well as key members within the working group. It has undergone two working group last calls and has been revised based on feedback from reviewers as well as implementation experience. There is strong WG consensus behind this document. Document quality: There is at least one known implementation of the protocol. Multiple vendors have indicated plans to implement this specification. All the key people who have reviewed this I-D are acknowledged in the document. |
2011-10-18
|
08 | Basavaraj Patil | Annotation tag Other - see Comment Log cleared. |
2011-09-23
|
05 | (System) | New version available: draft-ietf-netext-radius-pmip6-05.txt |
2011-08-17
|
04 | (System) | New version available: draft-ietf-netext-radius-pmip6-04.txt |
2011-06-28
|
08 | Basavaraj Patil | IETF state changed to In WG Last Call from Adopted by a WG |
2011-06-28
|
08 | Basavaraj Patil | June 27, 2011 This is the working group last call for the I-D: RADIUS Support for Proxy Mobile IPv6 The I-D has been updated by … June 27, 2011 This is the working group last call for the I-D: RADIUS Support for Proxy Mobile IPv6 The I-D has been updated by the authors following reviews by Avi Lior and Pete McCann. Abstract: This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. The I-D is intended for publication as a proposed standard. The deadline for receiving comments (i.e end of WG LC) is July 12th, 2011. Please send your review comments to the mailing list or authors. -Chairs |
2011-06-28
|
08 | Basavaraj Patil | Annotation tag Other - see Comment Log set. Annotation tag Awaiting External Review/Resolution of Issues Raised cleared. |
2011-06-27
|
03 | (System) | New version available: draft-ietf-netext-radius-pmip6-03.txt |
2011-06-13
|
08 | Basavaraj Patil | Reviews done by several experts. Awaiting revised version of I-D which incorporates the comments. |
2011-06-13
|
08 | Basavaraj Patil | IETF state changed to Adopted by a WG from WG Document |
2011-06-13
|
08 | Basavaraj Patil | Reviews done by several experts. Awaiting revised version of I-D which incorporates the comments. |
2011-06-13
|
08 | Basavaraj Patil | Annotation tag Awaiting External Review/Resolution of Issues Raised set. |
2011-03-14
|
02 | (System) | New version available: draft-ietf-netext-radius-pmip6-02.txt |
2010-11-15
|
01 | (System) | New version available: draft-ietf-netext-radius-pmip6-01.txt |
2010-05-24
|
00 | (System) | New version available: draft-ietf-netext-radius-pmip6-00.txt |