From nobody Thu Jan 5 23:04:55 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8512946A; Thu, 5 Jan 2017 23:04:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148368629449.20702.13880281960540461085.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 23:04:54 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-hnprenum-04.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 07:04:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : Home Network Prefix Renumbering in PMIPv6 Authors : Zhiwei Yan Jong-Hyouk Lee Xiaodong Lee Filename : draft-ietf-dmm-hnprenum-04.txt Pages : 9 Date : 2017-01-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 HNP renumbering is proposed, as an update of the PMIPv6 specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-hnprenum-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 23:15:23 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52F5129C21; Thu, 5 Jan 2017 23:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUcWolv7rEMT; Thu, 5 Jan 2017 23:15:13 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6ED1128BA2; Thu, 5 Jan 2017 23:15:13 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id g1so43181849pgn.0; Thu, 05 Jan 2017 23:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LrwntxkQVkLbDxb3F0qPLcloediKbgUB3L4bOdaHxqg=; b=QSCStFrQxhv6xThozo76jHz4+7dnfcNplMXDyFXuj1zE+Ryi4iqpZbaAyYidRwMywP qYg8TOIRri+5X9L64hHbNJSHmNqsuMSjlztJabeaipVtZAYTED6VNqGBphBHlq/YsMHc pKLPCPy4j1WDOntW5ztWDxFvz7EAM5NfEztWtAnQ5e7bGi7R1IeL4z7+UequSwAPKiAd P0Bi+BJ3XV7+ZA3PWvm6ymI9d4ZigaEnPRjKhtWkFyhnCI6BOSwdQPVCm1yS1E/CY11A mVxMEb44XRrd20XLBMpGk+9i+G3yoQh0CbSJv3lRtpo9hz4XJA5N9pCScFGpea4EXKQ+ 25Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LrwntxkQVkLbDxb3F0qPLcloediKbgUB3L4bOdaHxqg=; b=RmAC5wcfqBBpBwnQZePi46vg0+Nj3bYzq4Bl7YJILZSd3AkTvnEcc6ikfOTD4sUlYu 7EGVg9q8GP1WJI2mrs+4bC3zbikXjZlnwrl3JGTtpL1ulMmTKJatPNi7C14WoiSTjqKP YRKVYj3rqUsVsJm+6DCNTTdXvf0/OPCCZXw8190fIS3zwWQpoMdCNGLJpQ9MQJyO/deU a8YBM8osare3kBewQ2NxVyIqj1+09Tmhz2HvrQcg24Y08ofyeOyhaZWqZmYo6362Hty1 GSsZ+1byEH/6q3scVc+3WykOVcq1GmrzZTaNp11rMzPNNM9lMX7LXQrAs4MmNkvH4Z3U W1hQ== X-Gm-Message-State: AIkVDXJLjvUIaMoMaXH3lgm6ChX6XNAbMFJPcWDSh2CZbgmwFGoMFRiE4XWc8W/aEWqp5Q== X-Received: by 10.84.172.67 with SMTP id m61mr161940875plb.60.1483686913351; Thu, 05 Jan 2017 23:15:13 -0800 (PST) Received: from [10.0.1.20] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id j130sm134138439pgc.2.2017.01.05.23.15.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 23:15:11 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jong-Hyouk Lee In-Reply-To: <148217252412.12729.10717391067512660347.idtracker@ietfa.amsl.com> Date: Fri, 6 Jan 2017 16:15:07 +0900 Message-Id: References: <148217252412.12729.10717391067512660347.idtracker@ietfa.amsl.com> To: Jean-Michel Combes X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-dmm-hnprenum.all@ietf.org, ietf@ietf.org, dmm@ietf.org, int-dir@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-hnprenum-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 07:15:16 -0000 --Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Jean-Michel Thanks for your kind comments. We have revised the draft and uploaded = it: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-04 = Plz see inline then. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On 20 Dec 2016, at 3:35 AM, Jean-Michel Combes = wrote: >=20 > Reviewer: Jean-Michel Combes > Review result: Ready with Issues >=20 > Hi, >=20 > First, this is the first time I am trying this new tool for reviewers, > so, sorry if I am making process mistakes. >=20 > 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 http://www.ietf.org/iesg/directorate.html. >=20 >=20 > Please, find my review below: >=20 > *** Section 1, p2 *** > "However, a widespread use of PI addresses may cause Border Gateway > Protocol (BGP) scaling problems." > Any Ref? Thx for your point. The related reference (RFC7010) from 6renum WG has = been added in the revised draft (-04). >=20 > *** Section 7, p6 *** > "The protection of UPN and UPA messages in this document follows > [RFC5213] and [RFC7077]. This extension causes no further security > problem." >=20 > Sorry but, I must admit I don't agree: >=20 > [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." >=20 > 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. >=20 > So, IMHO, additional text is needed regarding this point. Thx for your comment. As you mentioned, unlike MIPv6, PMIPv6 does not = allow the MN to be involved in creating security associations or = creating binding cache entries. The LMA assigns the HNP for the MN. The = assignment of the valid HNP is a responsibility of the LMA in PMIPv6.=20 To reflect your comment, we have revised a bit Section 7 (Security = Considerations) as: "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.=E2=80=9D In = addition, we have added the following sentence in Section 6 (Other = Issues): "The LMA must assign only an authorized HNP for the MN.=E2=80=9D Thanks! >=20 > Best regards, >=20 > JMC. >=20 > >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Jean-Michel

Thanks for your kind comments. We have revised the draft and = uploaded it: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-04

Plz see inline = then.

--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On 20 Dec 2016, at 3:35 AM, Jean-Michel Combes <jeanmichel.combes@orange.com> wrote:

Reviewer: Jean-Michel Combes
Review result: = Ready with Issues

Hi,

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:
<JMC>
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 http://www.ietf.org/iesg/directorate.html.


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?

Thx for your point. The related reference = (RFC7010) from 6renum WG has been added in the revised draft = (-04).


*** Section 7, p6 ***
"The protection of UPN and UPA messages in this document = follows
[RFC5213] and [RFC7077].  This extension = causes no further security
problem."

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.

Thx = for your comment. As you mentioned, unlike MIPv6, PMIPv6 does not allow = the MN to be involved in creating security associations or creating = binding cache entries. The LMA assigns the HNP for the MN. The = assignment of the valid HNP is a responsibility of the LMA in = PMIPv6. 

To reflect your = comment, we have revised a bit Section 7 (Security Considerations) as: = "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.=E2=80=9D In addition, = we have added the following sentence in Section 6 (Other Issues): "The = LMA must assign only an authorized HNP for the MN.=E2=80=9D

Thanks!


Best regards,

JMC.

</JMC>


_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

= --Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF-- From nobody Fri Jan 6 11:08:46 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B63129611; Fri, 6 Jan 2017 11:08:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tatuya Jinmei To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 11:08:44 -0800 Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: [DMM] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:08:44 -0000 Reviewer: Tatuya Jinmei Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-dmm-4283mnids. 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 http://www.ietf.org/iesg/directorate.html. I've reviewed the 03 version of the draft. I didn't find anything obviously wrong/incorrect, and it's generally well-written. So I think it's basically ready for ship. But I'd have to note that I'm not familiar with many of the lower-layer technologies referenced in the draft, so my review and conclusion are somewhat superficial. I found some minor points. The authors may want to address them: - Section 4.1: I guess the MNID is generally supposed to be unique (at least in the realm the ID is used), but not all IPv6 addresses are guaranteed to be unique (a link-local or unspecified address is an obvious example, an ULA may also be inappropriate depending on the usage context). It may be better to note the fact, and you may also want to impose some restrictions on the type of address that can be used as an MNID. - Section 4.5 2000, modulo 2^32. Since the link-layer address can be of variable length [RFC2464], the DUID-LLT is of variable length. I don't understand why RFC2464 is referenced in this context. This RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) length of hardware address. - Section 4.9: s/is (GRAI)/(GRAI)/ The Global Returnable Asset Identifier is (GRAI) is defined by the From nobody Sun Jan 15 21:09:24 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562AD12941C; Sun, 15 Jan 2017 21:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQDLMDGGe4rd; Sun, 15 Jan 2017 21:09:20 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931871293FF; Sun, 15 Jan 2017 21:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1484543360; bh=hbSa6yKeBlDzCKt4tuINs7IOaR8JEZVM1uG7 9eZGd9g=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=GUrtthf Zw0tAXaBgVZXVYaCfLBt1wPav/xiy7KEtHF37JCcmI6CBwcUyRkPS9ZN+xasWr5Hd3U DxSeUH0b+pc59gsi4OwWRJLip8jq4JJpBppi3Y2stntsEwPQR88tbMqV1NknRSZV8UW /GXC2IQ+CUJ24Qe9W2sw+tz9yjhBjPRqFylVptywW0VVXms8FaTDaMLqNsUJ+3ttiTm sXXioZAran8felMM+39SyTtXoS6fw6LotQNdwWnFdMEVZ6f3XkPyexdGp2d7i8y2qZ5 lPuCaGc3jgLi+XCVm3DHpGhnwrr0RYw/uY9RAnaE0fK/g8lyua4SpwMqMc7K6MGTo1w == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=fy81pY6bbZ9LK+jramqomGVz/gvTMcE+cRCyVEhWD/IMO0DCHpRO0KvgQlotJEbBcn0D18drXRxSVwDkvOAqSVtk/pQRaTPlJsnF7j/8m2lgimT5ZQb/GOb0hGbgiRPe7FeGhosfabFe5D724IQ0YkOsMY+1CH8H5otxi8nfJxUdQe3cpuuGE92c3c7/YF6N7iEo98/Sx1W0bhfHAzEHRQ1m67u88sxbIu86L3P2QQS2DR9XSz5cRzWye5N2vA2YmgkfbA9GKYze//CnXCk+z2Sq1nIprDjR3YM+Y+KRSQG5Q/5Vs4qd1X7RNl55pvelKV9JCGhoiXpvGh/1RlNeKQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [50.203.2.195] (helo=[10.199.5.181]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cSzX9-0000wv-27; Mon, 16 Jan 2017 00:08:43 -0500 To: Tatuya Jinmei , int-dir@ietf.org References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> From: Charlie Perkins Message-ID: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> Date: Sun, 15 Jan 2017 21:08:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac761934719e9a4fcfb7fb9c3e3284d692c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 50.203.2.195 Archived-At: Cc: dmm@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 05:09:22 -0000 Hello Tatuya, Thank you for the careful review. Follow-up below: On 1/6/2017 11:08 AM, Tatuya Jinmei wrote: > - Section 4.1: I guess the MNID is generally supposed to be unique > (at > least in the realm the ID is used), but not all IPv6 addresses are > guaranteed to be unique (a link-local or unspecified address is an > obvious example, an ULA may also be inappropriate depending on the > usage context). It may be better to note the fact, and you may > also > want to impose some restrictions on the type of address that can be > used as an MNID. This is correct. I will fashion some language as suggested. I think it is appropriate to allow ULAs, but multicast and unspecified addresses seem clearly inappropriate, and I am i favor of disallowing link-local addresses. > > - Section 4.5 > > 2000, modulo 2^32. Since the link-layer address can be of > variable > length [RFC2464], the DUID-LLT is of variable length. > > I don't understand why RFC2464 is referenced in this context. This > RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) > length of hardware address. I don't quite know what to do about this. I actually just copied this language from RFC 3315. I think that the citation is also wrong in RFC 3315, for the same reason as given here. I could simply delete the reference to RFC 2464. > > - Section 4.9: s/is (GRAI)/(GRAI)/ > > The Global Returnable Asset Identifier is (GRAI) is defined by the > > Fixed. I also checked for other similar instances and did not find any. Regards, Charlie P. From nobody Mon Jan 16 00:09:47 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2EE1293E4 for ; Mon, 16 Jan 2017 00:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOttTCH3fZPH for ; Mon, 16 Jan 2017 00:09:44 -0800 (PST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8E7126D73 for ; Mon, 16 Jan 2017 00:09:44 -0800 (PST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP; 16 Jan 2017 00:09:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.33,238,1477983600"; d="scan'208,217"; a="53482274" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 16 Jan 2017 00:09:43 -0800 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 Jan 2017 00:09:42 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 Jan 2017 00:09:42 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.151]) by HASMSX110.ger.corp.intel.com ([169.254.11.57]) with mapi id 14.03.0248.002; Mon, 16 Jan 2017 10:09:24 +0200 From: "Moses, Danny" To: "Dave Dolson (ddolson@sandvine.com)" , "Lorenzo Colitti" Thread-Topic: Code sample for draft-ietf-dmm-ondemand-mobility Thread-Index: AdJvzjqldRsni7SJTq2xTMIFc3kECA== Date: Mon, 16 Jan 2017 08:09:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134ABE0EAHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] Code sample for draft-ietf-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 08:09:46 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134ABE0EAHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I am including a code sample that I plan to add to the draft. Please review= the code below and comment. There is another topic that we need to finalize regarding the blocking vs n= on-blocking nature of the setsockopt() function but I prefer to discuss it = under a separate email to simplify the tracking of the info. Clearly, if we= decide to make changes to the function (or add a new function), the code s= ample will be updates. Danny ------------ Code Sample --------------- #include #include int s ; = // Socket id sockaddr_in6 serverAddress ; = // server info for connect() uint32_t flags =3D IPV6_REQUIRE_SESSION_LASTIN= G_IP ; = // For requesting a Session-Lasting source IP= address // Create an IPv6 TCP socket s =3D socket(AF_INET6, SOCK_STREAM, 0) ; if (s!=3D0) { // Handle socket creation error // ... } // if socket creation failed else { // Socket creation is successful // The application cannot connect yet, since it wants to u= se a Session-Lasting source IP address // It needs to request the Session-Lasting source IP befor= e connecting if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCE, (void = *) flags, sizeof(flags)) =3D=3D 0){ // setting session continuity to Session Lasting is succes= sful // The application can connect to the server // Set the desired server's port# and IP ad= dress serverAddress.sin6_port =3D serverPort ; serverAddress.sin6_addr =3D serverIpAddress ; // Connect to the server if (connect(s, &serverAddress, sizeof(serverA= ddress)) =3D=3D 0) { // connect successful (3-way h= andshake has been completed with Session-Lasting source address // Continue application functi= onality // ... } // if connect() is successful else { // connect failed // ... // Application code that handl= es connect failure and closes the socket // ... } // if connect() failed } // if the request of a Session-Lasting source address was= successful else { // application code that does not use Sessi= on-lasting IP address // The application may either connect witho= ut the desired Session-lasting service, or close the socket //... } // if the socket was successfully created but a Session-La= sting source address was not provided } // if socket was created successfully // The rest of the application's code // ... ----------------- Code Sample ----------------- --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134ABE0EAHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I am including a code sample that I plan to add to t= he draft. Please review the code below and comment.

There is another topic that we need to finalize rega= rding the blocking vs non-blocking nature of the setsockopt() function but = I prefer to discuss it under a separate email to simplify the tracking of t= he info. Clearly, if we decide to make changes to the function (or add a new function), the code sample will= be updates.

 

Danny

 

 

------------ Code Sample ---------------<= /p>

#include <sys/socket.h>

#include <netinnet/in.h>

 

int         =             &nb= sp;             = ;     s ;       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;          // Socket id

sockaddr_in6        &n= bsp;            serv= erAddress ;           &nb= sp;            =         // server info for connect()

uint32_t        &= nbsp;           &nbs= p;         flags =3D IPV6_REQUIRE_S= ESSION_LASTING_IP ;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        // For requesting a Session= -Lasting source IP address

 

  // Create an IPv6 TCP socket

s =3D socket(AF_INET6, SOCK_STREAM, 0) ;<= /p>

if (s!=3D0) {

  // Handle socket= creation error

        &nbs= p;        // ...

  } // if socket creation failed

else {

 

        &nbs= p;       // Socket creation is successful

        &nbs= p;        // The application cannot connect y= et, since it wants to use a Session-Lasting source IP address

        &nbs= p;        // It needs to request the Session-= Lasting source IP before connecting

        &nbs= p;      if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_= PREFERENCE, (void *) flags, sizeof(flags)) =3D=3D 0){

 

    = ;             // set= ting session continuity to Session Lasting is successful

        &nbs= p;            &= nbsp;          // The application c= an connect to the server

 

        &nbs= p;            &= nbsp;          // Set the desired s= erver's port# and IP address

        &nbs= p;            &= nbsp;        serverAddress.sin6_port =3D= serverPort ;

        &nbs= p;            &= nbsp;        serverAddress.sin6_addr =3D= serverIpAddress ;

 

        &nbs= p;            &= nbsp;          // Connect to the se= rver

        &nbs= p;            &= nbsp;        if (connect(s, &serverA= ddress, sizeof(serverAddress)) =3D=3D 0) {

        &nbs= p;            &= nbsp;           &nbs= p;           // connect s= uccessful (3-way handshake has been completed with Session-Lasting source a= ddress

        &nbs= p;            &= nbsp;           &nbs= p;           // Continue = application functionality

        &nbs= p;            &= nbsp;           &nbs= p;           // …

        &nbs= p;            &= nbsp;        }  // if connect() is = successful

        &nbs= p;            &= nbsp;        else {

        &nbs= p;            &= nbsp;           &nbs= p;           // connect f= ailed

        &nbs= p;            &= nbsp;           &nbs= p;           // ...<= /o:p>

        &nbs= p;            &= nbsp;           &nbs= p;           // Applicati= on code that handles connect failure and closes the socket

        &nbs= p;            &= nbsp;           &nbs= p;           // ...<= /o:p>

        &nbs= p;            &= nbsp;        } // if connect() failed

 

        &nbs= p;      }  // if the request of a Session-Las= ting source address was successful

        &nbs= p;      else {

        &nbs= p;            &= nbsp;          // application code = that does not use Session-lasting IP address

        &nbs= p;            &= nbsp;          // The application m= ay either connect without the desired Session-lasting service, or close the= socket

        &nbs= p;            &= nbsp;          //...

        &nbs= p;      } // if the socket was successfully create= d but a Session-Lasting source address was not provided

}  // if socket was created successfully

 

  // The rest of the application's code

  // ...

 

