Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction
draft-ietf-dime-mip6-integrated-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2009-01-23
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-01-22
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-01-22
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-01-21
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-01-13
|
12 | (System) | IANA Action state changed to In Progress |
2009-01-12
|
12 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2009-01-12
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-01-12
|
12 | Amy Vezza | IESG has approved the document |
2009-01-12
|
12 | Amy Vezza | Closed "Approve" ballot |
2009-01-12
|
12 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2009-01-09
|
12 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-01-09
|
12 | (System) | New version available: draft-ietf-dime-mip6-integrated-12.txt |
2008-11-26
|
12 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2008-11-26
|
12 | Pasi Eronen | [Ballot discuss] (updated discuss on 2008-11-26) I have reviewed draft-ietf-dime-mip6-integrated-11, and I have a major concern about the document: Whenever we need to add … [Ballot discuss] (updated discuss on 2008-11-26) I have reviewed draft-ietf-dime-mip6-integrated-11, and I have a major concern about the document: Whenever we need to add couple of new attributes to existing AAA messages, we have basically three choices: (1) define one solution, with attributes in the 0-255 range, or (2) define two very similar solutions (one in the 0-255 range, another in the >255 range) and a translation between them, and occasionally (3) define one solution with attributes in the >255 range. (The third approach is realistic only when the functionality is not needed on the RADIUS side, and clearly does not apply to this situation.) In the second approach, the Diameter-only solution (in the >255 range) has some advantages: it can use nice Diameter features (such as grouped AVPs), so it's somewhat "cleaner" and more elegant. Its disadvantage is that defining two solutions plus the translation functionality is more *complexity* and *work* than just a single solution. It also requires updating the RADIUS/Diameter translation agents. In this particular case, this draft has taken approach #2, but it seems the main reason has been organizational: there have been two WGs (DIME and MEXT) working on this, and the WG that got to IESG evaluation first (DIME) chose the local optimum that made their draft slightly simpler (but the overall solution more complex). Interestingly enough, the other WG chose approach #1 -- so if MEXT had finished their draft first, this draft wouldn't be needed at all. I want to repeat the last point, since it's quite important: if the MEXT WG document (with a RADIUS+Diameter solution -- it's not RADIUS-only, despite the file name) would already be in IESG evaluation stage, it's IMHO highly unlikely that we would publish draft-ietf-dime-mip6-integrated. So far, it seems the only plausible reason for publishing this document is that 3GPP needs it soon, and we're in a hurry. Is this really a good enough reason? --- Other, more minor comments: If there are multiple MIP6-Agent-Info AVPs, there's no way to find out which home agent a MIP6-Home-Link-Prefix belongs to. Should the MIP6-Home-Link-Prefix AVP be inside the MIP6-Agent-Info group? Is MIP6-Home-Link-Prefix applicable to request messages? If it is, what are the semantics? The concept of "realm of a home agent" isn't defined anywhere (since realm in this AVP is a Diameter concept); should the text say it's the Diameter realm of the Diameter entity (NAS/LAAA/VAAA/HAAA) that added the AVP? |
2008-11-26
|
12 | Pasi Eronen | [Ballot discuss] (updated discuss on 2008-11-26) I have reviewed draft-ietf-dime-mip6-integrated-11, and I have a major concern about the document: Whenever we need to add … [Ballot discuss] (updated discuss on 2008-11-26) I have reviewed draft-ietf-dime-mip6-integrated-11, and I have a major concern about the document: Whenever we need to add couple of new attributes to existing AAA messages, we have basically three choices: (1) define one solution, with attributes in the 0-255 range, or (2) define two very similar solutions (one in the 0-255 range, another in the >255 range) and a translation between them, and occasionally (3) define one solution with attributes in the >255 range. (The third approach is realistic only when the functionality is not needed on the RADIUS side, and clearly does not apply to this situation.) In the second approach, the Diameter-only solution (in the >255 range) has some advantages: it can use nice Diameter features (such as grouped AVPs), so it's somewhat "cleaner" and more elegant. Its disadvantage is that defining two solutions plus the translation functionality is more *complexity* and *work* than just a single solution. It also requires updating the RADIUS/Diameter translation agents. In this particular case, this draft has taken approach #2, but it seems the main reason has been organizational: there have been two WGs (DIME and MEXT) working on this, and the WG that got to IESG evaluation first (DIME) chose the local optimum that made their draft slightly simpler (but the overall solution more complex). Interestingly enough, the other WG chose approach #1 -- so if MEXT had finished their draft first, this draft wouldn't be needed at all. I *strongly* suggest reconsidering this approach. The current DIME WG approach means extra complexity and work that needs to be justified by better arguments than "we're the Diameter WG, so we don't care about RADIUS". --- Other, more minor comments: If there are multiple MIP6-Agent-Info AVPs, there's no way to find out which home agent a MIP6-Home-Link-Prefix belongs to. Should the MIP6-Home-Link-Prefix AVP be inside the MIP6-Agent-Info group? Is MIP6-Home-Link-Prefix applicable to request messages? If it is, what are the semantics? The concept of "realm of a home agent" isn't defined anywhere (since realm in this AVP is a Diameter concept); should the text say it's the Diameter realm of the Diameter entity (NAS/LAAA/VAAA/HAAA) that added the AVP? |
2008-11-25
|
12 | Pasi Eronen | [Ballot comment] |
2008-11-24
|
12 | Jari Arkko | [Ballot discuss] In addition, the AVP specification(s) need to be clear that it is delivering *Mobile IPv6* home agent information. (The name of the AVP … [Ballot discuss] In addition, the AVP specification(s) need to be clear that it is delivering *Mobile IPv6* home agent information. (The name of the AVP is somewhat misleading, but I don't mind that as long as the section describing the AVP is clear about this). This does not appear to be clear for the reuse of the RFC4004 attribute, which was specified for MIP4. |
2008-11-24
|
12 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from No Objection by Jari Arkko |
2008-11-24
|
12 | Jari Arkko | [Ballot comment] The small detail that I complained about in my Discuss has been fixed. However, I still support Pasi in his Discuss. From an … [Ballot comment] The small detail that I complained about in my Discuss has been fixed. However, I still support Pasi in his Discuss. From an initial look it was not clear how it was addressed in the new version. |
2008-11-24
|
12 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2008-11-19
|
12 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-11-19
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-11-19
|
11 | (System) | New version available: draft-ietf-dime-mip6-integrated-11.txt |
2008-11-03
|
12 | Dan Romascanu | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Dan Romascanu |
2008-10-30
|
12 | Pasi Eronen | [Ballot comment] Overall: the RFC Editor nowadays strongly recommends using symbolic references (e.g. [RFC2119] instead of [2]) to improve readability. |
2008-10-30
|
12 | Pasi Eronen | [Ballot discuss] (updated discuss on 2008-10-30) I have reviewed draft-ietf-dime-mip6-integrated-10, and I have a major concern about the document: The relationship of this document … [Ballot discuss] (updated discuss on 2008-10-30) I have reviewed draft-ietf-dime-mip6-integrated-10, and I have a major concern about the document: The relationship of this document and draft-ietf-mip6-radius is very unclear. In particular, the latter document defines RADIUS attributes for the same purpose as this document (same contents and semantics), and those attributes can be used in Diameter as-is (and the mip6 document says so). If this is indeed the case, why is this document needed at all? (Having two different AVP/attribute numbers with exactly same contents and semantics doesn't seem like a good idea.) More detailed comments (mostly places that require some small clarification): MIP6-Feature-Vector: uses same name as mip6-radius document, but with different number/contents. The document needs to be clearer about its scope: while it can bootstrap the home agent address, and home link prefix, it doesn't create the security association. The syntax allows arbitrary large number of MIP6-Agent-Info and MIP6-Home-Link-Prefix AVPs in both request and response messages, but doesn't say much about the semantics of having more than 1 AVP (how exactly the AAA server and/or NAS and/or intermediaries process them). Semantics of MIP6-Home-Link-Prefix in request messages is not described? Section 4.2.1: the ABNF shows that either 0, 1, or 2 MIP-Home-Agent-Address AVPs can be present; but the text doesn't seem to describe the case of 2 AVPs? The document seems to support sending the IPv4 address of the DSMIPv6 HA; is there also need to send the IPv4 home address? The document (unlike RFC 4004) doesn't seem to describe any concrete use for the Destination-Realm part of the MIP-Home-Agent-Host AVP? (i.e. would anyone notice if this AVP was empty or junk?) Section 4.2.2: typo "contains IPv6 or IPv6 address" Section 4.2.4 should say that the bits outside the prefix-length MUST be zero. Section 4.2.5 "No HA allowed -> no mobility" is a quite inaccurate description: the MN can be allowed to use HA, and can do mobility, but needs to obtain the HA address (and other information) via some other means than this spec. Section 4.2.5, it seems the NAS can't actually tell the difference between the last three combinations? (Or can it?) Section 5: it would be useful to have an example that also included the MIP6-Home-Link-Prefix AVP to clarify how exactly it works. Figures 3 and 4 show a prefix length in MIP-Home-Agent-Address AVP, but it seems it doesn't contain a prefix length? Section 7.2: "Specification Required" implies the use of a Designated Expert; RFC 5226 says "the required documentation and review criteria for use by the Designated Expert should be provided when defining the registry". |
2008-10-24
|
12 | (System) | Removed from agenda for telechat - 2008-10-23 |
2008-10-23
|
12 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2008-10-23
|
12 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-10-23
|
12 | Chris Newman | [Ballot comment] I support the other ADs discuss positions. |
2008-10-23
|
12 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-10-23
|
12 | Jari Arkko | [Ballot discuss] This is a good spec and I will vote Yes as soon as the following small issue is corrected: The MIP-Home-Agent-Address AVP … [Ballot discuss] This is a good spec and I will vote Yes as soon as the following small issue is corrected: The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address and contains IPv6 or IPv6 address of the HA. Presumably IPv4 or IPv6 was meant here? In any case, the spec needs to be clear that both IPv4 or IPv6 address or both for the home agent can be delivered. In addition, the AVP specification(s) need to be clear that it is delivering *Mobile IPv6* home agent information. (The name of the AVP is somewhat misleading, but I don't mind that as long as the section describing the AVP is clear about this). |
2008-10-23
|
12 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-dime-mip6-integrated-10, and I have a major concern about the document: The relationship of this document and draft-ietf-mip6-radius is very … [Ballot discuss] I have reviewed draft-ietf-dime-mip6-integrated-10, and I have a major concern about the document: The relationship of this document and draft-ietf-mip6-radius is very unclear. In particular, the latter document defines RADIUS attributes for the same purpose as this document (same contents and semantics), and those attributes can be used in Diameter as-is (and the mip6 document says so). If this is indeed the case, why is this document needed at all? (Having two different AVP/attribute numbers with exactly same contents and semantics doesn't seem like a good idea.) (I have also other, more detailed comments about the document text, but those seem rather moot until this question is resolved.) |
2008-10-23
|
12 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-10-23
|
12 | Jari Arkko | [Ballot discuss] This is a good spec and I will vote Yes as soon as the following small issues are corrected: The MIP-Home-Agent-Address AVP … [Ballot discuss] This is a good spec and I will vote Yes as soon as the following small issues are corrected: The MIP-Home-Agent-Address AVP (AVP Code 334 [4]) is of type Address and contains IPv6 or IPv6 address of the HA. Presumably IPv4 or IPv6 was meant here? In any case, the spec needs to be clear that both IPv4 or IPv6 address or both for the home agent can be delivered. In addition, the AVP specification(s) need to be clear that it is delivering *Mobile IPv6* home agent information. (The name of the AVP is somewhat misleading, but I don't mind that as long as the section describing the AVP is clear about this). |
2008-10-23
|
12 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2008-10-23
|
12 | Magnus Westerlund | [Ballot discuss] 4.2.1. MIP6-Agent-Info The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and contains necessary information to assign a HA to … [Ballot discuss] 4.2.1. MIP6-Agent-Info The MIP6-Agent-Info AVP (AVP code TBD) is type of Grouped and contains necessary information to assign a HA to the MN. When the MIP6-Agent-Info AVP is present in a message, it MUST contain either the MIP-Home-Agent-Address AVP or the MIP-Home-Agent-Host AVP, or both AVPs. The grouped AVP has the following grammar: ::= < AVP Header: TBD > *2[ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host ] * [ AVP ] In the above text there is formal notation that defines allowed behavior. However, there are no reference to the definition of this formal notation. Please add that reference so that is clear what rules do apply. |
2008-10-23
|
12 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-10-22
|
12 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-10-22
|
12 | Tim Polk | [Ballot comment] In email Sept. 9, Jouni indicated his intention to add the following text to the security considerations, but it does not appear in … [Ballot comment] In email Sept. 9, Jouni indicated his intention to add the following text to the security considerations, but it does not appear in the current RFC Editor note. The Diameter messages may be transported between the HA and the Diameter server via one or more AAA brokers or Diameter agents. In this case the HA to the Diameter server AAA communication rely on the security properties of the intermediate AAA brokers and Diameter agents (such as proxies). |
2008-10-22
|
12 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-10-22
|
12 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2008-10-22
|
12 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-10-21
|
12 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-10-19
|
12 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-10-05
|
12 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
2008-10-05
|
12 | Dan Romascanu | Ballot has been issued by Dan Romascanu |
2008-10-05
|
12 | Dan Romascanu | Created "Approve" ballot |
2008-10-05
|
12 | Dan Romascanu | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Dan Romascanu |
2008-10-05
|
12 | Dan Romascanu | Placed on agenda for telechat - 2008-10-23 by Dan Romascanu |
2008-09-16
|
12 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Derek Atkins. |
2008-09-10
|
12 | Amanda Baber | IANA has questions: The paragraph on expert review is not clear as to the actual process to be followed. The instructions say "initiated by the … IANA has questions: The paragraph on expert review is not clear as to the actual process to be followed. The instructions say "initiated by the O&M Area Directors in consultation with the DIME working group chairs". Does this mean that IANA will only receive the request directly from the expert? Will requests be sent directly to the O&M ADs? In most cases the requests come directly to IANA and then IANA forwards the requests to the expert. Clarification is needed. Action 1 (section 7.1): [ IESG Note: Expert Review Required ] Upon approval of this document, the IANA will make the following assignments in the "AVP Codes" registry at http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml AVP Code Attribute Name Reference ------- --------------- ---------- TBD MIP6-Agent-Info [RFC-dime-mip6-integrated-09] TBD MIP6-Feature-Vector [RFC-dime-mip6-integrated-09] TBD MIP6-Home-Link-Prefix [RFC-dime-mip6-integrated-09] Action 2 (section 7.2): [ IESG Note: Expert Assignment Required ] Upon approval of this document, the IANA will create the following registry at http://www.iana.org/assignments/TBD Registry Name: Mobility Capability Allocation rule: Only numeric values that are 2^x (power of two) are allowed based on the allocation policy described below. Following the policies outlined in [RFC 3775] new values with a description of their semantic for usage with the MIP6-Feature-Vector AVP together with a Token will be assigned after Expert Review initiated by the O&M Area Directors in consultation with the DIME working group chairs or the working group chairs of a designated successor working group. Updates can be provided based on expert approval only. A designated expert will be appointed by the O&M Area Directors. No mechanism to mark entries as "deprecated" is envisioned. Based on expert approval it is possible to delete entries from the registry. Initial contents of this registry will be: Token Value Reference ---------------------------------- ---------------------- ------------ MIP6_INTEGRATED 0x0000000000000001 [RFC-dime-mip6-integrated-09] LOCAL_HOME_AGENT_ASSIGNMENT 0x0000000000000002 [RFC-dime-mip6-integrated-09] Available for Assignment via IANA 2^x [RFC-dime-mip6-integrated-09] We understand the above to be the only IANA Actions for this document. |
2008-09-10
|
12 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-09-05
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2008-09-05
|
12 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2008-09-05
|
10 | (System) | New version available: draft-ietf-dime-mip6-integrated-10.txt |
2008-08-27
|
12 | Amy Vezza | Last call sent |
2008-08-27
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-08-27
|
12 | Dan Romascanu | State Changes to Last Call Requested from Publication Requested by Dan Romascanu |
2008-08-27
|
12 | Dan Romascanu | Last Call was requested by Dan Romascanu |
2008-08-27
|
12 | (System) | Ballot writeup text was added |
2008-08-27
|
12 | (System) | Last call text was added |
2008-08-27
|
12 | (System) | Ballot approval text was added |
2008-07-03
|
12 | Dan Romascanu | Responsible AD has been changed to Dan Romascanu from Jari Arkko |
2008-06-26
|
12 | Amy Vezza | PROTO WRITEUP for draft-ietf-dime-mip6-integrated-09.txt ======================================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally … PROTO WRITEUP for draft-ietf-dime-mip6-integrated-09.txt ======================================================== (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? The Document Shepherd is David Frascone . The document is ready for publications and I have reviewed the document personally. (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 is part of the work done on Mobile IPv6 bootstrapping in the MIP6 working group. While the MIP6 WG developed the overall architecture and the protocol support for the front-end (namely MN towards NAS and MN to HA) this document is one of two specifications providing the necessary back-end infrastructure support. A list of the related Mobile IPv6 bootstrapping documents can be found in the draft. Without this document the MIPv6 bootstrapping solution is incomplete. A first WGLC was started on 26. August 2007, see http://www1.ietf.org/mail-archive/web/dime/current/msg01940.html The document has received reviews from DIME and MIP6 members. Two further draft versions have been submitted to reflect the review comments. The changes can be seen here: http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-06.txt http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-07.txt Due to the number of changes a second WGLC was started 3. Jan. 2008, see http://www1.ietf.org/mail-archive/web/dime/current/msg02290.html The received comments were incorporated into the document: http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-08.txt The final version reflects a contact info change and simplifications regarding the example usage (only Diameter EAP usage is shown; Diameter NASREQ usage has been removed): http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-dime-mip6-integrated-09.txt (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? There are no concerns with the document. (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. (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 consensus behind 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. The document does not contain nits. (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 references split 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? An IANA consideration section exists and is consistent with the rest of the document. The document defines 3 new AVPs and one registry, called "Mobility Capability" that is used for storing flag values. (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 ABNF for the Diameter commands has been checked. (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. Document Announcement Write-Up for "Diameter Mobile IPv6: Support for Network Access Server to Diameter" (draft-ietf-dime-mip6-integrated-09) Technical Summary A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. Working Group Summary There is consensus in the WG to publish this document. Document Quality The document has received extensive reviews from DIME and MIP6 working group members. This document is a building block in the Mobile IPv6 bootstrapping architecture. Personnel David Frascone is the document shepherd for this document. |
2008-06-26
|
12 | Amy Vezza | Draft Added by Amy Vezza in state Publication Requested |
2008-05-26
|
09 | (System) | New version available: draft-ietf-dime-mip6-integrated-09.txt |
2008-02-14
|
08 | (System) | New version available: draft-ietf-dime-mip6-integrated-08.txt |
2007-11-19
|
07 | (System) | New version available: draft-ietf-dime-mip6-integrated-07.txt |
2007-11-06
|
06 | (System) | New version available: draft-ietf-dime-mip6-integrated-06.txt |
2007-07-12
|
05 | (System) | New version available: draft-ietf-dime-mip6-integrated-05.txt |
2007-05-31
|
04 | (System) | New version available: draft-ietf-dime-mip6-integrated-04.txt |
2007-02-13
|
03 | (System) | New version available: draft-ietf-dime-mip6-integrated-03.txt |
2007-01-23
|
02 | (System) | New version available: draft-ietf-dime-mip6-integrated-02.txt |
2006-10-25
|
01 | (System) | New version available: draft-ietf-dime-mip6-integrated-01.txt |
2006-06-20
|
00 | (System) | New version available: draft-ietf-dime-mip6-integrated-00.txt |