--- 1/draft-ietf-dmm-hnprenum-04.txt	2017-01-25 22:13:07.975867961 -0800
+++ 2/draft-ietf-dmm-hnprenum-05.txt	2017-01-25 22:13:07.995868435 -0800
@@ -1,21 +1,21 @@
 
 DMM Working Group                                                 Z. Yan
 Internet-Draft                                                     CNNIC
 Intended status: Standards Track                                  J. Lee
-Expires: July 9, 2017                               Sangmyung University
+Expires: July 29, 2017                              Sangmyung University
                                                                   X. Lee
                                                                    CNNIC
-                                                         January 5, 2017
+                                                        January 25, 2017
 
                Home Network Prefix Renumbering in PMIPv6
-                       draft-ietf-dmm-hnprenum-04
+                       draft-ietf-dmm-hnprenum-05
 
 Abstract
 
    In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
    (MN) is assigned with a Home Network Prefix (HNP) during its initial
    attachment and the MN configures its Home Address (HoA) with the HNP.
    During the movement of the MN, the HNP remains unchanged to keep
    ongoing communications associated with the HoA.  However, the current
    PMIPv6 specification does not specify related operations when an HNP
    renumbering is happened.  In this document, a solution to support the
@@ -36,21 +36,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on July 9, 2017.
+   This Internet-Draft will expire on July 29, 2017.
 
 Copyright Notice
 
    Copyright (c) 2017 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -61,21 +61,21 @@
    described in the Simplified BSD License.
 
 Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
    2.  Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . .   2
    3.  PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . .   3
    4.  Session Connectivity  . . . . . . . . . . . . . . . . . . . .   5
    5.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .   6
    6.  Other Issues  . . . . . . . . . . . . . . . . . . . . . . . .   6
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
    8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
      9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
      9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8
 
 1.  Introduction
 
    Network managers currently prefer Provider Independent (PI)
    addressing for IPv6 to attempt to minimize the need for future
@@ -266,28 +266,32 @@
    new HNP and the related DHCP procedure is also triggered by the
    reception of UPN message [RFC3315].
 
 6.  Other Issues
 
    In order to maintain the reachability of the MN, the Domain Name
    System (DNS) resource record corresponding to this MN may need to be
    updated when the HNP of MN changes [RFC3007].  However, this is
    beyond the scope of this document.
 
-   The LMA must assign only an authorized HNP for the MN.
-
 7.  Security Considerations
 
    The protection of UPN and UPA messages in this document follows
    [RFC5213] and [RFC7077].  This extension thus causes no further
    security problems for protecting of the messages.
 
+   When the HNP renumbering is triggered, a new HNP has to be allocated
+   to the MN.  The LMA must follow the proceduer of PMIPv6 to make sure
+   that only an authorized HNP can be assigned for the MN.  In this way,
+   LMA is ready to be the topological anchor point of the new HNP and
+   the new HNP is for that MN's exclusive use.
+
 8.  IANA Considerations
 
    This document presents no IANA considerations.
 
 9.  References
 
 9.1.  Normative References
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,