----------------- Code Sample -----------------=

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134ABE0EAHASMSX106gercor_-- From nobody Mon Jan 16 00:42:27 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07D9129401 for ; Mon, 16 Jan 2017 00:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAHUiNPCf5jA for ; Mon, 16 Jan 2017 00:42:24 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF961293E4 for ; Mon, 16 Jan 2017 00:42:24 -0800 (PST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2017 00:42:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,238,1477983600"; d="scan'208,217";a="923003676" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 16 Jan 2017 00:42:21 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 Jan 2017 00:42:21 -0800 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 16 Jan 2017 00:42:20 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.151]) by LCSMSX154.ger.corp.intel.com ([169.254.7.209]) with mapi id 14.03.0248.002; Mon, 16 Jan 2017 10:42:18 +0200 From: "Moses, Danny" To: "Dave Dolson (ddolson@sandvine.com)" , "Lorenzo Colitti" Thread-Topic: Blocking vs non-blocking function behavior Thread-Index: AdJv0Bar9yFBYW6KQTKYo7zlz+ar+A== Date: Mon, 16 Jan 2017 08:42:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134ABE10AHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: [DMM] Blocking vs non-blocking function behavior X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 08:42:26 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134ABE10AHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Another concern that was raised is regarding the blocking vs non-blocking b= ehavior of the setsockopt() function with the new OnDemand feature. Lorenzo, in one of his comments, suggested to consider adding a new functio= n with a blocking nature, in order not to surprise application developers w= ith a blocking behavior to setsockopt() - which is a non-blocking function. I agree that this may surprise and confuse application developers. I would = like to suggest two alternatives for a solution: 1. Add a new function (setsockoptblocking()) which has a blocking beha= vior 2. Add a new option type to setsockopt() - IPV6_MOBILITY_ON_DEMAND - a= nd describe its possible blocking behavior The advantage of adding a new function, is the clear separation of the beha= vior. Setsockopt() always returns immediately (does not cause packet exchan= ge), and setsockoptblocking() may block execution if it requires packet exc= hange to be able to complete its functionality (for example, when it requir= es a new Session-lasting IP prefix from the network). The disadvantage is the definition of a new function to the long list of ex= isting functions - which adds to the complexity of the Socket API (which is= already quite complicated). Adding a new option to the setsockopt() may be a good compromise. We can do= cument that the new option may cause a blocking effect. It also clearly sep= arates the functionality of OnDemand support from the rest of the options. I also want to point out that so far I did not see any clear separation bet= ween blocking and non-blocking functions in the Socket API. It's true that = some functions have a blocking nature (like connect() in TCP) and some don'= t but the separation of functions did not take that in account. I believe t= hat there are functions that may or may not block execution depending on di= fferent situations and that setsockopt() will not be the first one to do so= . So our extension to the API is still consistent with the current design. What do you think? Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134ABE10AHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,

 

Another concern that was raised is regarding the blo= cking vs non-blocking behavior of the setsockopt() function with the new On= Demand feature.

Lorenzo, in one of his comments, suggested to consid= er adding a new function with a blocking nature, in order not to surprise a= pplication developers with a blocking behavior to setsockopt() – whic= h is a non-blocking function.

 

I agree that this may surprise and confuse applicati= on developers. I would like to suggest two alternatives for a solution:

1.      Add a new function (setsoc= koptblocking()) which has a blocking behavior

2.      Add a new option type to s= etsockopt() – IPV6_MOBILITY_ON_DEMAND – and describe its possib= le blocking behavior

 

The advantage of adding a new function, is the clear= separation of the behavior. Setsockopt() always returns immediately (does = not cause packet exchange), and setsockoptblocking() may block execution if= it requires packet exchange to be able to complete its functionality (for example, when it requires a new Se= ssion-lasting IP prefix from the network).

 

The disadvantage is the definition of a new function= to the long list of existing functions – which adds to the complexit= y of the Socket API (which is already quite complicated).

 

Adding a new option to the setsockopt() may be a goo= d compromise. We can document that the new option may cause a blocking effe= ct. It also clearly separates the functionality of OnDemand support from th= e rest of the options.

 

I also want to point out that so far I did not see a= ny clear separation between blocking and non-blocking functions in the Sock= et API. It’s true that some functions have a blocking nature (like co= nnect() in TCP) and some don’t but the separation of functions did not take that in account. I believe that there are functi= ons that may or may not block execution depending on different situations a= nd that setsockopt() will not be the first one to do so. So our extension t= o the API is still consistent with the current design.

 

What do you think?

 

Danny

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134ABE10AHASMSX106gercor_-- From nobody Mon Jan 16 05:17:55 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45C5129487; Mon, 16 Jan 2017 05:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz0HALubk8rj; Mon, 16 Jan 2017 05:17:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E64129431; Mon, 16 Jan 2017 05:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9114; q=dns/txt; s=iport; t=1484572666; x=1485782266; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pPCGTQRYVJKJcJBSbc+wyLYTBvkXsbXe4Sk9nE5svWE=; b=YneKAp3oxamuZ9onQvBQinkFe89PNhpBT69Xwtzq2k6y+Nz6PVRQ/uQQ K9dil0CxG1vDCdjCCjLSIeNXluR7b1nIm4kLX3GfKykvhK/1PiEKWuq3p 9B7Dr4cmG2zBkT6pOob+qDEaRJIREwaz7vkEondmWLqZQrZdmW+Cq/HIx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQD4xnxY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9fgQmFV4gBkXaQIIUrggsfAQqEHoFaAoIhPxgBAgE?= =?us-ascii?q?BAQEBAQFjKIRqAgQBAWwLEAIBCA4xBycLFBECBA4FiGgDGA6waIoCAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWIRwiCXYJQhSuCMQWVL4YLAYZcgxeHa5BtkmsBHzi?= =?us-ascii?q?BRBU6EAGDbjUDHIFfc4huAQEB?= X-IronPort-AV: E=Sophos;i="5.33,239,1477958400"; d="scan'208,217";a="372517686" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2017 13:17:45 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0GDHjIo030823 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Jan 2017 13:17:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 16 Jan 2017 07:17:44 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 16 Jan 2017 07:17:44 -0600 From: "Bernie Volz (volz)" To: Charlie Perkins Thread-Topic: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 Thread-Index: AQHSaFBRXgHG4F7CUkmyt5JN4S/GpKE7ASmAgAAkDkc= Date: Mon, 16 Jan 2017 13:17:43 +0000 Message-ID: References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com>, <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> In-Reply-To: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Tatuya Jinmei , "draft-ietf-dmm-4283mnids.all@ietf.org" , "ietf@ietf.org" , "dmm@ietf.org" , "int-dir@ietf.org" Subject: Re: [DMM] [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 13:17:48 -0000 --_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI: The RFC2464 reference in RFC3315 is about canonical order, not the lin= k-layer address length. "This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. Both the time a= nd the hardware type are stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [2]." - Bernie (from iPad) On Jan 16, 2017, at 12:09 AM, Charlie Perkins > wrote: Hello Tatuya, Thank you for the careful review. Follow-up below: On 1/6/2017 11:08 AM, Tatuya Jinmei wrote: - Section 4.1: I guess the MNID is generally supposed to be unique (at least in the realm the ID is used), but not all IPv6 addresses are guaranteed to be unique (a link-local or unspecified address is an obvious example, an ULA may also be inappropriate depending on the usage context). It may be better to note the fact, and you may also want to impose some restrictions on the type of address that can be used as an MNID. This is correct. I will fashion some language as suggested. I think it is= appropriate to allow ULAs, but multicast and unspecified addresses seem cl= early inappropriate, and I am i favor of disallowing link-local addresses. - Section 4.5 2000, modulo 2^32. Since the link-layer address can be of variable length [RFC2464], the DUID-LLT is of variable length. I don't understand why RFC2464 is referenced in this context. This RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) length of hardware address. I don't quite know what to do about this. I actually just copied this lang= uage from RFC 3315. I think that the citation is also wrong in RFC 3315, f= or the same reason as given here. I could simply delete the reference to R= FC 2464. - Section 4.9: s/is (GRAI)/(GRAI)/ The Global Returnable Asset Identifier is (GRAI) is defined by the Fixed. I also checked for other similar instances and did not find any. Regards, Charlie P. _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir --_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI: The RFC2464 reference in RFC3315 is about canonical order, not th= e link-layer address length.

"T=
his type of DUID consists of a two octet type field containing the
   value 1, a two octet hardware type code, four octets containing a
   time value, followed by link-layer address of any one network
   interface that is connected to the DHCP device at the time that the
   DUID is generated.  The time value is the time that the DUID is
   generated represented in seconds since midnight (UTC), January 1,
   2000, modulo 2^32.  The hardware type MUST be a valid hardware type
   assigned by the IANA as described in RFC 826 [14].  Both the time and
   the hardware type are stored in network byte order.  The link-layer
   address is stored in canonical form, as described in RFC 2464 [2]."

- Bernie (from iPad)

On Jan 16, 2017, at 12:09 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Tatuya,

Thank you for the careful review.  Follow-up below:


On 1/6/2017 11:08 AM, Tatuya Jinmei wrote:
- Section 4.1: I guess the MNID is generall= y supposed to be unique
(at
  least in the realm the ID is us= ed), but not all IPv6 addresses are
  guaranteed to be unique (a link= -local or unspecified address is an
  obvious example, an ULA may als= o be inappropriate depending on the
  usage context).  It may be= better to note the fact, and you may
also
  want to impose some restriction= s on the type of address that can be
  used as an MNID.

This is correct.  I will fashion some language as suggested. &nb= sp;I think it is appropriate to allow ULAs, but multicast and unspecified a= ddresses seem clearly inappropriate, and I am i favor of disallowing link-l= ocal addresses.

- Section 4.5

   2000, modulo 2^32.  = Since the link-layer address can be of
variable
   length [RFC2464], the DUI= D-LLT is of variable length.

  I don't understand why RFC2464 = is referenced in this context.  This
  RFC is about IPv6 over Ethernet= , and assumes a fixed (6 bytes)
  length of hardware address.

I don't quite know what to do about this.  I actually just copie= d this language from RFC 3315.  I think that the citation is also wron= g in RFC 3315, for the same reason as given here.  I could simply dele= te the reference to RFC 2464.



- Section 4.9: s/is (GRAI)/(GRAI)/

   The Global Returnable Ass= et Identifier is (GRAI) is defined by the



Fixed.  I also checked for other similar instances and did not f= ind any.

Regards,
Charlie P.

_______________________________________________
Int-dir mailing list
Int-dir@ietf.org
https://www= .ietf.org/mailman/listinfo/int-dir
--_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_-- From nobody Mon Jan 16 07:23:32 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD86129575; Mon, 16 Jan 2017 07:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QalgOI3JQtRz; Mon, 16 Jan 2017 07:23:29 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAB112957A; Mon, 16 Jan 2017 07:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1484580205; bh=LowWybMEldKGm0XZK6NVGH5UAS31dX5MeAfI nwv/Om0=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=B9WZObd KkjgqneSpspTwxQdRkXMr91YgJZclgFwcnpmswv8L1qsgHNogkqxV7uMaNxswvRbJaW 6OUB2r5DvlwkxZTdLASLpAEAx05/QGhUJIRAWWcxig1jG0yR4UmoDFPRyLv9iJXT4Q3 QLW0Ah6LfbLdZ0Y2wkQ9JIll5MpWHzUOM5RdDgYLL/ZpDhaw5SKiDULHK/rMZ+BHS1Z sFgYMFKYCbwmFjj3gtUvHt/xJ7rbMldkKLjma6MruOiRSpyq/ruQgOnVyLea7wH+wic BRG4MAAhWtPYK0Y6UCmUmFvYciUV5GWeYqbOV0WrgHbrLTE3hKC69gN6Bqer7lupJ8A == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=CxcKIQE+rbY5M69iGKGoCM65HU8rhWuOEZBEtIj8bf750wM7zrg8jhPMBM8OGzeaxMySZfZLNz+JwxpOsAT16rowSOb5qD1226MIhLbAYvuBMXowAjq4XhVD7JrbNbhxu5pIev0ZeSrlUEacI1DDkhTst7OnaCQhV6a4Q6c3Xwe3755K16QJh1GoR/dg8ounefTrctbWFC8hgj09r5cbqA4E73l1PF1bvPFGr96JP/Ajm725VoPbhy1VfdWl3gXCoQQYbRPjmg2xnnEDOE5VfN0FcfveKFCDvxC95J900giOAHPJkAjh3/25+s8Sr1nfffyegd3Z/fby1tP+8JzqqQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.101.229.226] (helo=[10.100.20.249]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cT97Z-00008O-GB; Mon, 16 Jan 2017 10:22:57 -0500 To: Tatuya Jinmei , int-dir@ietf.org References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> From: Charlie Perkins Message-ID: Date: Mon, 16 Jan 2017 07:22:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7ee6371292b8aa9a368b813cb26a0354c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.101.229.226 Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: Re: [DMM] [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:23:31 -0000 Hello again Tatuya, Here is an updated description of the IPv6 address type when used as a MNID: > 4.1. Description of the IPv6 address type > > The IPv6 address [RFC4291] is encoded as a 16 octet string containing > the full IPv6 address. The IPv6 address MUST be a unicast routable > IPv6 address. Multicast addresses, link-local addresses, and the > unspecified IPv6 address MUST NOT be used. IPv6 Unique Local > Addresses (ULAs) MAY be used, as long as any security operations > making use of the ULA also take into account the domain in which the > ULA is guaranteed to be unique. Please let me know if this resolves your concern. Regards, Charlie P. On 1/15/2017 9:08 PM, Charlie Perkins wrote: > Hello Tatuya, > > Thank you for the careful review. Follow-up below: > > > On 1/6/2017 11:08 AM, Tatuya Jinmei wrote: >> - Section 4.1: I guess the MNID is generally supposed to be unique >> (at >> least in the realm the ID is used), but not all IPv6 addresses are >> guaranteed to be unique (a link-local or unspecified address is an >> obvious example, an ULA may also be inappropriate depending on the >> usage context). It may be better to note the fact, and you may >> also >> want to impose some restrictions on the type of address that can be >> used as an MNID. > > This is correct. I will fashion some language as suggested. I think > it is appropriate to allow ULAs, but multicast and unspecified > addresses seem clearly inappropriate, and I am i favor of disallowing > link-local addresses. ..... From nobody Mon Jan 16 10:30:12 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C11295FC; Mon, 16 Jan 2017 10:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxXlZ1M3P0En; Mon, 16 Jan 2017 10:30:03 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FB612947E; Mon, 16 Jan 2017 10:30:02 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id f4so15797376qte.2; Mon, 16 Jan 2017 10:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UxnWFR6hIbYBrjXuHKVxY1iiLYObkPLq4qDToqFSQVY=; b=XjOrXZkrlvwqd2SA8AECdMFgp4tYGCY39Sq+6GIXU2GJaf30G7FC0CskRaA4GsoiGo lbwmQep8s8nspbIAPO9EgSFda6ugwD0qxwmZ+vN3D+HqoAw9Bvvq1gAYpvPhHGgezSr5 CtWTuA8pIxnTJgHA/8ZmKytqMjUaY87BmChuBqky7QTqjaUvUuZZHAoCTWgBuMUDfM2j DHCDuWDk1csW9PogYG4cGv6trMfM2dunOrcwi6yKfOgy4/POQuqi/6N5iYX5os2Nt2gC bWekZfiXZNaR0x6cVOqdOpMVWHgB28G3l5DTuf6YlrdyehpoQxAN+KihhuK1vgY1fch0 EHrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UxnWFR6hIbYBrjXuHKVxY1iiLYObkPLq4qDToqFSQVY=; b=sSOoz4d1so8P0Q/Nt/LKsXUhmvjONGYlUAVoF1eaOWszA1c4cVrRrEFajwsO0zC1AQ 3odwxCJF5UAMW5WLffxRPGPaNsqapJQxpD0yC/HW7dVequK9zdI5fU4pQkIX1gf362GB hUSyOVg0DEpVxuERlTmhOTn1QL3Xh/AFzoXClFPapnq0OsB8CQszV10kHeJfikr0CXb0 mbxGmyOdDICCLFFGuR4dGLHPWm+3Z3YdJd9pD3+Vfk6LwBxzo7sWQmV+vTf/5oPoX6A+ udDfG4PPkro/NaYyI7dLKLRtohPPBlOuQMjaEUyiiAaqmY/LWJRJG0AXHOI39bL2ZZ2x aweg== X-Gm-Message-State: AIkVDXL1YGEMR+xY1dNNDMBpfcysuxfMieEK9+/wGsYN9vmYaV53QSrOy76BBev6njsaZfHSMFczSJi6YIZoag== X-Received: by 10.55.3.14 with SMTP id 14mr30204048qkd.86.1484591401951; Mon, 16 Jan 2017 10:30:01 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Mon, 16 Jan 2017 10:30:01 -0800 (PST) In-Reply-To: References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 16 Jan 2017 10:30:01 -0800 X-Google-Sender-Auth: i_yQpb4i2LO5SBBTJqWJ6RQEPNA Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tatuya Jinmei , dmm@ietf.org, IETF Discussion , draft-ietf-dmm-4283mnids.all@ietf.org, "" Subject: Re: [DMM] [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 18:30:04 -0000 At Mon, 16 Jan 2017 07:22:56 -0800, Charlie Perkins wrote: > Here is an updated description of the IPv6 address type when used as a MNID: > > > 4.1. Description of the IPv6 address type > > > > The IPv6 address [RFC4291] is encoded as a 16 octet string containing > > the full IPv6 address. The IPv6 address MUST be a unicast routable > > IPv6 address. Multicast addresses, link-local addresses, and the > > unspecified IPv6 address MUST NOT be used. IPv6 Unique Local > > Addresses (ULAs) MAY be used, as long as any security operations > > making use of the ULA also take into account the domain in which the > > ULA is guaranteed to be unique. > > Please let me know if this resolves your concern. Looks good to me. -- JINMEI, Tatuya From nobody Mon Jan 16 10:40:44 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5855312960C; Mon, 16 Jan 2017 10:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuK3G6xlnMwE; Mon, 16 Jan 2017 10:40:41 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10381295FA; Mon, 16 Jan 2017 10:40:40 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id a29so15875211qtb.1; Mon, 16 Jan 2017 10:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iYDrKVLDNU1cBirnMncIqo6MMZiVB/htki+ZJri4W38=; b=KJB62TbtBEcXrUEpHcNzPM6A/n72GY0mGp7sJXIVRirw5v9YyDV8ZJnxYyFTw9Ae58 jgPKcP2Yv3eKgPOhePUpUuIB6sE9sHwnzj3mOmyLfsoGG5SrgSngV7rqACEk/CC8M8GZ GjRcgb0FVfVZrPf/P5IX/YayqWnexlBqBJRZH1zsysXwRKfEP14mtAWjepFFI+YGz0kn 8paQ2O7aUmFi87sm+IN3JPRh2x9pv4xLKuKb39rQv+jxcvTjD/w9sCAr1WnobCPATSl8 bs+3Cff2PUalo4ueFNjJXAAer6thEJuNTI1lNFgdXMzotaCU1H36zy9InvORc9qnw4EO uxMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iYDrKVLDNU1cBirnMncIqo6MMZiVB/htki+ZJri4W38=; b=LcEvfUwqABCNvActbBnv/J994kuw5GSLsZqXOACZJIaB+GeM76rOyh8JteFeRaruYm /7tGWLjQ0iB0hfiWzAaIKzTV+2wSomCyG1lrtG+fECW4ySyGYIfWZSV3UKeM/AWunAnJ N/pEB4rsmbcnj7K4AQicqNPrN571/YqOB7thqGYaLPlEDG/gv5/q8gK5rTgFLGCqQL/f YprUJOXjE9glJWcztIJBFvSOkNjq2oGK0IL6aHJMbKjNVsaDp5FZZwEj/kvf3n2Z6OdM J7H3aiXYXGJlzLTtbe7Ooxa4TD/U820Pc/88cR1I5E11ueSjacU7pEpNs+p7qBc6KcqJ +ZMw== X-Gm-Message-State: AIkVDXJBIjMZ4uw2zZcNdBiosiieC0Htvd5QLCy0WHwG7c6z9DdO4d8Ha81C8sYOMIHBNPEghjdWIdMcY/U2KA== X-Received: by 10.55.45.129 with SMTP id t123mr30190631qkh.311.1484592039680; Mon, 16 Jan 2017 10:40:39 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Mon, 16 Jan 2017 10:40:39 -0800 (PST) In-Reply-To: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 16 Jan 2017 10:40:39 -0800 X-Google-Sender-Auth: u5LJNL1WeGSwfJ-W0t9RRfNONoM Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tatuya Jinmei , draft-ietf-dmm-4283mnids.all@ietf.org, IETF Discussion , dmm@ietf.org, "" Subject: Re: [DMM] [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 18:40:42 -0000 At Sun, 15 Jan 2017 21:08:41 -0800, Charlie Perkins wrote: > > - Section 4.5 > > > > 2000, modulo 2^32. Since the link-layer address can be of > > variable > > length [RFC2464], the DUID-LLT is of variable length. > > > > I don't understand why RFC2464 is referenced in this context. This > > RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) > > length of hardware address. > > I don't quite know what to do about this. I actually just copied this > language from RFC 3315. I think that the citation is also wrong in RFC > 3315, for the same reason as given here. I could simply delete the > reference to RFC 2464. I don't see "Since the link-layer address can be of variable length [RFC2464], the DUID-LLT is of variable length." in RFC3315. See also the followup comment by Bernie. Deleting the reference will certainly address my concern, and I personally don't mind not having a reference here. -- JINMEI, Tatuya From nobody Tue Jan 17 01:05:38 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101D112952C for ; Tue, 17 Jan 2017 01:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.801 X-Spam-Level: X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlFxaCHrQ6WJ for ; Tue, 17 Jan 2017 01:05:36 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5DA12941E for ; Tue, 17 Jan 2017 01:05:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id ACD2F1004BF; Tue, 17 Jan 2017 10:05:33 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8FQ9W-vGL7B; Tue, 17 Jan 2017 10:05:33 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 8BB39101D20; Tue, 17 Jan 2017 10:05:27 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.191]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Tue, 17 Jan 2017 10:05:27 +0100 From: Marco Liebsch To: Satoru Matsushima , Charlie Perkins Thread-Topic: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] Thread-Index: AQHSYXuaMAvGZyKnl0uR0QDAbxChR6E8euew Date: Tue, 17 Jan 2017 09:05:26 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DAF06C624@PALLENE.office.hd> References: <147793286841.32501.6238148222555288408.idtracker@ietfa.amsl.com> <715d6603-f939-7d21-b6ae-b1a7e435b8d2@earthlink.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.170] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 09:05:38 -0000 VGhlIG1lYW5pbmcgb2YgcG9ydCBjaGFuZ2VkIHRocm91Z2hvdXQgdGhlIGV2b2x1dGlvbiBvZiB0 aGlzIGRyYWZ0LiBVcCB0byB2ZXJzaW9uIDMgYSBwb3J0IHdhcyBhDQpmb3J3YXJkaW5nIGNvbnN0 cnVjdCB0aGF0IGJpbmRzIHRyYWZmaWMgc2VsZWN0b3JzIHRvIHRyYWZmaWMgdHJlYXRtZW50IGFj dGlvbnMuIEFueSBvdGhlciB0ZXJtLA0KZS5nLiBydWxlLCBjb3VsZCBoYXZlIG1hZGUgaXQuIFRo ZXNlIGFyZSBjcmVhdGVkIChhdHRhY2gpLCBtb2RpZmllZCAoaGFuZG92ZXIpIG9yIGRlbGV0ZWQg cGVyDQp0aGUgbW9iaWxlIG5vZGUncyBsb2NhdGlvbiwgSVAgYWRkcmVzcywgZXRjLg0KDQpGcm9t IHZlcnNpb24gNCwgd2hhdCBoYXMgYmVlbiBhIHBvcnQgYmVmb3JlIGlzIG5vdyBtb3JlIHRoZSAn Y29udGV4dCcgc3RydWN0dXJlLCB3aGVyZWFzDQp0aGUgaW5oZXJpdGVkIHBvcnQgdGVybSBpcyB1 c2VkIHRvIGdyb3VwIHBvbGljaWVzIGFuZCBiaW5kIHRoZW0gdG8gY29udGV4dC4gQSBkaWZmZXJl bnQgdGVybSB3b3VsZCBiZSBtb3JlIG9idmlvdXMuDQpQb2xpY3kgZ3JvdXAgYmluZGluZyAoUEdC KSBvciBldmVuIHRoZSBwcm9wb3NlZCBGUEcgYXJlIG9rLCB0aG91Z2ggSSBhbSBhIGJpdCBwdXp6 bGVkIHdoeSBGbG93IGFwcGVhcnMgaW4gaGVyZS4NCg0KbWFyY28NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBTYXRvcnUgTWF0c3VzaGltYQ0KU2VudDogRG9ubmVyc3RhZywgMjkuIERlemVt YmVyIDIwMTYgMDM6MzENClRvOiBDaGFybGllIFBlcmtpbnMNCkNjOiBkbW1AaWV0Zi5vcmcNClN1 YmplY3Q6IFtETU1dIENoYW5nZSAiUG9ydCIgdG8gPyBbIHdhcyBSZTogSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1kbW0tZnBjLWNwZHAtMDUudHh0XQ0KDQpIaSBDaGFybGllLA0KDQpGaXJzdCwgdGhh bmsgeW91IGZvciByYWlzaW5nIHRoaXMgcG9pbnQgdG8gYmUgZGlzY3Vzc2VkLiBJIHNlY29uZCB0 aGF0IGl0IG5lZWRzIHRvIGJlIG1vcmUgaW50dWl0aXZlLg0KDQoNCj4gDQo+IEkgYW0gaW4gdGhl IHByb2Nlc3Mgb2YgcmV2aWV3aW5nIHRoZSBGUEMgZG9jdW1lbnQuICBJdCBpcyBhbiBpbXBvcnRh bnQgZG9jdW1lbnQgYW5kIHdpbGwgYmUgZm91bmRhdGlvbmFsIGZvciBzdWJzZXF1ZW50IHdvcmsg aW4gW2RtbV0uDQoNClllcCwgSSByZWFsbHkgYXBwcmVjaWF0ZSB0aGF0IHlvdSBzZWUgdGhpcyBk cmFmdCBhcyBhIGZvdW5kYXRpb24gZm9yIGZ1cnRoZXIgd29ya3MuDQoNCg0KPiAgSSB3b3VsZCBs aWtlIHRvIHN1Z2dlc3QgYSBjaGFuZ2UgaW4gdGVybWlub2xvZ3kuICBJIHRoaW5rIHRoZSB3YXkg IlBvcnQiIGlzIGN1cnJlbnRseSBkZWZpbmVkIGluIHRoZSBkb2N1bWVudCBpcyB2ZXJ5IGNvbmZ1 c2luZywgYmVjYXVzZSBpdCBpcyBub3QgdmVyeSBpbnR1aXRpdmVseSByZWxhdGVkIHRvIHRoZSB0 cmFkaXRpb25hbCB1c2VzIG9mICJwb3J0IiBhcyBpbiBUQ1AsIG9yIGluIHN3aXRjaGVzLg0KDQpS aWdodC4gVGhlIGNvYXV0aG9ycyBoYWQgZGlzY3Vzc2VkIHRoaXMgcG9pbnQgbWFueSB0aW1lcyBi dXQsIG1lIGF0IGxlYXN0LCBjb3VsZG7igJl0IGZpZ3VyZSBvdXQgbW9yZSBhcHByb3ByaWF0ZSB0 ZXJtIGluc3RlYWQgb2YgdGhhdCBzbyBmYXIuLi4NCg0KDQo+IA0KPiBBcyBJIHVuZGVyc3RhbmQg aXQsICJQb2xpY3kiIGxpdmVzIG9uIHRoZSBjb250cm9sIHBsYW5lIHNpZGUgb2YgdGhlIGludGVy ZmFjZSwgYW5kICJQb3J0IiBpcyBpbnRlbmRlZCB0byBkZW5vdGUgYSBjb25jZXB0IHRoYXQgaXMg aW1wb3J0YW50IG9uIHRoZSBkYXRhIHBsYW5lIHNpZGUgb2YgdGhlIGludGVyZmFjZS4NCg0KSWYg eW91IG1lYW4g4oCcY29udHJvbCBwbGFuZeKAnSBhcyBhYnN0cmFjdGVkIGRhdGEtcGxhbmUgbW9k ZWwgaW4gRlBDIGFnZW50LCAgSSB0aGluayB0aGF0IGJvdGgg4oCcUG9saWN54oCdIGFuZCDigJxQ b3J04oCdIGV4aXN0IG9uIHRoZSBjb250cm9sIHBsYW5lLiBJbiB0aGUgY3VycmVudCB2ZXJzaW9u IG9mIGRyYWZ0LCBQb3J0IGlzIGRlZmluZWQgYXMg4oCcQSBzZXQgb2YgZm9yd2FyZGluZyBwb2xp Y2llcy7igJ0NCg0KDQo+ICAiRmxvdyIgaXMgYW5vdGhlciB3b3JkIHRoYXQgaXMgY2xvc2VseSB0 aWVkIHRvIHRoZSBkYXRhIHBsYW5lLCBhbmQgaXQgc2VlbXMgdG8gbWUgdGhhdCBhcyBjdXJyZW50 bHkgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnQgYSAiUG9ydCIgaXMgYSBjb2xsZWN0aW9uIG9mIGZs b3dzIHRoYXQgY29ycmVzcG9uZCB0byBhIHNwZWNpZmljIFBvbGljeSBvciBQb2xpY3kgR3JvdXAu DQoNCkZvciBtZSwg4oCcRmxvd+KAnSBzZWVtcyBub3QgdG8gZXhhY3RseSBpbmRpY2F0ZSBzcGVj aWZpYyBwb2xpY3kgYXBwbGllZCBmbG93LiBJdCBjb3VsZCBpbmRpY2F0ZSBmbG93KHMpIHdoaWNo IGp1c3QgaGF2ZSBzYW1lIGNoYXJhY3RlcmlzdGljcyBpbiBuYXR1cmFsLiANCg0KDQo+IA0KPiBT bywgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCB0aGUgd29yZCAiUG9ydCIgc2hvdWxkIGJl IHJlcGxhY2VkIGJ5IHRoZSB0ZXJtICJGbG93IEdyb3VwIi4gIEFub3RoZXIgYWx0ZXJuYXRpdmUg d291bGQgYmUgIkZsb3cgUG9saWN5IEdyb3VwIiwgd2hpY2ggY291bGQgdGhlbiBiZSBhYmJyZXZp YXRlZCBGUEcuIEhvd2V2ZXIsIHRoZSBsYXR0ZXIgaGFzIHRoZSBwZXJoYXBzIHVuZGVzaXJhYmxl IGVmZmVjdCBvZiB0eWluZyB0aGUgd29yZCAiUG9saWN5IiB0byBhIGRhdGEtcGxhbmUgY29uY2Vw dC4NCg0KSSB0aGluayB0aGF0IHRoZSBzdWNjZXNzb3Igb2YgcG9ydCBzaG91bGQga2VlcCBzYW1l IG1lYW5pbmcgb2Yg4oCcQSBzZXQgb2YgZm9yd2FyZGluZyBwb2xpY2llcy7igJ0gSW4gdGhhdCBz ZW5zZSwgRlBHIHNvdW5kcyBtYWtlIHNlbnNlIHRvIG1lLiANCg0KaW4gYW5vdGhlciBhc3BlY3Qs IHdlIHVzZSBDb250ZXh0IGFzIGFic3RyYWN0ZWQgbW9iaWxpdHkgc2Vzc2lvbi4gSSBjYW4gc2Vl IHRoaXMgYXMgc291cmNlIG9mIGZsb3cocykgYW5kIGl0IGxvb2tzIGFscmVhZHkgcmVwcmVzZW50 IGEgZ3JvdXAgb2YgdGhvc2UgZmxvd3Mgd2hpY2ggYXJlIHJlY2VpdmVkIGFuZCBzZW50IG9uIGVh Y2ggbm9kZS4gQXR0YWNoaW5nIENvbnRleHQgdG8gYSBQb3J0IGludGVuZHMgdGhhdCBhcHBseWlu ZyBhIHNldCBvZiBwb2xpY2llcyB0byBhIGdyb3VwIG9mIGZsb3dzIHdoaWNoIGFyZSBhdHRyaWJ1 dGVkIHRvIHRoZSBjb250ZXh0Lg0KDQoNCj4gDQo+IFRoYW5rcyBmb3IgYW55IGNvbW1lbnRzIG9u IHRoaXMgcHJvcG9zYWwgdG8gbW9kaWZ5IHRoZSB0ZXJtaW5vbG9neS4NCj4gDQo+IEkgdGhpbmsg aXQgaXMgaW1wb3J0YW50IHRvIG1ha2UgdGhlIHRlcm1pbm9sb2d5IGFzIHVuYW1iaWd1b3VzIGFu ZCBpbnR1aXRpdmUgYXMgd2UgcG9zc2libHkgY2FuLCBlc3BlY2lhbGx5IGJlY2F1c2UgdGhlIGRv Y3VtZW50IGlzIG5lY2Vzc2FyaWx5IHdyaXR0ZW4gYXQgYSBoaWdoIGxldmVsIG9mIGFic3RyYWN0 aW9uLg0KPiANCg0KWWVzLCBJIGZ1bGx5IGFncmVlIHdpdGggeW91LCBsZXTigJlzIGtlZXAgdGhl IGRpc2N1c3Npb24uDQoNCg0KPiBSZWdhcmRzLA0KPiBDaGFybGllIFAuDQoNCkJlc3QgcmVnYXJk cywNCi0tc2F0b3J1DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg== From nobody Tue Jan 17 20:56:06 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B42D1294B7; Tue, 17 Jan 2017 20:56:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148471536441.32118.11073877420785342880.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 20:56:04 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-4283mnids-04.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 04:56:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : MN Identifier Types for RFC 4283 Mobile Node Identifier Option Authors : Charles E. Perkins Vijay Devarapalli Filename : draft-ietf-dmm-4283mnids-04.txt Pages : 14 Date : 2017-01-17 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 23 01:56:15 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A70051295CF; Mon, 23 Jan 2017 01:56:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148516537264.29574.10177842999970942137.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2017 01:56:12 -0800 Archived-At: Cc: dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] dmm - New Meeting Session Request for IETF 98 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 09:56:12 -0000 A new meeting session request has just been submitted by Dapeng Liu, a Chair of the dmm working group. --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Dapeng Liu Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: v6ops Special Requests: Conflicts to Avoid: Potential OTrP BoF --------------------------------------------------------- From nobody Mon Jan 23 02:09:38 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E50129AE4 for ; Mon, 23 Jan 2017 02:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hECXBpSydfE for ; Mon, 23 Jan 2017 02:09:36 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F348129405 for ; Mon, 23 Jan 2017 02:09:36 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id i68so106069454uad.0 for ; Mon, 23 Jan 2017 02:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tIDnC8sdq1FfgS3t71Au9HoWB/1ydsWtq83t1uZ1uNY=; b=UudMXtTfXCrfo/205CLTKPOn+ij/4P+yGNWGFydTUt8iw7qyJW8YwqQzD5MDVmWenc 9UWCQjb0/l4gEJhLNWpX2WtThVbQ1ZibfXTBB1vFUal3fW1h5WwsHsN2s6KccI3ly/DU X0TnPbKlDSKjt9w9D5AYrzBZX4rXE94oBWUGRMeZRA5KuREcNjG+9MdQLLdqbAMhKjcn reg5Spg6Wjdgkjd4/4giPBlqKNok9IQTd7CSYoNeyDuGbGMSGX9Dcbf1HYVQsEDGpdOP Orluovo0BeB0U2frMgvszVWqPFC1yM6WXBYLNc92SW8yqsVcppKEhBNGa3yzGMYVtAnX 6uPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tIDnC8sdq1FfgS3t71Au9HoWB/1ydsWtq83t1uZ1uNY=; b=Kf88neeATGhHvgaK+FxIEfO1MpxYxpSMUZt7X47FxUcVkheA+z8stqs12bJMRXwhkQ /4TRBDENZrgqEUjqz4UUOHaWsbA9mARfjJ57djJYkhhvb8msVQLQusa43r/9HOVID3C/ if7EClJ8YKnAuUQB2C7rTTmDNFmlVeQ3tXrD1zJh/0Cg3YsdKEoVu8snRmSCbDE3ciqT qcy9chgFb7O4WBEJJ+mNke35W6YG4pBH66CJAKb8g32RwFmZsDD1Z6550L2zOq46208f tbF80I9qbAkUhNzxRP9z1pnj2CqEFnqYrLFrwzZ2WPR5j7rQpEFhGIoLLc45Vfo7N7IE 3pfQ== X-Gm-Message-State: AIkVDXJkN2EPaX6gDOsp7KjkBWek8R7bXUebTPKyOynnxBe5WbqJQkWGwhXIdEJPAFJiBkvkKsn4Za81FIKy7w== X-Received: by 10.176.67.196 with SMTP id l62mr14603900ual.89.1485166175513; Mon, 23 Jan 2017 02:09:35 -0800 (PST) MIME-Version: 1.0 From: Dapeng Liu Date: Mon, 23 Jan 2017 10:09:24 +0000 Message-ID: To: dmm Content-Type: multipart/alternative; boundary=001a114bdf6052efa10546c03249 Archived-At: Subject: [DMM] DMM IETF 98 meeting X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:09:37 -0000 --001a114bdf6052efa10546c03249 Content-Type: text/plain; charset=UTF-8 Hello all, IETF 98 meeting is approaching. If you want to request a time slot, please send request to the chairs before *2017-02-23.* *Thanks,* *Dapeng & Sri* --001a114bdf6052efa10546c03249 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

IETF 98 meeting is approachi= ng. If you want to request a time slot, please send request to the chairs b= efore=C2=A02017-02-23.

=

Thanks,
Dapeng & Sr= i
--001a114bdf6052efa10546c03249-- From nobody Mon Jan 23 02:24:35 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95234129AE4 for ; Mon, 23 Jan 2017 02:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuAE76Dl_IvS for ; Mon, 23 Jan 2017 02:24:32 -0800 (PST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AC71294F8 for ; Mon, 23 Jan 2017 02:24:32 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP; 23 Jan 2017 02:24:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,274,1477983600"; d="scan'208,217";a="1116523962" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga002.fm.intel.com with ESMTP; 23 Jan 2017 02:24:31 -0800 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 23 Jan 2017 02:24:31 -0800 Received: from HASMSX110.ger.corp.intel.com (10.184.198.28) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 23 Jan 2017 02:24:30 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.151]) by HASMSX110.ger.corp.intel.com ([169.254.11.57]) with mapi id 14.03.0248.002; Mon, 23 Jan 2017 12:24:28 +0200 From: "Moses, Danny" To: Dapeng Liu , "Sri Gundavelli (sgundave@cisco.com)" Thread-Topic: [DMM] DMM IETF 98 meeting Thread-Index: AQHSdWDagppDfTBGJkmTKXKArQuALqFF2a1Q Date: Mon, 23 Jan 2017 10:24:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.11] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134ABEFD6HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: dmm Subject: Re: [DMM] DMM IETF 98 meeting X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 10:24:33 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134ABEFD6HASMSX106gercor_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGksDQoNCkkgd291bGQgbGlrZSB0d28gc2xvdHM6DQoNCsK3ICAgICAgICAxNSBtaW51dGVzIHRv IGRpc2N1c3MgcHJvZ3Jlc3Mgb24gdGhlIE9uRGVtYW5kIFNvY2tldCBleHRlbnNpb25zIChkcmFm dDogZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQtbW9iaWxpdHkpDQoNCsK3ICAgICAgICAxMCBtaW51 dGVzIHRvIGRpc2N1c3MgY2hhbmdlcyBpbiB0aGUgT25EZW1hbmQgZXh0ZW5zaW9ucyBmb3IgREhD UHY2IChkcmFmdDogZHJhZnQtbW9zZXMtZG1tLWRoY3Atb25kZW1hbmQtbW9iaWxpdHkpDQoNClRo YW5rcywNCkRhbm55DQoNCkZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRGFwZW5nIExpdQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDIzLCAyMDE3IDEy OjA5DQpUbzogZG1tIDxkbW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRE1NXSBETU0gSUVURiA5OCBt ZWV0aW5nDQoNCkhlbGxvIGFsbCwNCg0KSUVURiA5OCBtZWV0aW5nIGlzIGFwcHJvYWNoaW5nLiBJ ZiB5b3Ugd2FudCB0byByZXF1ZXN0IGEgdGltZSBzbG90LCBwbGVhc2Ugc2VuZCByZXF1ZXN0IHRv IHRoZSBjaGFpcnMgYmVmb3JlIDIwMTctMDItMjMuDQoNCg0KVGhhbmtzLA0KRGFwZW5nICYgU3Jp DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KQSBtZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9m IGNvbXBhbmllcwoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMuCg== --_000_F0CF5715D3D1884BAC731EA1103AC28134ABEFD6HASMSX106gercor_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow Y207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVm dDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjMxNzgxMjIxNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTA0NDgxMDg4IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SSB3b3VsZCBsaWtlIHR3byBzbG90czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MTUgbWludXRlcyB0byBkaXNjdXNzIHByb2dy ZXNzIG9uIHRoZSBPbkRlbWFuZCBTb2NrZXQgZXh0ZW5zaW9ucyAoZHJhZnQ6IGRyYWZ0LWlldGYt ZG1tLW9uZGVtYW5kLW1vYmlsaXR5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4xMCBtaW51dGVzIHRvIGRpc2N1c3MgY2hhbmdlcyBp biB0aGUgT25EZW1hbmQgZXh0ZW5zaW9ucyBmb3IgREhDUHY2IChkcmFmdDogZHJhZnQtbW9zZXMt ZG1tLWRoY3Atb25kZW1hbmQtbW9iaWxpdHkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRhbm55PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3Nl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYXBlbmcgTGl1PGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgSmFudWFyeSAyMywgMjAxNyAxMjowOTxicj4NCjxiPlRvOjwvYj4gZG1tICZsdDtkbW1A aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtETU1dIERNTSBJRVRGIDk4IG1lZXRp bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBhbGwsPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JRVRGIDk4IG1lZXRpbmcg aXMgYXBwcm9hY2hpbmcuIElmIHlvdSB3YW50IHRvIHJlcXVlc3QgYSB0aW1lIHNsb3QsIHBsZWFz ZSBzZW5kIHJlcXVlc3QgdG8gdGhlIGNoYWlycyBiZWZvcmUmbmJzcDs8c3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmIj4yMDE3LTAyLTIzLjwvc3Bhbj48L3N0cm9uZz48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+VGhh bmtzLDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+RGFwZW5nICZhbXA7IFNyaTwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cD4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+CkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBjb21wYW5pZXM8 L3A+Cgo8cD5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBtYXRlcmlhbCBmb3I8YnI+CnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbjxicj4KYnkgb3RoZXJzIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4KcmVjaXBp ZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy48L3A+ PC9ib2R5Pg0KPC9odG1sPg0K --_000_F0CF5715D3D1884BAC731EA1103AC28134ABEFD6HASMSX106gercor_-- From nobody Tue Jan 24 09:39:10 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 701B81294CF; Tue, 24 Jan 2017 09:39:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148527954841.12614.16693448128006766922.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 09:39:08 -0800 Archived-At: Cc: Dapeng Liu , draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] Last Call: (MN Identifier Types for RFC 4283 Mobile Node Identifier Option) to Proposed Standard X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 17:39:08 -0000 The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'MN Identifier Types for RFC 4283 Mobile Node Identifier Option' as Proposed Standard 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 2017-02-07. 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 Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jan 25 09:16:38 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF2A129A9B for ; Wed, 25 Jan 2017 09:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3rZjoSX_I30 for ; Wed, 25 Jan 2017 09:16:35 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E058129984 for ; Wed, 25 Jan 2017 09:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1485364595; bh=MNp2V87+pEBX5LHoZxkCOhtBIh7SN2NtSE9k 0ESCjeM=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=pDsjvcxdj+T/ACvSekH25d/7F+18lVyFrrk9sB0EKaeLK2 AanUIsJ6hD8QL/1I6ffqfnSr5+rTHWmTlPgtq2kCqbA/ePGh+iPNF0Ajho7A6HHEhOs fyuGmprVwFireJXOqKcATdh82X0kFRsG1jCN3OPo2dlj75EXEZxBwIW+nDJbG5ZAZWt ks49ZLWDt5JQmKa3EG1ZUMco3x/lD4P/rI9TKDPVnALdJasFLFy60EY7kbhjX6a1D25 ka8yZxHokUmVa7DDzEoq3Z1x3RW8a6avi0lpUoGihBUH4/lAXnN1BTdfRSjgDbsE69q eruSrovcssPGTGxFJ1yO8bso7WCQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=b3wSSJyqcJ0fSY43i1DmiYv5lI0uYafovCOvMwt1jlre0Y/rvJbPdQ9XUPehj93nHhAualtKHVQJC2wqL7GU4Gmay+aLo4uiyjAwaDrGQeBm1ObmLyDXNwhYfKUU6S9JTWwSt6iSUK6Zr9gzG39W04FAQ2vO2PwLZBkEnKx9q9VxYHvfznse6Tb81pIieyO3neyJvYvk6LAR6Z4lqkVjx3VdVVqLL/N8nMHiG9A+l3oKJOpYNpqr2BY8PlK2UT9heA1WjANKcD6u8/Bcc247tRAW94Sv+dkFLRUKrWCnpeKn9hHKhWDHrwbQp7dMHTMs9/ecz4W8rBSICl8rWJNBxQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cWRBR-0005zL-5V; Wed, 25 Jan 2017 12:16:33 -0500 To: Marco Liebsch , Satoru Matsushima References: <147793286841.32501.6238148222555288408.idtracker@ietfa.amsl.com> <715d6603-f939-7d21-b6ae-b1a7e435b8d2@earthlink.net> <69756203DDDDE64E987BC4F70B71A26DAF06C624@PALLENE.office.hd> From: Charlie Perkins Message-ID: <116dd8b8-ac89-5e9b-1c3e-eb92371b8f98@earthlink.net> Date: Wed, 25 Jan 2017 09:16:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <69756203DDDDE64E987BC4F70B71A26DAF06C624@PALLENE.office.hd> Content-Type: multipart/alternative; boundary="------------67EB4D712ED041D3463195AA" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7071ba56af08bba14b3e9cfdb812b7f61350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 17:16:37 -0000 This is a multi-part message in MIME format. --------------67EB4D712ED041D3463195AA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Marco, What would you think about replacing the term "port" by "virtual port", which would usually be shortened to "vport" (or "Vport")? I think it would have several benefits: * it seems intuitively appealing, at least to me * it avoids the unacceptable clash with the traditional meanings of the word "port" * it fits well with my understanding of "data-plane node" and "context". * it's a relatively easy editorial change to the draft Regards, Charlie P. On 1/17/2017 1:05 AM, Marco Liebsch wrote: > The meaning of port changed throughout the evolution of this draft. Up to version 3 a port was a > forwarding construct that binds traffic selectors to traffic treatment actions. Any other term, > e.g. rule, could have made it. These are created (attach), modified (handover) or deleted per > the mobile node's location, IP address, etc. > > From version 4, what has been a port before is now more the 'context' structure, whereas > the inherited port term is used to group policies and bind them to context. A different term would be more obvious. > Policy group binding (PGB) or even the proposed FPG are ok, though I am a bit puzzled why Flow appears in here. > > marco > > > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima > Sent: Donnerstag, 29. Dezember 2016 03:31 > To: Charlie Perkins > Cc: dmm@ietf.org > Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] > > Hi Charlie, > > First, thank you for raising this point to be discussed. I second that it needs to be more intuitive. > > >> I am in the process of reviewing the FPC document. It is an important document and will be foundational for subsequent work in [dmm]. > Yep, I really appreciate that you see this draft as a foundation for further works. > > >> I would like to suggest a change in terminology. I think the way "Port" is currently defined in the document is very confusing, because it is not very intuitively related to the traditional uses of "port" as in TCP, or in switches. > Right. The coauthors had discussed this point many times but, me at least, couldn’t figure out more appropriate term instead of that so far... > > >> As I understand it, "Policy" lives on the control plane side of the interface, and "Port" is intended to denote a concept that is important on the data plane side of the interface. > If you mean “control plane” as abstracted data-plane model in FPC agent, I think that both “Policy” and “Port” exist on the control plane. In the current version of draft, Port is defined as “A set of forwarding policies.” > > >> "Flow" is another word that is closely tied to the data plane, and it seems to me that as currently defined in the document a "Port" is a collection of flows that correspond to a specific Policy or Policy Group. > For me, “Flow” seems not to exactly indicate specific policy applied flow. It could indicate flow(s) which just have same characteristics in natural. > > >> So, I would like to propose that the word "Port" should be replaced by the term "Flow Group". Another alternative would be "Flow Policy Group", which could then be abbreviated FPG. However, the latter has the perhaps undesirable effect of tying the word "Policy" to a data-plane concept. > I think that the successor of port should keep same meaning of “A set of forwarding policies.” In that sense, FPG sounds make sense to me. > > in another aspect, we use Context as abstracted mobility session. I can see this as source of flow(s) and it looks already represent a group of those flows which are received and sent on each node. Attaching Context to a Port intends that applying a set of policies to a group of flows which are attributed to the context. > > >> Thanks for any comments on this proposal to modify the terminology. >> >> I think it is important to make the terminology as unambiguous and intuitive as we possibly can, especially because the document is necessarily written at a high level of abstraction. >> > Yes, I fully agree with you, let’s keep the discussion. > > >> Regards, >> Charlie P. > Best regards, > --satoru > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --------------67EB4D712ED041D3463195AA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Marco,

What would you think about replacing the term "port" by "virtual port", which would usually be shortened to "vport" (or "Vport")?

I think it would have several benefits:

  • it seems intuitively appealing, at least to me
  • it avoids the unacceptable clash with the traditional meanings of the word "port"
  • it fits well with my understanding of "data-plane node" and "context".
  • it's a relatively easy editorial change to the draft

Regards,
Charlie P.


On 1/17/2017 1:05 AM, Marco Liebsch wrote:
The meaning of port changed throughout the evolution of this draft. Up to version 3 a port was a
forwarding construct that binds traffic selectors to traffic treatment actions. Any other term,
e.g. rule, could have made it. These are created (attach), modified (handover) or deleted per
the mobile node's location, IP address, etc.

>From version 4, what has been a port before is now more the 'context' structure, whereas
the inherited port term is used to group policies and bind them to context. A different term would be more obvious.
Policy group binding (PGB) or even the proposed FPG are ok, though I am a bit puzzled why Flow appears in here.

marco


-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Donnerstag, 29. Dezember 2016 03:31
To: Charlie Perkins
Cc: dmm@ietf.org
Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt]

Hi Charlie,

First, thank you for raising this point to be discussed. I second that it needs to be more intuitive.



I am in the process of reviewing the FPC document.  It is an important document and will be foundational for subsequent work in [dmm].

Yep, I really appreciate that you see this draft as a foundation for further works.



 I would like to suggest a change in terminology.  I think the way "Port" is currently defined in the document is very confusing, because it is not very intuitively related to the traditional uses of "port" as in TCP, or in switches.

Right. The coauthors had discussed this point many times but, me at least, couldn’t figure out more appropriate term instead of that so far...



As I understand it, "Policy" lives on the control plane side of the interface, and "Port" is intended to denote a concept that is important on the data plane side of the interface.

If you mean “control plane” as abstracted data-plane model in FPC agent,  I think that both “Policy” and “Port” exist on the control plane. In the current version of draft, Port is defined as “A set of forwarding policies.”



 "Flow" is another word that is closely tied to the data plane, and it seems to me that as currently defined in the document a "Port" is a collection of flows that correspond to a specific Policy or Policy Group.

For me, “Flow” seems not to exactly indicate specific policy applied flow. It could indicate flow(s) which just have same characteristics in natural. 



So, I would like to propose that the word "Port" should be replaced by the term "Flow Group".  Another alternative would be "Flow Policy Group", which could then be abbreviated FPG. However, the latter has the perhaps undesirable effect of tying the word "Policy" to a data-plane concept.

I think that the successor of port should keep same meaning of “A set of forwarding policies.” In that sense, FPG sounds make sense to me. 

in another aspect, we use Context as abstracted mobility session. I can see this as source of flow(s) and it looks already represent a group of those flows which are received and sent on each node. Attaching Context to a Port intends that applying a set of policies to a group of flows which are attributed to the context.



Thanks for any comments on this proposal to modify the terminology.

I think it is important to make the terminology as unambiguous and intuitive as we possibly can, especially because the document is necessarily written at a high level of abstraction.


Yes, I fully agree with you, let’s keep the discussion.



Regards,
Charlie P.

Best regards,
--satoru


_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

--------------67EB4D712ED041D3463195AA-- From nobody Wed Jan 25 21:32:30 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B09B9129482; Wed, 25 Jan 2017 21:32:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148540874871.6323.12743661275979122801.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2017 21:32:28 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-hnprenum-05.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 05:32:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : Home Network Prefix Renumbering in PMIPv6 Authors : Zhiwei Yan Jong-Hyouk Lee Xiaodong Lee Filename : draft-ietf-dmm-hnprenum-05.txt Pages : 9 Date : 2017-01-25 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 HNP renumbering is proposed, as an update of the PMIPv6 specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-hnprenum-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 27 10:12:19 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 778C41296B6; Fri, 27 Jan 2017 10:12:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148554073645.17815.11291851951742751727.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 10:12:16 -0800 Archived-At: Cc: Dapeng Liu , dmm-chairs@ietf.org, dmm@ietf.org, draft-ietf-dmm-hnprenum@ietf.org Subject: [DMM] Last Call: (Home Network Prefix Renumbering in PMIPv6) to Proposed Standard X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 18:12:16 -0000 The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'Home Network Prefix Renumbering in PMIPv6' as Proposed Standard 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 2017-02-10. 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 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 HNP renumbering is proposed, as an update of the PMIPv6 specification. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jan 27 11:10:19 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688B212971E; Fri, 27 Jan 2017 11:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DWfNnjPR4zQ; Fri, 27 Jan 2017 11:10:12 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0CC129715; Fri, 27 Jan 2017 11:10:09 -0800 (PST) X-AuditID: c6180641-e87ff70000000a0b-d2-588b46a1b0b2 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 4B.1C.02571.1A64B885; Fri, 27 Jan 2017 14:09:56 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Fri, 27 Jan 2017 14:10:04 -0500 From: Suresh Krishnan To: "Dhananjay Patki (dhpatki)" , Ralph Droms , "int-dir@ietf.org" Thread-Topic: [Int-dir] Review of draft-ietf-dmm-lma-controlled-mag-params-02 Thread-Index: AQHSeND2RE5BgS32fESeyuUlVFmeUg== Date: Fri, 27 Jan 2017 19:10:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLrHT3eJW3eEwcy7ChYPbp5gt7j/qMbi zIcnLBaPrnSzWDRe62N1YPWY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfG+o4m1 oEelomF6QgPjFOUuRk4OCQETiR2P29m7GLk4hATWM0r8P9jOBuEsZ5RouvuUDaSKDahqw87P TCAJEYFGRolrfWfBHGaBaYwSU5c+BKsSFvCReLlzASuILSLgK/Hm6TV2CFtPYt2734wgNouA qsT/NbeZQGxeAXuJ5rd/mUFsRgExie+n1oDFmQXEJW49mc8EcZ+AxJI955khbFGJl4//gc0X BZq58cI0doi4ksTH3/OBbA6gXk2J9bv0IUxriZP3aiAmKkpM6X7IDrFVUOLkzCcsExhFZyFZ NguheRZC8ywkzbOQNC9gZF3FyFFaXJCTm25kuIkRGEfHJNgcdzDu7fU8xCjAwajEw2ug0R0h xJpYVlyZe4hRgoNZSYS3Ph8oxJuSWFmVWpQfX1Sak1p8iFGag0VJnPd6yP1wIYH0xJLU7NTU gtQimCwTB6dUA2Po4x0WPV0sjNyRN5dcZ3ye9jtuW+iBztq/fXkdHIoXfCKXLZnyfU/SLT8f n5Sknkj2Kua/WXKHrpvn5XIyKibvMfm+u6Vbk3F631WmBR2zfS4t80pI8dT7ol8k7+rBpltj /0BrN4/gv4dRHtzi5/+0FzJ8LeDnd9jl5HX3OsP114teMQsLKrEUZyQaajEXFScCABvT76Gf AgAA Archived-At: Cc: "dmm@ietf.org" , "draft-ietf-dmm-lma-controlled-mag-params.all@ietf.org" Subject: Re: [DMM] [Int-dir] Review of draft-ietf-dmm-lma-controlled-mag-params-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 19:10:14 -0000 SGkgRGhhbmFuamF5L2F1dGhvcnMsDQogIEFueSBwcm9ncmVzcyBvbiB0aGlzPyBJIHdvdWxkIGxp a2UgdG8gZ2V0IHRoaXMgbW92aW5nIHNvb24uDQoNClRoYW5rcw0KU3VyZXNoDQoNCk9uIDEyLzIy LzE2LCA0OjM1IEFNLCAiSW50LWRpciBvbiBiZWhhbGYgb2YgRGhhbmFuamF5IFBhdGtpIChkaHBh dGtpKSIgPGludC1kaXItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZGhwYXRraUBjaXNj by5jb20+IHdyb3RlOg0KDQogICAgSGVsbG8sDQogICAgDQogICAgVGhhbmtzIGZvciB0aGUgcmV2 aWV3LiBXZSB3aWxsIGFkZHJlc3MgdGhlIGNvbW1lbnRzIGFuZCBnZXQgYmFjayB3aXRoIGEgbmV3 IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KICAgIC0tDQogICAgUmVnYXJkcywNCiAgICBEaGFuYW5q YXkNCiAgICANCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206 IFJhbHBoIERyb21zIDxyZHJvbXMuaWV0ZkBnbWFpbC5jb20+DQogICAgRGF0ZTogV2VkbmVzZGF5 LCAyMSBEZWNlbWJlciAyMDE2IGF0IDExOjUxIFBNDQogICAgVG86ICJpbnQtZGlyQGlldGYub3Jn IiA8aW50LWRpckBpZXRmLm9yZz4NCiAgICBDYzogImRtbUBpZXRmLm9yZyIgPGRtbUBpZXRmLm9y Zz4sICJpZXRmQGlldGYub3JnIiA8aWV0ZkBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLWRtbS1sbWEt Y29udHJvbGxlZC1tYWctcGFyYW1zLmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtZG1tLWxtYS1j b250cm9sbGVkLW1hZy1wYXJhbXMuYWxsQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IFJldmlldyBv ZiBkcmFmdC1pZXRmLWRtbS1sbWEtY29udHJvbGxlZC1tYWctcGFyYW1zLTAyDQogICAgUmVzZW50 LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KICAgIFJlc2VudC1UbzogPGRocGF0a2lA Y2lzY28uY29tPiwgPHNndW5kYXZlQGNpc2NvLmNvbT4sIDxqb25naHlvdWtAc211LmFjLmtyPiwg PGZ1cWlhbzFAb3V0bG9vay5jb20+LCA8bHlsZS50LmJlcnR6QHNwcmludC5jb20+LCA8am91bmku bm9zcGFtQGdtYWlsLmNvbT4sIDxtYXhwYXNzaW9uQGdtYWlsLmNvbT4sIDxzdXJlc2gua3Jpc2hu YW5AZXJpY3Nzb24uY29tPiwgPHRlcnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmc+LCBEYXBlbmcgTGl1 IDxtYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4sIDxtYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4NCiAg ICBSZXNlbnQtRGF0ZTogV2VkbmVzZGF5LCAyMSBEZWNlbWJlciAyMDE2IGF0IDExOjUxIFBNDQog ICAgDQogICAgUmV2aWV3ZXI6IFJhbHBoIERyb21zDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkg d2l0aCBJc3N1ZXMNCiAgICANCiAgICBNYWpvciBpc3N1ZXM6ICBOb25lDQogICAgDQogICAgTWlu b3IgaXNzdWVzOg0KICAgIA0KICAgIFRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQgaXMgZmFpcmx5IHNpbXBsZS4gIEkNCiAgICByZWNvbW1lbmQgdGhhdCB0aGUgc3BlY2lm aWMgc2VtYW50aWNzIG9mIHRoZSB1c2Ugb2YgdGhlIHBhcmFtZXRlcg0KICAgIG9wdGlvbnMgc2hv dWxkIGJlIGV4cGxhaW5lZCB3aXRoIGdyZWF0ZXIgY2xhcml0eSB0byBlbnN1cmUgY29ycmVjdCBh bmQNCiAgICBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4gIEZvciBleGFtcGxlLCBJIGZv dW5kIHRoZSBkZXNjcmlwdGlvbg0KICAgIG9mIExNQSBiZWhhdmlvciBpbiBzZWN0aW9uIDUuMSB0 byBiZSBxdWl0ZSBjb252b2x1dGVkIGFuZCBjb25mdXNpbmcuIA0KICAgIFB1dHRpbmcgdGhlICJp Zi4uLnRoZW4uLi5lbHNlIiBjb25zdHJ1Y3QgaW4gdHdvIGJ1bGxldHMgc2VlbWVkIG9idHVzZS4N CiAgICAgSW4gdGhlIGZpcnN0IGJ1bGxldCwgdGhlIExNQSAiU0hPVUxEIGluY2x1ZGUiIHRoZSBz dWItb3B0aW9uLiAgQXJlDQogICAgdGhlcmUgY2lyY3Vtc3RhbmNlcyB1bmRlciB3aGljaCB0aGUg TE1BIHdvdWxkIG5vdCBpbmNsdWRlIHRoZQ0KICAgIHN1Yi1vcHRpb24gYW5kLCBpZiBzbywgd2hh dCBhcmUgdGhvc2UgY2lyY3Vtc3RhbmNlcz8gIENhbiB0aGUgTE1BDQogICAgZGVjaWRlLCBwZXJo YXBzIGZvciBlZmZpY2llbmN5LCB0byByZXR1cm4gdGhlIHN1Yi1vcHRpb24gaW4gb25seSwgc2F5 LA0KICAgIG9uZSBvZiB0ZW4gcmVzcG9uc2VzIHRvIHRoZSBNQUc/DQogICAgDQogICAgSXMgdGhl cmUgYSBzcGVjaWZpYyByZWFzb24gZm9yIGVuY29kaW5nIHRoZSBMQU0gQ29udHJvbGxlZCBNQUcg U2Vzc2lvbg0KICAgIFBhcmFtZXRlcnMgYXMgc3ViLW9wdGlvbnMgdW5kZXIgdGhlIExBTS1Db250 cm9sbGVkLU1BRy1QYXJhbWV0ZXJzDQogICAgb3B0aW9uPyAgV2lsbCBhZGRpdGlvbmFsIHN1Yi1v cHRpb25zIGJlIGRlZmluZWQgaW4gdGhlIGZ1dHVyZT8NCiAgICANCiAgICBFZGl0b3JpYWwgaXNz dWVzLg0KICAgIA0KICAgIEZvciBjbGFyaXR5LCB0aGUgZG9jdW1lbnQgc2hvdWxkIHVzZSBhY3Jv bnltcyBhbmQgbmFtZXMgZm9yIHN5c3RlbQ0KICAgIGNvbXBvbmVudHMgaW4gYSBjb25zaXN0ZW50 IHdheTogdXNlIGFjcm9ueW1zIHRocm91Z2hvdXQgYW5kIGV4cGFuZCB0aGUNCiAgICBhY3Jvbnlt IG9uIGZpcnN0IHVzZS4gIEZvciBleGFtcGxlLCBMTUEgYW5kICJsb2NhbCBtb2JpbGl0eSBhbmNo b3IiDQogICAgYXJlIHVzZWQgaW50ZXJjaGFuZ2VhYmx5IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50 LCB3aGljaCB0aGlzIHJldmlld2VyDQogICAgZm91bmQgdG8gYmUgZGlzdHJhY3RpbmcuDQogICAg DQogICAgV2hhdCBpcyB0aGUgZXhwYW5zaW9uIGZvciAiUEJVIj8NCiAgICANCiAgICBUaGUgdXNl IG9mIHRoZSAiQ29uZmlndXJhdGlvbiBWYXJpYWJsZXMiIGRlZmluZWQgaW4gc2VjdGlvbiA0IGlz DQogICAgcmVwZWF0ZWQgaW4gc2VjdGlvbiA1LjEuICBUbyBhdm9pZCBpbnRlcm5hbCBpbmNvbnNp c3RlbmN5LCBJIHJlY29tbWVuZA0KICAgIHRoYXQgdGhlIHVzZSBvZiB0aGUgdmFyaWFibGUgYmUg ZGVzY3JpYmVkIG9ubHkgb25jZSwgd2l0aCBpbnRlcm5hbA0KICAgIHBvaW50ZXJzIHRvIHRoYXQg dGV4dCBmcm9tIG90aGVyIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQuDQogICAgDQogICAgSW4gc2Vj dGlvbiA2LCBpdCB3b3VsZCBoZWxwIHRoZSByZWFkZXIgdG8gaW5jbHVkZSB0aGUgbmFtZSBvZiB0 aGUNCiAgICByZWdpc3RyeSB0byBiZSBtb2RpZmllZCBpbiB0aGUgZmlyc3QgYnVsbGV0LiAgDQog ICAgDQogICAgDQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBJbnQtZGlyIG1haWxpbmcgbGlzdA0KICAgIEludC1kaXJA aWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1k aXINCiAgICANCg0K From nobody Sun Jan 29 05:11:11 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AE212943E; Sun, 29 Jan 2017 05:11:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148569546522.24456.4029906086792954016.idtracker@ietfa.amsl.com> Date: Sun, 29 Jan 2017 05:11:05 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-10.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 13:11:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management of the IETF. Title : On Demand Mobility Management Authors : Alper Yegin Danny Moses Kisuk Kweon Jinsung Lee Jungshin Park Seil Jeon Filename : draft-ietf-dmm-ondemand-mobility-10.txt Pages : 15 Date : 2017-01-29 Abstract: Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account in selectively providing IP session continuity and IP address reachability on a per- socket basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 29 06:16:21 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF470129507 for ; Sun, 29 Jan 2017 06:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.255 X-Spam-Level: X-Spam-Status: No, score=-11.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSgrfAwIiQEG for ; Sun, 29 Jan 2017 06:16:18 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA101294E3 for ; Sun, 29 Jan 2017 06:16:18 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 29 Jan 2017 06:16:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.33,306,1477983600"; d="scan'208,217"; a="36996046" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 29 Jan 2017 06:16:16 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 29 Jan 2017 06:16:15 -0800 Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 29 Jan 2017 06:16:15 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.151]) by hasmsx108.ger.corp.intel.com ([169.254.9.175]) with mapi id 14.03.0248.002; Sun, 29 Jan 2017 16:16:12 +0200 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: New version for the On-Demand draft: draft-ietf-dmm-ondemand-mobility-10 Thread-Index: AdJ6OeToSE3AyAbBTEquWg6a3MNYXw== Date: Sun, 29 Jan 2017 14:16:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134ABFD6FHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] New version for the On-Demand draft: draft-ietf-dmm-ondemand-mobility-10 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 14:16:20 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134ABFD6FHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I have uploaded a new version including the text changes and usage example = according to the comments received on the list. I am planning to discuss two final topics during IETF98 and hopefully we ca= n resume WGLC and release the draft. Any comments? Thanks, Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134ABFD6FHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,

 

I have uploaded a new version including the text cha= nges and usage example according to the comments received on the list.=

I am planning to discuss two final topics during IET= F98 and hopefully we can resume WGLC and release the draft.

 

Any comments?

 

Thanks,

Danny

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134ABFD6FHASMSX106gercor_-- From nobody Tue Jan 31 01:03:54 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC66A126D74 for ; Tue, 31 Jan 2017 01:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3usfft088FO for ; Tue, 31 Jan 2017 01:03:50 -0800 (PST) Received: from mailer2.neclab.eu (mailer2.neclab.eu [195.37.70.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F45126D73 for ; Tue, 31 Jan 2017 01:03:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer2.neclab.eu (Postfix) with ESMTP id 0868BC1CF4; Tue, 31 Jan 2017 10:03:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (neclab.eu) Received: from mailer2.neclab.eu ([127.0.0.1]) by localhost (atlas-b.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW0m3HUu-0yU; Tue, 31 Jan 2017 10:03:47 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer2.neclab.eu (Postfix) with ESMTPS id CFB07C1CF2; Tue, 31 Jan 2017 10:03:41 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.182]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0319.002; Tue, 31 Jan 2017 10:03:41 +0100 From: Marco Liebsch To: Charlie Perkins Thread-Topic: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] Thread-Index: AQHSYXuaMAvGZyKnl0uR0QDAbxChR6E8euewgA0O5wCACPUQaQ== Date: Tue, 31 Jan 2017 09:03:41 +0000 Message-ID: <7FD7719B-8F2E-4EFD-9ABD-F272DD016784@neclab.eu> References: <147793286841.32501.6238148222555288408.idtracker@ietfa.amsl.com> <715d6603-f939-7d21-b6ae-b1a7e435b8d2@earthlink.net> <69756203DDDDE64E987BC4F70B71A26DAF06C624@PALLENE.office.hd>, <116dd8b8-ac89-5e9b-1c3e-eb92371b8f98@earthlink.net> In-Reply-To: <116dd8b8-ac89-5e9b-1c3e-eb92371b8f98@earthlink.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7FD7719B8F2E4EFD9ABDF272DD016784neclabeu_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 09:03:53 -0000 --_000_7FD7719B8F2E4EFD9ABDF272DD016784neclabeu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Charlie, If we keep the port term, your proposal is very good. I support the adoptio= n of the vport term. Thanks and best regards, Marco On 25 Jan 2017, at 19:14, Charlie Perkins > wrote: Hello Marco, What would you think about replacing the term "port" by "virtual port", whi= ch would usually be shortened to "vport" (or "Vport")? I think it would have several benefits: * it seems intuitively appealing, at least to me * it avoids the unacceptable clash with the traditional meanings of the= word "port" * it fits well with my understanding of "data-plane node" and "context"= . * it's a relatively easy editorial change to the draft Regards, Charlie P. On 1/17/2017 1:05 AM, Marco Liebsch wrote: The meaning of port changed throughout the evolution of this draft. Up to v= ersion 3 a port was a forwarding construct that binds traffic selectors to traffic treatment acti= ons. Any other term, e.g. rule, could have made it. These are created (attach), modified (handov= er) or deleted per the mobile node's location, IP address, etc. >From version 4, what has been a port before is now more the 'context' struc= ture, whereas the inherited port term is used to group policies and bind them to context.= A different term would be more obvious. Policy group binding (PGB) or even the proposed FPG are ok, though I am a b= it puzzled why Flow appears in here. marco -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima Sent: Donnerstag, 29. Dezember 2016 03:31 To: Charlie Perkins Cc: dmm@ietf.org Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-= cpdp-05.txt] Hi Charlie, First, thank you for raising this point to be discussed. I second that it n= eeds to be more intuitive. I am in the process of reviewing the FPC document. It is an important docu= ment and will be foundational for subsequent work in [dmm]. Yep, I really appreciate that you see this draft as a foundation for furthe= r works. I would like to suggest a change in terminology. I think the way "Port" i= s currently defined in the document is very confusing, because it is not ve= ry intuitively related to the traditional uses of "port" as in TCP, or in s= witches. Right. The coauthors had discussed this point many times but, me at least, = couldn=92t figure out more appropriate term instead of that so far... As I understand it, "Policy" lives on the control plane side of the interfa= ce, and "Port" is intended to denote a concept that is important on the dat= a plane side of the interface. If you mean =93control plane=94 as abstracted data-plane model in FPC agent= , I think that both =93Policy=94 and =93Port=94 exist on the control plane= . In the current version of draft, Port is defined as =93A set of forwardin= g policies.=94 "Flow" is another word that is closely tied to the data plane, and it seem= s to me that as currently defined in the document a "Port" is a collection = of flows that correspond to a specific Policy or Policy Group. For me, =93Flow=94 seems not to exactly indicate specific policy applied fl= ow. It could indicate flow(s) which just have same characteristics in natur= al. So, I would like to propose that the word "Port" should be replaced by the = term "Flow Group". Another alternative would be "Flow Policy Group", which= could then be abbreviated FPG. However, the latter has the perhaps undesir= able effect of tying the word "Policy" to a data-plane concept. I think that the successor of port should keep same meaning of =93A set of = forwarding policies.=94 In that sense, FPG sounds make sense to me. in another aspect, we use Context as abstracted mobility session. I can see= this as source of flow(s) and it looks already represent a group of those = flows which are received and sent on each node. Attaching Context to a Port= intends that applying a set of policies to a group of flows which are attr= ibuted to the context. Thanks for any comments on this proposal to modify the terminology. I think it is important to make the terminology as unambiguous and intuitiv= e as we possibly can, especially because the document is necessarily writte= n at a high level of abstraction. Yes, I fully agree with you, let=92s keep the discussion. Regards, Charlie P. Best regards, --satoru _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_7FD7719B8F2E4EFD9ABDF272DD016784neclabeu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Charlie,

If we keep the port term, your proposal is v= ery good. I support the adoption of the vport term.

Thanks and best regards,
Marco


On 25 Jan 2017, at 19:14, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Marco,

What would you think about replacing the term "port" by "= virtual port", which would usually be shortened to "vport" (= or "Vport")?

I think it would have several benefits:

  • it seems intuitively appealing, at least to me
  • it avoids the u= nacceptable clash with the traditional meanings of the word "port"= ;
  • it fits well with my understanding of "data-plane node" = and "context".
  • it's a relatively easy editorial change t= o the draft

Regards,
Charlie P.


On 1/17/2017 1:05 AM, Marco Liebsch wrote: 
The meaning of port changed throughout the evolution of this=
 draft. Up to version 3 a port was a
forwarding construct that binds traffic selectors to traffic treatment acti=
ons. Any other term,
e.g. rule, could have made it. These are created (attach), modified (handov=
er) or deleted per
the mobile node's location, IP address, etc.

>From version 4, what has been a port before is now more the 'context' struc=
ture, whereas
the inherited port term is used to group policies and bind them to context.=
 A different term would be more obvious.
Policy group binding (PGB) or even the proposed FPG are ok, though I am a b=
it puzzled why Flow appears in here.

marco


-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Donnerstag, 29. Dezember 2016 03:31
To: Charlie Perkins
Cc: dmm@=
ietf.org
Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-iet=
f-dmm-fpc-cpdp-05.txt]

