Distributed Mobility Anchoring
draft-ietf-dmm-distributed-mobility-anchoring-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-08-28
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-08-14
|
15 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-04-10
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-03-18
|
15 | (System) | RFC Editor state changed to EDIT |
2020-03-18
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-03-18
|
15 | (System) | Announcement was received by RFC Editor |
2020-03-18
|
15 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2020-03-18
|
15 | (System) | IANA Action state changed to In Progress |
2020-03-18
|
15 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-03-18
|
15 | Amy Vezza | IESG has approved the document |
2020-03-18
|
15 | Amy Vezza | Closed "Approve" ballot |
2020-03-18
|
15 | Amy Vezza | Ballot approval text was generated |
2020-03-18
|
15 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-03-17
|
15 | Benjamin Kaduk | [Ballot comment] Thanks for addressing my Discuss and Comment points! I think the current placement of the references to RFCs 8221 and 8247 make it … [Ballot comment] Thanks for addressing my Discuss and Comment points! I think the current placement of the references to RFCs 8221 and 8247 make it sound like they are references for IPsec and IKEv2 respectively, and not "just" the best-practices for configuring them. Moving the references later in the sentences would probably help, though I'd recommend adding another sentence "The current guidance for IPsec and IKEv2 usage is given in [RFC8221] and [RFC8247], respectively" to be fully clear about why they are being referenced. |
2020-03-17
|
15 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-03-07
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-03-07
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-03-07
|
15 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-15.txt |
2020-03-07
|
15 | (System) | New version approved |
2020-03-07
|
15 | (System) | Request for posting confirmation emailed to previous authors: Seil Jeon , Xinpeng Wei , Anthony Chan , Carlos Bernardos , Jong-Hyouk Lee |
2020-03-07
|
15 | Carlos Jesús Bernardos | Uploaded new revision |
2020-03-05
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-03-05
|
14 | Cindy Morgan | Changed consensus to Yes from Unknown |
2020-03-04
|
14 | Roman Danyliw | [Ballot comment] I support Ben Kaduk’s DISCUSS point. Section 5. To provide symmetry with the IPSec recommendation, s/IKEv2 should/IKEv2 SHOULD/ |
2020-03-04
|
14 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-03-04
|
14 | Barry Leiba | |
2020-03-04
|
14 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-03-04
|
14 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-03-04
|
14 | Benjamin Kaduk | [Ballot discuss] Thanks for discussing the need to secure the various control-plane interactions as part of the Security Considerations. In addition to the integrity and … [Ballot discuss] Thanks for discussing the need to secure the various control-plane interactions as part of the Security Considerations. In addition to the integrity and source-authentication properties already mentioned, we need to say that the control-plane functionality will apply authorization checks to any commands or updates that are made by the control-plane protocol. Similarly, I didn't see any discussion of authorization for applying or making changes to the "rules" that are mentioned as needing to be applied by a data-plane node (as mentioned in the COMMENT where I ask for clarification on the nature of such rules). Also, we should reference RFCs 8221 and 8247 for the current guidance on IPsec and IKEv2 usage. |
2020-03-04
|
14 | Benjamin Kaduk | [Ballot comment] While I see the value in having this document to crystallize thinking about the various mobility anchoring techniques that are possible, it's not … [Ballot comment] While I see the value in having this document to crystallize thinking about the various mobility anchoring techniques that are possible, it's not clear to me how much archival value this document would add to the RFC series in the absence of specific protocol mechanisms to implement the functionality described therein. As such, I expect to change my ballot position to Abstain after my Discuss points are resolved. Section 1 When the MN wants to continue using its assigned prefix to complete ongoing data sessions after it has moved to a new network, the network needs to provide support for the MN's IP address -- and The new network, right? Section 2 Anchoring (of an IP prefix/address): An IP prefix, i.e., Home Network Prefix (HNP), or address, i.e., HoA, assigned for use by an MN is topologically anchored to an anchor node when the anchor node is able to advertise a connected route into the routing Is "connected route" a term of art I should be looking up? and manages the network location information of an MN. The location information may be a binding of the advertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of the MN or of a node that can forward packets destined to the MN. I assume this ("may be [...] or") is not intended to be an exhaustive list? In a client-server protocol model, location query and update messages may be exchanged between a Location Management client (LMc) and a Location Management server (LMs), where the location information can be updated to or queried from the LMc. nit: s/updated to/updated from/? Do we want to discuss the authentication/authorization for such location management functions here? (Including both MN/LMc and LMc/LMs interactions.) Section 4 There may be multiple IP prefixes/addresses that an MN can select when initiating a flow. They may be from the same access network or different access networks. The network may advertise these prefixes with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node may choose the one with the least cost. In addition, these IP This draft has not been updated since 2016. Is it still expected to progress, such that a reference to it remains valuable? prefixes/addresses may be of different types regarding whether mobility support is needed [RFC8653]. A MN will need to choose which IP prefix/address to use for each flow according to whether it needs IP mobility support or not, using for example the mechanisms described in [RFC8653]. I'm confused. "these prefixes/addresses" seems to refer to the ones advertised by the network, but the question of whether mobility support is needed seems like a matter local to the MN and not a need of the network. (Perhaps the network might *provide* different mobility services for different prefixes/addresses, but that's not what this text currently says.) Section 4.1 I suggest to expand access router or list it in the terminology section. When IP session continuity is needed, even if a flow is ongoing as the MN moves, it may still be desirable for the flow to change to using the new IP prefix configured in the new network. The flow may then close and then restart using a new IP address configured in the new network. Such a change in the IP address of the flow may be It's perhaps a little confusing, in a rhetorical sense, to talk about "the flow changing to use the new prefix" but doing that by having the flow "close and then restart" -- is it really the same flow after it has closed? Note that in this scenarios, if there is no mobility support provided by L4 or above, an application might be able to stop before changing point of attachement, and therefore the traffic would stop. I'm not sure what "might be able to stop" is intended to mean. Regardless, it's quite clear that the traffic will stop upon the mobility event in this scenario, since the network does not provide continuity services! Section 4.2 prefix. The latter enables optimized routes but requires some data plane node that enforces rules for traffic indirection. Next, we I'm not sure I understand the role this rule-enforcment is meant to play. What sort of rules would it be enforcing? to AR1 per default routing). The LM and FM functions are implemented as shown in Figure 6. Where is FM indicated in Figure 6? I cannot find it. Also, should there be any control-plane anchoring indicated in Figure 6? Section 4.3 We focus next on the case where the mobility anchor (data plane function) is changed but binds the MN's transferred IP address/ prefix. This enables optimized routes but requires some data plane node that enforces rules for traffic indirection. [same question as above about the rules] IP mobility is invoked to enable IP session continuity for an ongoing flow as the MN moves to a new network. Here the anchoring of the IP address of the flow is in the home network of the flow (i.e., different from the current network of attachment). A centralized nit(?): this usage of "here" is surprising, in that it seems to discuss the same case as the previous section, and not the new mechanism that we're describing in this section. The IP prefix/address anchoring may move without changing the IP prefix/address of the flow. Here the LM and FM functions in Figure 1 in Section 3.1 are implemented as shown in Figure 7. Where is the FM function indicated in Figure 7? I cannot find it. [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor the anchor injects the mobile's prefix into the global routing system. If the mobile moves to a new anchor, the old anchor nit: "mobile node" or just "MN" (twice)? withdraws the /64 and the new anchor injects it instead. What kind of synchronization and/or serialization is needed between the withdrawl and injection of the /64 in question? Section 5 As stated in [RFC7333], "a DMM solution MUST supportany security nit: s/supportany/support any/ |
2020-03-04
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-03-04
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-03-03
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-03-03
|
14 | Warren Kumari | [Ballot comment] I am balloting NoObj, but I had a hard time deciding between this and DISCUSS (I went with NoObj because I'm submitting this … [Ballot comment] I am balloting NoObj, but I had a hard time deciding between this and DISCUSS (I went with NoObj because I'm submitting this late) - Qin Wu submitted an OpsDir review with a number of open questions, as well as some very easy to address comments / suggestions. It looks like this were either ignored, or missed (or, perhaps I missed the discussion) I strongly encourage the authors and AD to review and address these comments. |
2020-03-03
|
14 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2020-03-03
|
14 | Warren Kumari | [Ballot comment] I am balloting NoObj, but I had a hard time deciding between this and DISCUSS - Qin Wu submitted an OpsDir review with … [Ballot comment] I am balloting NoObj, but I had a hard time deciding between this and DISCUSS - Qin Wu submitted an OpsDir review with a number of open questions, as well as some very easy to address comments / suggestions. It looks like this were either ignored, or missed (or, perhaps I missed the discussion). I strongly encourage the authors and AD to review and address these comments. |
2020-03-03
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-03-03
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-03-02
|
14 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from … [Ballot comment] Thank you for the work put into this document. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. Please also address the review done by Carlos for the Internet Directorate (see: https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobility-anchoring-14-intdir-telechat-pignataro-2020-02-28/ ) Thank you Carlos for this review. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 4 -- Can you better define what is a "dynamic IP address" ? In the last paragraph, is there any reason why draft-ietf-intarea-provisioning-domains is not mentioned as yet another means to select an IP address for new connections ? -- Section 4.1 -- Please expand AR at first use -- Section 4.3 -- To be honest, relocating the DP anchor is sending a bad feeling under my skin... Scalability will be a major concerned as mentioned in your document: "such a solution may present some scalability concerns" |
2020-03-02
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-02-28
|
14 | Carlos Pignataro | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Pignataro. Sent review to list. |
2020-02-27
|
14 | Mirja Kühlewind | [Ballot comment] While I think the content of this document is fine and I'm sure it was valuable to has this written down as basis … [Ballot comment] While I think the content of this document is fine and I'm sure it was valuable to has this written down as basis for potentially on-going working group discussion, I don't see a value in publishing this document in a (separate) RFC. Further I don't see a milestone covering this document in the dmm charter. There is a bullet point on "Distributed mobility management deployment models and scenarios" however that does not mean that this has to be documented in potentially multiple RFCs. There is also draft-ietf-dmm-deployment-models with a quite central reference in the document, however, this draft is expired for more than a year. What's the plan here? In any case, thanks for quickly addressing the TSV-ART review (and Yoshi thanks for the review!)! |
2020-02-27
|
14 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2020-02-27
|
14 | Mirja Kühlewind | [Ballot comment] While I think the content of this document is fine and I'm sure it was valuable to has this written down as basis … [Ballot comment] While I think the content of this document is fine and I'm sure it was valuable to has this written down as basis for potentially on-going working group discussion, I don't see a value in publishing this document in a (separate) RFC. Further I don't see a milestone covering this document in the dmm charter. There is a bullet point on "Distributed mobility management deployment models and scenarios" however that does not mean that this has to be documented in potentially multiple RFCs. There is also draft-ietf-dmm-deployment-models with a quite central reference in the document, however, this draft is expired for more than a year. What's the plan here? |
2020-02-27
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, Abstain, has been recorded for Mirja Kühlewind |
2020-02-22
|
14 | Joseph Salowey | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Joseph Salowey. Sent review to list. |
2020-02-20
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Joseph Salowey |
2020-02-20
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Joseph Salowey |
2020-02-19
|
14 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2020-02-19
|
14 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Carlos Pignataro |
2020-02-19
|
14 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-02-14
|
14 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-02-14
|
14 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup::External Party |
2020-02-14
|
14 | Cindy Morgan | Placed on agenda for telechat - 2020-03-05 |
2020-02-14
|
14 | Suresh Krishnan | Ballot has been issued |
2020-02-14
|
14 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2020-02-14
|
14 | Suresh Krishnan | Created "Approve" ballot |
2020-02-14
|
14 | Suresh Krishnan | Ballot writeup was changed |
2020-02-14
|
14 | Suresh Krishnan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is appropriate given the informative nature of the work. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes architectural considerations and approaches for realizing distributed mobility management systems. These techniques can are applicable to any access specific and access agnostic mobility architectures. Working Group Summary This document has been in development, first as an individual submission in the DMM WG and later as a working group document. The document has gone through around 14 revisions. Document Quality The current version of the document is well-written. Some sections of the document can be drafted in a better way, but that just reflects a specific writing style. The work was completed by the authors in the earlier versions, however the chairs were not comfortable moving the document forward due to editorial issues. The chairs had to therefore appoint an editor for rewriting the document and had to put through WG reviews. We believe the quality of this document is good. Personnel Dapeng(Max) Liu is the document shepherd. Suresh Krishnan is the current responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I read the document, understood the content and have also discussed with the authors. I believe this version of the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document addresses an important topic related to IP Mobility architectures. The DMM WG has the expertise in this area, and we therefore believe the reviews from the WG are sufficient. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. We do not have any concerns forwarding this document to IESG for reviews. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There was one IPR disclosure related to this document. https://datatracker.ietf.org/ipr/3030/ WG is aware of these disclosures, but no one in the WG has expressed any concerns. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is rough consensus behind this document and no objections have been raised. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no issues reported by the tool. All the reported issues have been addressed in the prior versions. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not require IANA Actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new registries defined. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language. |
2020-02-14
|
14 | Suresh Krishnan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. This is appropriate given the informative nature of the work. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes architectural considerations and approaches for realizing distributed mobility management systems. These techniques can are applicable to any access specific and access agnostic mobility architectures. Working Group Summary This document has been in development, first as an individual submission in the DMM WG and later as a working group document. The document has gone through around 14 revisions. Document Quality The current version of the document is well-written. Some sections of the document can be drafted in a better way, but that just reflects a specific writing style. The work was completed by the authors in the earlier versions, however the chairs were not comfortable moving the document forward due to editorial issues. The chairs had to therefore appoint an editor for rewriting the document and had to put through WG reviews. We believe the quality of this document is good. Personnel Dapeng(Max) Liu is the document shepherd. Suresh Krishnan is the current responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I read the document, understood the content and have also discussed with the authors. I believe this version of the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The document addresses an important topic related to IP Mobility architectures. The DMM WG has the expertise in this area, and we therefore believe the reviews from the WG are sufficient. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. We do not have any concerns forwarding this document to IESG for reviews. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There was one IPR disclosure related to this document. https://datatracker.ietf.org/ipr/3030/ WG is aware of these disclosures, but no one in the WG has expressed any concerns. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is rough consensus behind this document and no objections have been raised. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no issues reported by the tool. All the reported issues have been addressed in the prior versions. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not require IANA Actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new registries defined. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is no YANG module |
2019-11-01
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-11-01
|
14 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-14.txt |
2019-11-01
|
14 | (System) | New version approved |
2019-11-01
|
14 | (System) | Request for posting confirmation emailed to previous authors: Anthony Chan , Carlos Bernardos , Xinpeng Wei , Jong-Hyouk Lee , Seil Jeon |
2019-11-01
|
14 | Carlos Jesús Bernardos | Uploaded new revision |
2019-10-25
|
13 | Suresh Krishnan | Expecting an updated shepherd writeup. |
2019-10-25
|
13 | Suresh Krishnan | IESG state changed to Waiting for Writeup::External Party from Waiting for Writeup |
2019-10-18
|
13 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Qin Wu was marked no-response |
2019-10-14
|
13 | Yoshifumi Nishida | Request for Last Call review by TSVART Completed: Almost Ready. Reviewer: Yoshifumi Nishida. Sent review to list. |
2019-10-14
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-10-13
|
13 | Joseph Salowey | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Joseph Salowey. Sent review to list. |
2019-10-12
|
13 | Paul Kyzivat | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Paul Kyzivat. |
2019-10-09
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-10-09
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dmm-distributed-mobility-anchoring-13, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-dmm-distributed-mobility-anchoring-13, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-10-04
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2019-10-04
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2019-10-03
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2019-10-03
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Joseph Salowey |
2019-10-02
|
13 | Qin Wu | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Qin Wu. Sent review to list. |
2019-10-01
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2019-10-01
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2019-10-01
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2019-10-01
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Qin Wu |
2019-10-01
|
13 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Yoshifumi Nishida |
2019-10-01
|
13 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Yoshifumi Nishida |
2019-09-30
|
13 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-09-30
|
13 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-10-14): From: The IESG To: IETF-Announce CC: Dapeng Liu , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, maxpassion@gmail.com, dmm-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2019-10-14): From: The IESG To: IETF-Announce CC: Dapeng Liu , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, maxpassion@gmail.com, dmm-chairs@ietf.org, dmm@ietf.org, suresh@kaloom.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Distributed Mobility Anchoring) to Informational RFC The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'Distributed Mobility Anchoring' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-14. 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 distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support according to the needs of mobility support. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or re-started using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3030/ |
2019-09-30
|
13 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-09-30
|
13 | Amy Vezza | Last call announcement was generated |
2019-09-30
|
13 | Amy Vezza | Last call announcement was changed |
2019-09-29
|
13 | Suresh Krishnan | Last call was requested |
2019-09-29
|
13 | Suresh Krishnan | Ballot approval text was generated |
2019-09-29
|
13 | Suresh Krishnan | Ballot writeup was generated |
2019-09-29
|
13 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2019-09-29
|
13 | Suresh Krishnan | Last call announcement was generated |
2019-06-12
|
13 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2019-04-19
|
13 | Sri Gundavelli | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 1) The type of RFC being requested is informational. 2) This document describes the deployment model of distributed mobility anchoring, it does not specify solutions; It only introduces various options to deploy mobility anchoring function in distributed ways; So this document is intended to be in informational in nature. 3) The type of RFC is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. Working Group Summary This document has been reviewed and agreed by the working group. Document Quality This document describes the ways to distributed deploy mobility anchoring functions, the mobility function itself could be implemented by existing IP mobility solutions such as PMIP etc. And there are several demos of those kind of implementations. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Dapeng(Max) Liu Responsible Area Director: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This version of the document is much simplified compared with old version. It more focus on how to deploy mobility anchoring function in a distributed way. It was reviewed and agreed by the working group and ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure references to this document: https://datatracker.ietf.org/ipr/3030/ Working group discussion and conclusion: WG is aware of this disclosure, but there has been no discussion. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has reached consensus in the working group and there is no objection to move forward. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Idnits has been checked, issues found has been solved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not specify IANA registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language. |
2019-04-19
|
13 | Sri Gundavelli | Responsible AD changed to Suresh Krishnan |
2019-04-19
|
13 | Sri Gundavelli | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-04-19
|
13 | Sri Gundavelli | IESG state changed to Publication Requested from I-D Exists |
2019-04-19
|
13 | Sri Gundavelli | IESG process started in state Publication Requested |
2019-04-19
|
13 | Sri Gundavelli | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-04-19
|
13 | Sri Gundavelli | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? 1) The type of RFC being requested is informational. 2) This document describes the deployment model of distributed mobility anchoring, it does not specify solutions; It only introduces various options to deploy mobility anchoring function in distributed ways; So this document is intended to be in informational in nature. 3) The type of RFC is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. Working Group Summary This document has been reviewed and agreed by the working group. Document Quality This document describes the ways to distributed deploy mobility anchoring functions, the mobility function itself could be implemented by existing IP mobility solutions such as PMIP etc. And there are several demos of those kind of implementations. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Dapeng(Max) Liu Responsible Area Director: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This version of the document is much simplified compared with old version. It more focus on how to deploy mobility anchoring function in a distributed way. It was reviewed and agreed by the working group and ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been reviewed by experts that active in DMM working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure references to this document: https://datatracker.ietf.org/ipr/3030/ Working group discussion and conclusion: WG is aware of this disclosure, but there has been no discussion. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has reached consensus in the working group and there is no objection to move forward. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Idnits has been checked, issues found has been solved. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not specify IANA registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document does not use formal language. |
2019-03-26
|
13 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-13.txt |
2019-03-26
|
13 | (System) | New version approved |
2019-03-26
|
13 | (System) | Request for posting confirmation emailed to previous authors: Anthony Chan , Carlos Bernardos , Xinpeng Wei , Jong-Hyouk Lee , Seil Jeon |
2019-03-26
|
13 | Carlos Jesús Bernardos | Uploaded new revision |
2019-03-12
|
12 | Dapeng Liu | Notification list changed to Dapeng Liu <maxpassion@gmail.com> |
2019-03-12
|
12 | Dapeng Liu | Document shepherd changed to Dapeng Liu |
2019-01-29
|
12 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-12.txt |
2019-01-29
|
12 | (System) | New version approved |
2019-01-29
|
12 | (System) | Request for posting confirmation emailed to previous authors: Anthony Chan , Carlos Bernardos , Xinpeng Wei , Jong-Hyouk Lee , Seil Jeon |
2019-01-29
|
12 | Carlos Jesús Bernardos | Uploaded new revision |
2018-08-29
|
11 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-11.txt |
2018-08-29
|
11 | (System) | New version approved |
2018-08-29
|
11 | (System) | Request for posting confirmation emailed to previous authors: Anthony Chan , Carlos Bernardos , Xinpeng Wei , Jong-Hyouk Lee , Seil Jeon |
2018-08-29
|
11 | Carlos Jesús Bernardos | Uploaded new revision |
2018-07-02
|
10 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-10.txt |
2018-07-02
|
10 | (System) | New version approved |
2018-07-02
|
10 | (System) | Request for posting confirmation emailed to previous authors: Anthony Chan , Carlos Bernardos , Xinpeng Wei , Jong-Hyouk Lee , Seil Jeon |
2018-07-02
|
10 | Carlos Jesús Bernardos | Uploaded new revision |
2018-07-02
|
09 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-09.txt |
2018-07-02
|
09 | (System) | New version approved |
2018-07-02
|
09 | (System) | Request for posting confirmation emailed to previous authors: Anthony Chan , Carlos Bernardos , Xinpeng Wei , Jong-Hyouk Lee , Seil Jeon |
2018-07-02
|
09 | Carlos Jesús Bernardos | Uploaded new revision |
2018-03-02
|
08 | Carlos Jesús Bernardos | New version available: draft-ietf-dmm-distributed-mobility-anchoring-08.txt |
2018-03-02
|
08 | (System) | New version approved |
2018-03-02
|
08 | (System) | Request for posting confirmation emailed to previous authors: Jong-Hyouk Lee , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Jong-Hyouk Lee , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Xinpeng Wei |
2018-03-02
|
08 | Carlos Jesús Bernardos | Uploaded new revision |
2017-11-12
|
07 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-07.txt |
2017-11-12
|
07 | (System) | New version approved |
2017-11-12
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jong-Hyouk Lee , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Jong-Hyouk Lee , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Xinpeng Wei |
2017-11-12
|
07 | Anthony Chan | Uploaded new revision |
2017-07-26
|
Jasmine Magallanes | Posted related IPR disclosure: InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-dmm-distributed-mobility-anchoring | |
2017-07-03
|
06 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-06.txt |
2017-07-03
|
06 | (System) | New version approved |
2017-07-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Jong-Hyouk Lee |
2017-07-03
|
06 | Anthony Chan | Uploaded new revision |
2017-07-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Jong-Hyouk Lee |
2017-07-03
|
06 | Anthony Chan | Uploaded new revision |
2017-07-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Jong-Hyouk Lee |
2017-07-03
|
06 | Anthony Chan | Uploaded new revision |
2017-05-09
|
05 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-05.txt |
2017-05-09
|
05 | (System) | New version approved |
2017-05-09
|
05 | (System) | Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Jong-Hyouk Lee |
2017-05-09
|
05 | Anthony Chan | Uploaded new revision |
2017-04-11
|
04 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-04.txt |
2017-04-11
|
04 | (System) | New version approved |
2017-04-11
|
04 | (System) | Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , … Request for posting confirmation emailed to previous authors: Xinpeng Wei , Seil Jeon , Alexandre Petrescu , dmm-chairs@ietf.org, Anthony Chan , Fred Templin , Jong-Hyouk Lee |
2017-04-11
|
04 | Anthony Chan | Uploaded new revision |
2016-12-15
|
03 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-03.txt |
2016-12-15
|
03 | (System) | New version approved |
2016-12-15
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Anthony Chan" , "Fred Templin" , "Seil Jeon" , "Jong-Hyouk Lee" , dmm-chairs@ietf.org, "Xinpeng Wei" , … Request for posting confirmation emailed to previous authors: "Anthony Chan" , "Fred Templin" , "Seil Jeon" , "Jong-Hyouk Lee" , dmm-chairs@ietf.org, "Xinpeng Wei" , "Alexandre Petrescu" |
2016-12-15
|
03 | Anthony Chan | Uploaded new revision |
2016-11-13
|
02 | Jouni Korhonen | The WGLC #1 ends 12/4/2016. |
2016-11-13
|
02 | Jouni Korhonen | Tag Other - see Comment Log set. |
2016-11-13
|
02 | Jouni Korhonen | IETF WG state changed to In WG Last Call from WG Document |
2016-09-24
|
02 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-02.txt |
2016-09-24
|
02 | Anthony Chan | New version approved |
2016-09-24
|
02 | Anthony Chan | Request for posting confirmation emailed to previous authors: "Anthony Chan" , "Fred Templin" , "Seil Jeon" , "Jong-Hyouk Lee" , dmm-chairs@ietf.org, "Xinpeng Wei" , … Request for posting confirmation emailed to previous authors: "Anthony Chan" , "Fred Templin" , "Seil Jeon" , "Jong-Hyouk Lee" , dmm-chairs@ietf.org, "Xinpeng Wei" , "Alexandre Petrescu" |
2016-09-23
|
02 | (System) | Uploaded new revision |
2016-09-08
|
01 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-01.txt |
2016-08-30
|
00 | Jouni Korhonen | This document now replaces draft-chan-dmm-distributed-mobility-anchoring instead of None |
2016-08-30
|
00 | Jouni Korhonen | Intended Status changed to Informational from None |
2016-08-30
|
00 | Anthony Chan | New version available: draft-ietf-dmm-distributed-mobility-anchoring-00.txt |