Skip to main content

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
[Ballot comment]
You include the BCP 14 boilerplate and references, but there are no BCP 14 key words in the document (except in a quotation …
[Ballot comment]
You include the BCP 14 boilerplate and references, but there are no BCP 14 key words in the document (except in a quotation from another document).  I suggest removing the boilerplate and the references.
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