Hi Charlie,

First, thank you for raising this point to be discussed. I second that it n=
eeds to be more intuitive.



I am in the process of reviewing the FPC document.  It is an=
 important document and will be foundational for subsequent work in [dmm].

Yep, I really appreciate that you see this draft as a founda=
tion for further works.



 I would like to suggest a change in terminology.  I think t=
he way "Port" is currently defined in the document is very confus=
ing, because it is not very intuitively related to the traditional uses of =
"port" as in TCP, or in switches.

Right. The coauthors had discussed this point many times but=
, me at least, couldn=92t figure out more appropriate term instead of that =
so far...



As I understand it, "Policy" lives on the control =
plane side of the interface, and "Port" is intended to denote a c=
oncept that is important on the data plane side of the interface.

If you mean =93control plane=94 as abstracted data-plane mod=
el in FPC agent,  I think that both =93Policy=94 and =93Port=94 exist on th=
e control plane. In the current version of draft, Port is defined as =93A s=
et of forwarding policies.=94



 "Flow" is another word that is closely tied to th=
e data plane, and it seems to me that as currently defined in the document =
a "Port" is a collection of flows that correspond to a specific P=
olicy or Policy Group.

For me, =93Flow=94 seems not to exactly indicate specific po=
licy applied flow. It could indicate flow(s) which just have same character=
istics in natural.=20



