Re: [DMM] Review of draft-ietf-dmm-hnprenum-03

"Z.W. Yan" <> Fri, 23 December 2016 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B47C129461; Thu, 22 Dec 2016 17:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ckPK2OXc_Z3h; Thu, 22 Dec 2016 17:15:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90014126BF6; Thu, 22 Dec 2016 17:15:38 -0800 (PST)
Received: from yanzhiwei (unknown []) by (Coremail) with SMTP id AQAAf0A5QZW4elxYa7VFDw--.43163S2; Fri, 23 Dec 2016 09:15:36 +0800 (CST)
Date: Fri, 23 Dec 2016 09:15:33 +0800
From: "Z.W. Yan" <>
To: "Jean-Michel Combes" <>, "" <>
References: <>
Subject: Re: [DMM] Review of draft-ietf-dmm-hnprenum-03
Message-ID: <>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon668162301745_====="
X-CM-TRANSID: AQAAf0A5QZW4elxYa7VFDw--.43163S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWryDtw4xZryxXFy7Cry7trb_yoW5Wr4DpF Z7t3WSkF1kGr48Aw4xAw4UZ347uFWftr47JryrWw18Cas8GF1ktF13Kw4Yva4DGrn3JF4U Xr429F4DJ3W5uaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU92b7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF 0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeV CFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xv F2IEb7IF0Fy26I8I3I1lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x 0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_ WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYx BIdaVFxhVjvjDU0xZFpf9x07beCztUUUUU=
X-CM-SenderInfo: x1dqqupqqluhdfq/
Archived-At: <>
Cc: "draft-ietf-dmm-hnprenum.all" <>, ietf <>, dmm <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Dec 2016 01:15:44 -0000

Hello, Jean-Michel,
Thank you so much for your comments.
We will address your comments and feedback with a new version of the draft. 

Merry Christmas, guys~  


Z.W. Yan 

发件人: Jean-Michel Combes 
发送时间: 2016-12-20  02:35:54 
抄送: draft-ietf-dmm-hnprenum.all; ietf; dmm 
主题: [DMM] Review of draft-ietf-dmm-hnprenum-03 
Reviewer: Jean-Michel Combes
Review result: Ready with Issues
First, this is the first time I am trying this new tool for reviewers,
so, sorry if I am making process mistakes.
Please find the official text below:
I am an assigned INT directorate reviewer for
draft-ietf-dmm-hnprenum-03. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with
any other Last Call comments that have been received. For more details
on the INT Directorate, see
Please, find my review below:
*** Section 1, p2 ***
"However, a widespread use of PI addresses may cause Border Gateway
Protocol (BGP) scaling problems."
Any Ref?
*** Section 7, p6 ***
"The protection of UPN and UPA messages in this document follows
[RFC5213] and [RFC7077].  This extension causes no further security
Sorry but, I must admit I don't agree:
[RFC5213] says:
"The Mobile IPv6 specification [RFC3775] requires the home agent to
prevent a mobile node from creating security associations or creating
binding cache entries for another mobile node's home address. In the
protocol described in this document, the mobile node is not involved
in creating security associations for protecting the signaling
messages or sending binding updates. Therefore, the local mobility
anchor MUST restrict the creation and manipulation of proxy bindings
to specifically authorized mobile access gateways and prefixes. The
local mobility anchor MUST be locally configurable to authorize such
specific combinations.  Additional mechanisms, such as a policy store
or Authentication, Authorization, and Accounting (AAA) may be
employed, but these are outside the scope of this specification."
Based on the fact that an operator could set up internal check-ups
about the allowed HNP(s) for the MN, there could be strong
restrictions (e.g., not allowed roaming between operators) about the
mechanism described inside this document.
So, IMHO, additional text is needed regarding this point.
Best regards,
dmm mailing list