So, I would like to propose that the word "Port" s=
hould be replaced by the term "Flow Group".  Another alternative =
would be "Flow Policy Group", which could then be abbreviated FPG=
. However, the latter has the perhaps undesirable effect of tying the word =
"Policy" to a data-plane concept.

I think that the successor of port should keep same meaning =
of =93A set of forwarding policies.=94 In that sense, FPG sounds make sense=
 to me.=20

in another aspect, we use Context as abstracted mobility session. I can see=
 this as source of flow(s) and it looks already represent a group of those =
flows which are received and sent on each node. Attaching Context to a Port=
 intends that applying a set of policies to a group of flows which are attr=
ibuted to the context.



Thanks for any comments on this proposal to modify the termi=
nology.

I think it is important to make the terminology as unambiguous and intuitiv=
e as we possibly can, especially because the document is necessarily writte=
n at a high level of abstraction.


Yes, I fully agree with you, let=92s keep the discussion.



Regards,
Charlie P.

Best regards,
--satoru


_______________________________________________
dmm mailing list
dmm@ietf=
.org
https://www.ietf.org/mailman/listinfo/dmm

--_000_7FD7719B8F2E4EFD9ABDF272DD016784neclabeu_-- From nobody Tue Jan 31 05:55:47 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA9D129F1B for ; Tue, 31 Jan 2017 05:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd38ddUgEy-H for ; Tue, 31 Jan 2017 05:55:40 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A160129F17 for ; Tue, 31 Jan 2017 05:55:37 -0800 (PST) Received: from DM2PR0501CA0029.namprd05.prod.outlook.com (10.162.29.167) by DM5PR05MB3115.namprd05.prod.outlook.com (10.173.219.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 31 Jan 2017 13:55:35 +0000 Received: from BY2NAM01FT023.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::200) by DM2PR0501CA0029.outlook.office365.com (2a01:111:e400:5148::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5 via Frontend Transport; Tue, 31 Jan 2017 13:55:35 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2NAM01FT023.mail.protection.outlook.com (10.152.69.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Tue, 31 Jan 2017 13:55:34 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v0VDpTLj009328; Tue, 31 Jan 2017 07:55:33 -0600 Received: from plswe13m04.ad.sprint.com (plswe13m04.corp.sprint.com [144.229.214.23]) by plsapdm2.corp.sprint.com with ESMTP id 28a5sv69gs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Jan 2017 07:55:33 -0600 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m04.ad.sprint.com (2002:90e5:d617::90e5:d617) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 07:55:32 -0600 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 07:55:32 -0600 From: "Bertz, Lyle T [CTO]" To: Marco Liebsch , Charlie Perkins Thread-Topic: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] Thread-Index: AQHSYXuWs6AH4ZKeOE+IDKdn8YYJVKE8400AgA0b2gCACORMgP//7O4g Date: Tue, 31 Jan 2017 13:55:31 +0000 Message-ID: References: <147793286841.32501.6238148222555288408.idtracker@ietfa.amsl.com> <715d6603-f939-7d21-b6ae-b1a7e435b8d2@earthlink.net> <69756203DDDDE64E987BC4F70B71A26DAF06C624@PALLENE.office.hd>, <116dd8b8-ac89-5e9b-1c3e-eb92371b8f98@earthlink.net> <7FD7719B-8F2E-4EFD-9ABD-F272DD016784@neclab.eu> In-Reply-To: <7FD7719B-8F2E-4EFD-9ABD-F272DD016784@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.22] Content-Type: multipart/alternative; boundary="_000_fc554c11297e4ecdbb1481f0cbfa7995plswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(7916002)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(2980300002)(438002)(51444003)(24454002)(13464003)(199003)(377454003)(189002)(54896002)(33646002)(606005)(106116001)(106466001)(790700001)(102836003)(3846002)(53936002)(260700001)(6306002)(2906002)(108616004)(230783001)(6116002)(5001770100001)(5250100002)(54356999)(8666007)(236005)(4326007)(76176999)(50986999)(2900100001)(93886004)(24736003)(97736004)(5890100001)(189998001)(2950100002)(356003)(7736002)(7906003)(8936002)(92566002)(345774005)(81156014)(8676002)(626004)(4546004)(84326002)(81166006)(5660300001)(86362001)(229853002)(512954002)(68736007)(38730400001)(7696004)(561944003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3115; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT023; 1:fOZ+wvCVNMM6rwP+OjdyAprb6XGbeNKT6EcRHGRwNfuW0kOq4zq4a8zG4CqsaKlnEjA/0DiSGvm7nCzGETE0RABsOJFIx8ho+Vzav8w8BlZl/eOSJ0Ej6nP66C2UT+4DVMMKqenbTQIvpjpJWcjXwx2HXEi3GN1gJrfMaJK6a7Nz/F2X9godO04BpEFEcK0mCNY/W7M1Vrl0iMIzvisBlJAFErlKH94XArAdwW/7EgrO+4PPDuynuWA4cUFvJKsHk3HnFt5E13qvtTe18TrKD0OWSWFJm1wrPuD62A4E4xJXmINcDJDvVtm/UjAT0LvBSk4tgyhkisiNcvpgkWeqWqYmpwYoCSolnYGvBmvDzb20zgQg6q9CeQnEhKcS8PnRUIPjACkwK37GBVyZx0S1woRANshXmLiugbW81TpWdo/zXhbj+uJAhT5ezUF4CaoeKh7/JY/RJd1TpdknjeMNlnAQRZJokfua5lfAMc/XBD52HjuOMp4IODJ7mxMd9Ykir4g2UBOaf61oHcB+6/oeLZBJ/36oG6ZZ1LYRDS/PT/ZUDpfY4QRLDbNTB9S8gfd4s8xB+r90di72cnzqw3IADqQWKyizFTYS2qCISzH0nXEWbwBnydJQrQdnZ7OLS7pp X-MS-Office365-Filtering-Correlation-Id: 5a7b13c8-c365-4d06-13c6-08d449e0d443 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:DM5PR05MB3115; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3115; 3:8UZK+XBTi9qLZIfk3+80P5LcOZipYxdkOBsYLzdmBhr7zQmJtqJELRg82GGNA09GYqfr58kOnHMz0g13F2ppJrDYu3qJxOG0lVD/ijg54Qyun3tffqea2VcL2XEeElVAfVAGK6zefMqtfIP+vHWYEDx+hTEZ5UtYqZW6OL8dFCLMBMKT5V/YWsCBEbPNxICW7BssMqFN4jiYEcVb0Gos1hznPtBPYPtkBNjf5yCpMGorBM9uu3y1lU2xtEFC959bsQZj8qg4GUgqFFob5E+r2M82ke7eR+Or8S+Df9bVXLsSwmtmQzvi2oz0OviViSKH4G4PcSlzLB2qJB71+Qksc7RY60Iv5NMjBB2OvqiTtd0aHhQP11MlRWo+7KwAvlCWbjvSRgWLOEOBRJhfdseDWA==; 25:B2afUSbrsc50nbxN8sNQQKz3vgaWsx/pxYtLzUBTX9fGmK+rsjR8QkYtkx3ezjnbqSA/JYzDLQcSm5VucdMWSP50fiZPSSgbtJ5louVISzgjiHWuBjZ6gr58ezHAR9351DKKNuPcWtMdhTlRiQZasFDzr1g4hbbiTd4HJR1PXZrJzT5nDYQLMd9inCxj8F+E9ybdrATol/n6Js9s4dMaYCpdHk9wvhJI+bOvnFV9wdCopkXdV9DkDz+r5xD0/xOsjE4F1hZsFshKBX7ukiG2xy7TBtnuA1CWIM/akM8QFRRwI19a20wh3cjTmLUYZvhRHqHH3ZflUw0LSHnMfLglEeMp2yfjJV5enEBQPU9nyVZlNJ08etSKh92b2TJSFgNkveEhey5YhBRsnACOlReBPFs2OIe3XK/FlzOz7uTI+m3gVK3xiGqOxa41fFvUKIG4wCY3ptKuYUiTE7JdgoE0RQ== X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3115; 31:DbsrzoduycEDtl8lksTV0Rc0OLh7Uu3go53WdHuT8Q3qNfCxWKPQtoLQPDFRSLi6+IGZLUrtqGa533hvOQoDyjQsXFBgKs/Jd3WR5NpjS6S2uWpOubujpj1WzdYtfwQZZQwJR+V1J1GSugy5JRyu8wd21Mjvq5SLwLowo7ttXVcrjm+NXEBb9k/IJuvy3EYYoJFe3E+S34TNhZGv/zWYl1vOwrDq43rZIWWWmFCS30W6RAVhV+zJxm9S02WqwAj+pGuowewKvY4y+82/oPt60g==; 20:W7zuZNy7T7R7GmCFQfm/B2QiXEKlgFjK8s3rS1vVdKkz1jRxxaa7ewYVWfttJwfSFjPtMT49LhR8g+ECLgnqtsts9H0gLGr47kjLZ4hcoEQb/pSiIdwxrmwwLtQfIaUsFOg3C9IeRtZJtI13ORT+9WPGo7Hpr+9Gyk1aIJ5oK2tEflSnmwBeo5QXwhDMB4j2pO78Bcag9ViPT79VUyDhgVmnLEtto7rqpVepkGa0hdAVIyJSIIBLAdFRwBpPNSIuArOSvcOWVhb8YH9UcyZ5ZwpWdG3TRQB0cNyTm6p45SH/M3Sc2+vq6FaoHKI0FqiRNdEZz7o67l3J0WJiy8zKULC3qzUL1c5Z8R6IamALTsKV9HSK1gJzNa8WsI/keaqKtnC5ve/Nry3Cpa46XlJv9I6W76BMkH21RCB1IYFsEm/QuA/9i5uFaKTdvyeumkXpQ/3X/c6103FFSpcpguAIoI5Qmy1UgdIQX3luDQgf23Dawix8YfgU56a6PJnb+teB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(226508931237476)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(13023025)(8121501046)(13024025)(13017025)(13018025)(13015025)(3002001)(10201501046)(6055026)(6041248)(20161123558021)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DM5PR05MB3115; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3115; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3115; 4:cMDADlo9DPQ+S0jXdcQo3ihavk7a9hkqf53dGBpXLzTxd3wXv7ero7Rfm+HUN7SnV/BdAsl03zgKRQNiEN8LlNLoXbdg8c4Se2suw5rQfAfSchvpxXdTjamefJ/68S2NDDs7Rse2MYFInRCf+v7l3eQovZaaYdJQ+mh//xKoE9iMKzKhLdELGRBvTvxvMlUYFKsje5WUfm+yHSweCxI3NA3LqECD0lI4p7Xw30m+QHKSCCoeyGvIWeWVvJ6Y5u47R4Vxm1ILAsRH0AxSC3N1agXm3qWv399p8Semaht61BqCwLiQukL38tsx9ilw6sZXrGWu97n/9ufAd5Ngo1EUztwlEieL9VayuZhJsFjoNhSSZTPNKftqH3jy+E9xzZPQtw/D4cAHnU0RoNhHuaxvss7sELyaO8YmY4GQHlNJDNRSU3rIzCRico79/mwOA1bKFXRMOpRZcDe3SvmYHSdgP8RQHZDa1JlU83tU3RgyrgmVgGDe0X0d+il2fNKLIEdpWd6d5RYcIx5tikw4sYp7ta+NIPTwedO4xbEwDsLyGBb3hFVsxPfCVm/nEusBd3tUBto60cWU+3wPm3RylJR/oFaJfX/RN54lz4Vt9dD3WpaURKHq0mxx+Gmf3ed9VmY3RLlJE19TnB+FoOKIWiICegBsHvPSQe7UE6byOEM3VHGlmQFKjlaE/k7UKhw8rJsyrV8jfwPTDTBhsMMvrCIr9xrUI+ZA1Em1jIAqRZbcP+5VZ68bzAvgKtyqVyGoHbefJoYc5LZDZY8aChgQJ8KbwjtZG8sAsl0aPG0Z5Ng1HfY= X-Forefront-PRVS: 0204F0BDE2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3115; 23:MsGB5//xeyW1qQ8L186Y05YiU3cqUIusSAGLlvYbg?= =?us-ascii?Q?jNgto2pyPLPSDrxkp1CgDbA6sf6PunhsnV4Hx85upP9ZFnJ18dPSejklZTlD?= =?us-ascii?Q?LOXiPuhxbqoog7buNUJue6BLh62y1hM6lPubzkiHohQXFxur7YiqiNspVZaY?= =?us-ascii?Q?hLwZh5DQuSasqt1yvMHfZ3f0k4gy6Xhx0VDH0LgkdEM23DOAWdGfmRGoUZjp?= =?us-ascii?Q?1yxT16knn7iZLyMuO9WIiqY2Dv2+JDMlwoEVpPdvdtO/AcnzipnrYKotWVyS?= =?us-ascii?Q?25Ddwh2mBWv02nuG4CTsVDndRLG9W8CFUqhgLKPRYsNT57CFoTKzeNPQmgzI?= =?us-ascii?Q?Egr9wZAI9oHOXIb97HZJgq0qQLayhF8tC5KawaIR7QxqrFMAL1k0o+b/XhI5?= =?us-ascii?Q?3DpwhhJ0Lkupqd3S7+UCbJCUxU9BiyT2Hkj4JkQJcV52BKKOKw3M0noEMJAd?= =?us-ascii?Q?sswEWwlcbi6O+K+0wlVbz7t3tgZf2EJYN/m/iWPgUZwhwpGOEqDbNVCRPRBy?= =?us-ascii?Q?IRlkmUk+DEikWeeRsA9CXYFLl2S0sTSSq8u82exedAUrANx1+r4hKU5pYpBI?= =?us-ascii?Q?gt8kxjpJczY72sAjU3mw7gVKQBOim1dq4zqK0HnhebdMIoAxryM7elCXs8VU?= =?us-ascii?Q?uh4VjYI3hodrDRgI+t6qOOMRbqd4jQtIDMtPPoravVcXLCpDvGopAWHNbGDb?= =?us-ascii?Q?B3+9ZoI3nIObcJzdkXJgsYbyOZiq+Ay7oNPLLymZsybms96tnff4vSZghrU3?= =?us-ascii?Q?+hA81g+bEG+RQXRzsMr/fnXwRavFLuKA8ZgFGLlm6W+Zco7P7slw1eg0RkyS?= =?us-ascii?Q?6gvHbsVM2gBxz1bf9/KFok1+Y77blqBmm/TnJ/MdoCDwefX6Xti04LNTqJ55?= =?us-ascii?Q?UdkHwW1y9/PRUc/QF6LFoWC9TKo2l8T20mGPRDkKwjhkgMDYJtAtXjA9yihp?= =?us-ascii?Q?KWQr/+VVLnd+s7REOdjojcdQJw1IYyoWqZwVEsCS2AVV2tt5d7x5wr/NR3uf?= =?us-ascii?Q?EOKKbBKFiBChxk092ZMmoTjamIuYHyFY9Yn7meDcBENAYHjCPaqTBnc4Xe8j?= =?us-ascii?Q?9lAHPZmBShIEn4vSDOfQCO00DdQKYQDijDA/bJwttqbw/wGWXN9sUbAOC1H/?= =?us-ascii?Q?6Io9103OqcOVaGhUQs0oAeaE9iXFPouCUvG0v0IJm9oG+im5ceQWbKMCwQBM?= =?us-ascii?Q?yEi133MF81YJ/EkSncEqyDEtRefNCp+PI7Pfg4DVMp5ykZhBKfwoIZzuKJ4B?= =?us-ascii?Q?xBBatMK3My3E3NABOSnO9wHdiWH3Dag2AULmvwFK5F1Daq+ngbJMOnL4yyTG?= =?us-ascii?Q?txB2vQ3LA4aUbQ9K6ewXtFUjzVvBzX+r6DxJxvG8f7H0PWRhj2Q6HKRKUyfW?= =?us-ascii?Q?nDRlXA/qNhh9Hbb6hJZfx99K1ZeB2bPym4pBz0rbmE3YCV0O/cb6xuO6mbMY?= =?us-ascii?Q?1/XsbJNv2k3lwTPeDqkEz282GGFWxPgmVqw7GPQkmtDBE8vzi94+R8E+ONNW?= =?us-ascii?Q?nSfVaQNVSXF9fkPk483rDeYWQxCs8S09lX3FEPOYG+ezks9+EwtQOe0usRVS?= =?us-ascii?Q?N1IgDJytdBRVVpjctlw7WshnUqxExZvY8OkjKhummNj448UR3FxUhd52o4Ua?= =?us-ascii?Q?fh4rgHelZt27uSvTGFLyw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3115; 6:42ejDTfb+o2e/mT0wOEBRLem5PDbncAxA4JKShplA33wMau/IP8yalHTf67qbq8eR09DeJt8TSpJQ3ZAFGgOxFd8xRvVCFJ6nYGUp+Knh2mJHuH9wwZ9o4D/KxDvskmsUPaUhVl8iXPTQdGavij5aiFjqw04VLvrKRreqfoKhZHIkp88wxbiqpwMG3pKGj8/8LFvLd5wGz4RBXtruv08abM69ubkeFqWlddVujdhMw0OQm02LZirtI8v5v7hx7wIBh9mPcViTHj3SAnhHzjAP4qhZXvuiBPhrlF6pBTm3S+Gk9yggMB0TmHNfjJ1dYv5XPZNXSi5KA6PgClM1O9mPQukhhI0WQqA8v0tAwTVebkssuGezbPS2716Xxs/FZTq6TZRKYvE2XDyg2noo65Z223/iLoiq/jPdEKxc93El/K61ly5ACp7m7Ogg85eUsot; 5:KcjoyJ+9iErD39S7J9SEl6389Qejxq4zWCGdIKEP1T3R9iqi1jr0rXdntjkILHM7C9o8AJ/Om1ysIDt9mb9b18kAC2lTznpOiACuJtb7YOBSvH8pxEZIl7z6phry64OCc5moYviX+8P4F4OQxTrhhw==; 24:uvzmqgrEGQvhK6jMRDsqtWs9wq0Vainff/gzIBcZgCuwF8ZPamNbmMREfGii6PvjQ5ai6fzKm4QWruR0TkkPIOwQNDM1xvdNZrxsGIsdoDs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3115; 7:ute1EgpBzolHVYRTrQYeRFNDWbL8EedI5VFwdSrqbXzO+zFT4Zk8uYNtq9PVSX70sa3gpY9GVJCBatzIYtFAOgrq79abV6zyWJEiQyJwZw3CQya09ZmHFjBw+o3kZBteV7AmWZyl0+EPwYr4QGFr4Ab0+LhDdqD3BkDIVQhxeGLqRU9TFq/1wESur48mIXNM4KBXGvQBW4aXoI8Lpy9prs0b9YSpR9v4ut3m/M50VRRTaqOdUW43FcvnlMN/AT9nXZ8oOmBvvr7vhm6N+kOs0sOkL/neYak3wRNNZuqUjt43tDrBxe9/mtu8h4XyJnM0/LmFqDuGcZgmlrp0nk6+oy5cV9BR6AFR2olWJiQoIRJPdif9zX+eTShvl+xtKwvaHhMYZXpDiizz26Z61zzfHkts6xaTYa2GFPOkK7HFDXzg05Yy1oxyVO06/F3NowoJjb+hg3xpjMzMvhBExqLR5qyqVjSwJXmDVp+8oZmQNkRsewiQxuaCMZMv41DVwL7P98jmveMMn/XxfHY8/y3odzagHZTKFounWvQujkGTsOSt1dFlS+3dX3KvS1hUft66 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2017 13:55:34.6718 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3115 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 13:55:44 -0000 --_000_fc554c11297e4ecdbb1481f0cbfa7995plswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Tuesday, January 31, 2017 3:04 AM To: Charlie Perkins Cc: dmm@ietf.org Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-= fpc-cpdp-05.txt] Hello Charlie, If we keep the port term, your proposal is very good. I support the adoptio= n of the vport term. Thanks and best regards, Marco On 25 Jan 2017, at 19:14, Charlie Perkins > wrote: Hello Marco, What would you think about replacing the term "port" by "virtual port", whi= ch would usually be shortened to "vport" (or "Vport")? I think it would have several benefits: * it seems intuitively appealing, at least to me * it avoids the unacceptable clash with the traditional meanings of the= word "port" * it fits well with my understanding of "data-plane node" and "context"= . * it's a relatively easy editorial change to the draft Regards, Charlie P. On 1/17/2017 1:05 AM, Marco Liebsch wrote: The meaning of port changed throughout the evolution of this draft. Up to v= ersion 3 a port was a forwarding construct that binds traffic selectors to traffic treatment acti= ons. Any other term, e.g. rule, could have made it. These are created (attach), modified (handov= er) or deleted per the mobile node's location, IP address, etc. >From version 4, what has been a port before is now more the 'context' stru= cture, whereas the inherited port term is used to group policies and bind them to context.= A different term would be more obvious. Policy group binding (PGB) or even the proposed FPG are ok, though I am a b= it puzzled why Flow appears in here. marco -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima Sent: Donnerstag, 29. Dezember 2016 03:31 To: Charlie Perkins Cc: dmm@ietf.org Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-= cpdp-05.txt] Hi Charlie, First, thank you for raising this point to be discussed. I second that it n= eeds to be more intuitive. I am in the process of reviewing the FPC document. It is an important docu= ment and will be foundational for subsequent work in [dmm]. Yep, I really appreciate that you see this draft as a foundation for furthe= r works. I would like to suggest a change in terminology. I think the way "Port" i= s currently defined in the document is very confusing, because it is not ve= ry intuitively related to the traditional uses of "port" as in TCP, or in s= witches. Right. The coauthors had discussed this point many times but, me at least, = couldn't figure out more appropriate term instead of that so far... As I understand it, "Policy" lives on the control plane side of the interfa= ce, and "Port" is intended to denote a concept that is important on the dat= a plane side of the interface. If you mean "control plane" as abstracted data-plane model in FPC agent, I= think that both "Policy" and "Port" exist on the control plane. In the cur= rent version of draft, Port is defined as "A set of forwarding policies." "Flow" is another word that is closely tied to the data plane, and it seem= s to me that as currently defined in the document a "Port" is a collection = of flows that correspond to a specific Policy or Policy Group. For me, "Flow" seems not to exactly indicate specific policy applied flow. = It could indicate flow(s) which just have same characteristics in natural. So, I would like to propose that the word "Port" should be replaced by the = term "Flow Group". Another alternative would be "Flow Policy Group", which= could then be abbreviated FPG. However, the latter has the perhaps undesir= able effect of tying the word "Policy" to a data-plane concept. I think that the successor of port should keep same meaning of "A set of fo= rwarding policies." In that sense, FPG sounds make sense to me. in another aspect, we use Context as abstracted mobility session. I can see= this as source of flow(s) and it looks already represent a group of those = flows which are received and sent on each node. Attaching Context to a Port= intends that applying a set of policies to a group of flows which are attr= ibuted to the context. Thanks for any comments on this proposal to modify the terminology. I think it is important to make the terminology as unambiguous and intuitiv= e as we possibly can, especially because the document is necessarily writte= n at a high level of abstraction. Yes, I fully agree with you, let's keep the discussion. Regards, Charlie P. Best regards, --satoru _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_fc554c11297e4ecdbb1481f0cbfa7995plswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: dmm [mailto:dmm-bounces@ietf.o= rg] On Behalf Of Marco Liebsch
Sent: Tuesday, January 31, 2017 3:04 AM
To: Charlie Perkins <charles.perkins@earthlink.net>
Cc: dmm@ietf.org
Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action= : draft-ietf-dmm-fpc-cpdp-05.txt]

 

Hello Charlie,

 

If we keep the port term, your proposal is very good= . I support the adoption of the vport term.

 

Thanks and best regards,

Marco


On 25 Jan 2017, at 19:14, Charlie Perkins <charles.perkins@earthlink.net> wrote:=

Hello Marco,

What would you think about replacing the term "port" by "= virtual port", which would usually be shortened to "vport" (= or "Vport")?

I think it would have several benefits:

  • it seems intuitively appealing, at least to me
  • it avoids the unacceptable clash with the traditional meanings of the word = "port"
  • it fits well with my understanding of "data-plane node" and "= ;context".
  • it's a relatively easy editorial change to the draft

Regards,
Charlie P.

 

On 1/17/2017 1:05 AM, Marco Liebsch wrote:

The meaning of port changed throughout the evolution of this draft. Up=
 to version 3 a port was a
forwarding construct that binds traffic selectors to traffic treatment=
 actions. Any other term,
e.g. rule, could have made it. These are created (attach), modified (h=
andover) or deleted per
the mobile node's location, IP address, etc.
 
>From version 4, what has been a port before is now more the 'conte=
xt' structure, whereas
the inherited port term is used to group policies and bind them to con=
text. A different term would be more obvious.
Policy group binding (PGB) or even the proposed FPG are ok, though I a=
m a bit puzzled why Flow appears in here.
 
marco
 
 
-----Original Message-----
From: dmm [mailto:dmm-bounces@=
ietf.org] On Behalf Of Satoru Matsushima
Sent: Donnerstag, 29. Dezember 2016 03:31
To: Charlie Perkins
Cc: dmm@ietf.org
Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draf=
t-ietf-dmm-fpc-cpdp-05.txt]
 
Hi Charlie,
 
First, thank you for raising this point to be discussed. I second that=
 it needs to be more intuitive.
 
 
I am in the process of reviewing the FPC document.  It is an impo=
rtant document and will be foundational for subsequent work in [dmm].<=
/o:p>
Yep, I really appreciate that you see this draft as a foundation for f=
urther works.
 
 
 I would like to suggest a change in terminology.  I think the wa=
y "Port" is currently defined in the document is very confusing, =
because it is not very intuitively related to the traditional uses of "=
;port" as in TCP, or in switches.
Right. The coauthors had discussed this point many times but, me at le=
ast, couldn’t figure out more appropriate term instead of that so far=
...
 
 
As I understand it, "Policy" lives on the control plane side=
 of the interface, and "Port" is intended to denote a concept tha=
t is important on the data plane side of the interface.
If you mean “control plane” as abstracted data-plane model=
 in FPC agent,  I think that both “Policy” and “Port=
” exist on the control plane. In the current version of draft, Port i=
s defined as “A set of forwarding policies.”
 
 
 "Flow" is another word that is closely tied to the data pla=
ne, and it seems to me that as currently defined in the document a "Po=
rt" is a collection of flows that correspond to a specific Policy or P=
olicy Group.
For me, “Flow” seems not to exactly indicate specific poli=
cy applied flow. It could indicate flow(s) which just have same characteris=
tics in natural. 
 
 
So, I would like to propose that the word "Port" should be r=
eplaced by the term "Flow Group".  Another alternative would=
 be "Flow Policy Group", which could then be abbreviated FPG. How=
ever, the latter has the perhaps undesirable effect of tying the word "=
;Policy" to a data-plane concept.
I think that the successor of port should keep same meaning of “=
A set of forwarding policies.” In that sense, FPG sounds make sense t=
o me. 
 
in another aspect, we use Context as abstracted mobility session. I ca=
n see this as source of flow(s) and it looks already represent a group of t=
hose flows which are received and sent on each node. Attaching Context to a=
 Port intends that applying a set of policies to a group of flows which are=
 attributed to the context.
 
 
Thanks for any comments on this proposal to modify the terminology.
 
I think it is important to make the terminology as unambiguous and int=
uitive as we possibly can, especially because the document is necessarily w=
ritten at a high level of abstraction.
 
Yes, I fully agree with you, let’s keep the discussion.
 
 
Regards,
Charlie P.
Best regards,
--satoru
 
 
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf=
.org/mailman/listinfo/dmm

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_fc554c11297e4ecdbb1481f0cbfa7995plswe13m04adsprintcom_-- From nobody Tue Jan 31 11:27:38 2017 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485651299DB for ; Tue, 31 Jan 2017 11:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k1R-u1xwNb5 for ; Tue, 31 Jan 2017 11:27:32 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0139.outbound.protection.outlook.com [104.47.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F39D12955B for ; Tue, 31 Jan 2017 11:27:32 -0800 (PST) Received: from BL2PR05CA0042.namprd05.prod.outlook.com (10.255.226.42) by CY4PR05MB3112.namprd05.prod.outlook.com (10.172.160.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 31 Jan 2017 19:27:30 +0000 Received: from BY2NAM01FT032.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::202) by BL2PR05CA0042.outlook.office365.com (2a01:111:e400:c04::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5 via Frontend Transport; Tue, 31 Jan 2017 19:27:30 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by BY2NAM01FT032.mail.protection.outlook.com (10.152.69.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Tue, 31 Jan 2017 19:27:28 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v0VJJdl1010831; Tue, 31 Jan 2017 13:27:27 -0600 Received: from plswe13m04.ad.sprint.com (plswe13m04.corp.sprint.com [144.229.214.23]) by plsapdm2.corp.sprint.com with ESMTP id 28a5sv8dkb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Jan 2017 13:27:27 -0600 Received: from PREWE13M17.ad.sprint.com (2002:90e2:8024::90e2:8024) by plswe13m04.ad.sprint.com (2002:90e5:d617::90e5:d617) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 13:27:24 -0600 Received: from PREWE13M17.ad.sprint.com ([fe80::6c7e:f9c4:95f9:d769]) by PREWE13M17.ad.sprint.com ([fe80::6c7e:f9c4:95f9:d769%23]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 14:27:24 -0500 From: "Bales, Mark [CTO]" To: "Bertz, Lyle T [CTO]" , Marco Liebsch , Charlie Perkins Thread-Topic: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] Thread-Index: AQHSYXuaMAvGZyKnl0uR0QDAbxChR6E8euewgA0O5wCACPUQaYAApVuAgAAI3PA= Date: Tue, 31 Jan 2017 19:27:23 +0000 Message-ID: References: <147793286841.32501.6238148222555288408.idtracker@ietfa.amsl.com> <715d6603-f939-7d21-b6ae-b1a7e435b8d2@earthlink.net> <69756203DDDDE64E987BC4F70B71A26DAF06C624@PALLENE.office.hd>, <116dd8b8-ac89-5e9b-1c3e-eb92371b8f98@earthlink.net> <7FD7719B-8F2E-4EFD-9ABD-F272DD016784@neclab.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.20] Content-Type: multipart/alternative; boundary="_000_b220931b91194929aa51ef24c7f755c1PREWE13M17adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39840400002)(39850400002)(39860400002)(39450400003)(2980300002)(438002)(189002)(377454003)(51444003)(199003)(24454002)(13464003)(54356999)(5001770100001)(50986999)(626004)(7906003)(97736004)(345774005)(76176999)(24736003)(189998001)(8936002)(8676002)(236005)(53936002)(81166006)(2900100001)(92566002)(4326007)(81156014)(7736002)(106116001)(55016002)(7696004)(93886004)(230783001)(561944003)(5890100001)(33646002)(86362001)(8666007)(38730400001)(6116002)(3846002)(102836003)(108616004)(229853002)(512954002)(790700001)(54896002)(6306002)(2906002)(4546004)(260700001)(5250100002)(5660300001)(356003)(2950100002)(84326002)(68736007)(606005)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3112; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT032; 1:sl5Nngyle/2nSZLhJnYiMVzr5kNncVpxcCxShDZ/q+0/Nlega0o5VjkfOcOa1hMpXTWRqgQ5U7ZBJFxTdPIHB88J9U1kp25qHECW1GTJE1pJUK/Bw3/UXkhfgc5ztJ8ocRfyPp2ibn916RCbATwxQuLU4Y0mQWofVjofdHjTrXg6k5/lFUBXqVf9VetDPfePg3a9yh4kXYhruHQhe71Dcf4qqxg8qGTRrA5WHxJgXmLheykpArOkHywqN4h6vr+MFkIf/79E0mz0tEZb5y7uYL2q3HAVeZ9bf/VCxNvHW4S75Mqwd3BTVSnD5vyuwND9wNijgr5bqb2b4c1ktO9RyxiPxnbAVXlMcd3SOuW7stWfq5U4nc13XbplEXOlHCfEmS0+AureWELC1RASRNfu/Sjjd5g8T1uOhobEw+DNO20VucwEonA5JGekgg+xhfQUnDHmqoCKrWMkQtPei8McTOugfIDFI4RAjrFKn4G7yiOG6HQ7uj2yTA13olqaOhUXxE+KUmmVOrIoW6HiXWNJ9E2J30Ti+YWSWMuND+GCg7jQeY6srNqQpHMUgwNuxJ1vndypttxmZIVNgtBB/wranre3hI8XwgZbPrZaED0uZZE0Xv8f0v+rxRsCDUo2rCBA X-MS-Office365-Filtering-Correlation-Id: 3b46e563-0ffc-4236-de8c-08d44a0f32a4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:CY4PR05MB3112; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3112; 3:X4/d1JjjzeBQdQZHJLx/St+xD7cbdl/vJrvjlXpBHPOawKRBmzyU9ERtbmQh13jg83TsedFcpPqbDFHHljAAL4MUaZT61/DT4OaDR0Fh7TNVtzXMY+4WZyZ1tHUTWChfEWVIku3UROyICMZ2Pna2el/lyRanfR5lzo+qwMS0RxOF+Azg0t+1i4I210skgFomwvcx/Y8LzTfS34sorJ+RopNXo6/UaH1iRq5wlTNR7Wu3EgqcE92z2+4gJz1ywN1UGzlU5BsKLIM/KEhZjRKjqCwiE6LWkM5L4sYfnkotHuE8n2Q9Bxnsq/hZ4ggqAwAbDy3bKY0R09Gf7TescIArl0TVy7p2+7T6x6W9gkyV/NQzhShyuRzEdLJeb09LKM0ZyKZg/i9XCihBWO6nMqAxRQ== X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3112; 25:TfkVq5b2OTQVzHAdTbRfNZhOI6e9wsfqyXlbleVP4?= =?us-ascii?Q?enbksNW3vUSFrReHzGIxAsn/tV0MwyVllhD1OqSsW1WPEuV/tFM8DqwyOShN?= =?us-ascii?Q?s7+Oti7IxSHQ+rW+uT0DRnGf+ULX0uzUSx9itZ0tlpw/JzmG1npN43MnOJkO?= =?us-ascii?Q?uWDrUgYt5AGlRZdXB3kovulFULprmzlBjiJ7Bn9uysrVmUlJ3ukP3wboQiUl?= =?us-ascii?Q?i0AfRBpY4dvtiNbnlST6RFJ5/6c8AMzlNS9LBK67XRaCkfPpUUbfljZ4wiM2?= =?us-ascii?Q?W8e3xoarqTxVkmaG6z7eqZtz8RNlUvfmgbNNOQY+4tQABRJg6wuXbFVfG+2M?= =?us-ascii?Q?s5uaT8UoIyyOOI+Z6QZtqkKE1oc1/h2d3/GQnFVD9hLKCo1ES5pYCM8LjFC3?= =?us-ascii?Q?GAezmdLU+XQzhDXllj3Li8HudT1sNnTdkiyqv7HOvO0OLAK26lQbMJoGQ+ko?= =?us-ascii?Q?qqtLjCXjQO2nbrBMT91SQASMHDcbbhPDK+KiIpZbwU0hOInP1ZndLT0QjwPT?= =?us-ascii?Q?XmEQ1eceTEYVPanrT8jkazRH3vfHVY4V/v/TOqJxz8Xwjine6rVod5pswNO8?= =?us-ascii?Q?11y/M54K45wIJksNcAI5+0n01WuaJG6Td0dq2I1EwSXmrvCn6UKpMQhE9fTm?= =?us-ascii?Q?6zTNqEoQrtHz/hPyUVXftG3QgR0gKvkLoEoPEeBLVvXSaPos1FD5x0p7e4Aq?= =?us-ascii?Q?jLQblC2uq9JlderbcQH/6dNUsT3QVAkui0Y3tUAfb3ZvaOKP1/ThW5RPZB6R?= =?us-ascii?Q?69rBwyPy34PGuQ1ilcZHZpkSBWBIU+smGnDeeyy7gOzPCMALI79qx2/ZokMl?= =?us-ascii?Q?ZcyBSUyRRp58owyHbXMjAqKgI+Cgzzj9QhHe0Vh3rDEPW7vQhk4F1szbl8U3?= =?us-ascii?Q?kc5Vf/zWVm1kdGzDD1BnpeIZbk7hXwSPApLk87aj5/OYtW7yaFadgMx2pj4z?= =?us-ascii?Q?Ex8PKvCEmAGtAhXaHtDB1iPUF8OPkJAmSVusxVsGsNhjCwrDfIC7F1XGpzlX?= =?us-ascii?Q?oTY/Sli41yh+UzzfsWOsKB8qilZlt2p9lqKBrU8Lvl8bQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3112; 31:IUwz3BsH0VbIHAfYKl41gQvxGgu+RVkmDZutG0afrlZLCCv208amPrG0Ww9WrWGqgHvP4IeBSC3RzhcIA3MwR7IJteGYlrADMtpXP+IYhQ2TpMLu2ouZyH7yMIrYnvAnWkmKVvB4dakrXF18q2uLQllaHIYpuoiZg/DgEC+gcVcrzTgdwtS/FPs5GJqNZ2jhI9ocaT8RuLDS0WyxiY1jNwFpfP1AAiJhbE8SVffLDDEtlY75yNvQ830YLdZSiJK1NN5dEX1myFpYw4CuBK6Rhw==; 20:r/i08MHeYC4SA6f4+MgkRmXLkkEO4aWF97IDhaUGpFCfIFbQC1QTcQRaLiFEL8eQFF3CDjJMLNOxpOimqS4JrVL/lY33GPHS/yxULj8d7KLoYHV7krvs9fmdMdN5ewqWlK+edm/vIpAEDNRZLSVabmOLOXcUTP/zs8UYMZx0WFgriZ3B5RY7VQCRBq5RvUXbWWFthsD1LGmR51YqZAhheD0Pepe/LdIUfRmbLgYg7KAkJFS0mMxt459M+PCfzhLJewT45Wc9NjjL7Ei3h/CKKhG12d9zyLcTQq2OS7fjZ5YenGEJm5YfyJOd5zLR883lLHvUEBt2H3SFGqV/MvzExGwj95ca2XX0xNN1gNVdljaX0DmFa35BZTT7NHo9I7plBZqluA710S7OiPwDzYkavr9HyxP4yEfRSPQflBlw0HzBd/S3txxzMiBWFKAJWFKgL9cCH23qHno4bIBg7lA71WkZCIQp5MD+ZwUR803DIIpf+ha6GszWNwvCAMtWN/Vc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(226508931237476)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13023025)(13015025)(13017025)(13018025)(13024025)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:CY4PR05MB3112; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3112; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3112; 4:RBN6TjmNet3sqrVflStDVS9n1BuGY3jOtbdHRoOvhU4sndofykZmPqEDUlPnTiD0u6SzT7lmtxatyUPgw0kH8O74jYC86Euh5hqpyq568M6qc0VWSmky+zcocO4oSfq4+kt+k1lR9Ddc4fCJvltzEP4s7EPG7cXa2mi1IfS4CmCIWlUWVo8G3a3KxCrgFSILQYBk9rOtwkwUUEcmXQZsXd8yLuh71BttyvgNECgWxHmrl+/uqfrGAlcccK9D4axoooHSMHzlvTatwAb+e+SfOr/mNz6ePEDmMCNY5fG+4OM+2PRWGk/N7uhEW+M9mlS0v+cwiEKoaHXSldygwIZp5HnE6BPCh0lmxNBjzD4VrIN40pV1MHT9TScrxF6JVGN1cQQ2JZJRCQIFq7axnzPmdZc1zM+7OYShhZcUjrWuZkZBHO7I7a8vO/KcthW2JQpXotcjHJ8N4o+p/+ZsFdkPpZB9J4V1DdSYB314sIgaeyBeSCXeqODirE/PWG5zH4QIkdkR72r1aY36MTZtjiuOYWYAKMEfe7oGPNnjwtMaxjpIl5Y/Ac2x58NHiJbgaAU6i4PefwnH3Qxn+pJsD8NsKWppW1rvWKwLKqKLHmoC/qREiQWGO83EdnKMZIQJBrNWZQ+4T8dG6mAL0zNC+Kua0rpJnxVmsh6zv5rI67wT3rIzS0gJ1ZrpjsrU1aEomyrqlV6ekjchnrTxqPQzBhvc7YKucjG4PcGnlh0aVKfRSKBCJYdrMndwq9ToGje4o8PKfxhqTmaxR8ImDJi/ftR3jA== X-Forefront-PRVS: 0204F0BDE2 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3112; 23:QA0ZANI12swP/mRq/hHegAvBZHYNhVRWt8O2vJD64?= =?us-ascii?Q?ue5eNbVxwM5DLj/J1SGGa01ULSHKtS7dcTXa4lhjbsF/BhhX7JQvFIxTgwpZ?= =?us-ascii?Q?cH35wLW+RTRkJzh+lh42XHtxor4YKGFRLox2etJwRbrDOARDsEWbtlq9Xmzz?= =?us-ascii?Q?2HZac6F5vwGSWF/OGPO3GHIM/snj/QEufDxHa3qCgnryGomnWW8j1FI/QEAq?= =?us-ascii?Q?rxatAydS/94kosQprNV6JIyVW30QqzQZ1POllWYKFKcH3iFi7q1Zj/WBSe4c?= =?us-ascii?Q?70k/sbiSn+UGQLrhdo92/HsPTUQ/saxPcVHNd4rU7xO8M49brr+oTAmaHk5e?= =?us-ascii?Q?SpUeZExxj2CXQj8xHx+NL00IGw5e5DuoPxd/GkeIKDHWC42IGBXfUjnpg5Fr?= =?us-ascii?Q?K+AVnCo89Plx3VnzANOQGkQIzODP7GHjREXVgYmx1xiGFt2w6h74GiNDWXQS?= =?us-ascii?Q?Pj/ZCuFtTRVUFjCxpQOMOHbIlHk4JFlHgr5OJnGhR5Db6aFyV9eaxYu2H/1n?= =?us-ascii?Q?wasjPJSn9E889rkPCEstnSsNt3Gp8xxf9Px3C4xMkGnMNdAi0gmOd0fr7odF?= =?us-ascii?Q?7Cl4flDxlVd2sjzJ2G6Dtb4qwiOlIEL8vrQN84csH8vQdWck0ENOS7gAugUA?= =?us-ascii?Q?as8aS6yu1IlH6hQfmZ9MhYDWPiaEC+4Ea96KbDh3rEGrJswEwqJME4issfLP?= =?us-ascii?Q?uzr9HdkcagTQYGoJB2wFdXeIp24pvHYb+vBGTBZhK2gpnii1IwzHGpipc2df?= =?us-ascii?Q?AcFBLrdQk71OYFpsfpEdZ3+8IfEjbmIOQ6sOLaME8yE8v8iaKc4CXj9GEWcm?= =?us-ascii?Q?wM4GITgvXb3H7x0xkaLKQY69jIqn5apACa5FvPpfEm9K/2ROrRKCNtheJa98?= =?us-ascii?Q?VggcgPp0s06fkeH2xaW0WJHm99GvQHFzzDIlItFBIeaWhnFFyckWX3Wz1mdT?= =?us-ascii?Q?Gaer+ERAF7CWyf1stzaRnLBjmsr9doztmxYWXqSbiu0T5nSDlXttdcCaPGTm?= =?us-ascii?Q?+BAz7MRJKDLu3OddLBiTBFNhER/YkmJ30DmrW3wG9HepYB5+tCDH/EO6g/C8?= =?us-ascii?Q?zNtGB+HjdPutACguWByCpvxi7ShRx+qw4j39+2CjUuE/OT87YCgfQVuTblGG?= =?us-ascii?Q?XDYfL+AJF7syxT2GzOlJi02GIeUCfZmuopqBjNOmiNlMhi3dGvMpTIEibvPk?= =?us-ascii?Q?8E/C/H0bW2uq+YwqVvvMXe70Ur9AqyC2vkDlTxe0ooH6MiP/yio73aVOEZex?= =?us-ascii?Q?X6LTboFqhkRC46ltWS3rHl7aYVua3PsW94Q5sEgObkeORwnAjfXrT+lSc88B?= =?us-ascii?Q?iOvU9pVtSps2nmWZYZhZ5QF+M1exkHdkLnC/Q2vuwLaTW407tBJeC+9uB/m5?= =?us-ascii?Q?Bhl5y/ZucEVut8OSYej6qORk80T5F5TJNNWlkNEXxIq15tcUYMCEVuVd8eoY?= =?us-ascii?Q?dQaB4PY0/XV0IKFStiDW5bjUT+GdEGfHM8okRNXDaji0c1xKKFCLJbO5S7gh?= =?us-ascii?Q?tXS8xLAzM7gm1GDpZAT/d7iu99V5aDkDqSb7y26mIISNjkdwJGloTTSnY4sG?= =?us-ascii?Q?E1VjU6zOJwR2JSiPA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3112; 6:frrHGjHj+T94OxEg0Ju1RD7n53On8a9mtP2ibEehdyXaKqSa2aGoGxNJZXYUGl0ppsCeHcGK3nNI1WZuVaVI9pyQ+qP1KUx5RU7UVW9BpI/nmBU+qhzzY5XH3dEO5ws9dqxmEpzJZ0x/rTjjcOAdPXCRf2kyVf8JmXZSsaa+/XYxL8bspBRp4Um/OiDdgE1wCS4u8N9ivD3D6BzgWZm1KYmz4wJlk+LjzESfr2WphrUFgnyZazRS7jPYaMnUbvhI6zxbqQ1OBNb6YwCxfTmqrpm7MU7L1X7DXBebcA1blB2WxX86RJOsjWNvvyvz6mBitysKK7fuGZ4KoOBsZobf9MVxLI+M08JH1ySQaIlSw4GkkLUA8PieNY14C7drFlu22FIvUV3kCIY55NiPp5jgRErAq3OWi14tHaSTNNbLoSEQClQ3OiSrxYBjXmIrbB6b; 5:JL8tishcEM8KcsYggZ7gjrSvp24P3gOKJTk4tmYk5p0KfKZjggUxc4WRG71TzxBIkq00Ijbn19gM8sZtR98bseBXTTz0U27RH75KaXtxMOAYoOHqBzqkye8ug2gT69JXYy7NjAUBBy/hZ42wR2YEXqhmSjUzzF4OfHAaO/MioGc=; 24:dtLDlDYeIBxR0OgTUC9/QJPcn7KQstp6O/xxzTXnKhE1IHddk+rQftL8WNItPYEvR1tShKuVc5cm67ramQWz9Uuuu32RTArptRMnGZdVEv8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3112; 7:kIDBrbZcLAcOWPXvuQiFVebECj4UwGKWOyIDNMNBHq7EwVuyMFwm9QLL33KdwfifGkd1fzDnUCK91Szqh3e6EdoZ42jXG3WTQDsaFY+r0tuNHdknYk0BLZsPrRtT46xQXzBMg5XbCkcDEJ+b99XunHnGA69uC2Td2/XEehD6XTrw7WVonSlmJP3fw0QpkXiUofo4CDqEkMZGJ+twZOdigZgXWd4His8wkLopbSiorzYMVlcRj4J/NhA3v9AoauH+70tvMo4LpdyEtQtEUPspak1NMNgzKuGhh0z+vuB6BzMXJ/IMRZJV87VoCPHijwghR2FdERIi55vdHV8t2fG08lcBl0YP2rBZNoAqa/eRYvq83RLUNUDD5XQjf3kxTbiAbcfyrPKEyDFwn1a6xRhBV1vIj2watB4UCV1nbvnDu2fzlYS040Z/3IjFj3WkryEAO9DIKKjtv7Behet2uL3czxuVbe3eHwP/1sLDAiRpgJTRqZApo4znm/pBzGhzo4QRnFvjmbDgTIoJOb9DmZv92V6u/pPITrNWZmyTwYTuh4XRxPL1V555zJYU9nAmC3xM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2017 19:27:28.8368 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3112 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:27:37 -0000 --_000_b220931b91194929aa51ef24c7f755c1PREWE13M17adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Tuesday, January 31, 2017 7:56 AM To: Marco Liebsch ; Charlie Perkins Cc: dmm@ietf.org Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-= fpc-cpdp-05.txt] +1 From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch Sent: Tuesday, January 31, 2017 3:04 AM To: Charlie Perkins > Cc: dmm@ietf.org Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-= fpc-cpdp-05.txt] Hello Charlie, If we keep the port term, your proposal is very good. I support the adoptio= n of the vport term. Thanks and best regards, Marco On 25 Jan 2017, at 19:14, Charlie Perkins > wrote: Hello Marco, What would you think about replacing the term "port" by "virtual port", whi= ch would usually be shortened to "vport" (or "Vport")? I think it would have several benefits: * it seems intuitively appealing, at least to me * it avoids the unacceptable clash with the traditional meanings of the= word "port" * it fits well with my understanding of "data-plane node" and "context"= . * it's a relatively easy editorial change to the draft Regards, Charlie P. On 1/17/2017 1:05 AM, Marco Liebsch wrote: The meaning of port changed throughout the evolution of this draft. Up to v= ersion 3 a port was a forwarding construct that binds traffic selectors to traffic treatment acti= ons. Any other term, e.g. rule, could have made it. These are created (attach), modified (handov= er) or deleted per the mobile node's location, IP address, etc. >From version 4, what has been a port before is now more the 'context' stru= cture, whereas the inherited port term is used to group policies and bind them to context.= A different term would be more obvious. Policy group binding (PGB) or even the proposed FPG are ok, though I am a b= it puzzled why Flow appears in here. marco -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima Sent: Donnerstag, 29. Dezember 2016 03:31 To: Charlie Perkins Cc: dmm@ietf.org Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-= cpdp-05.txt] Hi Charlie, First, thank you for raising this point to be discussed. I second that it n= eeds to be more intuitive. I am in the process of reviewing the FPC document. It is an important docu= ment and will be foundational for subsequent work in [dmm]. Yep, I really appreciate that you see this draft as a foundation for furthe= r works. I would like to suggest a change in terminology. I think the way "Port" i= s currently defined in the document is very confusing, because it is not ve= ry intuitively related to the traditional uses of "port" as in TCP, or in s= witches. Right. The coauthors had discussed this point many times but, me at least, = couldn't figure out more appropriate term instead of that so far... As I understand it, "Policy" lives on the control plane side of the interfa= ce, and "Port" is intended to denote a concept that is important on the dat= a plane side of the interface. If you mean "control plane" as abstracted data-plane model in FPC agent, I= think that both "Policy" and "Port" exist on the control plane. In the cur= rent version of draft, Port is defined as "A set of forwarding policies." "Flow" is another word that is closely tied to the data plane, and it seem= s to me that as currently defined in the document a "Port" is a collection = of flows that correspond to a specific Policy or Policy Group. For me, "Flow" seems not to exactly indicate specific policy applied flow. = It could indicate flow(s) which just have same characteristics in natural. So, I would like to propose that the word "Port" should be replaced by the = term "Flow Group". Another alternative would be "Flow Policy Group", which= could then be abbreviated FPG. However, the latter has the perhaps undesir= able effect of tying the word "Policy" to a data-plane concept. I think that the successor of port should keep same meaning of "A set of fo= rwarding policies." In that sense, FPG sounds make sense to me. in another aspect, we use Context as abstracted mobility session. I can see= this as source of flow(s) and it looks already represent a group of those = flows which are received and sent on each node. Attaching Context to a Port= intends that applying a set of policies to a group of flows which are attr= ibuted to the context. Thanks for any comments on this proposal to modify the terminology. I think it is important to make the terminology as unambiguous and intuitiv= e as we possibly can, especially because the document is necessarily writte= n at a high level of abstraction. Yes, I fully agree with you, let's keep the discussion. Regards, Charlie P. Best regards, --satoru _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_b220931b91194929aa51ef24c7f755c1PREWE13M17adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: dmm [mailto:dmm-bounces@ietf.o= rg] On Behalf Of Bertz, Lyle T [CTO]
Sent: Tuesday, January 31, 2017 7:56 AM
To: Marco Liebsch <Marco.Liebsch@neclab.eu>; Charlie Perkins &= lt;charles.perkins@earthlink.net>
Cc: dmm@ietf.org
Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action= : draft-ietf-dmm-fpc-cpdp-05.txt]

 

+1

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, January 31, 2017 3:04 AM
To: Charlie Perkins <charles.perkins@earthlink.net>
Cc: dmm@ietf.org
Subject: Re: [DMM] Change "Port" to ? [ was Re: I-D Action= : draft-ietf-dmm-fpc-cpdp-05.txt]

 

Hello Charlie,

 

If we keep the port term, your proposal is very good= . I support the adoption of the vport term.

 

Thanks and best regards,

Marco


On 25 Jan 2017, at 19:14, Charlie Perkins <charles.perkins@earthlink.net> wrote:=

Hello Marco,

What would you think about replacing the term "port" by "= virtual port", which would usually be shortened to "vport" (= or "Vport")?

I think it would have several benefits:

  • it seems intuitively appealing, at least to me
  • it avoids the unacceptable clash with the traditional meanings of the word = "port"
  • it fits well with my understanding of "data-plane node" and "= ;context".
  • it's a relatively easy editorial change to the draft

Regards,
Charlie P.

 

On 1/17/2017 1:05 AM, Marco Liebsch wrote:

The meaning of port changed throughout the evolution of this draft. Up=
 to version 3 a port was a
forwarding construct that binds traffic selectors to traffic treatment=
 actions. Any other term,
e.g. rule, could have made it. These are created (attach), modified (h=
andover) or deleted per
the mobile node's location, IP address, etc.
 
>From version 4, what has been a port before is now more the 'conte=
xt' structure, whereas
the inherited port term is used to group policies and bind them to con=
text. A different term would be more obvious.
Policy group binding (PGB) or even the proposed FPG are ok, though I a=
m a bit puzzled why Flow appears in here.
 
marco
 
 
-----Original Message-----
From: dmm [mailto:dmm-bounces@=
ietf.org] On Behalf Of Satoru Matsushima
Sent: Donnerstag, 29. Dezember 2016 03:31
To: Charlie Perkins
Cc: dmm@ietf.org
Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draf=
t-ietf-dmm-fpc-cpdp-05.txt]
 
Hi Charlie,
 
First, thank you for raising this point to be discussed. I second that=
 it needs to be more intuitive.
 
 
I am in the process of reviewing the FPC document.  It is an impo=
rtant document and will be foundational for subsequent work in [dmm].<=
/o:p>
Yep, I really appreciate that you see this draft as a foundation for f=
urther works.
 
 
 I would like to suggest a change in terminology.  I think the wa=
y "Port" is currently defined in the document is very confusing, =
because it is not very intuitively related to the traditional uses of "=
;port" as in TCP, or in switches.
Right. The coauthors had discussed this point many times but, me at le=
ast, couldn’t figure out more appropriate term instead of that so far=
...
 
 
As I understand it, "Policy" lives on the control plane side=
 of the interface, and "Port" is intended to denote a concept tha=
t is important on the data plane side of the interface.
If you mean “control plane” as abstracted data-plane model=
 in FPC agent,  I think that both “Policy” and “Port=
” exist on the control plane. In the current version of draft, Port i=
s defined as “A set of forwarding policies.”
 
 
 "Flow" is another word that is closely tied to the data pla=
ne, and it seems to me that as currently defined in the document a "Po=
rt" is a collection of flows that correspond to a specific Policy or P=
olicy Group.
For me, “Flow” seems not to exactly indicate specific poli=
cy applied flow. It could indicate flow(s) which just have same characteris=
tics in natural. 
 
 
So, I would like to propose that the word "Port" should be r=
eplaced by the term "Flow Group".  Another alternative would=
 be "Flow Policy Group", which could then be abbreviated FPG. How=
ever, the latter has the perhaps undesirable effect of tying the word "=
;Policy" to a data-plane concept.
I think that the successor of port should keep same meaning of “=
A set of forwarding policies.” In that sense, FPG sounds make sense t=
o me. 
 
in another aspect, we use Context as abstracted mobility session. I ca=
n see this as source of flow(s) and it looks already represent a group of t=
hose flows which are received and sent on each node. Attaching Context to a=
 Port intends that applying a set of policies to a group of flows which are=
 attributed to the context.
 
 
Thanks for any comments on this proposal to modify the terminology.
 
I think it is important to make the terminology as unambiguous and int=
uitive as we possibly can, especially because the document is necessarily w=
ritten at a high level of abstraction.
 
Yes, I fully agree with you, let’s keep the discussion.
 
 
Regards,
Charlie P.
Best regards,
--satoru
 
 
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf=
.org/mailman/listinfo/dmm

 

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

--_000_b220931b91194929aa51ef24c7f755c1PREWE13M17adsprintcom_-- From nobody Tue Jan 31 11:34:10 2017 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C81F61299D8; Tue, 31 Jan 2017 11:34:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 11:34:05 -0800 Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: [DMM] Review of draft-ietf-dmm-4283mnids-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.17 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:34:06 -0000 Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dmm-4283mnids-04 Reviewer: Dale R. Worley Review Date: 31 Jan 2017 IETF LC End Date: 2 Feb 2017 IESG Telechat date: 16 Feb 2017 Summary: This draft is on the right track but has open issues, described in the review. Technical issues: 1. The Introduction states Other types of identifiers are in common use, and even referenced in RFC 4283. For the reader's sanity, some sort of accounting needs to be made of these "other types of identifiers", especially because each type of identifier needs an identifier type number. The text in 4283 is Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). Are there any other types "in common use"? - NAI (type 1) is defined by 4283. - Fully Qualified Domain Name (FQDN) seems not to be specified - International Mobile Station Identifier (IMSI) (type 3) is defined in this draft - Mobile Subscriber Number (MSISDN) seems not to be specified 2. Is it intended to have an IMEI identifier type? The introduction mentions an IMEI type, but there is no specification for it, nor is there an identifier type number assigned for it. ... types for IMSI [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and GUTI [ThreeGPP-IDS]. Initially I suspected it was it was present in an earlier revision and then later deleted without this reference being updated. But all versions of draft-ietf-dmm-4283mnids and its predecessor draft-perkins-dmm-4283mnids mention IMEI in this way as one identifier type, but none specify it in any way. The only discussion I can find on the DMM mailing list of IMEI is: https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid=d29575f767ce67a1e67a7767008ee6af From: Marco Liebsch To: DMM Date: Wed, 10 September 2014 13:29 UTC Re: [DMM] regarding the re-chartering.. It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. Either the presence of IMEI in this list is a simple mistake that has persisted in all versions of the draft, or specifying IMEI has always been intended but has always been overlooked. 3. The definition of identifier types for both EUI-48 and EUI-64 suggests that it might be desirable to define an identifier type for arbitrary hardware (link-level) addresses. It seems that the natural differentiator for that purpose is the "hardware type" used in ARP, so a EUI-48 address would be represented as MN identifier type (one octet) 5 (say) hardware type (two octets) 1 EUI-48 (six octets) and an EUI-64 similarly, with hardware type 27. Although with only two subtypes in common use, generalizing this might not be worth the effort. 4. Several of the identifier types can be represented as URNs: - IMEI can be represented as a URN as urn:gsma:imei:... - all of the RFID types have a URN representation (called the "pure-identity URI" in the RFID specifications), which starts urn:epc:id:... Since all URN types are ensured of being unique and persistent, it seems that we could define a MNID type for URNs generally, and then any RFID URI or an IMEI (as a URN) could be used as a value of that type. If this idea is adopted, it seems that the other 3GPP types (IMSI, P-TMSI, and GUTI) should be given defined encodings as URNs in new sub-namespaces of the "gsma" URN namespace, to parallel the encoding of IMEIs defined in RFC 7254. This consolidation could be significantly beneficial. It allows MNID to use any URN scheme as an identifier. It reduces the three different RFID representations to one. It incorporates any future expansion of RFID schemes (because all schemes will have a pure-identity URN representation). A disadvantage is that the URN encodings are long, but the security considerations section states that MNIDs are used only on the first registration at the home agent, so there isn't much need for brevity. Similarly, this approach incorporates any future expansion of mobile identifiers that GSMA decides to define, as long as GSMA provides a URN representation for it. The most significant disadvantage is that some URN schemes allow several character strings to "mean" the same URN. In most URN schemes, the allowed variation is limited to the case of letters, and the common convention is to always use lower-case when there is a choice, leading to a unique conventional canonical form for the URN. 5. Regarding the encoding of a string of digits into octets, it is stated that "The last digit MUST be zero padded, if needed, for full octet size." This seems very unwise unless there is a 3GPP decree that if a zero is appended to a valid IMSI, the resulting string is never a valid IMSI. Instead, I would specify that padding is by filling the low-order 4 bits of the final octet with 0xF. That ensures that the encoding can be uniquely decoded into an IMSI. 6. There are four types of DUID specified, each with a distinct MNID value. However, DUIDs contain an initial two-octet type field which distinguishes the various types of DUID, so providing them with distinct MNID values is redundant. Distinguishing the types and allowing only four of them to be used as MNIDs seems to be contrary to the philosophy of DUID construction (RFC 3315 section 9): Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs. Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future. Of course, MNID isn't a DHCP operation, so it isn't subject to those requirements, but I expect that devices will use the same DUID for both mobile identification, and we don't want mobile identification to restrict future developments of DHCP. I think this specification must treat DUIDs as opaque and use only one MNID type that allows all types of DUIDs as values. Editorial issues: Abstract Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for IPv6 (RFC 4283). s/proposed/defined/ This document will define the new types (once it is approved)! 1. Introduction ... types for IMSI [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and GUTI [ThreeGPP-IDS]. There is no description of P-TMSI identifiers, although it is assigned identifier type 4. There is no description of GUTI identifiers, although it is assigned identifier type 7. 3. New Mobile Node Identifier Types The following types of identifiers are commonly used to identify mobile nodes. For each type, references are provided with full details on the format of the type of identifier. The Tag Data standard promoted by Electronic Product Code(TM) (abbreviated EPC) supports several encoding systems or schemes including o RFID-GID (Global Identifier), o RFID-SGTIN (Serialized Global Trade Item Number), o RFID-SSCC (Serial Shipping Container), o RFID-SGLN (Global Location Number), o RFID-GRAI (Global Returnable Asset Identifier), o RFID-DOD (Department of Defense ID), and o RFID-GIAI (Global Individual Asset Identifier). For each RFID scheme except GID, there are two variations: a 64-bit scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96). GID has only a 96-bit scheme. Within each scheme, an EPC identifier can be represented in a binary form or other forms such as URI. The following list includes the above RFID types as well as various other common identifiers and several different types of DUIDs. The organization of the text here seems to be poor -- section 3 enumerates the new identifier types, but much of the text at the beginning of the section is about the RFID-EPC set of types. It seems like a better organization is to use just paragraph 1 followed by table 1, and move paragraphs 2-5 into section 4.9. The Tag Data standard promoted by Electronic Product Code(TM) (abbreviated EPC) supports several encoding systems or schemes including The text is using "Tag Data", "EPC", and "RFID" in a way that is intertwined but not explained. I can see that it might be useful to use all of the terms if they commonly used in the field (don't forget to make them keywords for the RFC!), but you need to explain their connection and distinction to the reader or make it clear that the reader does not need to understand the differences among the terms. E.g., this formulation ties all three terms together The Tag Data standard promoted by Electronic Product Code(TM) (abbreviated EPC) supports several encoding systems or schemes which are commonly used in RFID (radio-frequency identification) applications, including -- For each RFID scheme except GID, there are two variations: a 64-bit scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96). GID has only a 96-bit scheme. Within each scheme, an EPC identifier can be represented in a binary form or other forms such as URI. The text uses "scheme" to mean the distinction between encoding systems (GID, SGTIN, etc.) and and also to mean the distinction between the 64-bit and 96-bit variations. This ambiguity is unwise. It matters here, because you say "within each scheme ... can be represented in a binary form or ... URI". Which meaning of "scheme" are you using here? I thought you meant the second meaning when I first read the paragraph, but after reading external documents about EPC, I now understand that that last sentence uses "scheme" to in the first sense. You need to be clearer here that there are three representations used, 64-bit binary, 96-bit binary, and URI (URN, actually), and representation is orthogonal to the seven RFID schemes, with the exception that RFID-GID does not have a 96-bit binary representation. I'm assuming that the Tag Data standard unambiguously defines the serialization of the binary representations as a sequence of octets. If it does not, this document MUST do that, or you will have an endless nightmare of byte-order problems. 4. Descriptions of MNID types Identifier ownership is a general concern -- it's worth mentioning for each type of identifier where the assigner of the identifier obtains delegation. For an EUI, I expect the reader will assume that it's an EUI assigned to the device under IEEE rules, and similarly for RFID and 3GPP identifiers. But for DUID identifiers, it's less clear. I'm guessing that the DUID is one that is, or could be, used by the device for DHCP purposes. For IPv6 addresses, it's even less clear, since the IPv6 architecture doesn't assume that the association of addresses with devices is permanent. 4.1. Description of the IPv6 address type It would be good if the document described what the semantics of this ID are. Yes, it's a unicast IPv6 address, but what is the connection between that address and the device? I suspect the connection is "the device has been configured to expect that it will be assigned this address as a long-term interface address", but there are other possibilities. E.g., I can imagine a mobile carrier obtaining a /64 prefix (there are plenty of them!) and then assigning addresses out of it simply to create a sequence of unique identifiers for devices, but not using those addresses on packets. Then again, perhaps you want to allow flexibility. But in any case, I think you need to specify what the rules are for what address is associated with what device. 4.2. Description of the IMSI MNID type What does "in network order" mean here? As far as I know, there is no defined "network order" for 4-bit quantities, only for dividing integers into octets and placing sequences of bits into octets. I assume you mean that in any octet, the high-order 4 bits are the first digit and the low-order 4 bits are the second digit, but I think you need to state that explicitly. 4.3. Description of the EUI-48 address type The IEEE EUI-48 address [IEEE802-eui48] is encoded as a 6 octet string containing the IEEE EUI-48 address. Is "string" the correct word, this not being a sequence of characters? I would say "sequence of 6 octets" or simply "encoded as 6 octets". 4.9. Description of the RFID types This section needs to be revised. It provides a lot of detail about the RFID types, but it's not enough detail for a reader who doesn't understand RFID to learn how any particular RFID scheme works. E.g., the first paragraph says that GID contains three fields in the first sentence, and that it contains four fields in the third sentence. Despite this, the description isn't enough to allow the reader to construct GID identifiers manually. On the other hand, readers who already understand the RFID schemes will find this text redundant. I think that almost all of this text can be replaced by references to the EPC documents, since these identifiers are opaque from the point of view of mobile identification. 5. Security Considerations The base MNID specification, RFC 4283, gives these security considerations (sec 4), which ought to be referenced and probably summarized in this section: Moreover, MNIDs containing sensitive identifiers might only be used for signaling during initial network entry. Subsequent binding update exchanges might then rely on a temporary identifier allocated during the initial network entry, perhaps using mechanisms not standardized within the IETF. Managing the association between long- lived and temporary identifiers is outside the scope of this document. What is the meaning of the word "might" in paragraph 3? I suspect that the purpose is to qualify this paragraph with "One way to address these vulnerabilities is to only use MNIDs containing ...". But if that is the meaning, that expanded wording should be used. Otherwise the text reads as if it is hypothetical. [END]