From nobody Wed Feb 1 07:51:58 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 787D91293FB for ; Wed, 1 Feb 2017 07:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 NRJbm4PFC6vD for ; Wed, 1 Feb 2017 07:51:56 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 C57721294BA for ; Wed, 1 Feb 2017 07:51:55 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 194so110137923pgd.2 for ; Wed, 01 Feb 2017 07:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=blSQyyx5hClGFEKUlmk/1UvRx+vjOBl8sylsC7UcZQ4=; b=WlbYVpOT6x3mrsuwnyG6nOW/Oq7rGpFpo9sfrq+hiMDcONiCOw4nvjLoxHjjIfKc/b QQ2ZhuDnEMoF8DNF3hrfzdc2crwVeO68r3+VmlbHzHDjFBL1FilmQMlR/sGBtIhHXYPy ZirIHy2aGS2C+03dtWhEnrZ8a1YzosmsK7TmcShkU8UHSVLMFChBAcgdC4XgcMlnQ4RA J9CLp1jgffQpLAr8fEFuZTF9srj20KlIZjoJDkyWny+/OctmlJMn/Uh9X3UCPpKaednH oMdsyKJdRfDwTAUiMp1sczs4i/QSmWd781ppE+oMi28pPzQXWCctSacb4225VyfsXJfm hUkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=blSQyyx5hClGFEKUlmk/1UvRx+vjOBl8sylsC7UcZQ4=; b=bWHG4jEHcJaaembsHXTw11eOZjbxZtcnr+/vfAbOZmlNK1IJSSkaSd7c3YUgobyOFB w00J/A+KpRgsHEmm8s0E3g57qS8/GRcCcSs13rcvPA7pHVKVDfAbs0V/jjSepnqTZUwj 6obwhFLKljGceJ7wPOSGmJ6iFMnzjaU1AIjFWpf4mL7UnpILm3rXl0OHeB1rnAZbC8oa fXCefB7uFaJUsfusSr9GnpFr5RISyzD+z0uf3p0Jv+hefdUe0lrL4jvnYCIXU6MQcwkO gnEFqmFDDksmiponf+vD6w5/p8VW4TTqkM7EaXe3qoiyYplY2Y+DrhYCZdGgXCNtWmD8 A92Q== X-Gm-Message-State: AIkVDXLNknDRPh8AvFTwxSpvZXLyA8vPDyXB8hGkiaIo1ap5PPxxIzLAWG00e8088NLA1g== X-Received: by 10.98.158.210 with SMTP id f79mr4371838pfk.145.1485964314970; Wed, 01 Feb 2017 07:51:54 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id q64sm34759450pga.0.2017.02.01.07.51.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 07:51:53 -0800 (PST) From: "jouni.nospam" Content-Type: multipart/alternative; boundary="Apple-Mail=_3E7C55FA-0E99-4906-B734-3BA7CDB5E375" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: References: <148591161114.5931.18258611553220397596.idtracker@ietfa.amsl.com> To: dmm@ietf.org Date: Wed, 1 Feb 2017 07:51:52 -0800 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [DMM] Fwd: dime - New Meeting Session Request for IETF 98 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, 01 Feb 2017 15:51:57 -0000 --Apple-Mail=_3E7C55FA-0E99-4906-B734-3BA7CDB5E375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, We have asked for 1h slot for the IETF98. The main topic would be = RFC4006bis. We might have other short status/progress updates on = Diameter group signaling, and e2e security. - Jouni & Lionel > Begin forwarded message: >=20 > From: "\"IETF Meeting Session Request Tool\"" = > Subject: dime - New Meeting Session Request for IETF 98 > Date: January 31, 2017 at 5:13:31 PM PST > To: > Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com, = stephen.farrell@cs.tcd.ie > Resent-From: > Resent-To: jouni.nospam@gmail.com, lionel.morand@orange.com >=20 >=20 >=20 > A new meeting session request has just been submitted by Jouni = Korhonen, a Chair of the dime working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Diameter Maintenance and Extensions > Area Name: Operations and Management Area > Session Requester: Jouni Korhonen >=20 > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 150 > Conflicts to Avoid:=20 > First Priority: detnet tsvwg tsvarea quic iccrg > Second Priority: 6man v6ops intarea=20 >=20 >=20 >=20 > People who must be present: > Stephen Farrell > Lionel Morand > Jouni Korhonen >=20 > Resources Requested: > Meetecho support in room >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 --Apple-Mail=_3E7C55FA-0E99-4906-B734-3BA7CDB5E375 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Folks,

We have asked for 1h slot for the = IETF98. The main topic would be RFC4006bis. We might have other short = status/progress updates on Diameter group signaling, and e2e = security.

- = Jouni & Lionel




Begin = forwarded message:

From: = "\"IETF Meeting Session Request = Tool\"" <session_request_developers@ietf.org>
Subject: = dime - New = Meeting Session Request for IETF 98
Date: = January 31, 2017 at 5:13:31 PM = PST
To: = <session-request@ietf.org>
Cc: = dime-chairs@ietf.org, = dime@ietf.org, jounikor@gmail.com, stephen.farrell@cs.tcd.ie
Resent-From: = <alias-bounces@ietf.org>
Resent-To: = jouni.nospam@gmail.com, lionel.morand@orange.com



A= new meeting session request has just been submitted by Jouni Korhonen, = a Chair of the dime working group.


---------------------------------------------------------
Working Group Name: Diameter Maintenance and Extensions
Area Name: Operations and Management Area
Session= Requester: Jouni Korhonen

Number of = Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 150
Conflicts to Avoid: =
First Priority:  detnet tsvwg tsvarea quic iccrg
Second Priority: 6man v6ops  intarea



People who must be present:
 Stephen Farrell
 Lionel Morand
 Jouni Korhonen

Resources = Requested:
 Meetecho support in room
Special Requests:

---------------------------------------------------------


= --Apple-Mail=_3E7C55FA-0E99-4906-B734-3BA7CDB5E375-- From nobody Wed Feb 1 17:00:53 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 589581294F0 for ; Wed, 1 Feb 2017 17:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 sQHstpvnr4QG for ; Wed, 1 Feb 2017 17:00:50 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 D68B9129466 for ; Wed, 1 Feb 2017 17:00:50 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 204so495209pge.0 for ; Wed, 01 Feb 2017 17:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=QIN34Cz7fV3q5tul1cZz82gC4oSlPDEnmb2P1fQJjkM=; b=swlr8gaXMPZPVJ2Qo8L7qtmsZ5LSSPHypFVp5gnX2/6XmelWOpLncAPqGTxB+2Xzqj m6/6aK2qVFrcODnR2VWEBnzkdly9yZ7mhloWYQJ/KlH1nmLV1/EP2sLAm9ub3Z4AnUMt qSIono6N8MZnVrL5Hsme+ZImn9QZgVKp7/bETKBBvxcNcC8ZKBe+e32ZMVctxtWIVR5w hWUr5O+Cg8qw0A7xNic4hoqF3F4oVS0VFbKl+sUpDWholbjA+U2LsmhLmEiOsR2Ygaw0 jozA4uqhrDL0NDgTkrdIeNB4cIt8lxbrLOvlaV0oJKcXzO3DyYFntHIXTta9NohJEabS 5JWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=QIN34Cz7fV3q5tul1cZz82gC4oSlPDEnmb2P1fQJjkM=; b=d08YJGqGk5UG7sFYEhw8CH87QFG9Q8oXyBDHKBUY4xXw0M0a2SAUhK6XtoB/FRn8CM I0wVWswjyn0kNNQGiupwClky728XlbtwuCjLUTe/bO17plth42h3iqX6aIS4jbqPIiOk ht2ctyTCnN0cEId+ZWeZqTfJtnmW1IBUjwBBsfVXU6tbbKkcowteFerpA80RUm3OATqd DJWJkqAB+wQ7RSBu3fO5q2u0LQu4F0MjUTVBT4JwVEOddEgccu0RmYLXhJavn2i9m46D Lpq9e6NlUAEMZDqtO11d7dKH/vmbl5WInmkirR5mB4g7VI92GjHOndoFDOGIM9ofWJs9 ynvA== X-Gm-Message-State: AIkVDXLjsspXwLpIprN+NT7yKv+Hhf8DIjgifEyLTTyuR13ebv6T1inBjKz0is8d5B1ukg== X-Received: by 10.98.50.66 with SMTP id y63mr7185430pfy.21.1485997249878; Wed, 01 Feb 2017 17:00:49 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id m6sm52659102pfm.22.2017.02.01.17.00.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 17:00:48 -0800 (PST) From: "jouni.nospam" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 1 Feb 2017 17:00:47 -0800 References: <148591161114.5931.18258611553220397596.idtracker@ietfa.amsl.com> To: dmm@ietf.org In-Reply-To: Message-Id: <9185B81C-0864-4D78-8753-8880F77B392A@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [DMM] dime - New Meeting Session Request for IETF 98 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: Thu, 02 Feb 2017 01:00:52 -0000 I was gently reminded that even if mobility could be achieved by = tunneling packets over Diameter AVPs, it is not really in the charter of = the DMM.. yet! ..and now I will turn off the address autocompletion on this $=C2=A2@#&^! = email client ;-) - Jouni > On Feb 1, 2017, at 7:51 AM, jouni.nospam = wrote: >=20 > Folks, >=20 > We have asked for 1h slot for the IETF98. The main topic would be = RFC4006bis. We might have other short status/progress updates on = Diameter group signaling, and e2e security. >=20 > - Jouni & Lionel >=20 >=20 >=20 >=20 >> Begin forwarded message: >>=20 >> From: "\"IETF Meeting Session Request Tool\"" = >> Subject: dime - New Meeting Session Request for IETF 98 >> Date: January 31, 2017 at 5:13:31 PM PST >> To: >> Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com, = stephen.farrell@cs.tcd.ie >> Resent-From: >> Resent-To: jouni.nospam@gmail.com, lionel.morand@orange.com >>=20 >>=20 >>=20 >> A new meeting session request has just been submitted by Jouni = Korhonen, a Chair of the dime working group. >>=20 >>=20 >> --------------------------------------------------------- >> Working Group Name: Diameter Maintenance and Extensions >> Area Name: Operations and Management Area >> Session Requester: Jouni Korhonen >>=20 >> Number of Sessions: 1 >> Length of Session(s): 1 Hour >> Number of Attendees: 150 >> Conflicts to Avoid:=20 >> First Priority: detnet tsvwg tsvarea quic iccrg >> Second Priority: 6man v6ops intarea=20 >>=20 >>=20 >>=20 >> People who must be present: >> Stephen Farrell >> Lionel Morand >> Jouni Korhonen >>=20 >> Resources Requested: >> Meetecho support in room >>=20 >> Special Requests: >>=20 >> --------------------------------------------------------- >>=20 >=20 From nobody Wed Feb 1 20:25:46 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 7CDDC127058; Wed, 1 Feb 2017 20:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 hp_KIjj-zytt; Wed, 1 Feb 2017 20:25:39 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E3B126579; Wed, 1 Feb 2017 20:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3676; q=dns/txt; s=iport; t=1486009539; x=1487219139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XRtSYogfAc/+A2WBrHKm2YNCkO0ss1DKzmgfi44Ibwk=; b=Cg/9VbQ0BoLEyMpl1qfcbmqOmbCWun6Nn+kbeOKTNbtuf1R9AMpz6Knl vUbVDxMXHHQS5h0ms/g9UBfy/hz+EupTKcRg2p4MHry0Kna+u/nJ+eYcW WNICHbbRd9cbWquDe8ITFzWWronhXr3ByOerLKaXM24D72fiSDKyc4f1s M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQA9tJJY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHjViSCIgMjSmCDR8LhXgCgkA/GAECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQEEAQE4NAsMBAIBCBEDAQIBHhAhBgsdCAIEAQ0FiVkDFQ6vHIc9DQuDWgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFhkuEb4JRh2EFjzaLbzgBjW+EF5ECiiqEQ4Q?= =?us-ascii?q?WAR84EIE7FTuGQnUBh1yBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="378813831" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Feb 2017 04:25:38 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v124PcMU002589 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Feb 2017 04:25:38 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 22:25:37 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 22:25:37 -0600 From: "Sri Gundavelli (sgundave)" To: Suresh Krishnan , "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: AQHSfQxnvUurZ2cW3E24BVZsGncTfA== Date: Thu, 2 Feb 2017 04:25:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 02 Feb 2017 04:25:41 -0000 Hi Suresh, Dhananjay has an updated draft, he will post it this week. Regards Sri On 1/27/17, 11:10 AM, "Suresh Krishnan" wrote: >Hi Dhananjay/authors, > Any progress on this? I would like to get this moving soon. > >Thanks >Suresh > >On 12/22/16, 4:35 AM, "Int-dir on behalf of Dhananjay Patki (dhpatki)" > wrote: > > Hello, > =20 > Thanks for the review. We will address the comments and get back with >a new version of the draft. > -- > Regards, > Dhananjay > =20 > =20 > -----Original Message----- > From: Ralph Droms > Date: Wednesday, 21 December 2016 at 11:51 PM > To: "int-dir@ietf.org" > Cc: "dmm@ietf.org" , "ietf@ietf.org" , >"draft-ietf-dmm-lma-controlled-mag-params.all@ietf.org" > > Subject: Review of draft-ietf-dmm-lma-controlled-mag-params-02 > Resent-From: > Resent-To: , , >, , , >, , >, , Dapeng Liu >, > Resent-Date: Wednesday, 21 December 2016 at 11:51 PM > =20 > Reviewer: Ralph Droms > Review result: Ready with Issues > =20 > Major issues: None > =20 > Minor issues: > =20 > The mechanism described in this document is fairly simple. I > recommend that the specific semantics of the use of the parameter > options should be explained with greater clarity to ensure correct and > interoperable implementations. For example, I found the description > of LMA behavior in section 5.1 to be quite convoluted and confusing. > Putting the "if...then...else" construct in two bullets seemed obtuse. > In the first bullet, the LMA "SHOULD include" the sub-option. Are > there circumstances under which the LMA would not include the > sub-option and, if so, what are those circumstances? Can the LMA > decide, perhaps for efficiency, to return the sub-option in only, say, > one of ten responses to the MAG? > =20 > Is there a specific reason for encoding the LAM Controlled MAG Session > Parameters as sub-options under the LAM-Controlled-MAG-Parameters > option? Will additional sub-options be defined in the future? > =20 > Editorial issues. > =20 > For clarity, the document should use acronyms and names for system > components in a consistent way: use acronyms throughout and expand the > acronym on first use. For example, LMA and "local mobility anchor" > are used interchangeably throughout the document, which this reviewer > found to be distracting. > =20 > What is the expansion for "PBU"? > =20 > The use of the "Configuration Variables" defined in section 4 is > repeated in section 5.1. To avoid internal inconsistency, I recommend > that the use of the variable be described only once, with internal > pointers to that text from other places in the document. > =20 > In section 6, it would help the reader to include the name of the > registry to be modified in the first bullet. > =20 > =20 > =20 > =20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir > =20 > From nobody Wed Feb 1 20:27:46 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 24CAA126BF6 for ; Wed, 1 Feb 2017 20:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 08b_PDjn4GJa for ; Wed, 1 Feb 2017 20:27:43 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC886126579 for ; Wed, 1 Feb 2017 20:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2370; q=dns/txt; s=iport; t=1486009663; x=1487219263; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yiaRGkPCLoXL5oI49UCUzL3gH4xH68d3CpUewQ5QEMs=; b=nEYKw6dczFlH/oAbp6IPZ6hLV5w5k1WAvCwjX0AW8670si57Tw+rDzQl KNBFHv/e9zzNTcEvv4WnaKKPalUX98Rc1ifXWO2VyyPAZ4IT7k3QplAHN oRH0NCgvqjSXwNEMFXNXRj6hsemb3LFlwxafchnv3unBo5ieIZjuwxaGA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAQA9tJJY/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHjViSCIgMjSmCDR8LhXMBAgEBAoJAPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRpAQEBBAEBbBsCAQgRAwECAS4hBgsdCAIEARKJWQMVDq8chz0Ng2UBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEbBYZLhG+BJIEtgU4RAYYBBYkFhjFAiy84AY1vhBeRAnC?= =?us-ascii?q?JOohZAR84dlUVO4ZCdYY8gSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="201409499" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 04:27:42 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v124Rg8t027448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Feb 2017 04:27:42 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 22:27:42 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 22:27:42 -0600 From: "Sri Gundavelli (sgundave)" To: "jouni.nospam" , "dmm@ietf.org" Thread-Topic: [DMM] dime - New Meeting Session Request for IETF 98 Thread-Index: AQHSfQyxXKeMCHCZJ0+sLgfE4sMTrg== Date: Thu, 2 Feb 2017 04:27:42 +0000 Message-ID: References: <148591161114.5931.18258611553220397596.idtracker@ietfa.amsl.com> <9185B81C-0864-4D78-8753-8880F77B392A@gmail.com> In-Reply-To: <9185B81C-0864-4D78-8753-8880F77B392A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <700530B40B73484B94264FD57663C0B7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] dime - New Meeting Session Request for IETF 98 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: Thu, 02 Feb 2017 04:27:45 -0000 :) Its by design .. even your email client does not want you to leave DMM. Thank you for all your contributions. Sri On 2/1/17, 5:00 PM, "dmm on behalf of jouni.nospam" wrote: >I was gently reminded that even if mobility could be achieved by >tunneling packets over Diameter AVPs, it is not really in the charter of >the DMM.. yet! > >..and now I will turn off the address autocompletion on this $=A2@#&^! >email client ;-) > >- Jouni > > > >> On Feb 1, 2017, at 7:51 AM, jouni.nospam wrote: >>=20 >> Folks, >>=20 >> We have asked for 1h slot for the IETF98. The main topic would be >>RFC4006bis. We might have other short status/progress updates on >>Diameter group signaling, and e2e security. >>=20 >> - Jouni & Lionel >>=20 >>=20 >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: "\"IETF Meeting Session Request Tool\"" >>> >>> Subject: dime - New Meeting Session Request for IETF 98 >>> Date: January 31, 2017 at 5:13:31 PM PST >>> To: >>> Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com, >>>stephen.farrell@cs.tcd.ie >>> Resent-From: >>> Resent-To: jouni.nospam@gmail.com, lionel.morand@orange.com >>>=20 >>>=20 >>>=20 >>> A new meeting session request has just been submitted by Jouni >>>Korhonen, a Chair of the dime working group. >>>=20 >>>=20 >>> --------------------------------------------------------- >>> Working Group Name: Diameter Maintenance and Extensions >>> Area Name: Operations and Management Area >>> Session Requester: Jouni Korhonen >>>=20 >>> Number of Sessions: 1 >>> Length of Session(s): 1 Hour >>> Number of Attendees: 150 >>> Conflicts to Avoid: >>> First Priority: detnet tsvwg tsvarea quic iccrg >>> Second Priority: 6man v6ops intarea >>>=20 >>>=20 >>>=20 >>> People who must be present: >>> Stephen Farrell >>> Lionel Morand >>> Jouni Korhonen >>>=20 >>> Resources Requested: >>> Meetecho support in room >>>=20 >>> Special Requests: >>>=20 >>> --------------------------------------------------------- >>>=20 >>=20 > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Feb 1 21:09:50 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 82F60126579; Wed, 1 Feb 2017 21:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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_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 qPTHz_7SXkpY; Wed, 1 Feb 2017 21:09:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86B3128B38; Wed, 1 Feb 2017 21:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15803; q=dns/txt; s=iport; t=1486012177; x=1487221777; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RXcYe8XEFbgJOe2pkyk2Xa03uI31b1HYArcRpuOUFSY=; b=TUAQ1WvrRPuQWZsUwtvLl+ZfAB5mQgimS/wOXwzPBEYY1Rq9pmASQ32x BUTHg6wF/obqHB78NZMZX+E/b5KYbidtQQbCl4bZt+IXGoRzX0fUxavdI t56A7xcjnxCIB0fqH8oGJNs7UXQ0UdStn6oQNwMkperp4XPb23zqDUCur 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAgBfvpJY/5ldJa1TAQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDU2GBCQeNWJExV5U1gg0fDYV2AoJAPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?qAgQBATgtBwsQAgEIEgIBIRAnCxcOAgQBDQMCiXEOrxyLLgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GS4NmgQmEJQEDXIUtBY82jCcBhmeDHogBgXtThESDTYYjiCe?= =?us-ascii?q?KXAEfOIFLFTuERB2BYUMyAYYsKoEGgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208";a="206564865" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2017 05:09:35 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1259ZLq009565 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Feb 2017 05:09:35 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 1 Feb 2017 23:09:34 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 1 Feb 2017 23:09:34 -0600 From: "Sri Gundavelli (sgundave)" To: Dale Worley , "gen-art@ietf.org" Thread-Topic: [DMM] Review of draft-ietf-dmm-4283mnids-04 Thread-Index: AQHSfRKL4IsoqrqRR0ud1/efTVlacQ== Date: Thu, 2 Feb 2017 05:09:34 +0000 Message-ID: References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> In-Reply-To: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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-04 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: Thu, 02 Feb 2017 05:09:40 -0000 Thank you Dale for a great review. Charlie/Authors - Can you please respond to Dale and address these comments. Regards Sri On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" wrote: >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: > > =20 >https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid >=3Dd29575f767ce67a1e67a7767008ee6af > > 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] > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Feb 1 22:10:22 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 E0D0F1293E9; Wed, 1 Feb 2017 22:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 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_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, 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 tSdI3YHjkYf3; Wed, 1 Feb 2017 22:10:18 -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 B9B541293EB; Wed, 1 Feb 2017 22:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1486015817; bh=x3HXDok/hHhnrTVX8MxFMbwSR5qc/TAYBNkK DaTz6OA=; 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=Adjph8i HRWUukzM+PAZenxSiRoJEFlc43bMa1HkqlDDouUO/MPdOVURNH5dUTSVVgbMjmFbTBJ rxIdcBoI686HJqPukvthzIjuYVcm1GZupOJ3TYIk3LfcGfgAijAV0rtR38leIuuZtaw CrWIpE+W0qsbdXdtcuusMw+YmZxntKkWc3A+btJL8iCIIAYFfGpxLWVezbKMQuAciez RtMwc3Zcy+IA3jsPmG21scNDjVPli01/XNgK2ZCN5IAJR6tt+WBmAsMupJ/cx8fJmUt KKQCxcEzVvnIioUB4HTouqjapIzxvmCrNYZUD9I9ztdWoZC+CabM8pCI+7zHYgGT01A == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=TcBMIhJbMY+uEKw7mtmEWPKj0m3/5Y2qKUsT9+tgGvDAfKsU7bU/AKdFxcAyvUfh9cdwuMDV+D+HykCG2ZJbh0p3eR4zNCtt9fC6luKDR3dOrRqWdMiAMKsqeuoNq2dS8yv1slqAmG/grwXx/nVGSKfZtSw2C9gRalFohqfPKPSSXEbaJxkHYeEUld+9YA2jWF45i7yXqim5tpgwY/i75GAw9iAjKd/SiS8x8/ej0SSQuu8To6XmpFYFnsHEALJwkg3BgqY+pnuHu/Y3UDRKMthvjTmjoI0PloMJ6oLegvAivWHvTdHq1z7xljPobtV1gr7bWM6SQyPS3s4cxQ+Ugg==; 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 [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 1cZAb1-0000v3-7i; Thu, 02 Feb 2017 01:10:15 -0500 To: "Sri Gundavelli (sgundave)" , Dale Worley , "gen-art@ietf.org" References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> From: Charlie Perkins Message-ID: <17671de0-7238-3a3f-c5b6-d6e8bbd3a5e2@earthlink.net> Date: Wed, 1 Feb 2017 22:10:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac703c35547c62c55d8cd28b8f65ed96334350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: "draft-ietf-dmm-4283mnids.all@ietf.org" , "ietf@ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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: Thu, 02 Feb 2017 06:10:21 -0000 Hello Sri, The review was indeed super. I'll respond sometime in the next few days. Regards, Charlie P. On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote: > Thank you Dale for a great review. > > > Charlie/Authors - Can you please respond to Dale and address these > comments. > > > Regards > Sri > > > On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" on behalf of worley@ariadne.com> wrote: > >> 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] >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Feb 2 06:10:41 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 4D337129408 for ; Thu, 2 Feb 2017 06:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 JlYjB492XZ7O for ; Thu, 2 Feb 2017 06:10:35 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0109.outbound.protection.outlook.com [104.47.37.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10571129453 for ; Thu, 2 Feb 2017 06:10:34 -0800 (PST) Received: from MWHPR05CA0001.namprd05.prod.outlook.com (10.168.242.139) by DM2PR0501MB811.namprd05.prod.outlook.com (10.242.115.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Thu, 2 Feb 2017 14:10:33 +0000 Received: from SN1NAM01FT045.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::208) by MWHPR05CA0001.outlook.office365.com (2603:10b6:300:59::11) 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; Thu, 2 Feb 2017 14:10:32 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) 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.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by SN1NAM01FT045.mail.protection.outlook.com (10.152.65.226) 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; Thu, 2 Feb 2017 14:10:32 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v12E8Lwf046753; Thu, 2 Feb 2017 09:10:31 -0500 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by preapdm1.corp.sprint.com with ESMTP id 28bpjavdjt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 Feb 2017 09:10:31 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 08:10:30 -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; Thu, 2 Feb 2017 08:10:30 -0600 From: "Bertz, Lyle T [CTO]" To: "Sri Gundavelli (sgundave)" , jouni.nospam , "dmm@ietf.org" Thread-Topic: [DMM] dime - New Meeting Session Request for IETF 98 Thread-Index: AQHSfO/S04P+V84qyEyPtrcOZYZ15aFVhBgAgAA99QA= Date: Thu, 2 Feb 2017 14:10:29 +0000 Message-ID: <9ba13f0fda844adf9adbdd94d1d12a7d@plswe13m04.ad.sprint.com> References: <148591161114.5931.18258611553220397596.idtracker@ietfa.amsl.com> <9185B81C-0864-4D78-8753-8880F77B392A@gmail.com> 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.123.104.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.80; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39410400002)(39450400003)(2980300002)(438002)(189002)(24454002)(13464003)(199003)(377454003)(345774005)(97736004)(68736007)(5001770100001)(33646002)(24736003)(47776003)(106466001)(229853002)(356003)(2501003)(626004)(189998001)(106116001)(93886004)(86362001)(5250100002)(2900100001)(5660300001)(6306002)(39060400001)(102836003)(6116002)(8936002)(3846002)(81166006)(38730400001)(2950100002)(81156014)(53936002)(305945005)(23756003)(108616004)(8746002)(50466002)(107886002)(92566002)(7736002)(7696004)(8676002)(76176999)(50986999)(54356999)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB811; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT045; 1:1BwAT4hKA7mUXWxAcJ2/KL5eFObJltnthjo+30DAthFzIrzhTrcOehaq7mryjn0MYsrYO5aOZpStg34QNuJ9/W9JNo2EYprSdlVIlPg9o3D8fSv/4aXu+7xF8ElmSltTD1sDsj/EypNLgXXKpZrAk82U/zgDesoSt93BhOFn4M8PmV/HEI92XWF0PV2F9uk8SNyIuQvSejXA2w0upPFxMe7dwiPtdfaPgI3CfJNz8sJgJ4xP98AjBFvYWRX0in2hOrRZqO3MX6um0APGGyir8Ofl7g5q3MvNpk7TG7bg/+lfZZNAppWCQUeJtsP1aZj3+JJPSdj7tdtgGOVWCvd4xFESvfugsd/+RrOk6Er7Lyvv7dMOckuPCfDt9WXeMOe4RAxpa4D4UHlCX52yhhFhjcYoFPlF/JWaYF3N3v1SVc0U1cHR7eQePJWTs3EqwR8oWqlNLLYja/ureKvWp0G4SZnn8dIN/bqVJT7McV2d78mwJpXWHX0F6CayayPgkHnCAIfijBFkHcuc9qoZTBPIm/7QMu7znDqRMiVLEZ/KV61flYExIUeyKSjJVDvIBSYBgQbpjqc0dg0pjS0XQF/L1d43BAiWg4SbGdBL0oWMsbzqs+SLOupVWdvYcigjOPmA X-MS-Office365-Filtering-Correlation-Id: b1fd7f5c-b558-4543-ca01-08d44b754000 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:DM2PR0501MB811; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 3:ff8CnQTqjWmfhDdusTq9189fRqEuqycj6C6E6WkmF39Fh+gb3SYwKcTzbt09cLPd+gjiqMjDyA7AVowOaH/d/xCNfv9Y1sNXKOksPbamSXIfEnXAw30BBox24/cET1Q3LeZ4+x+wSFC3iREWrjRDwugQYu1fTtKH5j42ojYYcN69IX5kjZfAdVhuJQaQ8E5LB77Z85kh2wvJtCcAx44cZRNEzxRnB99+8uZsF3JkV1wVGK2+vgSZmGDbPNsddECtBzhcwPDaf0fC4Uzyi3goBjVvgWS7XflZdP7Q95LCsz3/KifcTuoX6EtVFQk14ideFcpgyih7UQjFtw7I7mdzf4PSL724+fTJKgk3gxDxBbTns6Dkow2coSNsCORGenH6mf4P/f/CUcmZnhqvTUok8A==; 25:DSXboSIeFuTs9Xxf5R9Iy0GRAPXFCI5rr72MDhiSSqRVeiGPNOcnsjAnarRxUnogLbIRoEiHjnGIQmD029GD1boLMupV3qR0stMMP05u/pl5lIaoDS25FWoo71s85IAe8JCWGYCelVbwJWybDPbg19jLI8SSNWvD+2Edja6c8mfHOyyivnQg/KZEmqnOwjf6ZWPsd0q6uvCQLbE3vMNlELe0AhU8k4CO0w0o083wq5491bKhuiCGakx3I6cefC0SKVxEhbtWbu/6otdTwTePHbe3gz81bbLWy56KQiAgcEmQUhp0HhIzFUV++jJsEXiqJXFfEQXkiVptepcMBiQF3X3bo4qS2RE0MdRS8AS+hjNF11wPXHJ0bW4USihK7lHz+6KmYs2LphprcbJYIQ5t0YeSfHQTNlk83G0MC3eMpxlRZBADDvvXJoMmuU2KL5ky0mD0KbSFob3YlIZhKnhhow== X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 31:xDSy8+vjpx7cI3t78hBeTG6pqc2OjKlc/LrvFRv16tXn/vgIisco6MAs4uXDu0SX2G34D5bCQcq6J63OEp+ELHHoAUS+rn3T+VfZTf7cW1vqrY1HTD4eXTcXj++ZP3KCwlGt7nfTkx0rxWdWxqJCPaC6bwJd/Et/Dx+rCDb4tsNhx0oo/t9OKONojguN7bdWDziqGlBMwJZnCZtiq/0AMU64bCqcJS3CiEN7eDBS6XiA8A2n+onEIO81TMR4bfS3sr2SEItfD4UJfwuVTdhKMg==; 20:8BKDVZdEmude9IJXNv0qgCP9nrWS2wnQ0HFtLvCu4VpHhUhLQZqzZsS+1l9ivOv4UEUARsTCb70TaaAhxPYRCt0RkLYx2LuZUpppwBvL0UN+0BukuhWxTKZv3uPJCEnmtEysyymDPheFOKr2XMjew0Crto+WIGkuSTQmJ3/3NU/9iJWZoZ6jiz5+dZDo2QQrOuNjBowjV/4SRIoT59dJ6LYDdWmH+mI+XPYH9OyR4eLnQ9JNUBuv2NfX7LCtmphxuO7SAKZtkox4dNluitLWVy4JbOzb3PptWCusVz17eVJSGZhqUJobtJaHDIe0m/0xNeRbci7IJJdNJFg0GtP0VjAd/0/3/zPTYXU8PGMz1WP7CVSjK3J8uw5SrlrAwsNiNsglmLVikeU1UGTRmnLl7lAXUOD/glfBMZ0QKHT0iK9jzp3pgCDvfBSpl7VWL9iIgBK5+t8nvdC3+ZCx3h9gFAlZgodORPXL16PpZ/aFw4sLmgXlOaWdxj4jS5ZYimBg X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(32856632585715)(18271650672692); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13015025)(13017025)(13023025)(13024025)(5005006)(8121501046)(13018025)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR0501MB811; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB811; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 4:tJc4+LjV8G5oGqmF/tK1AIEC2d1Y6hCgQHmqyz8B5QKy5LZSfFEPGgmcICdL2nHtr6tRm81yYtJKXqBlk7gTb2ArgTH2SJxGZgKI6aTNZvc+tuer/teWi5Ey34xArSCD5S9P7F53mOFxVGGZZzRobtAy15WO6tPOy9cXG3pXub2oQ/596ZIDs84ASvfQRQPHRzC2zIlX+yNhu4QhxmUhnOqZ/fRNlGUkahw+0VQ/rWeZZuHGcA8DkBXi99/ulnU4uHKPmSjN4hC9X5+1VeVjQbCXMKdOSwq+rNu+GbFiUFgJgugMD3y9RKRddA/YB650YOQ8uJbJHQqeh6ir3iAkRUiaKRu/vrmFNJS/kcJQDactIaE6vx7JQj9dKBeBv880pPLlZaI4KGDlr8pp3ISvaithV7qE4mTeuTCPvHykJOF/thde5733sBX60UxLF1VPSph9+ZW5D1mM+WXl5/9bDxDkPlpz2MLx5k4Ojo3EHtGjHDGM87nkProYVipkRVPAG8CrWyETJFCnA3DXMIKONPk86wvqBVRNEOR7klAajd8pXGT6za5gnRwvTbrHIM/jppeI4IhePoznHqOWJE/IJNNdBAJZA6sqnYCRKWXsgOKYOx+KlhABEqzzsPUscNrfTdpyVSFAch3FXqlqxwjuSdq3vcfodddMXjbTY52tjpVT8C3JSHb9lotv6CDDIpRcUPFAtiUIn2rilGKnI4hqMCA9mtuw7rB4uZuAPJz5t0UxnBqmAXgCh8dUwz/U9pUOQzvxsRGzyLzL0GDzb3i76gVXM+F65/soblWnFXyyHFU= X-Forefront-PRVS: 02065A9E77 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DM2PR0501MB811; 23:e6G0JG7N3ZbGRok2JyQOlSHlAjClQqKWsL3eZq?= =?iso-8859-1?Q?soGe1HMQw7kNl8R4C57L7Vo+AOZhKdCeYMWaDe2l9NewxTmBE2MjG0GXrI?= =?iso-8859-1?Q?ncmew1ZEjvfBmMnE0jzqBsPOhD7VG0WKIDBui2nZzSxBvCnr2e/nh1chwO?= =?iso-8859-1?Q?p0nP+bA1J0C6Pwo9w0+Rl0qQoydMrP9hgeFEcgg75AojPRScgxPkxEehl1?= =?iso-8859-1?Q?6/k44P31adjhBf0FKwoCJsXf/XII86d2P8UPZ25KsJHuwDUSfc5io/g8jd?= =?iso-8859-1?Q?2GVcEcPqbFLYGxeocUEDa0U/2cexUkzntmpmvCGbiI4Q6MoNUE9ce3VMdi?= =?iso-8859-1?Q?YRLD5jpkI2ZZsJfW/MJ3Usii7kmK/yYAZAIKynCy5dPn4U2UAf8kRRIEG4?= =?iso-8859-1?Q?ue9duIpOFsm0Dd4rWhASPhmlgdfarqDSgZi8oqaDbSMnmHFzUzov7oapCH?= =?iso-8859-1?Q?aeXwSIv75fBh6lPMNSxCy9gnlkCXiBCF06Pc2Ga8uzlXhKS/Jaz8MpeSo8?= =?iso-8859-1?Q?/HQjJzXOYQyzh5E+E3VPderM5E+LkQB5w1ro3T7fWFF9IoX6KSWiPnWbBN?= =?iso-8859-1?Q?j65vWLoEnu8SzSylMCy9Q+BUDQMnw9O7Uz+nsPIeuJwxeQlwO0UdHDMqcN?= =?iso-8859-1?Q?XH943cnV1YbjvJGA2MZNbQYNhncNEOezygBJmPQsBj+b9XtSTR25/ACp4T?= =?iso-8859-1?Q?jzzNfFG9lhzhM9hMxuSYqnB30Um5FHaKy9+QVCfjWsJnTg3yo/bP6azxti?= =?iso-8859-1?Q?DhNVz883UxeFVHvCn2vgPGDOziWb62F7H3FrasL/PDtsRcQljvYg4eGkka?= =?iso-8859-1?Q?OK4QPBDPQGS79DJoDA7KxVBRjwWeLKkHvM+gB5ZsctHH95LsuICo/qtJE7?= =?iso-8859-1?Q?qc+RGsiTqDp8xT7gKkY8bbFOVXHqRq9DpLs+Gj5Ipzqo747P/99qxjZrBJ?= =?iso-8859-1?Q?4QbeaEWhyMZztVaEcuOYOPm/60oTIHsTqlPWDVIgsUBH4tOXy0XPqn9svN?= =?iso-8859-1?Q?+BsV6z/Buw3y0lNzlAArUxpJGQhduze6aVtPD3yRyB1eQGeoM+pHyOYb7Y?= =?iso-8859-1?Q?BUHUnvgdnlY4W3NWLIhHyIzTmZDDpW2QpTX83Pr2+ObfxbYCcjBwe3xpIM?= =?iso-8859-1?Q?4j5baQFK49QgJ+Kt7yhW5c0NpS++R8MSjiE1dGs7QzsN7RWmLa9kMMOSos?= =?iso-8859-1?Q?8yvvvYNEc8drr0OHf34q9+6q3Ph7FCUq476By1E5aSwdT5cPuXGNs3w6M9?= =?iso-8859-1?Q?/R5uqSnDKHqg3BDPQ65WmELIalOKghvOHjQ3V9enfbpQpiAkM+J4CrVCnz?= =?iso-8859-1?Q?7Rh1dGa9FwtKqKDidQrOVfPMqbzb5e83oSo/70alg7RCcG+UbCcwt72Uub?= =?iso-8859-1?Q?+aI4c0/TqFTOuNeoIvoA1ztTKWGN1B6uHkVbacSZrZyrmz3vBGRnjwXW1k?= =?iso-8859-1?Q?DXkx8PzDeGhhisFrgu+yAmyuFtAdZkvfJIXF?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 6:dGS0K77F17llLqXEV+i78tG1VfBI+g4m8fCzOzlvP7uaYPPtfJYvvGva5pHGQkvM56nldiJhPwh7c7uJ2HuucIsZFmtnafIqilu9kkGfn74OQdXnoHidoOaRmyEUHbyO+XxSnCW/iAHTtUqZxNTs0WrkOJ76cQYIhYc+LVauTUMD9Qrusuwqz1cL1dAgzU2LORZa76/EO9mDuA4OmJw8DNWfnF7+bH4OqNccsZzgDpfVhvBfPU8JWlv5T9CW7xdalzd1txiiSyWTmd0flU2FPBgud0PT2UEQoLPKmEkMGllLFwuzXS6ezL2hVKDzPv5knf6TNFCD+vOdR4AOMZQ1pOBJJRMLz4ptDxZZvA6Cp6SV5lAJ4SVPtO7LUTDSyHYw+iESSiZ6Gmh4ZyiFwPKKh2L0tS2i4BDDzQ1PqNY3qeg=; 5:CpG3OSy1u0ieqdLuee/OWrOob6Fyq67l7LsGIR/pJvSrRQ5wLpKanxD+9vqZTTWPQm6XysnkK69F05Dw0n1uI/ObQYVHyb9+ro9riawMZOBedWyaTx5jmplBG2FNmf2SjxJnAiXu901KASH0CsPEvQ==; 24:mfhZlqG8zyDOCHWHv6e1WRC5tojnBHp9k66pn2zVU6FCDAp062IL6GLHVGloPmRLT9XWDOZ3eZhjBqDud5lkokAqnPH/npD+fo7CiUXNNQo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB811; 7:OloIkOLn07Yfyx7u3VjLMHGUvK2d4pS3YTTMOCaHcztdUAsG7Ak2ODzHVi/pnYDAbkK0ral0cdyMHTfhOqlHAhf59cRkbiflVrErX7junPgxo5KYqWWzmbaAIG5nQnpRa15ZigcVoHLUOMenobeyTzuXBKaxpDzbtCCeOk3gwNnI6ccSD7skN8jH52ODWDkX7w+5vXSUMwlEfqf61zMQzdeLblThDzye0N6ivyAuS16C9kB97IkIyuHV9V1S+5PVwOFZPSr1aU3ckXYnZFxnJ9SBCmegHT2NB4HKZnEOq6RZDcWMcNku6/0xskzi5weSW5JgnaD+/TJSpDu+xs5RxImFS1IJedeFGJNu0hk5PbZB6CPncH2JZbIiC1IZ/hAmcZHQVSOBj8WeQ9YKpJ6i+BX2zVRalVzuqTipHmZb/nwp91cQYUeKbGgTUv2Sitq1bi9xlt6VxzgHAxxXWCEbZoU/J/yILcbmuf4bxzy9tV5bR816JVvK2sxJ0VV1AV1wEfNxeavtIQtyb1AG7oxKhg== X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2017 14:10:32.0632 (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.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB811 Archived-At: Subject: Re: [DMM] dime - New Meeting Session Request for IETF 98 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: Thu, 02 Feb 2017 14:10:39 -0000 k. so it's not in the dmm charter? Where then should I submit the 'mobility over diameter' spec then? -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Wednesday, February 01, 2017 10:28 PM To: jouni.nospam ; dmm@ietf.org Subject: Re: [DMM] dime - New Meeting Session Request for IETF 98 :) Its by design .. even your email client does not want you to leave DMM. Thank you for all your contributions. Sri On 2/1/17, 5:00 PM, "dmm on behalf of jouni.nospam" wrote: >I was gently reminded that even if mobility could be achieved by >tunneling packets over Diameter AVPs, it is not really in the charter >of the DMM.. yet! > >..and now I will turn off the address autocompletion on this $=A2@#&^! >email client ;-) > >- Jouni > > > >> On Feb 1, 2017, at 7:51 AM, jouni.nospam wrote: >> >> Folks, >> >> We have asked for 1h slot for the IETF98. The main topic would be >>RFC4006bis. We might have other short status/progress updates on >>Diameter group signaling, and e2e security. >> >> - Jouni & Lionel >> >> >> >> >>> Begin forwarded message: >>> >>> From: "\"IETF Meeting Session Request Tool\"" >>> >>> Subject: dime - New Meeting Session Request for IETF 98 >>> Date: January 31, 2017 at 5:13:31 PM PST >>> To: >>> Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com, >>>stephen.farrell@cs.tcd.ie >>> Resent-From: >>> Resent-To: jouni.nospam@gmail.com, lionel.morand@orange.com >>> >>> >>> >>> A new meeting session request has just been submitted by Jouni >>>Korhonen, a Chair of the dime working group. >>> >>> >>> --------------------------------------------------------- >>> Working Group Name: Diameter Maintenance and Extensions Area Name: >>> Operations and Management Area Session Requester: Jouni Korhonen >>> >>> Number of Sessions: 1 >>> Length of Session(s): 1 Hour >>> Number of Attendees: 150 >>> Conflicts to Avoid: >>> First Priority: detnet tsvwg tsvarea quic iccrg Second Priority: >>> 6man v6ops intarea >>> >>> >>> >>> People who must be present: >>> Stephen Farrell >>> Lionel Morand >>> Jouni Korhonen >>> >>> Resources Requested: >>> Meetecho support in room >>> >>> Special Requests: >>> >>> --------------------------------------------------------- >>> >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ 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. From nobody Thu Feb 2 07:21:34 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 35D0F129660 for ; Thu, 2 Feb 2017 07:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, 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 Q-RR1gR0Ghnh for ; Thu, 2 Feb 2017 07:21:21 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3642B129657 for ; Thu, 2 Feb 2017 07:21:21 -0800 (PST) Received: from BN6PR05CA0029.namprd05.prod.outlook.com (10.174.92.170) by SN2PR05MB2495.namprd05.prod.outlook.com (10.166.213.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Thu, 2 Feb 2017 15:21:20 +0000 Received: from BN3NAM01FT059.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::207) by BN6PR05CA0029.outlook.office365.com (2603:10b6:405:39::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16 via Frontend Transport; Thu, 2 Feb 2017 15:21:19 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.36) smtp.mailfrom=sprint.com; sandvine.com; dkim=none (message not signed) header.d=none;sandvine.com; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.36 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.36; helo=plsapdm1.corp.sprint.com; Received: from plsapdm1.corp.sprint.com (144.230.172.36) by BN3NAM01FT059.mail.protection.outlook.com (10.152.66.160) 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; Thu, 2 Feb 2017 15:21:19 +0000 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v12F4gSX010608; Thu, 2 Feb 2017 09:21:19 -0600 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by plsapdm1.corp.sprint.com with ESMTP id 28bpq2vqvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 Feb 2017 09:21:19 -0600 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 09:21:18 -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; Thu, 2 Feb 2017 09:21:18 -0600 From: "Bertz, Lyle T [CTO]" To: "dmm@ietf.org" Thread-Topic: RFC 4006 failover of alternate and backup servers Thread-Index: AdJ9Z7OeVfUUcAVaQfyK61B3O463oQ== Date: Thu, 2 Feb 2017 15:21:17 +0000 Message-ID: <381a7094da9a450e973900a8d138859b@plswe13m04.ad.sprint.com> 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.29] Content-Type: multipart/alternative; boundary="_000_381a7094da9a450e973900a8d138859bplswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.36; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(2980300002)(438002)(189002)(199003)(2900100001)(6916009)(626004)(8936002)(7696004)(68736007)(5660300001)(5250100002)(84326002)(102836003)(97736004)(54356999)(30436002)(790700001)(24736003)(50986999)(189998001)(6116002)(512954002)(3846002)(2501003)(33646002)(86362001)(108616004)(106466001)(54896002)(6306002)(53936002)(38730400001)(5640700003)(4546004)(81156014)(1730700003)(81166006)(7736002)(356003)(2906002)(2351001)(8676002)(260700001)(92566002)(54906002)(110136003)(4326007); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2495; H:plsapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT059; 1:kfhr6Uhr509XlK2syhIlybA4HPbAhuL5dQJlYB0AEtDvGP/bhehy4kAiZVGaPMHZMVcErSVgWd0XiT2GtpnlnZQI8XKUyU4rrIlTFQs3iIhlks7fUIfEDnwNCyzCxkymdSfuvlvsXhfPgu5y4ocZyWa35nVstopjUs+VCSzWLCyqtXlAqP4opV3Vmu2S4A7aS1xXTbFUbaLaCPsKlRwKn3sgBEtyehXOxKr/cB/hhB9rRxcODjSQ2w3jwuz/lDVMNx1uHwmCN7/DwZ5on+PjctIUVqhSHcCP8JkHc/pNRdZLVqTz8UAOJWf2qXHiIy5xYmzKPVbfWcb2vL9zaLWLG/Ofh39XxkeMRAWaAaXE1Eo8tLPXS0D2ZIK8syRycXHqIRpX+yfJG5dcMZJRW2wHFjwoRBqDbHvwRCSslVQ23AFkM0KSGKk+T5MKOpM457BucCdOQ96apCozDNEuZZn2OH5eK/iV0ZZvXYlKawnd/AF147gdltzHVGQf2KV8c5C0U7mqnTo0S+hghDQJN9p6XhnDVyzyErVFD0178loGUQN+VKrCMzXgGN3hcJpV+Fq9lCAZ+n8NvarVnggTXM9s8rfkb2hQ0zbLJhNnJsUDEiU= X-MS-Office365-Filtering-Correlation-Id: b0814587-e1bd-4a1e-2980-08d44b7f239c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:SN2PR05MB2495; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 3:gcfrg9m/S2mxTdrg52hTmZKrQvM5KKxzK/qDnhb357QppFG1EQKbWmFf/HBXpvoDPSx3wPKeLYPHfWcWn5HfIU+jJHaFl7ju2KwoKyHIUWdQXWWhBZn33ZL/C9AlElt91MA4IagwOeJle9wNU/wGiBw3/ClZFtx7DMI/76iRmBrU/jU5zgO00NOR2fqQ0xnSPEYRfrMhBISV2VGoJ9mHdI4/Q3DKZBdR85EWFaGvSN5ltW6Jawrq8MsD0tl0VV6num+cBBZS0ea/jg12fPhDNM0SABoEEjHgGK0FAeVEOSE7lRdfqF3RK0H+kacCUq5r74S6s9MgzViFf/6fM/k/ZWm76xvYQ1TEwXrcOsn6WLEqNeKaJ+S6XAhe5/Em7BBMuaaQxflgIzP6O5ZJiGUGvw== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 25:s4xfzIWVi7f2Pnae2aRver3zG6E+nNRPOA2hL7AIOJkCeZEXg8O85sC+EgWv6kTtbRV1pol7PTUE8wOgvhvjvQGk612ZMY4s+ClO8x9nHH+UvAlzh22wn77WvtA+Ral0KnDue/ZSL5E7W/0pT2Kr3iFWz3yGI+jNJzMdx7XWUv2LtI13JsMDY/J8ZTLagP5mdq6LGdfM4n+w19gPEdQVtosabcEshFP8AmaazgLx14drMaz9+FKmY989E6Rd6h7diKP7/lU4yxLlqKirHNbQy2u60Q8uyfwp0/0+nz4ygE9tQbo9AMDzENrR6mNfreN+npdQYBe8C9UhWoFs+ratiWp6xDJiAip67tlqJkIoEy8crtVyAAEuETPZA/F/pKhlreJWbg/GpjrCdgfMp/SOoGrokHjIJoOFW5D1GJLyucu8dVhMEbBK5tfAzeKj28NmM5FbVEYj8rkaEfKRRjPwsayyeAirQ1AvBCsT+Bu7Y1eoAsj16Hv40rMu2Ep+MMnGMujtafuA8tTAbMzXisBE316VyO1QuAof5rDgg7L1cFMrFgZCLju85B3ti09AHjQ1pmS7Qu5mJZXTXNH3xmSyew0qdzunayaiY3ryfE78AZvXXmIIJcfhj7t3t32FEm+072wvgnNLd/Nm6eHkPGcVRDdDBexWrca/9t6D9UqlEdTWUOGAJ1z3hE1h7mXxWCgfV8Vbrfi9GA5sJVwYY68fnmNJcmWSgB753g8LZZx3TfnspNvckuZ9bYUMlc7eYgg7TjsrhvgF4P1VO4XHwkKJlat5VXsoPF9NItoyEfA8W9gfDQtzSk/jLmaQX5wYX9Zqwl4HRkDFXg0PNmIObFTaIBs4Su4jN7G/Ha86tB5NjtdT7WqsqfFjcU38Cc86z1TPEy4cjAnpq9S6VS6ip57H/XdyWA1LGnMT6lR/IqRu2kc= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 31:wf3mxC81pWnAeZMurRpxOXQevZiUFNMZFwUCU+BPjMOIKtMD/VNLid7GcGyUZqf6rXN537knb+cB2qqhZHXvPMM0F8jXQl/0jauaIuv5gT9+hF1uZoK26UMeTR+z+2QDx9YQ0n4tYv4xxxAWRT9ibp3HqRtdbI1HI+biSU0hz5HvBxNGjGOgDB7vrtvzCCUSmmgmwzkVyuvc8VED1SyuRwO5wDHG6VnG/QXHedDvYM66jRG0NoXmtpqeTM5Xbyg0j3gzVJ/40usp21mmwbSZOw==; 20:fW45JVmEQmC2O/FDi5JTAiwsjr3bDZIBiptegYRGVej5Z1VeqQ6jWqSPgEXtSal3G9PlmXL0KwJ1OCjoc6udrIgneUk90SBA2o9WKmjGj+6NayL2gFUPwsjrETHSjQO/tmVe7qwFSJ54eKpO9r6duzUSXiXV9X2I0lAJBeAk0x+YxseB4N1U6UeyRtPlWjHMqqF0mhXQtpLnUWggsxL+Ion9C2TnsuHjblqsNwnN08zUuXaySxJSxHpKCgciYqrBb9bt6A2h5pZKmJ7MiVJ8NgQhpwT2woLMtKXPOy83BrHWnMxWKPyWaSZ4mRpdTHRRWESxuGP4SaNufbq7/o5kWrgk920dkmPH3yx/+O3X8hIGGWUmb6+lmkehRenbRywdlC2IQrhatARi0hyDyeBMCO/4QhOLNOUMr9FfDHW5yDHV+UQt+AoZDIrBF/hFCYULVJeMklte16A2Ub/pGVuLo97nBvDllUrYEpIhV4P7+n2eOx99E0CXeeJgmb6ZstYn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13023025)(13024025)(13017025)(13018025)(13015025)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR05MB2495; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2495; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 4:ttkyL/bWFUcup9dqi7Jp8DTGERKyOd3plUDNPE3kpZR0kVTh6/3EvHWWbhnlAttoEyOve14s4fBmBTlB4AYDkK2yY4LULnOLn0YfWhjG9EASOLR6KX2OB6fIL69SMN0QcU+VB8Np4q2Pjm/ZrDFEMQTXG19PCWyAzPknill0mtVBBVIA2aDAYacdijqwUzDPnmu8jjc/4j7xAmR1suY+QuZMHLFxfESxLvEBnt1YbvQLuedXIdMG4EpShLtHYaJSxjComqSDOiPfO+/Z/wmZycvfonnbrOhPqP0+1dmF7ScXj+c2zG5tTV2y7z0S3EtuTN8f7NdYYnBWHRF1XsPMB4ZoHF9dOJnDsBA7iMfyHibyA3rgpZ+T5vbiTwFnGoNCw4xcHcPv/aZWpfIXS2tOTNAzn/DeNKOkB6WCYWmnfzyOoj/n0ndNOxCWwhCbH/UYAbsaG4DgC4n+SKuyFFWwdI8NIBoGdq1uXlIHIXn77hoAbu6BVoZT03nLuNHM7ip5Tm/q/d+Y6v3stcY4JkSv/xRo/ukOtX0s0abpIWEpjygZ5qUvzUTgbnJjySgyfIy7uW9z2ycDI/6WylUceKzRHTFei+Li64NC7XXbilEcKkGpHLxCLhCSQo3TDlczfnjXfWdye6Z2AZDGCWIzp8vWLs+pw+JG97Uw2W7d6r/Zf7E4FMtYpjrFLcwF89KUbrLf71D531oHDBJxAxMpIKv4fCN0Dq5sTFIgexmt3fetF2F4SxQjZWx9X0k76T7LIZ4s8RvVFeo07aFSkSo5QOdYp2bCD7lKKUwjVyfVGxbZJOA= X-Forefront-PRVS: 02065A9E77 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2495; 23:ReK53nNlxZ2LqSQ0YbqtkksdpR7IQu9yTUH8iNSYl?= =?us-ascii?Q?ycGs7bvNoWBuBBxObe/zmI2TdFlW2ahWTNvPo8nGVxusPmM18vhv7PoJByWe?= =?us-ascii?Q?kDfe/zpcWE5yEINb0ywQxpibrxFJ30KzMi7PbSNpjibsE6BiOvznZVifaONx?= =?us-ascii?Q?cPbd+jR31F+KREgDRbD2lVfHWIjeS7qB2SaVdPalp6gx04ajECOdZIqDSoT/?= =?us-ascii?Q?eUoF2gN6vhDDV/jO0vMeEVQbqiT6v4vD9fb2umzlHnbYJuWY01/yXXx9hgRk?= =?us-ascii?Q?Vc6Q+yQ6SqnotOTHBX6GuShCli8jtoZ4/gY+inIsQw6N2Ea4LUTwAFWj3azd?= =?us-ascii?Q?Qh40J3N7sKquPwHPJzFu42PfCiFe4bO/o0FzgTRGoSYW/txvNK71W8F0gjYF?= =?us-ascii?Q?za5RwTymuTGb0bcx1Xc0ILz/5hWDy2ck42Pr7LNksketje+17GbQLCckybTE?= =?us-ascii?Q?38naKiLIzi4fJrsvYJJy+QVjDsHAZYJ96AY2mMcekX5o+VswLwqjm2B08jU7?= =?us-ascii?Q?R2qlS4EkI9PcbKKKptpcUw89w/vlDWLVsdAzHpVINw/HHK0kP5HzSQHn1xxs?= =?us-ascii?Q?FEs2i7TBgumlxgOIq9cpjIGnXKNcrUqfd/FJXF/DPhKyLdAHkBDRQN1Vc1rW?= =?us-ascii?Q?Vbn5lxugY8rida+YverW3m1WtN891Ezz+UHzuYYPe8MZfvqR7F/Qbe0JjKpe?= =?us-ascii?Q?jgSt3rHBlptSdKvVCHEONEidA7WbCTD9B+Yz5uAVnmi6Pg4G2WWWOp4fzXhx?= =?us-ascii?Q?aoM5rQBMjNrrisKAo+sMpwW2LJpEaRDH2cku6Q8mJulsrg/tbUZ49Yx79Lvy?= =?us-ascii?Q?4jYyEHL1pXJmjdp7YIg5/RjFsiTIydDR4Ndg0LqR4GrkhFaTOgiJX1EqhXnL?= =?us-ascii?Q?Lex7NSsbrbBd8sb0PvS00rQ+hO9JKQcQhUkrnKqraVFnlRbIiNAJJcM9LwuQ?= =?us-ascii?Q?gaJMMXTFORB2opWBA16pXqoWSQigeDL3+dtbJXNWq5izvgkyDkauk5gY/Vah?= =?us-ascii?Q?mljvIVgOiwQkL1ZlObhMcrhY+UO3br28laxIYz+dE16pkd6hkyVreE1CT+/i?= =?us-ascii?Q?Udtk4ALJ3YFGO3AMoSwxK1cZ4JqTk7CrVxur3yEsNjAGMFCiNvjaNiIo8KGV?= =?us-ascii?Q?1FrJqnoHv4aH9Z0+2/NsbZw3tuGfB6ICi4FFzPg31l6ikfKPsXLl7TXTM/ok?= =?us-ascii?Q?Y/x5h7tJ8tY4n+EeyJlShOCwkVGCSricBtkUv0qkgD8w/9EaTq3vfQlptfYm?= =?us-ascii?Q?pFby99I9RpeUuHNWsN4Lm3nSFKmzVmY1UZAeZ5T0D4heKJbGkXkKntFeGzKd?= =?us-ascii?Q?aGWN8f2hWu/p3xMvlPo4d4=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 6:dZuYxjseLpyXrqLwsBL2N+O9TGbOc+cX3jqinpu2Ska5u3IxBcghtQN/axdbdZ+JtAuGTTfueErOziuZFUoUZyrpNLJqcbWACkint3KtkiH+5rMofen5dB12G8r794zPnguzMCPWSvc/bt8WdGAmD87mzOoYMrVrN5ysc4SILR15Tbwv2w1FYCeA3Qs5h+2yRkew+co8im074sK9XZalOJR6lUCFEdcoX6959CYrb/hs3z96+RA85Yaez3MP+lvaDD+ppZ/FrPZha++LXDzlVd22GQ1oltz0Jkpf2j5+b3JoePCHWCZ+biYaO+y/l+1jwe9TQukEcZO1/Ps6Yc+/og4ESxuaCFo60E6Vowerv50rMGWBFn1pJFwnXYUQ6xZ7F2i9+dZ8klGPyKAlIyPgzbCPElaothJQaGbgT9tVfSk=; 5:93DpAyAqXaccO7DJxZar/B8Oua2QIbHtNmmRl7ZF3b81RlO7mKqizaQuxgsqku5sS4Kpdv6aZElJ6r5nwZm3EjANgeYsnzFTh9C4JGLTu2gCmiQ/1fCbciuPN2wEmcDtNeVsfK/SuvYRmeLzI9053xNDYEFrDnF+BhqkrGc0VPE=; 24:7wPTAKQemHS7b2s97AmelxU7U6h22GiCfg7e/j4mc/Or0cdxlWnmUvyR8K+gRs3KuoT75nj1Js7OQ7efOStYFj6G6Ojt6W0Y6OD6LFg+VTs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2495; 7:jJQaQmwNG02JgbdptpzBJkaM3Tx1Gmu1uPG+AowLzAtyZI9odoFyRnf7nDVS5Tz5N4/JVpb44R5l64raHpsXVWkxmjoZIXA4Xkxyv7DVZ5QG0ruxu3U5NxIOMkGDgUWay1RsJviyrF8az9z2bf5Vl351iPhQVYbZP5JyOtgTr5Th+3ypN0CutBYvpHvbmcRhKX9JQdM0VIsRoH/NbDpzIhzNLQcbFH5OBmVEkZr3rSqVwrLG1WDfa8CbXuLMvCZIvl6ZA2e7PWqvoGa5YosEj4g5wgg3yBZPnYCweOFXfhBs0PdFGwuUOz0jJ+3M6oBIW+ITJ9aEEKniMXrGhZ3eTDrrBVQ5LsWtDoV8LLHUyxZHI3wgM05piLWlJMhsQh7ITZY9HhwoWgCWymk+GgTAB4SYnnmCOv0EeOmc6M+eMGDLM35TDwOkzREhIG4xMBXyghzgYXZOErytcZ0rFGvpc17hCiOAQpBAvBtb7wEzlJsd+OZgAO4bWfDYzqDaYEkNocNF97dg8HFcsadJR2N+dw== X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2017 15:21:19.4730 (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.36]; Helo=[plsapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2495 Archived-At: Subject: [DMM] RFC 4006 failover of alternate and backup servers 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: Thu, 02 Feb 2017 15:21:25 -0000 --_000_381a7094da9a450e973900a8d138859bplswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, The CC-Session-Failover AVP in its definition uses 'backup server' but the = ENUM value for FAILOVER_SUPPORTED states "Moving the credit- control message stream to a backup server MAY require that information related to the credit-control session should also be forwarded to an alternative server." It is a bit vague to me what the point was here. They use the term backup = server and talk about the info related to credit-control session being forw= arded to an 'alternate server' implying it is not the backup? But the diame= ter server in this case is the backup server. Could someone elaborate on this please? It seems a bit vague to me. Lyle ________________________________ 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_381a7094da9a450e973900a8d138859bplswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The CC-Session-Failover AVP in its definition uses ‘backup serverR= 17; but the ENUM value for FAILOVER_SUPPORTED states

=  

“Moving the credit-

   control message stream to a backup server MAY require that<= o:p>

   information related to the credit-control session should al= so be

   forwarded to an alternative server.”

 

It is a bit vague to me what the point was here.  They use the term= backup server and talk about the info related to credit-control session be= ing forwarded to an ‘alternate server’ implying it is not the backup? But the diameter server in this case is the backup serv= er.

 

Could someone elaborate on this please?  It seems a bit vague to me= .

 

Lyle



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_381a7094da9a450e973900a8d138859bplswe13m04adsprintcom_-- From nobody Thu Feb 2 09:22:45 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 678911294CE for ; Thu, 2 Feb 2017 09:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zZi7LQmIjG-h for ; Thu, 2 Feb 2017 09:22:43 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr710091.outbound.protection.outlook.com [40.107.71.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1FA1294BD for ; Thu, 2 Feb 2017 09:22:42 -0800 (PST) Received: from BY1PR0501CA0033.namprd05.prod.outlook.com (10.162.139.43) by SN2PR0501MB816.namprd05.prod.outlook.com (10.160.14.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Thu, 2 Feb 2017 17:22:39 +0000 Received: from SN1NAM01FT042.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::204) by BY1PR0501CA0033.outlook.office365.com (2a01:111:e400:4821::43) 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; Thu, 2 Feb 2017 17:22:40 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) 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.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by SN1NAM01FT042.mail.protection.outlook.com (10.152.65.205) 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; Thu, 2 Feb 2017 17:22:39 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v12H4dwk008676 for ; Thu, 2 Feb 2017 12:22:38 -0500 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by preapdm1.corp.sprint.com with ESMTP id 28bpjawmem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 02 Feb 2017 12:22:38 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m03.ad.sprint.com (2002:90e5:d616::90e5:d616) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Feb 2017 11:22:37 -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; Thu, 2 Feb 2017 11:22:37 -0600 From: "Bertz, Lyle T [CTO]" To: "dmm@ietf.org" Thread-Topic: RFC 4006 failover of alternate and backup servers Thread-Index: AdJ9Z7OeVfUUcAVaQfyK61B3O463oQAESj2w Date: Thu, 2 Feb 2017 17:22:36 +0000 Message-ID: <254812adb6c84299882d2d6471b1933f@plswe13m04.ad.sprint.com> References: <381a7094da9a450e973900a8d138859b@plswe13m04.ad.sprint.com> In-Reply-To: <381a7094da9a450e973900a8d138859b@plswe13m04.ad.sprint.com> 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.29] Content-Type: multipart/alternative; boundary="_000_254812adb6c84299882d2d6471b1933fplswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.80; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39850400002)(39860400002)(39840400002)(2980300002)(438002)(199003)(377454003)(189002)(229853002)(108616004)(189998001)(512954002)(2351001)(107886002)(7736002)(76176999)(50986999)(106466001)(30436002)(54356999)(97736004)(260700001)(4546004)(626004)(2906002)(92566002)(33646002)(86362001)(1730700003)(356003)(3846002)(102836003)(450100001)(790700001)(6306002)(6116002)(8676002)(81166006)(68736007)(2501003)(110136003)(2950100002)(53936002)(24736003)(38730400001)(5250100002)(81156014)(84326002)(2900100001)(7696004)(8936002)(6916009)(54896002)(5640700003)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0501MB816; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT042; 1:BOZpjAn1vdGad+MOc5/Bx4netBMZO9aorQbtsahEd4iVmjsx12haeDe2LGtXsLyY58qKOqsl5uMdiEiRLVKKG1tFMNT+QaVwlGm67C+wFvZjC/4AGnRfWIFkci2wcoJD/QCEOnh3dzSkla3eSCjl3UHylYtVWleGeFo5CZWVopqYukBCpedbRJ66OlPjmfciH2qJhirCaRnLoOiyKz82TbOY/Fmxlom1++AfGTb8pLg/0Xe6Lw7hUJpFw6hfkTsn4sCFPXclONBH5ToFh3u0fuWwHnX+ZncM3twuH0WFj9F3Sg8zWPP9vVL181UgXkjp2riPof5MxHN43RCAJIV8nCKlgUV/jFo0iAb0IZMJyOLgREmvYPp+G1byPG5yQke65SiaIusZa9jpzlIV6f1w1Z/zn3OjMhiF36KqLNn+3DFaJ/RzXamINezD3bTXjFCy/NKafGzimQg7CGbvkbBe/bGWOwPOOAnIbQahGgkVWp27q4qRurpERqME9KF1Yl9nhnSM4AtX/mWiwZsnjzHvrsXAjksKzfsbWEN5f+AhPJA9uOzUWSogw/meEnvbMILw X-MS-Office365-Filtering-Correlation-Id: 07d99a82-ec4f-4615-9bfd-08d44b9016d1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:SN2PR0501MB816; X-Microsoft-Exchange-Diagnostics: 1; SN2PR0501MB816; 3:yauVWHwhWViuLQ6U80CbQbM8MjFEiJlrjAV5UIXgbnibKCSiYN+sZvHocdQ1MbZQ5ND/ANvdUHQcvmlvoHihCbE200NeXRz5FGeYdcshWvAVIMImEGSmgHQc4H0vDZpNLnzrwGDw6ip2fNLV9icoBk8nxW2jZJ78rOw4wT+LjCeh/Xsyufao2gPqxg+WyYi4+yOv0ZHNOO6w7R1QyNMAxPnm5+8Kc1DaS2NfxOz8fWgBfDrM8NzwVjoHHQWGkUZdabWCmMrW+YDjmymoBXjWrw2boKEamiOlG1q60sTzGtS9qmp+s1osaWXu6gpWN7yoMoha003wYGJeM+a1YZQjI34wNq5uareEOQbMQGF3InQEjk+ywzrkfT1GpDG+i1Kf9ZsS06wVVFCnM4CP3avHEQ== X-Microsoft-Exchange-Diagnostics: 1; SN2PR0501MB816; 25:kOsVGqORjIsddwjoKo+ACIAdS+ba/YEM/hA+ymRqfb5ldOKgkUZkFMrcE1T8gxFUWMYbpHKB4HQNKbl8+L5VCTJnSCuRPSDYoBDH9a+nV6ABD4uDYheokHj90gsTf8vAXM91nW4R3tCIwo9QEKFRnzeRQs6alDzhh8poEhlSEv4IJC4AdkUsa4bFH2ddL5+7Zcei7VKJT4CWM7GCPq7TQBY98neYHIctFQsMygqh2kQ5sGPkuifBeYyrwuiCEp62LSrkGaZEsL+Wne3uHTN1Jlnv7FW0etU+wS6yUN0RGVwZwcwE6QIQ9SYKG8OSgATpHBq/1Les2rTk1C7GzARJfzMRRu919seU0jyP1dQy3bQ37t269oR3KdJe3o6iFfJNOFBrgFzJLFGWOQWWe7lzEAKOw3XhDr1uN+HBEkLljrlQz6AXccJ/OXEYcPIrs0l1BUdC13k/qKuOvxlkgSlwTZIe0GQEy/EKyKiwCL1vWBMq7tagptPqhVaTESwwLTtKv/UXRIwfhSmgp5F3z2eFhKzdQtT/oUxmEtePYzECs8a/9Oa/Cb9mu9bstshBMzBqu9zkuCDEmiOmGqAIcNYcWd+gjmwipmJfJUYMYgW/9D6ohPQc52fwUjLctXzzNVi9jq0l67hPgpppCpQlOi+TGbzWZv8MN1n2/gdUG9048eVd5UtkGQ9RS7xOAyPFtp/JLi6Hj+ky6qgN8LL3dO9HnDCGJz8vV4dRPMZZ7NJ8Xd1ovJ9wVr6RLFSyu83KEMSORSdnzhx3fMo+Uo3VWmFG3ltm28qIroTjXUfYSCj6r7qil/Z4u8ss4RziS+fTyo7Ng7cvh0fyRoLHkSsATWyC1Z2eUWBSwSXHNlraTkwgTl85KdKTAyo9npQt9+mDCzJ6Z8kqPuiZS6oLo8gvGH09FUgc42lItb5aCm/mcKs+oj8= X-Microsoft-Exchange-Diagnostics: 1; SN2PR0501MB816; 31:8L8oQSqBdvNOJQYVw8VMOy4dnu8V/Ph6EIxRyiR7E5FQVkDT40ZMsBe+Tn5iuKyWlASZU/PZ8/oGXOL8sO+xOmNtLjfRuhEkYv44qEq6V4fPzXp6j7wW7Q6fwmBLWluJYPGbxdSayMO//KkcxUDmNhHzBz1xix7tXpOhN5oKv2Px2paBPnU01mBE5bplNH6YhGrOw65lDAE5nF64rUNnZPCt/hkm4/VVe0491W5V2PWfDDRiWblI3waA1JfGL+NgAUdMOMm8lNIGbU0oI+q6tg==; 20:Z0UwzIH/IImQ4n+2RqQtnPpiQtKEFEhVQQ2NPhTpY+MRjcyaa6sXGk3czGjmV8MdCuR1xOyLLCEohAqPfzx0XfogNZFX7RMCU7KNfd7CpHVrs/GHOcWMyhRMAUMuck2wWMSMeinbVPKFztcZ0SAvCR6bnh5/wqYgPKyr2v+PkQJqViD7zMdr88x3HJUHcTP4Hjodrae7LvYcmGjs18nOsK714+VJaIkU0RlHQbnDMAd8nIm6Cyt6X5atyZ5PChiFGfRPobucnOtqjD3I3MvIr8l3TXS48iFDH13cXAQ2PHLw57giD45N8dDXxE2PdqjyeCLGO/KBVUVT4VdO8NQwZMUzzEQD4Z0mUKgWSeppxnLYd0AUKejgRswXEAF5DJ9b/tt0eVQDEdqDcfgP2kgjmuLDNGutzZULk+vfaaGaVmFMlINFtHh+LMbH68WUXQ/IpU5nevp9C4bHiMlXw+2J9ILkJUsycuD8qrOfJNJVdWfDOHDNqupAhcUCyYXa8BOl X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(13024025)(13015025)(13017025)(13023025)(8121501046)(13018025)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:SN2PR0501MB816; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0501MB816; X-Microsoft-Exchange-Diagnostics: 1; SN2PR0501MB816; 4:JINgsxYq8cAg7BJqduC23EYypZDtTn1qH0TMt4v4oheEaJgrh7HqSK26Ij3u2j+6h4RTgEEslJKZ8l4oQH1UC0JAVo2JoDkgE8leRHMUtaZ768N118/HPago6ZFe1iDhtjDCuZJoH3fFRZngX/nFoPE1zC2F52Rc3Q11Od6pa/ZDG+eYrvlvW7aPbsROz0ner2R2SP6F2/hT5LIN3m8rlhbYPINGttnbHr+Dygprc/pxmzxj9qF7OXO1iTUyun+zlpWzPNhCpZA4+0sy6bYeYuKsdQ1qVAL6B1C9SEpMcwmt/amYVHVE+Y0n8ad7ZGdS5s61B1LxF+G6WFnV8uE/SFwaJmT+RHIi7Gqj/Cw8jU/L31HY3WKGAuuMwMtSQsDnK4ijd9A+1J9fA9di4Wcr8yf6kKS6JvWEm2ZeNsZnlApym8pepJfrLRvgnc2EWy4oCAi7Mu9SCn6+wBOAAyFKtqSFdjS6d/qxTdhtqmUVofE7MFIWh/MUeL1czpoXCymsyCLvqxdxflNgEVmLo6AxNyOgguwn5+tcOp+SP5vM/CHeCzkf50H8aU66/FOZbsFYhFR/IUGi0SS6y1UuEUS0sEfZHtayp4/Vg54Vfz186f0/+Uooq2kyfQI/EfKNfa4xwSFF+o7R9IA4bJewssyh4JC/uAbgnVkW/5bpkwpQ9wd/QiLlHQKWjbuYhtYnVoAwOJc137WGiX1yjRGOi3lyUcIdFlu0UzMEpzSq3KEHx9/MGAoVq297elclgCGtsWI0F9PAfN6+xTJaolyPsvHVi7mHI9V98YtsEHOOKwDjC58= X-Forefront-PRVS: 02065A9E77 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR0501MB816; 23:mkF3rUVFe+Rkvezljd+lvvEZE3CviBlj2xsZUjcj?= =?us-ascii?Q?+Vl7CPymq1t2aov8t7bDQZjTrTqnuM3gSQwDiMgXNb+QrCmEQTE92HJsPt/I?= =?us-ascii?Q?pql87QhGpuArBAdKVXmsEGAWp6qcs9aT9cdGNtm9ELdhwRWYraDgm0kLE+qp?= =?us-ascii?Q?AQPCTNIJS3cchFl7IQoa2fzghndc57IuUXhggDcEqY73bcQywCG1D4oaDPp2?= =?us-ascii?Q?mFg9OxHOzgAfFuAUwS69WjUhSrGwZMkkxZ0M3t50ByYW/hx6wUgj1Q7qBIYa?= =?us-ascii?Q?hbx/Ibocx4VW1qGJh3bHeEk8FBAoVQNcU+hlZrjJ8TL1NX88LPH3NMDFoo+X?= =?us-ascii?Q?o+tFesus68ELYuKeKIUVL6nFRjdSq5b5fIpvmhhOJ6DdGkra2qkKZ4x2K+6Q?= =?us-ascii?Q?UQGULcPqy1l6rRPYtqt6IucqpD51w/vzjECQEQlDf8bIMJzy+osucLaIvsSA?= =?us-ascii?Q?Vb8jf4NtvDcHE8jMTFM66UBFjA/C0CDGz/kptMrRr0YehDfl2JP9DU/0A3Zd?= =?us-ascii?Q?lsqw1uJ0CTDWHk7sQaEI4Nfjxw62tDF4G71HL+dqgOZg9O6yaS98mlSLMSB+?= =?us-ascii?Q?yHM/NLqZKffoy89IqNGuiE8P6xCpQvOVX6N3y4bw+p0/HKGe2EQOvtu18htU?= =?us-ascii?Q?EqV7hC1VR89EbVR7oo5T2bMOqK07ldNvC+KeZUpaIn3RLyKYkYFt1Gu+qP7d?= =?us-ascii?Q?RaQtADlHpPUHQ9eQXB7wjfQ2VE9e4uuHR09LmAwMD9MlM0f0IfYxarYsQvz6?= =?us-ascii?Q?PZSOqdkMOfH61FR1uPrm+sfdmmwPxqXTu5mCWT4/dwlZGa88NClMzlMuLrqV?= =?us-ascii?Q?8Vxud1PRxh6OIVNbmk6C9wBcr3I4RiGkD+Ho1mcp7S81mo3jN03EEmfx8zvF?= =?us-ascii?Q?brycs8LKpdBszn7E4NuP4CJWj9fjFJwRRbK12uyzdH2Hxib1pT4tcAkybYMI?= =?us-ascii?Q?TOpZBZ64gli+X3IqWcRj1sts5bYvRFX2zGdzR3vtOPD3l78vsXU7CcWQ9FBI?= =?us-ascii?Q?e5vBJhOK0rYL8YVPv2kIj/9NReCQA0fBDhmsNnzWrk2b5TwM9RuWzu6p4yyl?= =?us-ascii?Q?DfBc/Qa/37D/jOts1I8YquVNh7mD/OG+m1gfOL7ZC3WKjwB1l2qnE6nwGGMa?= =?us-ascii?Q?/8agBfO2Qu30YGjJMEKRDtTvasK4YrU7SO3BPBCuR4xbmX3ydPnD6Q5JdANi?= =?us-ascii?Q?iGZtYp6XFoNebHSYwLG3en5/XJQpxm6V3vkZCycryjv9qqmmupnFQ8wjB0zU?= =?us-ascii?Q?ciCw+rGYR6oYmUbKgwuy0g4kzJmTzBEOJm7KenzugpsUXEjiMP6RNrRmTGW1?= =?us-ascii?Q?GWiYjkqHqwNpGnv5gnHCVskYQocrf0h4yw3d3NUAaxlO0wrEh6RiqUMnRJuF?= =?us-ascii?Q?TRmNiNdkl8obY0KwJ/XGeO4gNFMV2otP8NaJZB2Dxojiu/8fo+EhpoRfvvRG?= =?us-ascii?Q?ayWJMvsHDw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR0501MB816; 6:Njnhl+TtzHUElAmWhJrPJEmInMFvr7vLbj/N40o23OceY7T3rVfAp0kBMX5gDjz8v7DfdW0ongtB/AVGXQm0t1Wl55ywGihFPwwpRSgFYdYpzVog2ImsaHrl7fDAZw6i2648raaqu202BbVEkmUT+ubVzW3qbeme6iTWam/9cUxzZHA2w0X6QKsHLUMZvvP+scReANtcGkbu6Qvk/pBVdKH8p95t9fkfh2HOW7TJC4dqCAYz9FTzXnJKRqvQsrufUHMpBTTKEcV+k8QRsi24HCAUKkd7WH+4NonG0MlIMf2xOheVfuS2M0OUK537iMTOedZQq4xVczT/G2nnN0YQF4C+NyZEoF6a+FVHeW+fPEhvsYrMz2BgHVak9/2lUD7e4zCfZcWk7niKo5/d1wAnv3jsnBElRWhD1+820mWrOOY=; 5:uBReBudKq7YuWlXwAnFQMfQWMfrXVYbpCLF8pEIh8C4i4DatK4ueiEZa6akgtvx3EaLxPSzI/e+m9Q0Vd4P2tAwQGFprDnzg3RsVTkz1PMs5UYdaAUmsozKe4Xf4e/Y/J0PhkLrh7hsHcy/tUsspeA==; 24:7oI0GvSp9Ayv1ivV5LOGUdLbLIQ+cjxVMoGn+yb2H8EI2YX/Ev/W37lomz7uXLrzPhhXTrnX52i57UvkhAA+Jz5WO1hs9OOhCihgb+UXVnY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR0501MB816; 7:lO0i+lIYsoWLEm36NkOMFq/gWgxvlPqFTYZjS7mxZkiW6KSPJbi0hcSsnnBK4ksA3q8XRwjFFIIJ6uMoMmMS8I+PBd30gozJmBb7DqFVkDUXN0ntM7pDe0CHT7yvafnhKeiIaGaoLISlc/PN3uPhszDYTWMC6HSTKAuUNdZQt9fvrpiR2lGNPW43MFaX/NQ75lsL5FN643ADcx1icCaK4120cI2XNKsbhGfr7RmukJrSaRRkNHo6m8FhEZ3Hbos5J6ErT0TeMQ10Gyf9vtA8OOwJMmm+XVr4S2nUt4/MD9e+DXeDT5LBThFpRqp5E+Kf+RNMxDcYyNIuUxRKZC9G3fSpna/I4UQxVnpFxo6BC6z5tY88dqSMGX2MnW8nnX0Xjjg/JwxjOmsTVDf4LoXNqUOBxG8mgHz4GzPZ6et8buRErV4/0cIejTEqdL+BCF6O1HjectXR4wZEGZ+rPDswTAoTbjtH8Fske6FCgZ4wRyNuPnU2YTMpz7x06DoKba2Uim3G2pFaBL/UWljFBX8ZlA== X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2017 17:22:39.4260 (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.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0501MB816 Archived-At: Subject: Re: [DMM] RFC 4006 failover of alternate and backup servers 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: Thu, 02 Feb 2017 17:22:44 -0000 --_000_254812adb6c84299882d2d6471b1933fplswe13m04adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wrong list! My apologies! Please disregard. From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Thursday, February 02, 2017 9:21 AM To: dmm@ietf.org Subject: [DMM] RFC 4006 failover of alternate and backup servers All, The CC-Session-Failover AVP in its definition uses 'backup server' but the = ENUM value for FAILOVER_SUPPORTED states "Moving the credit- control message stream to a backup server MAY require that information related to the credit-control session should also be forwarded to an alternative server." It is a bit vague to me what the point was here. They use the term backup = server and talk about the info related to credit-control session being forw= arded to an 'alternate server' implying it is not the backup? But the diame= ter server in this case is the backup server. Could someone elaborate on this please? It seems a bit vague to me. Lyle ________________________________ 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_254812adb6c84299882d2d6471b1933fplswe13m04adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wrong list! My apologi= es! Please disregard.

 

From: dmm [mailto:dmm-bounces@ietf.org] On= Behalf Of Bertz, Lyle T [CTO]
Sent: Thursday, February 02, 2017 9:21 AM
To: dmm@ietf.org
Subject: [DMM] RFC 4006 failover of alternate and backup servers

 

All,

 

The CC-Session-Failover AVP in its definition uses ‘backup serverR= 17; but the ENUM value for FAILOVER_SUPPORTED states

=  

“Moving the credit-

   control message stream to a backup server MAY require that<= o:p>

   information related to the credit-control session should al= so be

   forwarded to an alternative server.”

 

It is a bit vague to me what the point was here.  They use the term= backup server and talk about the info related to credit-control session be= ing forwarded to an ‘alternate server’ implying it is not the backup? But the diameter server in this case is the backup serv= er.

 

Could someone elaborate on this please?  It seems a bit vague to me= .

 

Lyle

 


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_254812adb6c84299882d2d6471b1933fplswe13m04adsprintcom_-- From nobody Sun Feb 5 23:20: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 8D58E129C90 for ; Sun, 5 Feb 2017 23:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Yjw-4Gn9j1Ct for ; Sun, 5 Feb 2017 23:20:30 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 1A0C7129488 for ; Sun, 5 Feb 2017 23:20:30 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 194so8366317pgd.0 for ; Sun, 05 Feb 2017 23:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qa7Yiw8CwHXZL7Q+OwwVtHddmzxK+nW7Me6uW0aLR6k=; b=LazxEdrtUETPrgBQ3zjO4p8JsfIBtGIRzGcZfVLGQMkcwxmxzR2f1V2P646FxIKoWB g5Os7895qbIwIN49U9+3Wpc57LzkpYpByeRbZGqr8Xp0MBlNDFR2aCFnD9xhmPEXKNln CmEf7VjetpUqI7H6KwJC9RfLlnAcmHgTt04Mpb+yUhWElwYxFvY8+ma0nzq4XLLTzVwc GNdd7HmObf/4Trg55ZRF8ntwWRsHZyU5pAjoZjLR8+Es0/tU4NiUV98+HMX1m6eYZvqT orvsgKrpL9+2+3x4HsQaE2l1Z5EugQFQWdJZ+YZIn4YzciNtb8V+9MNgFtW0nnemym1b adwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qa7Yiw8CwHXZL7Q+OwwVtHddmzxK+nW7Me6uW0aLR6k=; b=tW7/60Za/I37XdD5DllXesKpWCbS6+qabT1waJjpoL3NY4FK9Yy+8SB9R0vuJ8RGBi PnnkQLS/1OWuLMI3C7dOg7gNPkbcNpBdUvueO1GCyux/3SHiKJXQilpiH6LAMfFTU1iX xN7rHBZOGIC3MFjGKzxRXOztFe+Tv9gnyAa94oV2IrayRWkJUoX4T73oWDzr2tcZTcGK izf6dSIgORBqFrRcfrjGT28hbBNHj3vcOMwiWwAGlw4+59zylE5p9N46VbuSt1LnQ/Eu ds6PitQLQj3T145sf6MgD4sUvF4soxHwcFD3eucXQzxH+8CChYw4RQ/306O+5vgBisXc 6JEg== X-Gm-Message-State: AIkVDXJuvvqMq1TRX9LoCusmQ/vsJvv7DJxw1eCBXt7anlZuuazLkXKCP+ewNyzoFGvh2A== X-Received: by 10.84.169.67 with SMTP id g61mr15524743plb.137.1486365629708; Sun, 05 Feb 2017 23:20:29 -0800 (PST) Received: from [10.207.114.107] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id a1sm24552146pgc.14.2017.02.05.23.20.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Feb 2017 23:20:28 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <116dd8b8-ac89-5e9b-1c3e-eb92371b8f98@earthlink.net> Date: Mon, 6 Feb 2017 16:20:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <041B7084-FA37-4C3F-8F72-D07E9948E080@gmail.com> 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> To: Charlie Perkins X-Mailer: Apple Mail (2.3124) 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: Mon, 06 Feb 2017 07:20:31 -0000 +1 --satoru > 2017/01/26 2:16=E3=80=81Charlie Perkins = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC= =9A >=20 > Hello Marco, >=20 > What would you think about replacing the term "port" by "virtual = port", which would usually be shortened to "vport" (or "Vport")? >=20 > I think it would have several benefits: >=20 > =E2=80=A2 it seems intuitively appealing, at least to me > =E2=80=A2 it avoids the unacceptable clash with the traditional = meanings of the word "port" > =E2=80=A2 it fits well with my understanding of "data-plane = node" and "context". > =E2=80=A2 it's a relatively easy editorial change to the draft > Regards, > Charlie P. >=20 From nobody Mon Feb 6 22:16:00 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 5FFE6129477; Mon, 6 Feb 2017 22:15:58 -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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148644815834.754.17353219113073599922.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 22:15:58 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-lma-controlled-mag-params-03.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: Tue, 07 Feb 2017 06:15:58 -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 : LMA Controlled MAG Session Parameters Authors : Dhananjay Patki Sri Gundavelli Jong-Hyouk Lee Qiao Fu Lyle T Bertz Filename : draft-ietf-dmm-lma-controlled-mag-params-03.txt Pages : 12 Date : 2017-02-05 Abstract: This specification defines a new extension, LMA-Controlled-MAG- Session-Params to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIPv6) signaling for notifying the mobile access gateway (MAG) to conform to various parameters contained in this extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-lma-controlled-mag-params/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-lma-controlled-mag-params-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-lma-controlled-mag-params-03 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 Tue Feb 7 01:52:03 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 B62E412949F for ; Tue, 7 Feb 2017 01:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tE5cCz9AWciE for ; Tue, 7 Feb 2017 01:52:00 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 2C8EC127058 for ; Tue, 7 Feb 2017 01:52:00 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 07 Feb 2017 01:51:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,345,1477983600"; d="scan'208";a="817982664" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 07 Feb 2017 01:51:58 -0800 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Feb 2017 01:51:57 -0800 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 7 Feb 2017 01:51:57 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.151]) by LCSMSX154.ger.corp.intel.com ([169.254.7.96]) with mapi id 14.03.0248.002; Tue, 7 Feb 2017 11:51:55 +0200 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: New Version Notification for draft-moses-dmm-dhcp-ondemand-mobility-05 Thread-Index: AdKBJ8/P3JAoG+0NTKqXNsvAgG9cOg== Date: Tue, 7 Feb 2017 09:51:54 +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: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: [DMM] New Version Notification for draft-moses-dmm-dhcp-ondemand-mobility-05 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, 07 Feb 2017 09:52:02 -0000 SGksDQoNCkkgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCwgd2l0aCBz b21lIGNsYXJpZmljYXRpb24gb2YgdGV4dCBhbmQgYSBzcGVjaWZpYyBub3RlIGFib3V0IHRoZSBu ZWVkIHRvIGZvbGxvdyBSRkM3OTM0J3MgcmVjb21tZW5kYXRpb24gYW5kIGd1aWRlbGluZXMgcmVn YXJkaW5nIHRoZSBwcmVmZXJlbmNlIG9mIGFsbG9jYXRpbmcgSVB2NiBwcmVmaXhlcyBvdmVyIElQ djYgYWRkcmVzc2VzIGJ5IHRoZSBuZXR3b3JrLg0KDQpUaGlzIGlzIGFzIGEgcmVzdWx0IG9mIGEg Y29tbWVudCBpbiB0aGUgbGFzdCBETU0gRjJGLiBUaGUgZXh0ZW5zaW9uIHN1cHBvcnRpbmcgdGhl IGFsbG9jYXRpb24gb2YgSVB2NiBhZGRyZXNzZXMgd2FzIGxlZnQgYXMgcmVxdWVzdGVkIGluIHRo ZSBtZWV0aW5nIGFuZCBvbiB0aGUgbGlzdCAoZm9yIHN1cHBvcnRlZCB1c2UtY2FzZXMgd2hlcmUg cHJlZml4IGFsbG9jYXRpb24gaXMgbm90IHBvc3NpYmxlKS4NCg0KSSB3b3VsZCBsaWtlIHRvIHJl cXVlc3QgdGhlIFdHIHRvIGFkb3B0IHRoaXMgZHJhZnQuDQoNClJlZ2FyZHMsDQpEYW5ueQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDA3LCAyMDE3IDExOjQzDQpUbzogQWxwZXIgWWVnaW4gPGFscGVyLnllZ2luQHllZ2luLm9y Zz47IE1vc2VzLCBEYW5ueSA8ZGFubnkubW9zZXNAaW50ZWwuY29tPg0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tb3Nlcy1kbW0tZGhjcC1vbmRlbWFuZC1tb2Jp bGl0eS0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbW9zZXMtZG1tLWRo Y3Atb25kZW1hbmQtbW9iaWxpdHktMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IERhbm55IE1vc2VzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZToJCWRyYWZ0LW1vc2VzLWRtbS1kaGNwLW9uZGVtYW5kLW1vYmlsaXR5DQpSZXZpc2lvbjoJ MDUNClRpdGxlOgkJREhDUHY2IEV4dGVuc2lvbiBmb3IgT24gRGVtYW5kIE1vYmlsaXR5IGV4cG9z dXJlDQpEb2N1bWVudCBkYXRlOgkyMDE3LTAyLTA3DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LW1vc2VzLWRtbS1kaGNwLW9uZGVtYW5kLW1vYmlsaXR5LTA1LnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW1vc2VzLWRtbS1kaGNwLW9uZGVtYW5kLW1vYmlsaXR5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb3Nlcy1kbW0tZGhjcC1vbmRlbWFuZC1tb2Jp bGl0eS0wNQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1tb3Nlcy1kbW0tZGhjcC1vbmRlbWFuZC1tb2JpbGl0eS0wNQ0KDQpBYnN0cmFjdDoN CiAgIEFwcGxpY2F0aW9ucyBkaWZmZXIgd2l0aCByZXNwZWN0IHRvIHdoZXRoZXIgb3Igbm90IHRo ZXkgbmVlZCBJUA0KICAgc2Vzc2lvbiBjb250aW51aXR5IGFuZC9vciBJUCBhZGRyZXNzIHJlYWNo YWJpbGl0eS4gIE5ldHdvcmtzDQogICBwcm92aWRpbmcgdGhlIHNhbWUgdHlwZSBvZiBzZXJ2aWNl IHRvIGFueSBtb2JpbGUgaG9zdCBhbmQgYW55DQogICBhcHBsaWNhdGlvbiBydW5uaW5nIG9uIHRo ZSBob3N0IHlpZWxkcyBpbmVmZmljaWVuY2llcy4gIFRoaXMgZG9jdW1lbnQNCiAgIGRlc2NyaWJl cyBleHRlbnNpb25zIHRvIHRoZSBESENQdjYgcHJvdG9jb2wgdG8gZW5hYmxlIG1vYmlsZSBob3N0 cyB0bw0KICAgaW5kaWNhdGUgdGhlIHJlcXVpcmVkIG1vYmlsaXR5IHNlcnZpY2UgdHlwZSBhc3Nv Y2lhdGVkIHdpdGggYQ0KICAgcmVxdWVzdGVkIElQIHByZWZpeCAob3IgYWRkcmVzcyksIGFuZCBu ZXR3b3JrcyB0byBpbmRpY2F0ZSB0aGUgdHlwZQ0KICAgb2YgbW9iaWxpdHkgc2VydmljZSBhc3Nv Y2lhdGVkIHdpdGggdGhlIGFsbG9jYXRlZCBJUCBwcmVmaXggKG9yDQogICBhZGRyZXNzKSBpbiBy ZXR1cm4uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpB IG1lbWJlciBvZiB0aGUgSW50ZWwgQ29ycG9yYXRpb24gZ3JvdXAgb2YgY29tcGFuaWVzCgpUaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRl cmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K From nobody Fri Feb 10 06:17: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 2382B129614; Fri, 10 Feb 2017 06:17:30 -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 11cTzIcZstsh; Fri, 10 Feb 2017 06:17:27 -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 32BF212998D; Fri, 10 Feb 2017 06:17:18 -0800 (PST) X-AuditID: c6180641-c3fff70000000a06-dc-589d8518899b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 0C.3B.02566.8158D985; Fri, 10 Feb 2017 10:17:14 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 09:17:14 -0500 From: Suresh Krishnan To: Charlie Perkins , "Sri Gundavelli (sgundave)" , Dale Worley , "gen-art@ietf.org" Thread-Topic: [DMM] Review of draft-ietf-dmm-4283mnids-04 Thread-Index: AQHSe/j/cjYYsQbutUCsVh56ND0V9aFVgPUAgAAQ6gCADSuDgA== Date: Fri, 10 Feb 2017 14:17:13 +0000 Message-ID: <8E97344D-93A5-4B6F-96F3-735068A4D713@ericsson.com> References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> <17671de0-7238-3a3f-c5b6-d6e8bbd3a5e2@earthlink.net> In-Reply-To: <17671de0-7238-3a3f-c5b6-d6e8bbd3a5e2@earthlink.net> 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.12] Content-Type: text/plain; charset="utf-8" Content-ID: <8F92523113235A438CA26F0B60E987E7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyuXRPuK5U69wIgwd7jSzu37nGZnH/UY3F /9lb2C2uvvrMYvFs43wWi4N/trFZvDxR5sDuMXn/V2aPKb83snqs+jKB2WPJkp9MASxRXDYp qTmZZalF+nYJXBn3Xk5jK3hxkrHi/IITjA2MF44wdjFycEgImEg8PVvZxcjFISSwnlHi7J49 7BDOckaJhnkdQEWcHGxARRt2fmYCSYgIbGKUuPrlJxuIwywwnVFixc8pbCBVwgIWEjOnXwbr EBGwlJg44yIzhO0kcex6LyuIzSKgKnH++T6wel4Be4meWVuYIdatZpQ40LMa7CZOAUeJ1tX6 IDWMAmIS30+tYQKxmQXEJW49mQ9mSwgISCzZc54ZwhaVePn4H9h8UQE9iY0XprFDxJUk5ry+ xgwykllAU2L9Ln2IMdYSN+4cghqpKDGl+yE7xDmCEidnPmGZwCg+C8m2WQjds5B0z0LSPQtJ 9wJG1lWMHKXFBTm56UaGmxiBsXlMgs1xB+PeXs9DjAIcjEo8vBu850QIsSaWFVfmHmKU4GBW EuGdcGhuhBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe6yH3w4UE0hNLUrNTUwtSi2CyTBycUg2M 0Y8uhrRu/LdaKGlVfdTcIOYLZguOSW59m+RnsH2hqFfqZMW4BRMi+l0a3+S+d5cUs1Lsa82/ zyHVLjpj/mP2K0krYtf7T5z3i1tJrPRtQNi8Z2KK7UVHZzFx3foo0r1+s35XugdHwyOBuJem a9Tk5JqXvN5/aHfAPPdwDePdGg87Dx86ZbpViaU4I9FQi7moOBEA0ffDPckCAAA= Archived-At: Cc: "draft-ietf-dmm-4283mnids.all@ietf.org" , "ietf@ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 10 Feb 2017 14:17:30 -0000 SGkgQ2hhcmxpZSwNCiAgSSBoYXZlIG5vdCB5ZXQgc2VlbiBhIHJlc3BvbnNlIHRvIHRoaXMgcmV2 aWV3LiBEbyB5b3UgdGhpbmsgeW91IHdpbGwgYmUgYWJsZSB0byBnZXQgdG8gdGhpcyBpbiB0aGUg bmV4dCBkYXkgb3IgdHdvPyBUaGUgZG9jdW1lbnQgaXMgb24gdGhlIEZlYnJ1YXJ5IDE2IDIwMTcg dGVsZWNoYXQgYW5kIEkgd291bGQgbGlrZSB0byBzZWUgcmVzb2x1dGlvbiB0byB0aGVzZSBpc3N1 ZXMgaW4gdGltZSBmb3IgdGhlIG90aGVyIEFEcyB0byBiYWxsb3QuDQoNClRoYW5rcw0KU3VyZXNo DQoNCk9uIDIvMi8xNywgMToxMCBBTSwgIkNoYXJsaWUgUGVya2lucyIgPGNoYXJsZXMucGVya2lu c0BlYXJ0aGxpbmsubmV0PiB3cm90ZToNCg0KICAgIEhlbGxvIFNyaSwNCiAgICANCiAgICBUaGUg cmV2aWV3IHdhcyBpbmRlZWQgc3VwZXIuICBJJ2xsIHJlc3BvbmQgc29tZXRpbWUgaW4gdGhlIG5l eHQgZmV3IGRheXMuDQogICAgDQogICAgUmVnYXJkcywNCiAgICBDaGFybGllIFAuDQogICAgDQog ICAgDQogICAgT24gMi8xLzIwMTcgOTowOSBQTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3 cm90ZToNCiAgICA+IFRoYW5rIHlvdSBEYWxlIGZvciBhIGdyZWF0IHJldmlldy4NCiAgICA+DQog ICAgPg0KICAgID4gQ2hhcmxpZS9BdXRob3JzIC0gQ2FuIHlvdSBwbGVhc2UgcmVzcG9uZCB0byBE YWxlIGFuZCBhZGRyZXNzIHRoZXNlDQogICAgPiBjb21tZW50cy4NCiAgICA+DQogICAgPg0KICAg ID4gUmVnYXJkcw0KICAgID4gU3JpDQogICAgPg0KICAgID4NCiAgICA+IE9uIDEvMzEvMTcsIDEx OjM0IEFNLCAiZG1tIG9uIGJlaGFsZiBvZiBEYWxlIFdvcmxleSIgPGRtbS1ib3VuY2VzQGlldGYu b3JnDQogICAgPiBvbiBiZWhhbGYgb2Ygd29ybGV5QGFyaWFkbmUuY29tPiB3cm90ZToNCiAgICA+ DQogICAgPj4gUmV2aWV3ZXI6IERhbGUgV29ybGV5DQogICAgPj4gUmV2aWV3IHJlc3VsdDogUmVh ZHkgd2l0aCBJc3N1ZXMNCiAgICA+Pg0KICAgID4+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuICBUaGUgR2VuZXJhbCBBcmVhDQogICAgPj4gUmV2aWV3 IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZA0KICAgID4+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0DQogICAgPj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLg0KICAgID4+DQogICAgPj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl IEZBUSBhdA0KICAgID4+IDxodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL2dlbi90cmFj L3dpa2kvR2VuQXJ0ZmFxPi4NCiAgICA+Pg0KICAgID4+IERvY3VtZW50OiAgZHJhZnQtaWV0Zi1k bW0tNDI4M21uaWRzLTA0DQogICAgPj4gUmV2aWV3ZXI6ICBEYWxlIFIuIFdvcmxleQ0KICAgID4+ IFJldmlldyBEYXRlOiAgMzEgSmFuIDIwMTcNCiAgICA+PiBJRVRGIExDIEVuZCBEYXRlOiAgMiBG ZWIgMjAxNw0KICAgID4+IElFU0cgVGVsZWNoYXQgZGF0ZTogIDE2IEZlYiAyMDE3DQogICAgPj4N CiAgICA+PiBTdW1tYXJ5Og0KICAgID4+DQogICAgPj4gICAgICAgIFRoaXMgZHJhZnQgaXMgb24g dGhlIHJpZ2h0IHRyYWNrIGJ1dCBoYXMgb3BlbiBpc3N1ZXMsDQogICAgPj4gZGVzY3JpYmVkDQog ICAgPj4gICAgICAgIGluIHRoZSByZXZpZXcuDQogICAgPj4NCiAgICA+PiBUZWNobmljYWwgaXNz dWVzOg0KICAgID4+DQogICAgPj4gMS4gVGhlIEludHJvZHVjdGlvbiBzdGF0ZXMNCiAgICA+Pg0K ICAgID4+ICAgIE90aGVyIHR5cGVzIG9mIGlkZW50aWZpZXJzIGFyZSBpbg0KICAgID4+ICAgIGNv bW1vbiB1c2UsIGFuZCBldmVuIHJlZmVyZW5jZWQgaW4gUkZDIDQyODMuDQogICAgPj4NCiAgICA+ PiBGb3IgdGhlIHJlYWRlcidzIHNhbml0eSwgc29tZSBzb3J0IG9mIGFjY291bnRpbmcgbmVlZHMg dG8gYmUgbWFkZSBvZg0KICAgID4+IHRoZXNlICJvdGhlciB0eXBlcyBvZiBpZGVudGlmaWVycyIs IGVzcGVjaWFsbHkgYmVjYXVzZSBlYWNoIHR5cGUgb2YNCiAgICA+PiBpZGVudGlmaWVyIG5lZWRz IGFuIGlkZW50aWZpZXIgdHlwZSBudW1iZXIuICBUaGUgdGV4dCBpbiA0MjgzIGlzDQogICAgPj4N CiAgICA+PiAgICBTb21lIGV4YW1wbGVzIG9mIGlkZW50aWZpZXJzDQogICAgPj4gICAgaW5jbHVk ZSBOZXR3b3JrIEFjY2VzcyBJZGVudGlmaWVyIChOQUkpLCBGdWxseSBRdWFsaWZpZWQgRG9tYWlu DQogICAgPj4gTmFtZQ0KICAgID4+ICAgIChGUUROKSwgSW50ZXJuYXRpb25hbCBNb2JpbGUgU3Rh dGlvbiBJZGVudGlmaWVyIChJTVNJKSwgYW5kIE1vYmlsZQ0KICAgID4+ICAgIFN1YnNjcmliZXIg TnVtYmVyIChNU0lTRE4pLg0KICAgID4+DQogICAgPj4gQXJlIHRoZXJlIGFueSBvdGhlciB0eXBl cyAiaW4gY29tbW9uIHVzZSI/DQogICAgPj4NCiAgICA+PiAtIE5BSSAodHlwZSAxKSBpcyBkZWZp bmVkIGJ5IDQyODMuDQogICAgPj4gLSBGdWxseSBRdWFsaWZpZWQgRG9tYWluIE5hbWUgKEZRRE4p IHNlZW1zIG5vdCB0byBiZSBzcGVjaWZpZWQNCiAgICA+PiAtIEludGVybmF0aW9uYWwgTW9iaWxl IFN0YXRpb24gSWRlbnRpZmllciAoSU1TSSkgKHR5cGUgMykgaXMgZGVmaW5lZA0KICAgID4+IGlu DQogICAgPj4gICB0aGlzIGRyYWZ0DQogICAgPj4gLSBNb2JpbGUgU3Vic2NyaWJlciBOdW1iZXIg KE1TSVNETikgc2VlbXMgbm90IHRvIGJlIHNwZWNpZmllZA0KICAgID4+DQogICAgPj4gMi4gSXMg aXQgaW50ZW5kZWQgdG8gaGF2ZSBhbiBJTUVJIGlkZW50aWZpZXIgdHlwZT8gIFRoZSBpbnRyb2R1 Y3Rpb24NCiAgICA+PiBtZW50aW9ucyBhbiBJTUVJIHR5cGUsIGJ1dCB0aGVyZSBpcyBubyBzcGVj aWZpY2F0aW9uIGZvciBpdCwgbm9yIGlzDQogICAgPj4gdGhlcmUgYW4gaWRlbnRpZmllciB0eXBl IG51bWJlciBhc3NpZ25lZCBmb3IgaXQuDQogICAgPj4NCiAgICA+PiAgICAuLi4gdHlwZXMgZm9y IElNU0kNCiAgICA+PiAgICBbVGhyZWVHUFAtSURTXSwgUC1UTVNJIFtUaHJlZUdQUC1JRFNdLCBJ TUVJIFtUaHJlZUdQUC1JRFNdLCBhbmQNCiAgICA+PiBHVVRJDQogICAgPj4gICAgW1RocmVlR1BQ LUlEU10uDQogICAgPj4NCiAgICA+PiBJbml0aWFsbHkgSSBzdXNwZWN0ZWQgaXQgd2FzIGl0IHdh cyBwcmVzZW50IGluIGFuIGVhcmxpZXIgcmV2aXNpb24NCiAgICA+PiBhbmQNCiAgICA+PiB0aGVu IGxhdGVyIGRlbGV0ZWQgd2l0aG91dCB0aGlzIHJlZmVyZW5jZSBiZWluZyB1cGRhdGVkLiAgQnV0 IGFsbA0KICAgID4+IHZlcnNpb25zIG9mIGRyYWZ0LWlldGYtZG1tLTQyODNtbmlkcyBhbmQgaXRz IHByZWRlY2Vzc29yDQogICAgPj4gZHJhZnQtcGVya2lucy1kbW0tNDI4M21uaWRzIG1lbnRpb24g SU1FSSBpbiB0aGlzIHdheSBhcyBvbmUNCiAgICA+PiBpZGVudGlmaWVyDQogICAgPj4gdHlwZSwg YnV0IG5vbmUgc3BlY2lmeSBpdCBpbiBhbnkgd2F5LiAgVGhlIG9ubHkgZGlzY3Vzc2lvbiBJIGNh biBmaW5kDQogICAgPj4gb24gdGhlIERNTSBtYWlsaW5nIGxpc3Qgb2YgSU1FSSBpczoNCiAgICA+ Pg0KICAgID4+ICAgIA0KICAgID4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvZG1tL3BObXRhcTYtSk9RNFJ1WHlfRDdaYzJKZ3ZZay8/cWlkDQogICAgPj4gPWQyOTU3NWY3 NjdjZTY3YTFlNjdhNzc2NzAwOGVlNmFmDQogICAgPj4NCiAgICA+PiAgICAgRnJvbTogTWFyY28g TGllYnNjaCA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+DQogICAgPj4gICAgIFRvOiBETU0NCiAg ICA+PiAgICAgRGF0ZTogV2VkLCAxMCBTZXB0ZW1iZXIgMjAxNCAxMzoyOSBVVEMNCiAgICA+PiAg ICAgUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQogICAgPj4NCiAgICA+ PiAgICAgSXQgc2VlbXMgdGhlIE1OSUQgaXMgc29tZWhvdyBvdmVybG9hZGVkIHRvIGNhcnJ5IGJv dGgsDQogICAgPj4gbm9kZS1zcGVjaWZpYw0KICAgID4+ICAgICBJRHMsIGUuZy4gTUFDLCBhcyB3 ZWxsIGFzIHN1YnNjcmliZXIgSURzLCB3aGljaCBpcyB0aGUgSU1TSS4NCiAgICA+PiAgICAgVGhl cmUgbWF5IGJlIHZhbHVlIGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJs ZQ0KICAgID4+IHR5cGVzIG9mDQogICAgPj4gICAgIG5vZGUtc3BlY2lmaWMgSURzLg0KICAgID4+ DQogICAgPj4gRWl0aGVyIHRoZSBwcmVzZW5jZSBvZiBJTUVJIGluIHRoaXMgbGlzdCBpcyBhIHNp bXBsZSBtaXN0YWtlIHRoYXQgaGFzDQogICAgPj4gcGVyc2lzdGVkIGluIGFsbCB2ZXJzaW9ucyBv ZiB0aGUgZHJhZnQsIG9yIHNwZWNpZnlpbmcgSU1FSSBoYXMgYWx3YXlzDQogICAgPj4gYmVlbiBp bnRlbmRlZCBidXQgaGFzIGFsd2F5cyBiZWVuIG92ZXJsb29rZWQuDQogICAgPj4NCiAgICA+PiAz LiBUaGUgZGVmaW5pdGlvbiBvZiBpZGVudGlmaWVyIHR5cGVzIGZvciBib3RoIEVVSS00OCBhbmQg RVVJLTY0DQogICAgPj4gc3VnZ2VzdHMgdGhhdCBpdCBtaWdodCBiZSBkZXNpcmFibGUgdG8gZGVm aW5lIGFuIGlkZW50aWZpZXIgdHlwZSBmb3INCiAgICA+PiBhcmJpdHJhcnkgaGFyZHdhcmUgKGxp bmstbGV2ZWwpIGFkZHJlc3Nlcy4gIEl0IHNlZW1zIHRoYXQgdGhlIG5hdHVyYWwNCiAgICA+PiBk aWZmZXJlbnRpYXRvciBmb3IgdGhhdCBwdXJwb3NlIGlzIHRoZSAiaGFyZHdhcmUgdHlwZSIgdXNl ZCBpbiBBUlAsDQogICAgPj4gc28NCiAgICA+PiBhIEVVSS00OCBhZGRyZXNzIHdvdWxkIGJlIHJl cHJlc2VudGVkIGFzDQogICAgPj4NCiAgICA+PiAgICAgTU4gaWRlbnRpZmllciB0eXBlIChvbmUg b2N0ZXQpIDUgKHNheSkNCiAgICA+PiAgICAgaGFyZHdhcmUgdHlwZSAodHdvIG9jdGV0cykgMQ0K ICAgID4+ICAgICBFVUktNDggKHNpeCBvY3RldHMpDQogICAgPj4NCiAgICA+PiBhbmQgYW4gRVVJ LTY0IHNpbWlsYXJseSwgd2l0aCBoYXJkd2FyZSB0eXBlIDI3Lg0KICAgID4+DQogICAgPj4gQWx0 aG91Z2ggd2l0aCBvbmx5IHR3byBzdWJ0eXBlcyBpbiBjb21tb24gdXNlLCBnZW5lcmFsaXppbmcg dGhpcw0KICAgID4+IG1pZ2h0DQogICAgPj4gbm90IGJlIHdvcnRoIHRoZSBlZmZvcnQuDQogICAg Pj4NCiAgICA+PiA0LiBTZXZlcmFsIG9mIHRoZSBpZGVudGlmaWVyIHR5cGVzIGNhbiBiZSByZXBy ZXNlbnRlZCBhcyBVUk5zOg0KICAgID4+DQogICAgPj4gLSBJTUVJIGNhbiBiZSByZXByZXNlbnRl ZCBhcyBhIFVSTiBhcyB1cm46Z3NtYTppbWVpOi4uLg0KICAgID4+IC0gYWxsIG9mIHRoZSBSRklE IHR5cGVzIGhhdmUgYSBVUk4gcmVwcmVzZW50YXRpb24gKGNhbGxlZCB0aGUNCiAgICA+PiAgICJw dXJlLWlkZW50aXR5IFVSSSIgaW4gdGhlIFJGSUQgc3BlY2lmaWNhdGlvbnMpLCB3aGljaCBzdGFy dHMNCiAgICA+PiAgIHVybjplcGM6aWQ6Li4uDQogICAgPj4NCiAgICA+PiBTaW5jZSBhbGwgVVJO IHR5cGVzIGFyZSBlbnN1cmVkIG9mIGJlaW5nIHVuaXF1ZSBhbmQgcGVyc2lzdGVudCwgaXQNCiAg ICA+PiBzZWVtcyB0aGF0IHdlIGNvdWxkIGRlZmluZSBhIE1OSUQgdHlwZSBmb3IgVVJOcyBnZW5l cmFsbHksIGFuZCB0aGVuDQogICAgPj4gYW55IFJGSUQgVVJJIG9yIGFuIElNRUkgKGFzIGEgVVJO KSBjb3VsZCBiZSB1c2VkIGFzIGEgdmFsdWUgb2YgdGhhdA0KICAgID4+IHR5cGUuDQogICAgPj4N CiAgICA+PiBJZiB0aGlzIGlkZWEgaXMgYWRvcHRlZCwgaXQgc2VlbXMgdGhhdCB0aGUgb3RoZXIg M0dQUCB0eXBlcyAoSU1TSSwNCiAgICA+PiBQLVRNU0ksIGFuZCBHVVRJKSBzaG91bGQgYmUgZ2l2 ZW4gZGVmaW5lZCBlbmNvZGluZ3MgYXMgVVJOcyBpbiBuZXcNCiAgICA+PiBzdWItbmFtZXNwYWNl cyBvZiB0aGUgImdzbWEiIFVSTiBuYW1lc3BhY2UsIHRvIHBhcmFsbGVsIHRoZSBlbmNvZGluZw0K ICAgID4+IG9mIElNRUlzIGRlZmluZWQgaW4gUkZDIDcyNTQuDQogICAgPj4NCiAgICA+PiBUaGlz IGNvbnNvbGlkYXRpb24gY291bGQgYmUgc2lnbmlmaWNhbnRseSBiZW5lZmljaWFsLiAgSXQgYWxs b3dzIE1OSUQNCiAgICA+PiB0byB1c2UgYW55IFVSTiBzY2hlbWUgYXMgYW4gaWRlbnRpZmllci4g IEl0IHJlZHVjZXMgdGhlIHRocmVlDQogICAgPj4gZGlmZmVyZW50IFJGSUQgcmVwcmVzZW50YXRp b25zIHRvIG9uZS4gIEl0IGluY29ycG9yYXRlcyBhbnkgZnV0dXJlDQogICAgPj4gZXhwYW5zaW9u IG9mIFJGSUQgc2NoZW1lcyAoYmVjYXVzZSBhbGwgc2NoZW1lcyB3aWxsIGhhdmUgYQ0KICAgID4+ IHB1cmUtaWRlbnRpdHkgVVJOIHJlcHJlc2VudGF0aW9uKS4gIEEgZGlzYWR2YW50YWdlIGlzIHRo YXQgdGhlIFVSTg0KICAgID4+IGVuY29kaW5ncyBhcmUgbG9uZywgYnV0IHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBzZWN0aW9uIHN0YXRlcw0KICAgID4+IHRoYXQgTU5JRHMgYXJlIHVzZWQg b25seSBvbiB0aGUgZmlyc3QgcmVnaXN0cmF0aW9uIGF0IHRoZSBob21lIGFnZW50LA0KICAgID4+ IHNvIHRoZXJlIGlzbid0IG11Y2ggbmVlZCBmb3IgYnJldml0eS4NCiAgICA+Pg0KICAgID4+IFNp bWlsYXJseSwgdGhpcyBhcHByb2FjaCBpbmNvcnBvcmF0ZXMgYW55IGZ1dHVyZSBleHBhbnNpb24g b2YgbW9iaWxlDQogICAgPj4gaWRlbnRpZmllcnMgdGhhdCBHU01BIGRlY2lkZXMgdG8gZGVmaW5l LCBhcyBsb25nIGFzIEdTTUEgcHJvdmlkZXMgYQ0KICAgID4+IFVSTiByZXByZXNlbnRhdGlvbiBm b3IgaXQuDQogICAgPj4NCiAgICA+PiBUaGUgbW9zdCBzaWduaWZpY2FudCBkaXNhZHZhbnRhZ2Ug aXMgdGhhdCBzb21lIFVSTiBzY2hlbWVzIGFsbG93DQogICAgPj4gc2V2ZXJhbCBjaGFyYWN0ZXIg c3RyaW5ncyB0byAibWVhbiIgdGhlIHNhbWUgVVJOLiAgSW4gbW9zdCBVUk4NCiAgICA+PiBzY2hl bWVzLCB0aGUgYWxsb3dlZCB2YXJpYXRpb24gaXMgbGltaXRlZCB0byB0aGUgY2FzZSBvZiBsZXR0 ZXJzLCBhbmQNCiAgICA+PiB0aGUgY29tbW9uIGNvbnZlbnRpb24gaXMgdG8gYWx3YXlzIHVzZSBs b3dlci1jYXNlIHdoZW4gdGhlcmUgaXMgYQ0KICAgID4+IGNob2ljZSwgbGVhZGluZyB0byBhIHVu aXF1ZSBjb252ZW50aW9uYWwgY2Fub25pY2FsIGZvcm0gZm9yIHRoZSBVUk4uDQogICAgPj4NCiAg ICA+PiA1LiBSZWdhcmRpbmcgdGhlIGVuY29kaW5nIG9mIGEgc3RyaW5nIG9mIGRpZ2l0cyBpbnRv IG9jdGV0cywgaXQgaXMNCiAgICA+PiBzdGF0ZWQgdGhhdCAiVGhlIGxhc3QgZGlnaXQgTVVTVCBi ZSB6ZXJvIHBhZGRlZCwgaWYgbmVlZGVkLCBmb3IgZnVsbA0KICAgID4+IG9jdGV0IHNpemUuIiAg VGhpcyBzZWVtcyB2ZXJ5IHVud2lzZSB1bmxlc3MgdGhlcmUgaXMgYSAzR1BQIGRlY3JlZQ0KICAg ID4+IHRoYXQgaWYgYSB6ZXJvIGlzIGFwcGVuZGVkIHRvIGEgdmFsaWQgSU1TSSwgdGhlIHJlc3Vs dGluZyBzdHJpbmcgaXMNCiAgICA+PiBuZXZlciBhIHZhbGlkIElNU0kuICBJbnN0ZWFkLCBJIHdv dWxkIHNwZWNpZnkgdGhhdCBwYWRkaW5nIGlzIGJ5DQogICAgPj4gZmlsbGluZyB0aGUgbG93LW9y ZGVyIDQgYml0cyBvZiB0aGUgZmluYWwgb2N0ZXQgd2l0aCAweEYuICBUaGF0DQogICAgPj4gZW5z dXJlcyB0aGF0IHRoZSBlbmNvZGluZyBjYW4gYmUgdW5pcXVlbHkgZGVjb2RlZCBpbnRvIGFuIElN U0kuDQogICAgPj4NCiAgICA+PiA2LiBUaGVyZSBhcmUgZm91ciB0eXBlcyBvZiBEVUlEIHNwZWNp ZmllZCwgZWFjaCB3aXRoIGEgZGlzdGluY3QgTU5JRA0KICAgID4+IHZhbHVlLiAgSG93ZXZlciwg RFVJRHMgY29udGFpbiBhbiBpbml0aWFsIHR3by1vY3RldCB0eXBlIGZpZWxkIHdoaWNoDQogICAg Pj4gZGlzdGluZ3Vpc2hlcyB0aGUgdmFyaW91cyB0eXBlcyBvZiBEVUlELCBzbyBwcm92aWRpbmcg dGhlbSB3aXRoDQogICAgPj4gZGlzdGluY3QgTU5JRCB2YWx1ZXMgaXMgcmVkdW5kYW50Lg0KICAg ID4+DQogICAgPj4gRGlzdGluZ3Vpc2hpbmcgdGhlIHR5cGVzIGFuZCBhbGxvd2luZyBvbmx5IGZv dXIgb2YgdGhlbSB0byBiZSB1c2VkIGFzDQogICAgPj4gTU5JRHMgc2VlbXMgdG8gYmUgY29udHJh cnkgdG8gdGhlIHBoaWxvc29waHkgb2YgRFVJRCBjb25zdHJ1Y3Rpb24NCiAgICA+PiAoUkZDDQog ICAgPj4gMzMxNSBzZWN0aW9uIDkpOg0KICAgID4+DQogICAgPj4gICAgQ2xpZW50cyBhbmQgc2Vy dmVycyBNVVNUIHRyZWF0IERVSURzIGFzIG9wYXF1ZSB2YWx1ZXMgYW5kIE1VU1QNCiAgICA+PiBv bmx5DQogICAgPj4gICAgY29tcGFyZSBEVUlEcyBmb3IgZXF1YWxpdHkuICBDbGllbnRzIGFuZCBz ZXJ2ZXJzIE1VU1QgTk9UIGluIGFueQ0KICAgID4+ICAgIG90aGVyIHdheSBpbnRlcnByZXQgRFVJ RHMuICBDbGllbnRzIGFuZCBzZXJ2ZXJzIE1VU1QgTk9UIHJlc3RyaWN0DQogICAgPj4gICAgRFVJ RHMgdG8gdGhlIHR5cGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgYXMgYWRkaXRpb25hbCBE VUlEDQogICAgPj4gdHlwZXMNCiAgICA+PiAgICBtYXkgYmUgZGVmaW5lZCBpbiB0aGUgZnV0dXJl Lg0KICAgID4+DQogICAgPj4gT2YgY291cnNlLCBNTklEIGlzbid0IGEgREhDUCBvcGVyYXRpb24s IHNvIGl0IGlzbid0IHN1YmplY3QgdG8gdGhvc2UNCiAgICA+PiByZXF1aXJlbWVudHMsIGJ1dCBJ IGV4cGVjdCB0aGF0IGRldmljZXMgd2lsbCB1c2UgdGhlIHNhbWUgRFVJRCBmb3INCiAgICA+PiBi b3RoIG1vYmlsZSBpZGVudGlmaWNhdGlvbiwgYW5kIHdlIGRvbid0IHdhbnQgbW9iaWxlIGlkZW50 aWZpY2F0aW9uDQogICAgPj4gdG8NCiAgICA+PiByZXN0cmljdCBmdXR1cmUgZGV2ZWxvcG1lbnRz IG9mIERIQ1AuDQogICAgPj4NCiAgICA+PiBJIHRoaW5rIHRoaXMgc3BlY2lmaWNhdGlvbiBtdXN0 IHRyZWF0IERVSURzIGFzIG9wYXF1ZSBhbmQgdXNlIG9ubHkNCiAgICA+PiBvbmUNCiAgICA+PiBN TklEIHR5cGUgdGhhdCBhbGxvd3MgYWxsIHR5cGVzIG9mIERVSURzIGFzIHZhbHVlcy4NCiAgICA+ Pg0KICAgID4+IEVkaXRvcmlhbCBpc3N1ZXM6DQogICAgPj4NCiAgICA+PiBBYnN0cmFjdA0KICAg ID4+DQogICAgPj4gICAgQWRkaXRpb25hbCBJZGVudGlmaWVyIFR5cGVzIGFyZSBwcm9wb3NlZCBm b3IgdXNlIHdpdGggdGhlIE1vYmlsZQ0KICAgID4+IE5vZGUNCiAgICA+PiAgICBJZGVudGlmaWVy IE9wdGlvbiBmb3IgSVB2NiAoUkZDIDQyODMpLg0KICAgID4+DQogICAgPj4gcy9wcm9wb3NlZC9k ZWZpbmVkLw0KICAgID4+IFRoaXMgZG9jdW1lbnQgd2lsbCBkZWZpbmUgdGhlIG5ldyB0eXBlcyAo b25jZSBpdCBpcyBhcHByb3ZlZCkhDQogICAgPj4NCiAgICA+PiAxLiAgSW50cm9kdWN0aW9uDQog ICAgPj4NCiAgICA+PiAgICAuLi4gdHlwZXMgZm9yIElNU0kNCiAgICA+PiAgICBbVGhyZWVHUFAt SURTXSwgUC1UTVNJIFtUaHJlZUdQUC1JRFNdLCBJTUVJIFtUaHJlZUdQUC1JRFNdLCBhbmQNCiAg ICA+PiBHVVRJDQogICAgPj4gICAgW1RocmVlR1BQLUlEU10uDQogICAgPj4NCiAgICA+PiBUaGVy ZSBpcyBubyBkZXNjcmlwdGlvbiBvZiBQLVRNU0kgaWRlbnRpZmllcnMsIGFsdGhvdWdoIGl0IGlz DQogICAgPj4gYXNzaWduZWQNCiAgICA+PiBpZGVudGlmaWVyIHR5cGUgNC4NCiAgICA+Pg0KICAg ID4+IFRoZXJlIGlzIG5vIGRlc2NyaXB0aW9uIG9mIEdVVEkgaWRlbnRpZmllcnMsIGFsdGhvdWdo IGl0IGlzIGFzc2lnbmVkDQogICAgPj4gaWRlbnRpZmllciB0eXBlIDcuDQogICAgPj4NCiAgICA+ PiAzLiAgTmV3IE1vYmlsZSBOb2RlIElkZW50aWZpZXIgVHlwZXMNCiAgICA+Pg0KICAgID4+ICAg IFRoZSBmb2xsb3dpbmcgdHlwZXMgb2YgaWRlbnRpZmllcnMgYXJlIGNvbW1vbmx5IHVzZWQgdG8g aWRlbnRpZnkNCiAgICA+PiAgICBtb2JpbGUgbm9kZXMuICBGb3IgZWFjaCB0eXBlLCByZWZlcmVu Y2VzIGFyZSBwcm92aWRlZCB3aXRoIGZ1bGwNCiAgICA+PiAgICBkZXRhaWxzIG9uIHRoZSBmb3Jt YXQgb2YgdGhlIHR5cGUgb2YgaWRlbnRpZmllci4NCiAgICA+Pg0KICAgID4+ICAgIFRoZSBUYWcg RGF0YSBzdGFuZGFyZCBwcm9tb3RlZCBieSBFbGVjdHJvbmljIFByb2R1Y3QgQ29kZShUTSkNCiAg ICA+PiAgICAoYWJicmV2aWF0ZWQgRVBDKSBzdXBwb3J0cyBzZXZlcmFsIGVuY29kaW5nIHN5c3Rl bXMgb3Igc2NoZW1lcw0KICAgID4+ICAgIGluY2x1ZGluZw0KICAgID4+DQogICAgPj4gICAgbyAg UkZJRC1HSUQgKEdsb2JhbCBJZGVudGlmaWVyKSwNCiAgICA+PiAgICBvICBSRklELVNHVElOIChT ZXJpYWxpemVkIEdsb2JhbCBUcmFkZSBJdGVtIE51bWJlciksDQogICAgPj4gICAgbyAgUkZJRC1T U0NDIChTZXJpYWwgU2hpcHBpbmcgQ29udGFpbmVyKSwNCiAgICA+PiAgICBvICBSRklELVNHTE4g KEdsb2JhbCBMb2NhdGlvbiBOdW1iZXIpLA0KICAgID4+ICAgIG8gIFJGSUQtR1JBSSAoR2xvYmFs IFJldHVybmFibGUgQXNzZXQgSWRlbnRpZmllciksDQogICAgPj4gICAgbyAgUkZJRC1ET0QgKERl cGFydG1lbnQgb2YgRGVmZW5zZSBJRCksIGFuZA0KICAgID4+ICAgIG8gIFJGSUQtR0lBSSAoR2xv YmFsIEluZGl2aWR1YWwgQXNzZXQgSWRlbnRpZmllcikuDQogICAgPj4NCiAgICA+PiAgICBGb3Ig ZWFjaCBSRklEIHNjaGVtZSBleGNlcHQgR0lELCB0aGVyZSBhcmUgdHdvIHZhcmlhdGlvbnM6IGEN CiAgICA+PiA2NC1iaXQNCiAgICA+PiAgICBzY2hlbWUgKGZvciBleGFtcGxlLCBTR0xOLTY0KSBh bmQgYSA5Ni1iaXQgc2NoZW1lIChTR0xOLTk2KS4gIEdJRA0KICAgID4+IGhhcw0KICAgID4+ICAg IG9ubHkgYSA5Ni1iaXQgc2NoZW1lLiAgV2l0aGluIGVhY2ggc2NoZW1lLCBhbiBFUEMgaWRlbnRp ZmllciBjYW4NCiAgICA+PiBiZQ0KICAgID4+ICAgIHJlcHJlc2VudGVkIGluIGEgYmluYXJ5IGZv cm0gb3Igb3RoZXIgZm9ybXMgc3VjaCBhcyBVUkkuDQogICAgPj4NCiAgICA+PiAgICBUaGUgZm9s bG93aW5nIGxpc3QgaW5jbHVkZXMgdGhlIGFib3ZlIFJGSUQgdHlwZXMgYXMgd2VsbCBhcw0KICAg ID4+IHZhcmlvdXMNCiAgICA+PiAgICBvdGhlciBjb21tb24gaWRlbnRpZmllcnMgYW5kIHNldmVy YWwgZGlmZmVyZW50IHR5cGVzIG9mIERVSURzLg0KICAgID4+DQogICAgPj4gVGhlIG9yZ2FuaXph dGlvbiBvZiB0aGUgdGV4dCBoZXJlIHNlZW1zIHRvIGJlIHBvb3IgLS0gc2VjdGlvbiAzDQogICAg Pj4gZW51bWVyYXRlcyB0aGUgbmV3IGlkZW50aWZpZXIgdHlwZXMsIGJ1dCBtdWNoIG9mIHRoZSB0 ZXh0IGF0IHRoZQ0KICAgID4+IGJlZ2lubmluZyBvZiB0aGUgc2VjdGlvbiBpcyBhYm91dCB0aGUg UkZJRC1FUEMgc2V0IG9mIHR5cGVzLiAgSXQNCiAgICA+PiBzZWVtcw0KICAgID4+IGxpa2UgYSBi ZXR0ZXIgb3JnYW5pemF0aW9uIGlzIHRvIHVzZSBqdXN0IHBhcmFncmFwaCAxIGZvbGxvd2VkIGJ5 DQogICAgPj4gdGFibGUgMSwgYW5kIG1vdmUgcGFyYWdyYXBocyAyLTUgaW50byBzZWN0aW9uIDQu OS4NCiAgICA+Pg0KICAgID4+ICAgIFRoZSBUYWcgRGF0YSBzdGFuZGFyZCBwcm9tb3RlZCBieSBF bGVjdHJvbmljIFByb2R1Y3QgQ29kZShUTSkNCiAgICA+PiAgICAoYWJicmV2aWF0ZWQgRVBDKSBz dXBwb3J0cyBzZXZlcmFsIGVuY29kaW5nIHN5c3RlbXMgb3Igc2NoZW1lcw0KICAgID4+ICAgIGlu Y2x1ZGluZw0KICAgID4+DQogICAgPj4gVGhlIHRleHQgaXMgdXNpbmcgIlRhZyBEYXRhIiwgIkVQ QyIsIGFuZCAiUkZJRCIgaW4gYSB3YXkgdGhhdCBpcw0KICAgID4+IGludGVydHdpbmVkIGJ1dCBu b3QgZXhwbGFpbmVkLiAgSSBjYW4gc2VlIHRoYXQgaXQgbWlnaHQgYmUgdXNlZnVsIHRvDQogICAg Pj4gdXNlIGFsbCBvZiB0aGUgdGVybXMgaWYgdGhleSBjb21tb25seSB1c2VkIGluIHRoZSBmaWVs ZCAoZG9uJ3QgZm9yZ2V0DQogICAgPj4gdG8gbWFrZSB0aGVtIGtleXdvcmRzIGZvciB0aGUgUkZD ISksIGJ1dCB5b3UgbmVlZCB0byBleHBsYWluIHRoZWlyDQogICAgPj4gY29ubmVjdGlvbiBhbmQg ZGlzdGluY3Rpb24gdG8gdGhlIHJlYWRlciBvciBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlDQogICAg Pj4gcmVhZGVyIGRvZXMgbm90IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZXMgYW1v bmcgdGhlIHRlcm1zLg0KICAgID4+IEUuZy4sIHRoaXMgZm9ybXVsYXRpb24gdGllcyBhbGwgdGhy ZWUgdGVybXMgdG9nZXRoZXINCiAgICA+Pg0KICAgID4+ICAgIFRoZSBUYWcgRGF0YSBzdGFuZGFy ZCBwcm9tb3RlZCBieSBFbGVjdHJvbmljIFByb2R1Y3QgQ29kZShUTSkNCiAgICA+PiAgICAoYWJi cmV2aWF0ZWQgRVBDKSBzdXBwb3J0cyBzZXZlcmFsIGVuY29kaW5nIHN5c3RlbXMgb3Igc2NoZW1l cw0KICAgID4+ICAgIHdoaWNoIGFyZSBjb21tb25seSB1c2VkIGluIFJGSUQgKHJhZGlvLWZyZXF1 ZW5jeSBpZGVudGlmaWNhdGlvbikNCiAgICA+PiAgICBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZw0K ICAgID4+DQogICAgPj4gLS0NCiAgICA+Pg0KICAgID4+ICAgIEZvciBlYWNoIFJGSUQgc2NoZW1l IGV4Y2VwdCBHSUQsIHRoZXJlIGFyZSB0d28gdmFyaWF0aW9uczogYQ0KICAgID4+IDY0LWJpdA0K ICAgID4+ICAgIHNjaGVtZSAoZm9yIGV4YW1wbGUsIFNHTE4tNjQpIGFuZCBhIDk2LWJpdCBzY2hl bWUgKFNHTE4tOTYpLiAgR0lEDQogICAgPj4gaGFzDQogICAgPj4gICAgb25seSBhIDk2LWJpdCBz Y2hlbWUuICBXaXRoaW4gZWFjaCBzY2hlbWUsIGFuIEVQQyBpZGVudGlmaWVyIGNhbg0KICAgID4+ IGJlDQogICAgPj4gICAgcmVwcmVzZW50ZWQgaW4gYSBiaW5hcnkgZm9ybSBvciBvdGhlciBmb3Jt cyBzdWNoIGFzIFVSSS4NCiAgICA+Pg0KICAgID4+IFRoZSB0ZXh0IHVzZXMgInNjaGVtZSIgdG8g bWVhbiB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBlbmNvZGluZw0KICAgID4+IHN5c3RlbXMgKEdJ RCwgU0dUSU4sIGV0Yy4pIGFuZCBhbmQgYWxzbyB0byBtZWFuIHRoZSBkaXN0aW5jdGlvbg0KICAg ID4+IGJldHdlZW4gdGhlIDY0LWJpdCBhbmQgOTYtYml0IHZhcmlhdGlvbnMuICBUaGlzIGFtYmln dWl0eSBpcyB1bndpc2UuDQogICAgPj4gSXQgbWF0dGVycyBoZXJlLCBiZWNhdXNlIHlvdSBzYXkg IndpdGhpbiBlYWNoIHNjaGVtZSAuLi4gY2FuIGJlDQogICAgPj4gcmVwcmVzZW50ZWQgaW4gYSBi aW5hcnkgZm9ybSBvciAuLi4gVVJJIi4gIFdoaWNoIG1lYW5pbmcgb2YgInNjaGVtZSINCiAgICA+ PiBhcmUgeW91IHVzaW5nIGhlcmU/ICBJIHRob3VnaHQgeW91IG1lYW50IHRoZSBzZWNvbmQgbWVh bmluZyB3aGVuIEkNCiAgICA+PiBmaXJzdCByZWFkIHRoZSBwYXJhZ3JhcGgsIGJ1dCBhZnRlciBy ZWFkaW5nIGV4dGVybmFsIGRvY3VtZW50cyBhYm91dA0KICAgID4+IEVQQywgSSBub3cgdW5kZXJz dGFuZCB0aGF0IHRoYXQgbGFzdCBzZW50ZW5jZSB1c2VzICJzY2hlbWUiIHRvIGluIHRoZQ0KICAg ID4+IGZpcnN0IHNlbnNlLg0KICAgID4+DQogICAgPj4gWW91IG5lZWQgdG8gYmUgY2xlYXJlciBo ZXJlIHRoYXQgdGhlcmUgYXJlIHRocmVlIHJlcHJlc2VudGF0aW9ucw0KICAgID4+IHVzZWQsDQog ICAgPj4gNjQtYml0IGJpbmFyeSwgOTYtYml0IGJpbmFyeSwgYW5kIFVSSSAoVVJOLCBhY3R1YWxs eSksIGFuZA0KICAgID4+IHJlcHJlc2VudGF0aW9uIGlzIG9ydGhvZ29uYWwgdG8gdGhlIHNldmVu IFJGSUQgc2NoZW1lcywgd2l0aCB0aGUNCiAgICA+PiBleGNlcHRpb24gdGhhdCBSRklELUdJRCBk b2VzIG5vdCBoYXZlIGEgOTYtYml0IGJpbmFyeSByZXByZXNlbnRhdGlvbi4NCiAgICA+Pg0KICAg ID4+IEknbSBhc3N1bWluZyB0aGF0IHRoZSBUYWcgRGF0YSBzdGFuZGFyZCB1bmFtYmlndW91c2x5 IGRlZmluZXMgdGhlDQogICAgPj4gc2VyaWFsaXphdGlvbiBvZiB0aGUgYmluYXJ5IHJlcHJlc2Vu dGF0aW9ucyBhcyBhIHNlcXVlbmNlIG9mIG9jdGV0cy4NCiAgICA+PiBJZiBpdCBkb2VzIG5vdCwg dGhpcyBkb2N1bWVudCBNVVNUIGRvIHRoYXQsIG9yIHlvdSB3aWxsIGhhdmUgYW4NCiAgICA+PiBl bmRsZXNzIG5pZ2h0bWFyZSBvZiBieXRlLW9yZGVyIHByb2JsZW1zLg0KICAgID4+DQogICAgPj4g NC4gIERlc2NyaXB0aW9ucyBvZiBNTklEIHR5cGVzDQogICAgPj4NCiAgICA+PiBJZGVudGlmaWVy IG93bmVyc2hpcCBpcyBhIGdlbmVyYWwgY29uY2VybiAtLSBpdCdzIHdvcnRoIG1lbnRpb25pbmcN CiAgICA+PiBmb3INCiAgICA+PiBlYWNoIHR5cGUgb2YgaWRlbnRpZmllciB3aGVyZSB0aGUgYXNz aWduZXIgb2YgdGhlIGlkZW50aWZpZXIgb2J0YWlucw0KICAgID4+IGRlbGVnYXRpb24uICBGb3Ig YW4gRVVJLCBJIGV4cGVjdCB0aGUgcmVhZGVyIHdpbGwgYXNzdW1lIHRoYXQgaXQncyBhbg0KICAg ID4+IEVVSSBhc3NpZ25lZCB0byB0aGUgZGV2aWNlIHVuZGVyIElFRUUgcnVsZXMsIGFuZCBzaW1p bGFybHkgZm9yIFJGSUQNCiAgICA+PiBhbmQgM0dQUCBpZGVudGlmaWVycy4gIEJ1dCBmb3IgRFVJ RCBpZGVudGlmaWVycywgaXQncyBsZXNzIGNsZWFyLg0KICAgID4+IEknbQ0KICAgID4+IGd1ZXNz aW5nIHRoYXQgdGhlIERVSUQgaXMgb25lIHRoYXQgaXMsIG9yIGNvdWxkIGJlLCB1c2VkIGJ5IHRo ZQ0KICAgID4+IGRldmljZQ0KICAgID4+IGZvciBESENQIHB1cnBvc2VzLiAgRm9yIElQdjYgYWRk cmVzc2VzLCBpdCdzIGV2ZW4gbGVzcyBjbGVhciwgc2luY2UNCiAgICA+PiB0aGUgSVB2NiBhcmNo aXRlY3R1cmUgZG9lc24ndCBhc3N1bWUgdGhhdCB0aGUgYXNzb2NpYXRpb24gb2YNCiAgICA+PiBh ZGRyZXNzZXMNCiAgICA+PiB3aXRoIGRldmljZXMgaXMgcGVybWFuZW50Lg0KICAgID4+DQogICAg Pj4gNC4xLiAgRGVzY3JpcHRpb24gb2YgdGhlIElQdjYgYWRkcmVzcyB0eXBlDQogICAgPj4NCiAg ICA+PiBJdCB3b3VsZCBiZSBnb29kIGlmIHRoZSBkb2N1bWVudCBkZXNjcmliZWQgd2hhdCB0aGUg c2VtYW50aWNzIG9mIHRoaXMNCiAgICA+PiBJRCBhcmUuICBZZXMsIGl0J3MgYSB1bmljYXN0IElQ djYgYWRkcmVzcywgYnV0IHdoYXQgaXMgdGhlIGNvbm5lY3Rpb24NCiAgICA+PiBiZXR3ZWVuIHRo YXQgYWRkcmVzcyBhbmQgdGhlIGRldmljZT8gIEkgc3VzcGVjdCB0aGUgY29ubmVjdGlvbiBpcw0K ICAgID4+ICJ0aGUNCiAgICA+PiBkZXZpY2UgaGFzIGJlZW4gY29uZmlndXJlZCB0byBleHBlY3Qg dGhhdCBpdCB3aWxsIGJlIGFzc2lnbmVkIHRoaXMNCiAgICA+PiBhZGRyZXNzIGFzIGEgbG9uZy10 ZXJtIGludGVyZmFjZSBhZGRyZXNzIiwgYnV0IHRoZXJlIGFyZSBvdGhlcg0KICAgID4+IHBvc3Np YmlsaXRpZXMuICBFLmcuLCBJIGNhbiBpbWFnaW5lIGEgbW9iaWxlIGNhcnJpZXIgb2J0YWluaW5n IGEgLzY0DQogICAgPj4gcHJlZml4ICh0aGVyZSBhcmUgcGxlbnR5IG9mIHRoZW0hKSBhbmQgdGhl biBhc3NpZ25pbmcgYWRkcmVzc2VzIG91dA0KICAgID4+IG9mDQogICAgPj4gaXQgc2ltcGx5IHRv IGNyZWF0ZSBhIHNlcXVlbmNlIG9mIHVuaXF1ZSBpZGVudGlmaWVycyBmb3IgZGV2aWNlcywgYnV0 DQogICAgPj4gbm90IHVzaW5nIHRob3NlIGFkZHJlc3NlcyBvbiBwYWNrZXRzLg0KICAgID4+DQog ICAgPj4gVGhlbiBhZ2FpbiwgcGVyaGFwcyB5b3Ugd2FudCB0byBhbGxvdyBmbGV4aWJpbGl0eS4g IEJ1dCBpbiBhbnkgY2FzZSwNCiAgICA+PiBJDQogICAgPj4gdGhpbmsgeW91IG5lZWQgdG8gc3Bl Y2lmeSB3aGF0IHRoZSBydWxlcyBhcmUgZm9yIHdoYXQgYWRkcmVzcyBpcw0KICAgID4+IGFzc29j aWF0ZWQgd2l0aCB3aGF0IGRldmljZS4NCiAgICA+Pg0KICAgID4+IDQuMi4gIERlc2NyaXB0aW9u IG9mIHRoZSBJTVNJIE1OSUQgdHlwZQ0KICAgID4+DQogICAgPj4gV2hhdCBkb2VzICJpbiBuZXR3 b3JrIG9yZGVyIiBtZWFuIGhlcmU/ICBBcyBmYXIgYXMgSSBrbm93LCB0aGVyZSBpcw0KICAgID4+ IG5vDQogICAgPj4gZGVmaW5lZCAibmV0d29yayBvcmRlciIgZm9yIDQtYml0IHF1YW50aXRpZXMs IG9ubHkgZm9yIGRpdmlkaW5nDQogICAgPj4gaW50ZWdlcnMgaW50byBvY3RldHMgYW5kIHBsYWNp bmcgc2VxdWVuY2VzIG9mIGJpdHMgaW50byBvY3RldHMuICBJDQogICAgPj4gYXNzdW1lIHlvdSBt ZWFuIHRoYXQgaW4gYW55IG9jdGV0LCB0aGUgaGlnaC1vcmRlciA0IGJpdHMgYXJlIHRoZQ0KICAg ID4+IGZpcnN0DQogICAgPj4gZGlnaXQgYW5kIHRoZSBsb3ctb3JkZXIgNCBiaXRzIGFyZSB0aGUg c2Vjb25kIGRpZ2l0LCBidXQgSSB0aGluayB5b3UNCiAgICA+PiBuZWVkIHRvIHN0YXRlIHRoYXQg ZXhwbGljaXRseS4NCiAgICA+Pg0KICAgID4+IDQuMy4gIERlc2NyaXB0aW9uIG9mIHRoZSBFVUkt NDggYWRkcmVzcyB0eXBlDQogICAgPj4NCiAgICA+PiAgICBUaGUgSUVFRSBFVUktNDggYWRkcmVz cyBbSUVFRTgwMi1ldWk0OF0gaXMgZW5jb2RlZCBhcyBhIDYgb2N0ZXQNCiAgICA+PiAgICBzdHJp bmcgY29udGFpbmluZyB0aGUgSUVFRSBFVUktNDggYWRkcmVzcy4NCiAgICA+Pg0KICAgID4+IElz ICJzdHJpbmciIHRoZSBjb3JyZWN0IHdvcmQsIHRoaXMgbm90IGJlaW5nIGEgc2VxdWVuY2Ugb2YN CiAgICA+PiBjaGFyYWN0ZXJzPw0KICAgID4+IEkgd291bGQgc2F5ICJzZXF1ZW5jZSBvZiA2IG9j dGV0cyIgb3Igc2ltcGx5ICJlbmNvZGVkIGFzIDYgb2N0ZXRzIi4NCiAgICA+Pg0KICAgID4+IDQu OS4gIERlc2NyaXB0aW9uIG9mIHRoZSBSRklEIHR5cGVzDQogICAgPj4NCiAgICA+PiBUaGlzIHNl Y3Rpb24gbmVlZHMgdG8gYmUgcmV2aXNlZC4gIEl0IHByb3ZpZGVzIGEgbG90IG9mIGRldGFpbCBh Ym91dA0KICAgID4+IHRoZSBSRklEIHR5cGVzLCBidXQgaXQncyBub3QgZW5vdWdoIGRldGFpbCBm b3IgYSByZWFkZXIgd2hvIGRvZXNuJ3QNCiAgICA+PiB1bmRlcnN0YW5kIFJGSUQgdG8gbGVhcm4g aG93IGFueSBwYXJ0aWN1bGFyIFJGSUQgc2NoZW1lIHdvcmtzLiAgRS5nLiwNCiAgICA+PiB0aGUg Zmlyc3QgcGFyYWdyYXBoIHNheXMgdGhhdCBHSUQgY29udGFpbnMgdGhyZWUgZmllbGRzIGluIHRo ZSBmaXJzdA0KICAgID4+IHNlbnRlbmNlLCBhbmQgdGhhdCBpdCBjb250YWlucyBmb3VyIGZpZWxk cyBpbiB0aGUgdGhpcmQgc2VudGVuY2UuDQogICAgPj4gRGVzcGl0ZSB0aGlzLCB0aGUgZGVzY3Jp cHRpb24gaXNuJ3QgZW5vdWdoIHRvIGFsbG93IHRoZSByZWFkZXIgdG8NCiAgICA+PiBjb25zdHJ1 Y3QgR0lEIGlkZW50aWZpZXJzIG1hbnVhbGx5Lg0KICAgID4+DQogICAgPj4gT24gdGhlIG90aGVy IGhhbmQsIHJlYWRlcnMgd2hvIGFscmVhZHkgdW5kZXJzdGFuZCB0aGUgUkZJRCBzY2hlbWVzDQog ICAgPj4gd2lsbCBmaW5kIHRoaXMgdGV4dCByZWR1bmRhbnQuDQogICAgPj4NCiAgICA+PiBJIHRo aW5rIHRoYXQgYWxtb3N0IGFsbCBvZiB0aGlzIHRleHQgY2FuIGJlIHJlcGxhY2VkIGJ5IHJlZmVy ZW5jZXMgdG8NCiAgICA+PiB0aGUgRVBDIGRvY3VtZW50cywgc2luY2UgdGhlc2UgaWRlbnRpZmll cnMgYXJlIG9wYXF1ZSBmcm9tIHRoZSBwb2ludA0KICAgID4+IG9mIHZpZXcgb2YgbW9iaWxlIGlk ZW50aWZpY2F0aW9uLg0KICAgID4+DQogICAgPj4gNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z DQogICAgPj4NCiAgICA+PiBUaGUgYmFzZSBNTklEIHNwZWNpZmljYXRpb24sIFJGQyA0MjgzLCBn aXZlcyB0aGVzZSBzZWN1cml0eQ0KICAgID4+IGNvbnNpZGVyYXRpb25zIChzZWMgNCksIHdoaWNo IG91Z2h0IHRvIGJlIHJlZmVyZW5jZWQgYW5kIHByb2JhYmx5DQogICAgPj4gc3VtbWFyaXplZCBp biB0aGlzIHNlY3Rpb246DQogICAgPj4NCiAgICA+PiAgICBNb3Jlb3ZlciwgTU5JRHMgY29udGFp bmluZyBzZW5zaXRpdmUgaWRlbnRpZmllcnMgbWlnaHQgb25seSBiZQ0KICAgID4+IHVzZWQNCiAg ICA+PiAgICBmb3Igc2lnbmFsaW5nIGR1cmluZyBpbml0aWFsIG5ldHdvcmsgZW50cnkuICBTdWJz ZXF1ZW50IGJpbmRpbmcNCiAgICA+PiAgICB1cGRhdGUgZXhjaGFuZ2VzIG1pZ2h0IHRoZW4gcmVs eSBvbiBhIHRlbXBvcmFyeSBpZGVudGlmaWVyDQogICAgPj4gYWxsb2NhdGVkDQogICAgPj4gICAg ZHVyaW5nIHRoZSBpbml0aWFsIG5ldHdvcmsgZW50cnksIHBlcmhhcHMgdXNpbmcgbWVjaGFuaXNt cyBub3QNCiAgICA+PiAgICBzdGFuZGFyZGl6ZWQgd2l0aGluIHRoZSBJRVRGLiAgTWFuYWdpbmcg dGhlIGFzc29jaWF0aW9uIGJldHdlZW4NCiAgICA+PiBsb25nLQ0KICAgID4+ICAgIGxpdmVkIGFu ZCB0ZW1wb3JhcnkgaWRlbnRpZmllcnMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KICAg ID4+ICAgIGRvY3VtZW50Lg0KICAgID4+DQogICAgPj4gV2hhdCBpcyB0aGUgbWVhbmluZyBvZiB0 aGUgd29yZCAibWlnaHQiIGluIHBhcmFncmFwaCAzPyAgSSBzdXNwZWN0DQogICAgPj4gdGhhdCB0 aGUgcHVycG9zZSBpcyB0byBxdWFsaWZ5IHRoaXMgcGFyYWdyYXBoIHdpdGggIk9uZSB3YXkgdG8N CiAgICA+PiBhZGRyZXNzDQogICAgPj4gdGhlc2UgdnVsbmVyYWJpbGl0aWVzIGlzIHRvIG9ubHkg dXNlIE1OSURzIGNvbnRhaW5pbmcgLi4uIi4gIEJ1dCBpZg0KICAgID4+IHRoYXQgaXMgdGhlIG1l YW5pbmcsIHRoYXQgZXhwYW5kZWQgd29yZGluZyBzaG91bGQgYmUgdXNlZC4gIE90aGVyd2lzZQ0K ICAgID4+IHRoZSB0ZXh0IHJlYWRzIGFzIGlmIGl0IGlzIGh5cG90aGV0aWNhbC4NCiAgICA+Pg0K ICAgID4+IFtFTkRdDQogICAgPj4NCiAgICA+Pg0KICAgID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4gZG1tIG1haWxpbmcgbGlzdA0KICAg ID4+IGRtbUBpZXRmLm9yZw0KICAgID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG1tDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgID4gZG1tIG1haWxpbmcgbGlzdA0KICAgID4gZG1tQGlldGYub3JnDQogICAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KICAgID4NCiAgICAN CiAgICANCg0K From nobody Fri Feb 10 07:17:32 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 81F751293EB; Fri, 10 Feb 2017 07:17:21 -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.43.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148673984149.29180.8692659009242511380.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 07:17:21 -0800 Archived-At: Cc: Dapeng Liu , draft-ietf-dmm-lma-controlled-mag-params@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] Last Call: (LMA Controlled MAG Session Parameters) 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, 10 Feb 2017 15:17:21 -0000 The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'LMA Controlled MAG Session Parameters' 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-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a new extension, LMA-Controlled-MAG- Session-Params to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in Proxy Mobile IPv6 (PMIPv6) signaling for notifying the mobile access gateway (MAG) to conform to various parameters contained in this extension. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmm-lma-controlled-mag-params/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmm-lma-controlled-mag-params/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Feb 10 07:30: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 E769A1293EB; Fri, 10 Feb 2017 07:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.588 X-Spam-Level: X-Spam-Status: No, score=-4.588 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_H2=-1.887, RP_MATCHES_RCVD=-0.001] 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 X9BLFZ4OUA8K; Fri, 10 Feb 2017 07:30:38 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38111299D4; Fri, 10 Feb 2017 07:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1486740637; bh=p9ZgACpUrg2s7MwHvTkWa+7J+uZMDVMgyJiL jYlugjU=; 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=D5ICUNk 1SX3xY2/5Ie5bnRitY3jP2yi6QbTnImgQuldB4JelPtvjRhlHd/Kv/KtrSs8E6vRKpt oimF6fGct7Cn1jiOG2HWkX5HHh88Iu2EJItM4eyr9RWTfdXOu02ZxDQPW/fc0UVmfEU TEygHfFmLCHfRMTu9yIWje7JiwjKpYyRpv0IKzyTi06l6du3Qs443fafZFgU54ue/Em qrKi/St8BqEM9IdEJhldd1YeikvQRH2EQQe+wxWW3XtvLxs7PEe5hab72d7r5JTIxl+ vDJferAZ+Sko/as8XtsK1QVFdcBJU7mxfq77E4Me1Ebss2FY3LvPhwkE3g03NtUUVuw == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=DAiyh7HSTtebU4N3mdop2M8MqUGLKU2O5ZHPIKEH5WxQ7QhNQ/PtiugXjZFMLi76TJKZa8XPhLa8wdFhAf2ixNS9d18ss44oj4Xe2u6U+p/wlKohHaZA561df+OisnyGDYLPXGDIOOpQyuqs+H5DsZ6GOItUh4cNQIS/iAb0vemRRWQjMHRZnrmptzL4Hb6LM4WuYZYCliCsBgySvIkQaNKMc4eC9Nw8xiNFl+4V4rB5SUWw4sL/tur0kekoeLfUGJXABo24Tya7hCPx0E0FTZmJOM+TT69L9JGfLHsrNSzE2/9E/4rvZCnAkNSlmNRtQYoO+cz1Zh4yt0wdlMPeSw==; 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 [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ccD9A-0001KY-SL; Fri, 10 Feb 2017 10:30:05 -0500 To: Suresh Krishnan , "Sri Gundavelli (sgundave)" , Dale Worley , "gen-art@ietf.org" References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> <17671de0-7238-3a3f-c5b6-d6e8bbd3a5e2@earthlink.net> <8E97344D-93A5-4B6F-96F3-735068A4D713@ericsson.com> From: Charlie Perkins Message-ID: Date: Fri, 10 Feb 2017 07:30:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8E97344D-93A5-4B6F-96F3-735068A4D713@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7b153f6b79f77d65ed61c86f789d10901350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 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-04 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, 10 Feb 2017 15:30:42 -0000 Hello folks, The last two days have been crammed full with other urgent work requirements. I will respond to these comments today. Suresh, do you mean to ask if I can submit a revised document before Monday? Regards, Charlie P. On 2/10/2017 6:17 AM, Suresh Krishnan wrote: > Hi Charlie, > I have not yet seen a response to this review. Do you think you will be able to get to this in the next day or two? The document is on the February 16 2017 telechat and I would like to see resolution to these issues in time for the other ADs to ballot. > > Thanks > Suresh > > On 2/2/17, 1:10 AM, "Charlie Perkins" wrote: > > Hello Sri, > > The review was indeed super. I'll respond sometime in the next few days. > > Regards, > Charlie P. > > > On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote: > > Thank you Dale for a great review. > > > > > > Charlie/Authors - Can you please respond to Dale and address these > > comments. > > > > > > Regards > > Sri > > > > > > On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" > on behalf of worley@ariadne.com> wrote: > > > >> 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] > >> > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri Feb 10 07:35: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 EA56D1299F1; Fri, 10 Feb 2017 07:35:11 -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 tJrhxPbwcbF7; Fri, 10 Feb 2017 07:35:10 -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 3599A1299EB; Fri, 10 Feb 2017 07:35:09 -0800 (PST) X-AuditID: c6180641-c53ff70000000a06-31-589d9756878f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 96.0E.02566.6579D985; Fri, 10 Feb 2017 11:35:06 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 10:35:05 -0500 From: Suresh Krishnan To: Charlie Perkins Thread-Topic: [DMM] Review of draft-ietf-dmm-4283mnids-04 Thread-Index: AQHSe/j/cjYYsQbutUCsVh56ND0V9aFVgPUAgAAQ6gCADSuDgIAAA5SAgAABaIA= Date: Fri, 10 Feb 2017 15:35:04 +0000 Message-ID: <54184D70-CFE4-4BCF-A7BA-075D2EC767FE@ericsson.com> References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> <17671de0-7238-3a3f-c5b6-d6e8bbd3a5e2@earthlink.net> <8E97344D-93A5-4B6F-96F3-735068A4D713@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_5C86FE03-0A3D-4A96-9F4A-316287CDB199"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyuXRPrG7U9LkRBltu8ljcv3ONzeL+oxqL /7O3sFtcffWZxeLZxvksFgf/bGOzeHmizIHdY/L+r8weU35vZPVY9WUCs8eSJT+ZAliiuGxS UnMyy1KL9O0SuDL2/njFWrDEqGLa1YvMDYwf9LsYOTkkBEwkZuxYx9bFyMUhJLCeUWLByzvs EM5yRon5u5ezgVSxAVVt2PmZCcQWETCWaOi9xwxiMwv8Y5TYeNkYxBYWsJCYOf0yI0SNpcTE GReZIWw/ie9/V4DZLAKqEsv6vgPN4eDgFbCXuHTEAGLXDCaJ3a1PwHZxCjhKXOs7BFbPKCAm 8f3UGiaIXeISt57MZ4K4WkTi4cXTbBC2qMTLx/9YIWwliY+/54M9wCwwhVFiyr/TYA28AoIS J2c+YZnAKDILyaxZyOpmIamDKNKWWLbwNfMsoGOZBXQkJi9khAibSrw++hHKtpaY8esgG4St KDGl+yH7AkaOVYwcpcUFObnpRoabGIGxeUyCzXEH495ez0OMAhyMSjy8G7znRAixJpYVV+Ye YlQBan20YfUFRimWvPy8VCUR3sc35kYI8aYkVlalFuXHF5XmpBYfYpTmYFES570ecj9cSCA9 sSQ1OzW1ILUIJsvEwSnVwJj8qYDpgvfRfXZZx6b6zDyy//9jHduVZ6dsucdz6V1ewts/zFf/ L5aPqZ3RXVfS/vbSxUA/y9Wt8oET35c/C1913qtyn6K07IbVl0SLmmy/Wc6Meyig9N5iWpLr Hz9+kx+RsnGBfF+cOgL4Ny5fW8vx4aR01JpJC2Pmvr4SflyvdU2Utm1aZLgSS3FGoqEWc1Fx IgCJjE+E1QIAAA== Archived-At: Cc: "ietf@ietf.org" , Gen art , "draft-ietf-dmm-4283mnids.all@ietf.org" , Dale Worley , "dmm@ietf.org" Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 10 Feb 2017 15:35:12 -0000 --Apple-Mail=_5C86FE03-0A3D-4A96-9F4A-316287CDB199 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Charlie, > On Feb 10, 2017, at 10:30 AM, Charlie Perkins = wrote: >=20 > Hello folks, >=20 > The last two days have been crammed full with other urgent work = requirements. I will respond to these comments today. Great. >=20 > Suresh, do you mean to ask if I can submit a revised document before = Monday? No. If you can agree on the changes to be applied with Dale by = Monday/Tuesday I think it would be great. If there are other comments in = IESG eval, you can address them as well in a new revision. Thanks Suresh --Apple-Mail=_5C86FE03-0A3D-4A96-9F4A-316287CDB199 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjEwMTUzNTA0WjAjBgkqhkiG9w0B CQQxFgQUF8FHCP6B39DJNK3w7EZmBO66BG4wXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQAaxZykHmGn669je599n3IJWdMlQOL9Ged26nK8NP10IwJVkwedvzEKFfaqkpC7 MOvs4hnztmdlpKGOZAQq57iimbJXRXaeypExikciCQtm04r3GnxAIB58Glp2qlhxoAKGZJVDKht5 FhkmwewHbE83Xz5VQ2cXde4tR4HjJrdxWizk+WARERwbL4cZtJbFMZ2uv8byf/Dz60W5djUYnt09 gOzvEY0PCyTMjjGC/lepSC/rEqMUudv1PgmtPOjFDxbDy1Gm8fWhf4sB8BFTKx1GCpjU+L8jxQR7 vT6fyyn4TqRV8npy5VzJkcr4GsEV8jBUzcQpqx3P2kxzdfN2dUoFAAAAAAAA --Apple-Mail=_5C86FE03-0A3D-4A96-9F4A-316287CDB199-- From nobody Fri Feb 10 09:08:16 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 50D0E129A50; Fri, 10 Feb 2017 09:08:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 09:08:07 -0800 Archived-At: Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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, 10 Feb 2017 17:08:10 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dmm-4283mnids-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would realy like to see the following changes in the security considerations section: OLD "If used in the MNID extension as defined in this document, the packet including the MNID extension should be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers." NEW "If used in the MNID extension as defined in this document, the packet including the MNID extension SHOULD be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers." Or even better make it a MUST? Is there a reason for only having a SHOULD? as well as the following change: OLD "Moreover, MNIDs containing sensitive identifiers might only be used for signaling during initial network entry. " NEW "Moreover, MNIDs containing sensitive identifiers MUST only be used for signaling during initial network entry and MUST NOT be leaked to other networks." From nobody Fri Feb 10 14:29:28 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 B0144129E75; Fri, 10 Feb 2017 14:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 h7TRqykg-poB; Fri, 10 Feb 2017 14:29:21 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A3E129DC6; Fri, 10 Feb 2017 14:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1486765760; bh=NBBNkzcneukveGKcrKonaU2IS7LMOzfY0+d3 FZQv7d0=; 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=IjEREYXu4O7MDECgGGbRE9OHLV6ZqnpaZNXxRE5HIOH1D4 x/2LeAt0ZCjA7yTVE0pD2IR4LrYEA5uNMbJC1BFzs9/uc+tU6e8tgvTEeNtwuXZHsQK zgVwJYwAfAtBaVx5lqvGNkVT/mrk82qxh6Cc2NZvvK+G8zC2YDOEtZ7OrjIbB0oRfHV B3ZYCXaokGnrjkd9WLZb38dWQyicHxO6EGehXO4xSgkiUX92LAJ216OWXhdaZuVojKP 4mxhCWsRzbtH5778gR5vg8/igY8nmbnpVA9NQashz0eSVH0U64OCycs3bbNpvn/2m1I rmVvaAp9PE7uKevtvV+sp4mcYfAA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=N97Z4iuHYnUdyuL3brNQuX2cJmdnw8+Vdl4mWLdxftcXqOlPeJsTSEPifxh5v6JK1rkMQN13Naj1apqf7u+IfE96JFH6ReH/HrfRhKz4kAbgOMaOIechYkVoo9omkrMKoLavxkhHPN5jhj6n4E1xpV/3lj0z60d6X6VHRpf5YXNbP3K9z7CRJAoN0rAYEbQ7TtfWf6BGgP/o4lt0hgEaG9/2FZt9eSuSGkXy776hzogY1IR7+oodeaSCI9UKMf0U+CXmbFKY+L88uWTJTPVwOJHwd4dxtEg7Ypzlk9lbC04dbewhRFYH7JSmdmvQeRShNEe4k0gUWCmUzldFRqlWag==; 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-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ccJgP-0006un-JW; Fri, 10 Feb 2017 17:28:49 -0500 To: Dale Worley , gen-art@ietf.org References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> From: Charlie Perkins Message-ID: <400befde-9457-74b0-274f-87c739d2af86@earthlink.net> Date: Fri, 10 Feb 2017 14:28:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------34D9108758E61C1C73F50279" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac788c72805e4d8e22a6c46c4a40f98dc8c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 10 Feb 2017 22:29:26 -0000 This is a multi-part message in MIME format. --------------34D9108758E61C1C73F50279 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello Dale, Thanks for the thorough review. My follow-up comments are inline below. On 1/31/2017 11:34 AM, Dale Worley wrote: > 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"? I will add some text according to your suggestion. My criterion for whether the identifier type was included in the document was whether or not anyone had asked for it to be included. > > - 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 It is not the jurisdiction of the MNIDs document to specify these identifiers, but citations for the specifications are located elsewhere in the document. I will also include those citations here. > > 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. I don't know why this happened, but I am happy to include an identifier type for IMEI as well as a citation for it. Thanks for catching this and looking through the archives! > > 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. Actually, I am O.K. either way on this matter. However, at this point in time it does not seem that we are likely to see any other link hardware address types to be used as MNIDs. > > 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. There is a sort of "hidden" disadvantage to long names, especially for tiny devices using constrained link layers. Namely, a longer name makes it more likely to require lower-layer fragmentation. I'm not sure that it should be the job of a layer-3 mobility entity to parse URNs and determine if two different flavors are supposed to be equivalent. Other than that, I don't have any real objection to reorganizing the namespace, but I'd like some additional confirmation that it's a good idea. > > 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. I am O.K. with this. I need to go find out where I got that language from, because I don't think I was the person who crafted it. > > 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. Thanks for this observation. I will make the corresponding revisions to the text. > > 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)! O.K. with your modification. The document just defines numbers for the types, not the types. > > 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. I will insert text from the relevant 3GPP documents to describe these identifiers. > > 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. O.K. Thanks for the suggestion. > > 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 Thanks for the text. I will use it. > -- > > 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. This is a good idea. How about the following: > For each RFID scheme except GID, there are three representations: > - a 64-bit binary representation (for example, SGLN-64) > - a 96-bit binary representation (SGLN-96). > - a representation as a URI I didn't originate the use of URI for the non-binary representation. The EPC document has the following language: > All categories of URIs are represented as Uniform Reference Names > (URNs) as defined by [RFC2141], where the URN Namespace is epc. > If I were to change it to URN, then I would have to go into some detail about why this document somehow disagrees with the EPC-Tag-Data document. Do you think that is necessary? > > 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. I read through some relevant text in the EPC-Tag-Data document and it seems O.K. to me, but nontrivial and it relies on digging through other even more arcane documents to be absolutely sure. I am pretty sure that the IETF document should not get into the business of augmenting the standards already in place from the external SDOs. > > 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. I hope that this document does not have to specify allocation procedures for the MNIDs. It seems to me that if a system designer wants to use one of the MNID types, that person will already know about how to request the allocation and would not need to rely on the MNIDs document for that information. Plus it's really out of scope. This document was always intended to be a simple tabulation of types already in use elsewhere and enabling IETF mobility management protocols to use the most natural identifier available for a mobile node. I hope that citing the defining documents for the identifier types will be enough to satisfy that. > > 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. As far as I have understood, the unicast IPv6 address in use as a MNID is already assigned to the device. I have not heard anyone asking for this to be an address for future assignment. I'll try to make that clear in the text. > > 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. I probably lifted that language directly from the IMSI spec, but I can make further clarification according to your suggestion. > > 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". O.K. I also lifted that language from elsewhere. > > 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. Here I am at a loss, because I was specifically requested to insert some descriptive but not normative text. I will ask the person who made the request to provide their feedback on the mailing list. For myself, I am more than happy to delete the text. > > 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. This text was meant to be generally descriptive, so that people wanting to include the Mobile Node Identifier Option with the relevant MNIDs could understand how the identifiers are actually used in various circumstances. I could replace constructions using "might" with "in some specifications" or "in some situations" if needed. Is it also necessary to include citations to the relevant documents of the external SDO? Regards, Charlie P. --------------34D9108758E61C1C73F50279 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Dale,

Thanks for the thorough review.  My follow-up comments are inline below.


On 1/31/2017 11:34 AM, Dale Worley wrote:
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"?

I will add some text according to your suggestion.  My criterion for whether the identifier type was included in the document was whether or not anyone had asked for it to be included.


- 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

It is not the jurisdiction of the MNIDs document to specify these identifiers, but citations for the specifications are located elsewhere in the document.  I will also include those citations here.


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 <Marco.Liebsch@neclab.eu>
    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.

I don't know why this happened, but I am happy to include an identifier type for IMEI as well as a citation for it.  Thanks for catching this and looking through the archives!


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.

Actually, I am O.K. either way on this matter.  However, at this point in time it does not seem that we are likely to see any other link hardware address types to be used as MNIDs.


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.

There is a sort of "hidden" disadvantage to long names, especially for tiny devices using constrained link layers.  Namely, a longer name makes it more likely to require lower-layer fragmentation.  I'm not sure that it should be the job of a layer-3 mobility entity to parse URNs and determine if two different flavors are supposed to be equivalent.

Other than that, I don't have any real objection to reorganizing the namespace, but I'd like some additional confirmation that it's a good idea.


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.

I am O.K. with this.  I need to go find out where I got that language from, because I don't think I was the person who crafted it.


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.

Thanks for this observation.  I will make the corresponding revisions to the text.


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)!

O.K. with your modification.  The document just defines numbers for the types, not the types.


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.

I will insert text from the relevant 3GPP documents to describe these identifiers.


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.

O.K.  Thanks for the suggestion.


   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

Thanks for the text.  I will use it.

--

   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.

This is a good idea.  How about the following:

   For each RFID scheme except GID, there are three representations:
    - a 64-bit binary representation (for example, SGLN-64)
    - a 96-bit binary representation (SGLN-96).
    - a representation as a URI

I didn't originate the use of URI for the non-binary representation. The EPC document has the following language:

All categories of URIs are represented as Uniform Reference Names (URNs) as defined by [RFC2141], where the URN Namespace is   epc.


If I were to change it to URN, then I would have to go into some detail about why this document somehow disagrees with the EPC-Tag-Data document.  Do you think that is necessary? 


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.

I read through some relevant text in the EPC-Tag-Data document and it seems O.K. to me, but nontrivial and it relies on digging through other even more arcane documents to be absolutely sure.  I am pretty sure that the IETF document should not get into the business of augmenting the standards already in place from the external SDOs.


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.

I hope that this document does not have to specify allocation procedures for the MNIDs.  It seems to me that if a system designer wants to use one of the MNID types, that person will already know about how to request the allocation and would not need to rely on the MNIDs document for that information.  Plus it's really out of scope.  This document was always intended to be a simple tabulation of types already in use elsewhere and enabling IETF mobility management protocols to use the most natural identifier available for a mobile node.  I hope that citing the defining documents for the identifier types will be enough to satisfy that.


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.

As far as I have understood, the unicast IPv6 address in use as a MNID is already assigned to the device.  I have not heard anyone asking for this to be an address for future assignment.  I'll try to make that clear in the text.


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.

I probably lifted that language directly from the IMSI spec, but I can make further clarification according to your suggestion.


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".

O.K.  I also lifted that language from elsewhere.

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.

Here I am at a loss, because I was specifically requested to insert some descriptive but not normative text.  I will ask the person who made the request to provide their feedback on the mailing list.  For myself, I am more than happy to delete the text.


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.

This text was meant to be generally descriptive, so that people wanting to include the Mobile Node Identifier Option with the relevant MNIDs could understand how the identifiers are actually used in various circumstances.  I could replace constructions using "might" with "in some specifications" or "in some situations" if needed.  Is it also necessary to include citations to the relevant documents of the external SDO?


Regards,
Charlie P.

--------------34D9108758E61C1C73F50279-- From nobody Fri Feb 10 20:06:09 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 0F58B129680; Fri, 10 Feb 2017 20:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 u-eD2Zolo_zg; Fri, 10 Feb 2017 20:06:03 -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 25F24129551; Fri, 10 Feb 2017 20:06:00 -0800 (PST) X-AuditID: c6180641-c3fff70000000a06-4f-589e4751cd69 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 84.90.02566.1574E985; Sat, 11 Feb 2017 00:05:56 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 23:05:55 -0500 From: Suresh Krishnan To: Mirja Kuehlewind Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kbW0t?= =?utf-8?Q?4283mnids-04:_(with_DISCUSS)?= Thread-Index: AQHSg8BIeh/d4aOeZ0GssdxcekDl7KFjhJmA Date: Sat, 11 Feb 2017 04:05:55 +0000 Message-ID: References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> In-Reply-To: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_2D1950D9-1079-4F75-A2B2-CC8A2E4A2850"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyuXRPrG6I+7wIg12PdCw6Tm9mtrj/qMbi 1sJDLBYz/kxktnhx/SOzxd5pN1kc2Dwmvv3I4rFkyU8mj5aPC1kDmKO4bFJSczLLUov07RK4 Mj5uOshWsN2h4vzEJcwNjMesuxg5OSQETCRmtj5h72Lk4hASWM8o0f75LAuEs5xR4sijTnaQ Kjagqg07PzOB2CICWhIvP7SyghQxC7xhlPg9oxOsQ1iggVGi8+IfZhBHRKCRUaJvTx9QhgPI MZI4/sgApJtFQFXi+anzYJN4BewlFs9bygpiCwn4StzZuYkNxOYU8JNYsv4dWA2jgJjE91Nr wGxmAXGJW0/mM0HcLSLx8OJpNghbVOLl43+sELaSxMff89khrpvCKPFh/X12iGWCEidnPmGZ wCgyC8msWcjqZiGpgyjSlli28DUzhK0psb97OVTcVOL10Y+MELa1xIxfB9kgbEWJKd0P2Rcw cqxi5CgtLsjJTTcy3MQIjMdjEmyOOxj39noeYhTgYFTi4TWYOzdCiDWxrLgy9xCjClDrow2r LzBKseTl56UqifCWVcyLEOJNSaysSi3Kjy8qzUktPsQozcGiJM57PeR+uJBAemJJanZqakFq EUyWiYNTqoGx+k/etbT7ucd65x6onPrMlJU7QWfqT/GjcptrZ95WOhDc5Svk8a3hWn7e4aSt 39InNbknZ216G7rrSH+d77T4nw+3JoXpRrd/7PgzM8VTybv60ERutQ1l35ada1E98HXB18Xl j503bHAJC561b8nXbZsL+ORN/pbEimg/eRLsIF0WsOOQ2vl1SizFGYmGWsxFxYkA6mMSis8C AAA= Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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: Sat, 11 Feb 2017 04:06:05 -0000 --Apple-Mail=_2D1950D9-1079-4F75-A2B2-CC8A2E4A2850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HI Mirja, > On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dmm-4283mnids-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I would realy like to see the following changes in the security > considerations section: > OLD > "If used in the MNID extension as defined in this > document, the packet including the MNID extension should be > encrypted > so that personal information or trackable identifiers would not be > inadvertently disclosed to passive observers." > NEW > "If used in the MNID extension as defined in this > document, the packet including the MNID extension SHOULD be > encrypted > so that personal information or trackable identifiers would not be > inadvertently disclosed to passive observers.=E2=80=9D Is this just for changing the "should" to upper case? I think that makes = sense. > Or even better make it a MUST? Is there a reason for only having a > SHOULD? Authors, any specific reason for this to be a SHOULD? >=20 > as well as the following change: > OLD > "Moreover, MNIDs containing sensitive identifiers might only be used > for signaling during initial network entry. " > NEW > "Moreover, MNIDs containing sensitive identifiers MUST only be used > for signaling during initial network entry and MUST NOT be leaked to > other networks.=E2=80=9D The statement in OLD: is just a statement of fact that in some networks = use temporary identifiers for reattachment and they use long term (and = hence sensitive) identifiers only at initial attach. I don=E2=80=99t = think it makes sense to change this to 2119 language. Thanks Suresh --Apple-Mail=_2D1950D9-1079-4F75-A2B2-CC8A2E4A2850 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjExMDQwNTU1WjAjBgkqhkiG9w0B CQQxFgQUcqhRa4y6jdeYLHAj9SlZMN3mf0cwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQAwwRiRgkYG4ST9ahPwzGVXknt3G6QkqqvgmdMnHcumYMpr5gGjDzROe5qBW2vz ru6fbS6RRE8A0E1ileH5lmDqDrCErsJjmSxXVoIkRrDe5VYKeBtkeU4tuZgbpAYPXn2f5oIoXOAQ MRfKgKSh9Alr2/my9hN2GSqA8XUGdwvbOfxS58PM/o0JxL0fTCFPDcYZ6DBU/yM25Tc/KJICY1gX 6/NKKMTNjThwOxP3MDJbRPI3wFOqr/45yXhoUDAbi/eUo0bYDlEbjdGYA3JFE4HhmjgL/ko8o9fh TLdCT62nCshM53v+EqRb/qqE6Ofd7TL2I/1O/ORs72WemYQKecejAAAAAAAA --Apple-Mail=_2D1950D9-1079-4F75-A2B2-CC8A2E4A2850-- From nobody Sat Feb 11 01:01:02 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 03359129502 for ; Sat, 11 Feb 2017 01:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OL1gwykksNTP for ; Sat, 11 Feb 2017 01:00:57 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3611296F6 for ; Sat, 11 Feb 2017 01:00:56 -0800 (PST) Received: (qmail 18035 invoked from network); 11 Feb 2017 10:00:54 +0100 Received: from p5dec284d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Feb 2017 10:00:54 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Sat, 11 Feb 2017 10:00:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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: Sat, 11 Feb 2017 09:01:00 -0000 Hi Suresh, sounds all good! I=E2=80=99m happy to quickly resolve my discuss if the = authors agree! Mirja > Am 11.02.2017 um 05:05 schrieb Suresh Krishnan = : >=20 > HI Mirja, >=20 >> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind = wrote: >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-dmm-4283mnids-04: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I would realy like to see the following changes in the security >> considerations section: >> OLD >> "If used in the MNID extension as defined in this >> document, the packet including the MNID extension should be >> encrypted >> so that personal information or trackable identifiers would not be >> inadvertently disclosed to passive observers." >> NEW >> "If used in the MNID extension as defined in this >> document, the packet including the MNID extension SHOULD be >> encrypted >> so that personal information or trackable identifiers would not be >> inadvertently disclosed to passive observers.=E2=80=9D >=20 > Is this just for changing the "should" to upper case? I think that = makes sense. >=20 >> Or even better make it a MUST? Is there a reason for only having a >> SHOULD? >=20 > Authors, any specific reason for this to be a SHOULD? >=20 >>=20 >> as well as the following change: >> OLD >> "Moreover, MNIDs containing sensitive identifiers might only be used >> for signaling during initial network entry. " >> NEW >> "Moreover, MNIDs containing sensitive identifiers MUST only be used >> for signaling during initial network entry and MUST NOT be leaked to >> other networks.=E2=80=9D >=20 > The statement in OLD: is just a statement of fact that in some = networks use temporary identifiers for reattachment and they use long = term (and hence sensitive) identifiers only at initial attach. I don=E2=80= =99t think it makes sense to change this to 2119 language. >=20 > Thanks > Suresh >=20 From nobody Sun Feb 12 16:52:53 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 48401129521; Sun, 12 Feb 2017 16:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 36iWBtMFHc88; Sun, 12 Feb 2017 16:52:45 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46021294E9; Sun, 12 Feb 2017 16:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10991; q=dns/txt; s=iport; t=1486947164; x=1488156764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BYQ9fDmK7GmTXhib7cVNaX+eYAAwaYK3/ly0Rpk4VuM=; b=MIqphDEtN6X+wfYrJoBXZYXUcT4kg6+rilfy9Biugc4qDSHksxeOiwXc AyJFS/cznrn5nkd9a9S2X4olZTr9m3gJqWzE9oHoE0eOnc+6hfXcHgrFl r/OAMLIeEOPxdbaB+5ciSzKIRnAduJcdO8ol5GLiGYf+VxurkfvKLxyA8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQBZAqFY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9jgWoHjVqSCpAKhSyCDIYiAoJ7PxgBAgEBAQEBAQFiKIRpAQE?= =?us-ascii?q?BAwFuCwULAgEIDgMDAQIoBzIUCQgCBAENBYlSAw0IsQcrixYBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhkyEb4JRgVURATwWhS8FkAOFUYYeAZITgXuFF4lzkxQBHzh?= =?us-ascii?q?4CFEVPYRFHYFhdYgSgSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,155,1484006400"; d="scan'208,217";a="383183107" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 00:52:43 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1D0qh1E004281 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 00:52:43 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 12 Feb 2017 18:52:42 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Sun, 12 Feb 2017 18:52:42 -0600 From: "Sri Gundavelli (sgundave)" To: Charlie Perkins , Dale Worley , "gen-art@ietf.org" Thread-Topic: [DMM] Review of draft-ietf-dmm-4283mnids-04 Thread-Index: AQHShZN7GUjlGCaTJE+d8OzNd5SzNQ== Date: Mon, 13 Feb 2017 00:52:42 +0000 Message-ID: References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> <400befde-9457-74b0-274f-87c739d2af86@earthlink.net> In-Reply-To: <400befde-9457-74b0-274f-87c739d2af86@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: multipart/alternative; boundary="_000_D4C63E242598D8sgundaveciscocom_" MIME-Version: 1.0 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-04 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, 13 Feb 2017 00:52:47 -0000 --_000_D4C63E242598D8sgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Charlie, Please see inline. From: dmm > on behalf of = Charlie Perkins > Date: Friday, February 10, 2017 at 2:28 PM To: Dale Worley >, "gen-art@i= etf.org" > Cc: "draft-ietf-dmm-4283mnids.all@ietf.org" >, "ietf@ietf.org" >, "dmm@ietf.org" > Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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. > Here I am at a loss, because I was specifically requested to insert some = descriptive but not normative text. I will ask the person who made the req= uest to provide their feedback on the mailing list. For myself, I am more = than happy to delete the text. When we discussed this issue in the past, the general feedback from the WG = was that the draft should provide some minimal amount of details on the new= identifier types, what the identifier is, how the identifier is constructe= d, what is the access technology and a reference to the specification that = provides that definition. The idea is NOT TO provide extensive details on t= he spec, but to enable a reader with some high level details and a pointer = to the specification. I tend to think the text in the current specification= just does that. If the text is seen as redundant text, we can certainly ad= d a statement saying that the definition for the identifier is provided in = spec-XYZ and is repeated here for convenience. May be other folks in the WG= have some views on this. Comments from 10/11/2015 email: "Some text on the motivation for defining new Types may be helpful. Documen= t is not just standardizing the currently in-use/popular identifier types, = its also introducing new types are not in use. The reasons/interest for def= ining identifiers that are tied to the physical elements of the device (RFI= D, MAC address ..etc) and how it helps in deployment of the technology may = be useful. Few lines of text will really help." "I was hoping to see a sub-section for each of the types. We cannot standar= dize a identifier type without providing any explanation on the identifier = type or the references to the base definitions. This can be painful, but I'= d have a small section for each of the types. It can be 3 line text on the = a.) Definition b.) Format c.) Example format d.) Reference to the base spec= that defines those identifiers." --_000_D4C63E242598D8sgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Charlie,

Please see inline.


From: dmm <dmm-bounces@ietf.org> on behalf of Charlie Perkin= s <charles.perkins@eart= hlink.net>
Date: Friday, February 10, 2017 at = 2:28 PM
To: Dale Worley <worley@ariadne.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ietf-dmm-4283mnids.all@ietf.org&q= uot; <draft-iet= f-dmm-4283mnids.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Review of draft-= ietf-dmm-4283mnids-04

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.

> Here I am at a loss, because I was specifically requested to insert so= me descriptive but not normative text.  I will ask the person who made= the request to provide their feedback on the mailing list.  For mysel= f, I am more than happy to delete the text.

When we discussed this issue in the past, the general feedback from the WG = was that the draft should provide some minimal amount of details on the new= identifier types, what the identifier is, how the identifier is constructe= d, what is the access technology and a reference to the specification that provides that definition. The id= ea is NOT TO provide extensive details on the spec, but to enable a reader = with some high level details and a pointer to the specification. I tend to = think the text in the current specification just does that. If the text is seen as redundant text, we can certainly ad= d a statement saying that the definition for the identifier is provided in = spec-XYZ and is repeated here for convenience. May be other folks in the WG= have some views on this.


Comments from 10/11/2015 email:
"Some text on the motivation for defining new Types may b=
e helpful. Document is not just standardizing the currently in-use/popular identifier types, its =
also introducing new types are not in use. The reasons/interest for definin=
g identifiers that are tied to the physical elements of the device (RFID, M=
AC address ..etc) and how it helps in deployment of the technology may be u=
seful. Few lines of text will really help.”=
"I was hoping to see a sub-section for each= of the types. We cannot standardize a identifier type without providing any explanation on the identifier type or the refer= ences to the base definitions. This can be painful, but I'd have a small se= ction for each of the types. It can be 3 line text on the a.) Definition b.= ) Format c.) Example format d.) Reference to the base spec that defines those identifiers.”


 --_000_D4C63E242598D8sgundaveciscocom_-- From nobody Sun Feb 12 19:13:31 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 0617C1295CC for ; Sun, 12 Feb 2017 19:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 S5o1mhAiaNli for ; Sun, 12 Feb 2017 19:13:23 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 598C91295CD for ; Sun, 12 Feb 2017 19:13:21 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-07v.sys.comcast.net with SMTP id d74dcBOUnO8Emd74qc2Xep; Mon, 13 Feb 2017 03:13:20 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-03v.sys.comcast.net with SMTP id d74ncX3wGAjV2d74ocTEdC; Mon, 13 Feb 2017 03:13:19 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1D3DHXd028897; Sun, 12 Feb 2017 22:13:17 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1D3DG6o028894; Sun, 12 Feb 2017 22:13:16 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Charlie Perkins In-Reply-To: <400befde-9457-74b0-274f-87c739d2af86@earthlink.net> (charles.perkins@earthlink.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 12 Feb 2017 22:13:16 -0500 Message-ID: <87efz2wzoz.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBTClhHcg8kU70LEEhc9rVMAWPpsRcs1E/x+FAUazwjqoreRWMCkvgfT1wS+L9lve2zQsI6Ba4OQbdCytoLFFiwUPVsxYh/J1gMb28E/aqkTcsac86s0 vqmK/MMN4by2jBEoAejfVmfw/PApFXPVe/ThpB+2Kh0xFNZ+LoaTMSs96oPn/W/hB2UPknUDXn+PU8A/0nmXA+avnTSNoHvc1ABuVt3PDacUQgNPyvVx/SWv 9GM3V3S3gdkGDN5/AHBUFaReexK/KlD9SYFdKrTwC0ftNJ74axLNkNTZ0tdFZMqt Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, gen-art@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 13 Feb 2017 03:13:25 -0000 Charlie Perkins writes: > > Are there any other types "in common use"? > > I will add some text according to your suggestion. My criterion for > whether the identifier type was included in the document was whether or > not anyone had asked for it to be included. A good criterion -- if it's commonly used, likely someone would have asked. > > - 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 > > It is not the jurisdiction of the MNIDs document to specify these > identifiers, but citations for the specifications are located elsewhere > in the document. I will also include those citations here. What I was noting was that 4283 says: Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). but that taking 4283 and this document together, there is no way to specify FQDN or MSISDN as MN identifiers. If in practice, people don't use either of those, then the situation is OK, though 4283 is inaccurate. But if people do use FQDNs or MSISDNs as MN identifiers, should those be added to this document? (I can't find them specified elsewhere.) > > 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. > I don't know why this happened, but I am happy to include an identifier > type for IMEI as well as a citation for it. Thanks for catching this > and looking through the archives! I'm not saying, "Add it because I think it's a good idea to use IMEIs.", I'm saying, "Your introduction says that you define an MNID type for IMEIs, but you don't." Perhaps there is no need for IMEIs, but in that case, the introduction needs to be edited. > > 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 > Actually, I am O.K. either way on this matter. However, at this point > in time it does not seem that we are likely to see any other link > hardware address types to be used as MNIDs. I agree with you there, although I wouldn't be entirely surprised if a new mobile network introduced a new link-layer address. But there doesn't seem to be much value in making the change I suggested, other than for generality. > There is a sort of "hidden" disadvantage to long names, especially for > tiny devices using constrained link layers. Namely, a longer name makes > it more likely to require lower-layer fragmentation. I'm not sure that > it should be the job of a layer-3 mobility entity to parse URNs and > determine if two different flavors are supposed to be equivalent. > > Other than that, I don't have any real objection to reorganizing the > namespace, but I'd like some additional confirmation that it's a good idea. There are a couple of reasons I like this idea. One is that EPC seems to have a policy of providing a URN form for all of the identifier classes it defines. Making a single URN MNID type means that you've incorporated all future classes of identifier that EPC defines. A single URN MNID type would incorporate any of the defined URN namespaces that turn out to be useful for anybody. This isn't so interesting for really large deployments, since they could ask for a new MNID type, but experimental or small-scale deployments may want to define their own identifiers, and URNs provide several convenient ways to do that. It removes a certain amount of redundancy, in that each RFID class now has three representations, for a total of 20 MNID types, whereas they could all be collapsed into one MNID type. The negatives I see are: Some URN schemes do not have a unique representation as a character string. In practice, this is combated by either (1) Code that handles URNs of arbitrary namespace copies and compares them as character strings. Users of such systems know to write URNs that have multiple representations in a canonical form. Or, (2) Code that handles one or a small fixed set of URN namespaces knows the canonicalization/comparison rules for those namespaces. Generally, using these processes doesn't cause problems in practice. I expect that whatever receives the MNID and looks it up in appropriate databases would not be a constrained device, so it could process URNs carefully. If the link layer is constrained, longer identifiers may require fragmentation. Changing a 96-bit binary representation into a URN seems to add something like 40 octets, given the examples I've found online. OTOH, it seems that the MNID is only transmitted when attaching to a network, and so having that one packet require extra work doesn't seem to be much of a penalty. The all-URN ides envisions embedding IMSI and possibly MSISDN into the gsma URN namespace. (IMEI is already embedded as urn:gsma:imei:...) That would take additional specification, although I don't see that being controversial. (Andrew Allen would be a good contact for doing this.) > > 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. > > I am O.K. with this. I need to go find out where I got that language > from, because I don't think I was the person who crafted it. I suspect this is really an editorial mistake, but I had to treat it as technical because I couldn't rule out that it was a design question. > > 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. > > Thanks for this observation. I will make the corresponding revisions to > the text. Give that there has been only 4 types of DUID defined in 13 years, I don't expect much need for extensibility, but it seems to me that if devices take their MNID from their platform's DHCP implementation, there is a risk that the protocol will fail if someone uses a proprietary/experimental DUID type. > > Editorial issues: Trimming everything I have no further comment on: > > 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)! > > O.K. with your modification. The document just defines numbers for the > types, not the types. True... So really "Additional Identifier Type Numbers are defined for use ..." > > -- > > > > 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. > > This is a good idea. How about the following: > > > For each RFID scheme except GID, there are three representations: > > - a 64-bit binary representation (for example, SGLN-64) > > - a 96-bit binary representation (SGLN-96). > > - a representation as a URI That's close, but it doesn't assert the representations for GID. Better: For each RFID there are three representations: - a 64-bit binary representation (for example, SGLN-64) (except for GID) - a 96-bit binary representation (SGLN-96). - a representation as a URI (a URN, actually) (Though all of this discussion can be removed of the binary representations are removed in favor of the URN representation.) > I didn't originate the use of URI for the non-binary representation. The > EPC document has the following language: > > > All categories of URIs are represented as Uniform Reference Names > > (URNs) as defined by [RFC2141], where the URN Namespace is epc. > > If I were to change it to URN, then I would have to go into some detail > about why this document somehow disagrees with the EPC-Tag-Data > document. Do you think that is necessary? We do want to stay aligned with EPC, otherwise there would be chaos. And technically, all URNs are URIs. But approaching the subject from the IETF, it makes a lot more sense that RFID schemes are represented as URNs rather than general URIs. It seems to me to be quite sufficient to notify the reader in some appropriate place that these URIs are URNs. See the last line of the text I suggested above for one way to do it. > > 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. > > I read through some relevant text in the EPC-Tag-Data document and it > seems O.K. to me, but nontrivial and it relies on digging through other > even more arcane documents to be absolutely sure. I am pretty sure that > the IETF document should not get into the business of augmenting the > standards already in place from the external SDOs. Oh, yes, we don't want to duplicate EPC's work. I just wanted to know that you've checked that EPC does define a sequence of octets, rather than only a sequence of *bits*, which would leave the ordering of the bits within the octets unspecified. > > 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. > > I hope that this document does not have to specify allocation procedures > for the MNIDs. It seems to me that if a system designer wants to use > one of the MNID types, that person will already know about how to > request the allocation and would not need to rely on the MNIDs document > for that information. Plus it's really out of scope. This document was > always intended to be a simple tabulation of types already in use > elsewhere and enabling IETF mobility management protocols to use the > most natural identifier available for a mobile node. I hope that citing > the defining documents for the identifier types will be enough to > satisfy that. OK, I can agree with you there. The only identifier which doesn't seem to have a "natural" ownership scheme is IPv6 addresses; I think of IPv6 addressed as being assigned to a device every time it is initialized, rather than being a way to identify the device. But you address that in the item below. > > 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. > > As far as I have understood, the unicast IPv6 address in use as a MNID > is already assigned to the device. I have not heard anyone asking for > this to be an address for future assignment. I'll try to make that > clear in the text. OK, if that's the case, then the usage is clear, as is how the device obtains ownership of an address. > > 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. > > I probably lifted that language directly from the IMSI spec, but I can > make further clarification according to your suggestion. It's likely that in the context of the IMSI spec that "network order" means high-to-low for all sizes quantities, but I've not seen that used in IETF context, so it's probably worth clarifying just to be thorough. > > 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. > > Here I am at a loss, because I was specifically requested to insert some > descriptive but not normative text. I will ask the person who made the > request to provide their feedback on the mailing list. For myself, I am > more than happy to delete the text. OK, if people have asked for descriptions, I can see the value in that. But you might want to check that your phrasing makes sense to someone who isn't already familiar with the EPC schemes. > > 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. > > This text was meant to be generally descriptive, so that people wanting > to include the Mobile Node Identifier Option with the relevant MNIDs > could understand how the identifiers are actually used in various > circumstances. I could replace constructions using "might" with "in > some specifications" or "in some situations" if needed. Is it also > necessary to include citations to the relevant documents of the external > SDO? I'd definitely prefer some other term than "might". I'm not sure why, but I think that it's because "might" isn't used much in specifications If the external documents show how MNIDs will be used, and if that context shows why the security problems are small, then I'd definitely reference them. One point that is not clear to me. The above quoted paragraph suggests that MNIDs are only transmitted during initial network entry. But reading it again, I'm led to guess that they are currently also used for "binding update exchanges". And you are suggesting that their use in binding update exchanges could be eliminated by using temporary identifiers? If the first case is true, you can make the statement more definitive as simply: Currently, MNIDs are only be used for signaling during initial network entry. [external reference] If the second case is true, you want to make it clearer that the current risks are (slightly) higher: Currently, MNIDs are only be used for signaling during initial network entry and binding update exchanges. [external reference] Future work could ensure that MNIDs are only be used for signaling during initial network entry by having subsequent binding update exchanges rely on a temporary identifier allocated during the initial network entry, perhaps using mechanisms not standardized within the IETF. [perhaps delete that last phrase as not really adding anything?] Managing the association between long-lived and temporary identifiers is outside the scope of this document. Dale From nobody Mon Feb 13 08:56:05 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 7C108129565 for ; Mon, 13 Feb 2017 08:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 r4psBvc5dGfX for ; Mon, 13 Feb 2017 08:55:54 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 AE439129642 for ; Mon, 13 Feb 2017 08:55:53 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with SMTP id dJthclBcsdAFEdJurcZU88; Mon, 13 Feb 2017 16:55:53 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id dJuocoNOPgcVOdJuqcaYLc; Mon, 13 Feb 2017 16:55:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1DGtnOd013897; Mon, 13 Feb 2017 11:55:49 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1DGtmKN013894; Mon, 13 Feb 2017 11:55:48 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Sri Gundavelli \(sgundave\)" In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 13 Feb 2017 11:55:48 -0500 Message-ID: <87wpcuuj1n.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLBYsvvQpSgsytl+ZkBaSpG8sIpIb+R578s7f49lUIVmj/oCsOqEvGTJnwlhOQ7/rbp+jcGowToziBn3MMJfUMpswQKdPcOUus/aKYzpN7zDiMLm9pYR rQAO2NvrotFI8CEdjXoc3EV/ZF/eXZmRM1AXDu7T5nU80+NV+axvqoGNfiXYefgsRRa2rVGUJJgKk7AgkSHZu8skex9p14dwd7YWgCaJWZ29hZvWqrhE941L bEEkARtbsy3aIpkv6oUiIOiW/TYKS3WPAU8WDmKJNQHlH8Y3p+VQB9NyeKaMR4a6VnjB+5hpwvSJIs01Kd/bCj77Gnlw/djxk9KTN8zTXog= Archived-At: Cc: charles.perkins@earthlink.net, gen-art@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org, dmm@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 13 Feb 2017 16:55:55 -0000 "Sri Gundavelli (sgundave)" writes: > When we discussed this issue in the past, the general feedback from > the WG was that the draft should provide some minimal amount of > details on the new identifier types, what the identifier is, how the > identifier is constructed, what is the access technology and a > reference to the specification that provides that definition. The idea > is NOT TO provide extensive details on the spec, but to enable a > reader with some high level details and a pointer to the > specification. I tend to think the text in the current specification > just does that. If the text is seen as redundant text, we can > certainly add a statement saying that the definition for the > identifier is provided in spec-XYZ and is repeated here for > convenience. May be other folks in the WG have some views on this. I take it that the following are typical comments from the WG: > Comments from 10/11/2015 email: > > "Some text on the motivation for defining new Types may be > helpful. Document is not just standardizing the currently > in-use/popular identifier types, its also introducing new types are > not in use. The reasons/interest for defining identifiers that are > tied to the physical elements of the device (RFID, MAC address ..etc) > and how it helps in deployment of the technology may be useful. Few > lines of text will really help." > > "I was hoping to see a sub-section for each of the types. We cannot > standardize a identifier type without providing any explanation on the > identifier type or the references to the base definitions. This can be > painful, but I'd have a small section for each of the types. It can be > 3 line text on the a.) Definition b.) Format c.) Example format d.) > Reference to the base spec that defines those identifiers." I can understand these desires, and I agree with following them. In regard to the first message, it seems to request "The reasons/interest for defining identifiers that are tied to the physical elements of the device (RFID, MAC address ..etc) and how it helps in deployment of the technology may be useful." As far as I can tell, this isn't handled in section 4.9 (which is the part I was complaining about). And I don't recall if the earlier parts of the draft are specific about "the reasons/interest" for any of the new types. I believe from this discussion that the reason an identifier was included is that somebody told the authors that they wanted to use the identifier in question -- and that is quite legitimate. Perhaps saying it explicitly in the early parts of the draft would help. In regard to the second message, it seems to request a small section for each of the types. It can be 3 line text on the a.) Definition b.) Format c.) Example format d.) Reference to the base spec that defines those identifiers. Of course, (d) "reference to base spec" is necessary, and the sub-sections of 4.9 do that for each format, as does Table 1. For (a) "definition", the texts in 4.9 proper seem to be fairly good. E.g., The EPC encoding scheme for SGTIN permits the direct embedding of EAN.UCC System standard GTIN and Serial Number codes on EPC tags. In all cases, the check digit is not encoded. Two encoding schemes are specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits). Based on that alone, I couldn't possibly construct a SGTIN-64 myself, but I have some idea of the information it contains and the technical terms to look up to find the real definition of the data items. However (b) "format" seems to be missing (except in the most abstract sense) and (c) "example format" seem to be missing entirely. OTOH, I'm not sure that the space needed to specify those would be worth the effort. Summary: After thinking about it more, I think it's not worth the effort to revise 4.9 heavily. Most of that information is for the use of people who are familiar with the RFID identifiers and their formats, and if they are happy with it, there's no reason to change it. Dale From nobody Mon Feb 13 13:07: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 895DE1294D6; Mon, 13 Feb 2017 13:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 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_H2=-1.887, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 1ahQDXo1g-hf; Mon, 13 Feb 2017 13:07:23 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE86129424; Mon, 13 Feb 2017 13:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1487020043; bh=85v3eYHXpsgPy6kW7Sb0vAvdrtCjsoCUkbXd QuS/4fI=; 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=MqDKM7q CrPDkMCK1YYkxPdGwT65DjpVDK2ZHdDZzQVV4w2zVbfWaJT8CvekFEilXheh0pBPDn1 IEUZJtU5ggnnIkdysTcEWDmCtg+UfGY6oIyxydYs08liZcHSOSYf/P4lkB/hBbOezfc ZilV77YR0UlrkcSkEkDU96mDaIB5vVTvCOe3P3cg/M4tqQUuYYi/+BUpHeArEA9j9OO r8/QORsHs6PYucBqTbQf+Dnr9U+fXAr8BWCUUktdY8XtqMrcSevihSP91tYK5G8f6lD w/8RRGRkHguv6OR2m/bFEgERCUaT0Xt63JiTEhhon3f9jxTbKPbmGbpQ1nGnF7FdLqA == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=EXotnJ2wvz3po00/D7KLbnx9C8VtByEQTLCbMdBVv/wbHQa+/Lb7fkwAAgtCqvfsD/IMGrpijbj4Y2Te5nzJNJO8jtlGO3RNxoaKwUv8ZYdJR7Lr+ULErWFETggEVeguDfmSWrYyp6l+DqkwPmpRHzGF39X0CLXZl6AQXu8TArYacKTjFbj/gMNUbeYv+SSp4U5TKeodczZllSdu4xCFXTJUscHINUWxJV9V0Jn1uQuEbSGPTMsR4SJ7YZOvRVW8Z+a9jb1PHPQsPy6FiGtzi7KnK28KOS8kUIypmIyX74/F64sduUr3+K19J2McnWyDJ+x1KN8HL2ENxF2aSTk6dQ==; 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 [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cdNpe-00033P-FZ; Mon, 13 Feb 2017 16:06:46 -0500 To: "Mirja Kuehlewind (IETF)" , Suresh Krishnan References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> From: Charlie Perkins Message-ID: Date: Mon, 13 Feb 2017 13:06:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac72878a1c6ca14f53ddb962142ae32dec0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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, 13 Feb 2017 21:07:25 -0000 Hello Mirja and Suresh, I am happy to make the proposed changes as agreed below. Regards, Charlie P. On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote: > Hi Suresh, > > sounds all good! I’m happy to quickly resolve my discuss if the authors agree! > > Mirja > > >> Am 11.02.2017 um 05:05 schrieb Suresh Krishnan : >> >> HI Mirja, >> >>> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind wrote: >>> >>> Mirja Kühlewind has entered the following ballot position for >>> draft-ietf-dmm-4283mnids-04: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I would realy like to see the following changes in the security >>> considerations section: >>> OLD >>> "If used in the MNID extension as defined in this >>> document, the packet including the MNID extension should be >>> encrypted >>> so that personal information or trackable identifiers would not be >>> inadvertently disclosed to passive observers." >>> NEW >>> "If used in the MNID extension as defined in this >>> document, the packet including the MNID extension SHOULD be >>> encrypted >>> so that personal information or trackable identifiers would not be >>> inadvertently disclosed to passive observers.” >> Is this just for changing the "should" to upper case? I think that makes sense. >> >>> Or even better make it a MUST? Is there a reason for only having a >>> SHOULD? >> Authors, any specific reason for this to be a SHOULD? >> >>> as well as the following change: >>> OLD >>> "Moreover, MNIDs containing sensitive identifiers might only be used >>> for signaling during initial network entry. " >>> NEW >>> "Moreover, MNIDs containing sensitive identifiers MUST only be used >>> for signaling during initial network entry and MUST NOT be leaked to >>> other networks.” >> The statement in OLD: is just a statement of fact that in some networks use temporary identifiers for reattachment and they use long term (and hence sensitive) identifiers only at initial attach. I don’t think it makes sense to change this to 2119 language. >> >> Thanks >> Suresh >> > From nobody Mon Feb 13 14:04:33 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 D1ED51299A9; Mon, 13 Feb 2017 14:04:27 -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 Zk8aPlOezQOI; Mon, 13 Feb 2017 14:04:26 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 CC6671299A2; Mon, 13 Feb 2017 14:04:25 -0800 (PST) X-AuditID: c618062d-14208980000009d8-2d-58a23d5a640a Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 95.22.02520.95D32A85; Tue, 14 Feb 2017 00:12:26 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 17:04:21 -0500 From: Suresh Krishnan To: Charlie Perkins Thread-Topic: =?iso-8859-1?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-dmm-4283mnids-04?= =?iso-8859-1?Q?:_(with_DISCUSS)?= Thread-Index: AQHSg8BIeh/d4aOeZ0GssdxcekDl7KFjhJmAgABSawCAA+9xAIAAEBwA Date: Mon, 13 Feb 2017 22:04:20 +0000 Message-ID: <20245605-FE26-4FF1-94F2-64CCA72DB09D@ericsson.com> References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/signed; boundary="Apple-Mail=_37A099BA-D5FC-4C17-9CE8-6F507191EBCE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyuXRPiG6U7aIIg1N7RSzu37nGZtFxejOz xf1HNRa3Fh5isZjxZyKzxYvrH5kt9k67yeLA7jHx7UcWj1VfJjB7LFnyk8mj5eNC1gCWKC6b lNSczLLUIn27BK6M5qU3GQsWGFT0v+RrYFyt18XIySEhYCKxauU11i5GLg4hgfWMEnv2z2WC cJYzSsy5vIcRpIoNqGrDzs9MILaIgLFEQ+89ZpAiZoH5TBK3L01jA0kIC9RIzNiykR2iqFZi 94w1zBC2m8TC6SvBbBYBVYn2y9/B6nkF7CUO3NrCArHtE6PE3TvrWUESnAKOEmvuTwNrYBQQ k/h+ag3YZmYBcYlbT+YzQdwtIvHw4mk2CFtU4uXjf6wQtqLEvv7p7BDXTWGUuNWzgx1im6DE yZlPWCYwisxCMmsWsrpZSOogirQlli18zTyLkQPI1pGYvJARImwq8froRyjbWmLGr4NsELai xJTuh+wLGDlWMXKUFhfk5KYbGWxiBMbnMQk23R2M96d7HmIU4GBU4uE1YFoUIcSaWFZcmXuI UQWo9dGG1RcYpVjy8vNSlUR4p/5eGCHEm5JYWZValB9fVJqTWnyIUZqDRUmcN271/XAhgfTE ktTs1NSC1CKYLBMHpxQwVvd2LNPr2r+kUWTR04gPR87xJF6N53Z5ypJ9dcL0SM4s2e2zl1zS 5HjJX2DGaWR7oGx5WFzDlrXqZgvOptzVZ2pblWUhezX8lHjwyQttWTWGCYf/OnZf28mcFuIz ectbjdi6N7mJkXpXPk28utpuldLCLKV3+W9Nd8XwcDkx+V5i+bLOKVpciaU4I9FQi7moOBEA mPbX+9cCAAA= Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" , "Mirja Kuehlewind \(IETF\)" Subject: Re: [DMM] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf-?= =?iso-8859-1?q?dmm-4283mnids-04=3A_=28with_DISCUSS=29?= 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, 13 Feb 2017 22:04:28 -0000 --Apple-Mail=_37A099BA-D5FC-4C17-9CE8-6F507191EBCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 13, 2017, at 4:06 PM, Charlie Perkins = wrote: >=20 > Hello Mirja and Suresh, >=20 > I am happy to make the proposed changes as agreed below. Sounds good Charlie. Please fold these changes into your next rev then = once you have converged with Dale. Regards Suresh --Apple-Mail=_37A099BA-D5FC-4C17-9CE8-6F507191EBCE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjEzMjIwNDIxWjAjBgkqhkiG9w0B CQQxFgQU5oJ85vMibexuzMSmSWbFjjZO5MIwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQBDWfRgAOCrthkK9HyEIxsp7XMmcJDrCTumyjja+7uKYUgQRb90EuEyd56JruTJ 4WZtFZMIce4a4XkQ94/0/OhMSZ2dK0kKgQhJ4QLwE5CcOcX6+w7CXOxTAMuVU/aE6cROHAO5jyKj nkuqg8Rwd1Adm/0ctCznBEvQTl/SorYAybB/5QWm4R5VWXQhTzIw5YKHBBKGYvnnf/+GkLNVz6ja VWEza2MYcTFaaPhMWU0Hnm6mmkxnMGmmkS1MsSpUbXwo3os42y3854LNQChSMTVXwIPav6+EPuEG uWJ7tudf0t7RcYWS4Ohk2JopinWsAgv2Lfj/jH+Of/R7GtwmcProAAAAAAAA --Apple-Mail=_37A099BA-D5FC-4C17-9CE8-6F507191EBCE-- From nobody Mon Feb 13 21:20:00 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 9613E1293F2; Mon, 13 Feb 2017 21:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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=-0.001] 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 TUh48_2MheQo; Mon, 13 Feb 2017 21:19:53 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EDC12947B; Mon, 13 Feb 2017 21:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1487049591; bh=oQL8LJ6JXMs2JvYPClb8bnZ1wKrcwZo0B48V KdgI39Q=; 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=Go617Mm hd1IapmbNf1rZnFYJ+NFgTLvJvJGZSDcoHvEy7FsM1N5YXHLmAM2txhzKj+ct7vGrcq wxrihlgq/Vq9VKfmJePpsctYVGQ4sT7Qp6PTmJY5mL8gALlqNIwzHRwyOcSxBo2nUXf 6THOOVzSTp4EXwndtsVKCzNTKM8ntZX+iCGfQmPX4aj4qHthAQt0aZjUZPcVbAE/Rbt mY691TloIA9Hm4gW7lA3tO3nPx7zyb0t1hXgbgGnyfyN8Yl+//js/BxfqiVBLXr+2j8 sb9UP1t6X/znzX8cjNTkmE3ZNvqg5itiBvrsYAw+ZnKrlxzmH74L5B0aBJUCRBUIi2w == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=DhvR0B69kFGg/8vEOlRmbCkPxhpttcNF9gEzxBAJRqrecxA14mhLcjDE2PoSUH8ljWjrnRcjEvL1zrh/fkYTgDIrc+F3wRVgLfF5DezlgtaS/uf15ScECCBD/xhIVBDr8dCY1bun12qWZMawMNBSJSjlvtePXzThnXLcKT0kadmRAB6Okn87Qs8x00xXkePANsBHOs/iu9g7oVFgk1AWKZ+93b6ImGd1cIui7JpGX5NFFw4i6xXhhhj7vixAfeb3Up5Jl+y85Wr5idXahLTPUF7Xox9MF8ytdvODpOn/o7lD3cOxafZR8xlN95AkfFQqqMqH/jbEJ5+Mz/uaVqEhgw==; 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 [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cdVWX-0005Kc-CJ; Tue, 14 Feb 2017 00:19:33 -0500 To: "Dale R. Worley" References: <87efz2wzoz.fsf@hobgoblin.ariadne.com> From: Charlie Perkins Message-ID: Date: Mon, 13 Feb 2017 21:19:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87efz2wzoz.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7598ed599bdacb1532843c9b011678fe5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org, dmm@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 14 Feb 2017 05:19:55 -0000 Hello Dale, Follow-up below... On 2/12/2017 7:13 PM, Dale R. Worley wrote: > >> There is a sort of "hidden" disadvantage to long names, especially for >> tiny devices using constrained link layers. Namely, a longer name makes >> it more likely to require lower-layer fragmentation. I'm not sure that >> it should be the job of a layer-3 mobility entity to parse URNs and >> determine if two different flavors are supposed to be equivalent. >> >> Other than that, I don't have any real objection to reorganizing the >> namespace, but I'd like some additional confirmation that it's a good idea. > There are a couple of reasons I like this idea. > > One is that EPC seems to have a policy of providing a URN form for all > of the identifier classes it defines. Making a single URN MNID type > means that you've incorporated all future classes of identifier that EPC > defines. > > A single URN MNID type would incorporate any of the defined URN > namespaces that turn out to be useful for anybody. This isn't so > interesting for really large deployments, since they could ask for a new > MNID type, but experimental or small-scale deployments may want to > define their own identifiers, and URNs provide several convenient ways > to do that. > > It removes a certain amount of redundancy, in that each RFID class now > has three representations, for a total of 20 MNID types, whereas they > could all be collapsed into one MNID type. > > The negatives I see are: > > Some URN schemes do not have a unique representation as a character > string. In practice, this is combated by either (1) Code that handles > URNs of arbitrary namespace copies and compares them as character > strings. Users of such systems know to write URNs that have multiple > representations in a canonical form. Or, (2) Code that handles one or a > small fixed set of URN namespaces knows the canonicalization/comparison > rules for those namespaces. Generally, using these processes doesn't > cause problems in practice. I expect that whatever receives the MNID > and looks it up in appropriate databases would not be a constrained > device, so it could process URNs carefully. > > If the link layer is constrained, longer identifiers may require > fragmentation. Changing a 96-bit binary representation into a URN seems > to add something like 40 octets, given the examples I've found online. > OTOH, it seems that the MNID is only transmitted when attaching to a > network, and so having that one packet require extra work doesn't seem > to be much of a penalty. > > The all-URN ides envisions embedding IMSI and possibly MSISDN into the > gsma URN namespace. (IMEI is already embedded as urn:gsma:imei:...) > That would take additional specification, although I don't see that > being controversial. (Andrew Allen would be a > good contact for doing this.) I am hesitant to replace so many MNID types by a single URN type with substructure. What would you think about replacing the existing RFID-*-URI types with a single URN type, but leaving the existing binary types? This gets the benefit you suggest for future extensibility, but retains the shorter forms that may often be advantageous. >>> 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. >> This text was meant to be generally descriptive, so that people wanting >> to include the Mobile Node Identifier Option with the relevant MNIDs >> could understand how the identifiers are actually used in various >> circumstances. I could replace constructions using "might" with "in >> some specifications" or "in some situations" if needed. Is it also >> necessary to include citations to the relevant documents of the external >> SDO? > I'd definitely prefer some other term than "might". I'm not sure why, > but I think that it's because "might" isn't used much in specifications > > .... I changed the text as follows: > Some MNIDs contain sensitive identifiers which, as used in protocols > specified by other SDOs, are only used for signaling during initial > network entry. In such protocols, subsequent exchanges then rely on > a temporary identifier allocated during the initial network entry. > Managing the association between long-lived and temporary identifiers > is outside the scope of this document. I can't remember exactly why this text was added - it was a long time ago. But anyway the main point is to simply mention that there may be associations between some of the MNID types that might be important from a security standpoint, without meaning to go into examples. Regards, Charlie P. From nobody Tue Feb 14 17:04:30 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 602A312945D for ; Tue, 14 Feb 2017 17:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 leDmt2Bhji1w for ; Tue, 14 Feb 2017 17:04:24 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 1DEF7129669 for ; Tue, 14 Feb 2017 17:04:23 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-07v.sys.comcast.net with SMTP id dnykcV4rB7NeDdo18cU9Sb; Wed, 15 Feb 2017 01:04:22 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with SMTP id do16cIP3uanCido17cdSBQ; Wed, 15 Feb 2017 01:04:22 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1F14K3c028393; Tue, 14 Feb 2017 20:04:20 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1F14JIs028390; Tue, 14 Feb 2017 20:04:19 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Charlie Perkins In-Reply-To: (charles.perkins@earthlink.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 14 Feb 2017 20:04:19 -0500 Message-ID: <87o9y4s1rg.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKS5k4ydAZv1A456HK1fKqO6j5y19L1ZpbVVuQFDzw5RJynsm4EAMW/wcjOfIV/X2s1VMEvayTR3vLd+fyExBbJ4s+untlG2qrb6SFcan1fbUFhjyWJi BuWJ2XhXWcrJM9lz9/6nA+ONc7YRHvEIZzAN6p6B9Mj+SD33E4czqMy3Q/LYHEvDJI+QY3qSNkzvw2XpIoLuwqBEyYtWSo35V6QdQZOBWEt02DkGEokD6VkX qaVRCcr4CJFrMjY+moCAJVvIRT2bi5AXh8g2OMgkykVP8wp5PlSLFJlZv7DcnV7T Archived-At: Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org, dmm@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 15 Feb 2017 01:04:25 -0000 Charlie Perkins writes: > I am hesitant to replace so many MNID types by a single URN type with > substructure. What would you think about replacing the existing > RFID-*-URI types with a single URN type, but leaving the existing binary > types? This gets the benefit you suggest for future extensibility, but > retains the shorter forms that may often be advantageous. Suddenly today I realized something I should have realized in the review, which would have saved us much time in discussion. Viz., consider this proposal: - one MNID type for *all* the EPC binary schemes - one MNID type for *all* URNs, *including* the EPC URI forms This would work, since (1) (not surprisingly) the EPC binary schemes are all differentiated by their first 8 bits. (see table on page 19 of the tag-data standard, http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf) and (2) all URNs are differentiated by their namespace part. (This parallels using one MNID number for all DUID types, since DUIDs have an internal indicator for the four types.) This approach has all the desirable properties anyone has mentioned so far: - includes all EPC binary and URI forms - automatically includes all existing and future EPC binary forms - automatically includes all existing and future URN forms *including* all existing and future EPC URI forms - doesn't have a proliferation of MNID type numbers which duplicate information that can be fairly easily extracted from the identifier itself - includes all the short EPC forms, allowing brevity when that is desirable This seems to be practical, simple, and almost as elegant as possible. What do you think? > I changed the text as follows: > >> Some MNIDs contain sensitive identifiers which, as used in protocols >> specified by other SDOs, are only used for signaling during initial >> network entry. In such protocols, subsequent exchanges then rely on >> a temporary identifier allocated during the initial network entry. >> Managing the association between long-lived and temporary identifiers >> is outside the scope of this document. > > I can't remember exactly why this text was added - it was a long time > ago. But anyway the main point is to simply mention that there may be > associations between some of the MNID types that might be important from > a security standpoint, without meaning to go into examples. Certainly the new text is clear enough. Dale From nobody Wed Feb 15 04:46:15 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 74D861299F9 for ; Wed, 15 Feb 2017 04:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 1TWT7MoF_LjC for ; Wed, 15 Feb 2017 04:46:12 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6D21299BB for ; Wed, 15 Feb 2017 04:46:11 -0800 (PST) Received: (qmail 27829 invoked from network); 15 Feb 2017 13:46:10 +0100 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 15 Feb 2017 13:46:10 +0100 To: Charlie Perkins , Suresh Krishnan References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <6a8360d0-f214-3b41-1529-b767e545793c@kuehlewind.net> Date: Wed, 15 Feb 2017 13:46:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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, 15 Feb 2017 12:46:13 -0000 Hi Charlie, can you please also answer the question below on SHOULD vs. MUST? Thanks! Also, does it maybe make sense to then add something in the security section that information should/must not be leaked to other networks? Thanks! Mirja On 13.02.2017 22:06, Charlie Perkins wrote: > Hello Mirja and Suresh, > > I am happy to make the proposed changes as agreed below. > > Regards, > Charlie P. > > > On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote: >> Hi Suresh, >> >> sounds all good! I’m happy to quickly resolve my discuss if the authors agree! >> >> Mirja >> >> >>> Am 11.02.2017 um 05:05 schrieb Suresh Krishnan : >>> >>> HI Mirja, >>> >>>> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind wrote: >>>> >>>> Mirja Kühlewind has entered the following ballot position for >>>> draft-ietf-dmm-4283mnids-04: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I would realy like to see the following changes in the security >>>> considerations section: >>>> OLD >>>> "If used in the MNID extension as defined in this >>>> document, the packet including the MNID extension should be >>>> encrypted >>>> so that personal information or trackable identifiers would not be >>>> inadvertently disclosed to passive observers." >>>> NEW >>>> "If used in the MNID extension as defined in this >>>> document, the packet including the MNID extension SHOULD be >>>> encrypted >>>> so that personal information or trackable identifiers would not be >>>> inadvertently disclosed to passive observers.” >>> Is this just for changing the "should" to upper case? I think that makes sense. >>> >>>> Or even better make it a MUST? Is there a reason for only having a >>>> SHOULD? >>> Authors, any specific reason for this to be a SHOULD? >>> >>>> as well as the following change: >>>> OLD >>>> "Moreover, MNIDs containing sensitive identifiers might only be used >>>> for signaling during initial network entry. " >>>> NEW >>>> "Moreover, MNIDs containing sensitive identifiers MUST only be used >>>> for signaling during initial network entry and MUST NOT be leaked to >>>> other networks.” >>> The statement in OLD: is just a statement of fact that in some networks use temporary identifiers for reattachment and they use long term (and hence sensitive) identifiers only at initial attach. I don’t think it makes sense to change this to 2119 language. >>> >>> Thanks >>> Suresh >>> >> > From nobody Wed Feb 15 08:50:40 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 633CA1295B2; Wed, 15 Feb 2017 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ok8EPOgBdOIU; Wed, 15 Feb 2017 08:50:38 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E745D1294BF; Wed, 15 Feb 2017 08:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4817; q=dns/txt; s=iport; t=1487177438; x=1488387038; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LvaLyYXBEHd/sV2pU29zz1G76QP7etmzTklSI2CI5R0=; b=P9/il7gp/kWRZodNyqfenNij1OWOt1m3F44EcOl0ws6iZUsPtZpvXhyQ R5mnwpY1g1I5NOpUetexUjh7YW/X5kSXAHlvL5/I81hkhSu3Shrc4wSav rzSrbFJgwxkSw+Xub0xk1jHddlAQ5BrF954LvSc255U8X2JfJMWg9Rmfx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQBVhqRY/4UNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1KBageNWqdGggyGIgKCEz8YAQIBAQEBAQEBYiiEcQYOLCsUEAIBCDY?= =?us-ascii?q?QMiUCBA4FiWuyVIs8AQEBAQEBAQEBAQEBAQEBAQEBAQEehk2Eb4QmEQGGAQWbd?= =?us-ascii?q?wGSE4F7hReJdJMWAR84eAhRFYUCHYFhdYgkgSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="386049403" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2017 16:50:36 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1FGoaqY008674 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 16:50:36 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 10:50:35 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 10:50:35 -0600 From: "Sri Gundavelli (sgundave)" To: "Dale R. Worley" Thread-Topic: [DMM] Review of draft-ietf-dmm-4283mnids-04 Thread-Index: AQHSh6ugGmBv2a9UCEeirDF7S0m5iA== Date: Wed, 15 Feb 2017 16:50:35 +0000 Message-ID: References: <87wpcuuj1n.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpcuuj1n.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <581AF40AA8C8B448A365053BBAEE2D0C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "charles.perkins@earthlink.net" , "gen-art@ietf.org" , "ietf@ietf.org" , "draft-ietf-dmm-4283mnids.all@ietf.org" , "dmm@ietf.org" Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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, 15 Feb 2017 16:50:39 -0000 HI Dale, Thanks again for the comments. Please see inline. On 2/13/17, 8:55 AM, "Dale R. Worley" wrote: >"Sri Gundavelli (sgundave)" writes: >> When we discussed this issue in the past, the general feedback from >> the WG was that the draft should provide some minimal amount of >> details on the new identifier types, what the identifier is, how the >> identifier is constructed, what is the access technology and a >> reference to the specification that provides that definition. The idea >> is NOT TO provide extensive details on the spec, but to enable a >> reader with some high level details and a pointer to the >> specification. I tend to think the text in the current specification >> just does that. If the text is seen as redundant text, we can >> certainly add a statement saying that the definition for the >> identifier is provided in spec-XYZ and is repeated here for >> convenience. May be other folks in the WG have some views on this. > >I take it that the following are typical comments from the WG: > >> Comments from 10/11/2015 email: >> >> "Some text on the motivation for defining new Types may be >> helpful. Document is not just standardizing the currently >> in-use/popular identifier types, its also introducing new types are >> not in use. The reasons/interest for defining identifiers that are >> tied to the physical elements of the device (RFID, MAC address ..etc) >> and how it helps in deployment of the technology may be useful. Few >> lines of text will really help." >> >> "I was hoping to see a sub-section for each of the types. We cannot >> standardize a identifier type without providing any explanation on the >> identifier type or the references to the base definitions. This can be >> painful, but I'd have a small section for each of the types. It can be >> 3 line text on the a.) Definition b.) Format c.) Example format d.) >> Reference to the base spec that defines those identifiers." > >I can understand these desires, and I agree with following them. > >In regard to the first message, it seems to request "The >reasons/interest for defining identifiers that are tied to the physical >elements of the device (RFID, MAC address ..etc) and how it helps in >deployment of the technology may be useful." As far as I can tell, this >isn't handled in section 4.9 (which is the part I was complaining >about). And I don't recall if the earlier parts of the draft are >specific about "the reasons/interest" for any of the new types. I >believe from this discussion that the reason an identifier was included >is that somebody told the authors that they wanted to use the identifier >in question -- and that is quite legitimate. Perhaps saying it >explicitly in the early parts of the draft would help. > >In regard to the second message, it seems to request > > a small section for each of the types. It can be > 3 line text on the > a.) Definition > b.) Format > c.) Example format > d.) Reference to the base spec that defines those identifiers. > >Of course, (d) "reference to base spec" is necessary, and the >sub-sections of 4.9 do that for each format, as does Table 1. > >For (a) "definition", the texts in 4.9 proper seem to be fairly good. >E.g., > > The EPC encoding scheme for SGTIN permits the direct embedding of > EAN.UCC System standard GTIN and Serial Number codes on EPC tags. In > all cases, the check digit is not encoded. Two encoding schemes are > specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits). > >Based on that alone, I couldn't possibly construct a SGTIN-64 myself, >but I have some idea of the information it contains and the technical >terms to look up to find the real definition of the data items. > >However (b) "format" seems to be missing (except in the most abstract >sense) and (c) "example format" seem to be missing entirely. OTOH, I'm >not sure that the space needed to specify those would be worth the >effort. [Sri] I agree. The goal was to make the spec complete. What ever identifiers we are carrying in this option, we provide the format, structure and semantics of construction and not treat it like an opaque container. But, its a delicate balance, not ending up with a lot of duplicated text, vs incomplete specification. I agree, its not worth the efforts doing a significant re-write. The current text is probably fine. > >Summary: After thinking about it more, I think it's not worth the >effort to revise 4.9 heavily. Most of that information is for the use >of people who are familiar with the RFID identifiers and their formats, >and if they are happy with it, there's no reason to change it. [Sri] I agree with your summary. > >Dale From nobody Wed Feb 15 08:58:15 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 9ACE5129AE8 for ; Wed, 15 Feb 2017 08:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oPwvPZzvW1Y9 for ; Wed, 15 Feb 2017 08:58:12 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EC5129AE6 for ; Wed, 15 Feb 2017 08:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3269; q=dns/txt; s=iport; t=1487177892; x=1488387492; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bdjbpOfSCkfVqH3nM1DfltFP89ZrsJiovKlDYcX7baw=; b=C76TAEpdqYd8g+3mMzugYCc8AX6eqmk9ezrmlnpgGBEAppN3Pxyhe7U8 LZGeKA+5CIYvrvkC5YNB6S1ulM4eYGhWvHF5j6i6574TnpqJw6FdFj7va t33H178aWbLnOzdvo2TW+RRzJcaIzZsR4+h6lOERz73nM/w707ASoB/jj U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAQCEh6RY/49dJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9jgWoHjVqSEIgMh36DHYIPggyGIgKCEz8YAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQSBCQIBCAQKAwMBAigHIREUCQgCBAESiVMDFbJYhzkNg3YBAQEBAQEBAwEBA?= =?us-ascii?q?QEBAQEBIIZNhG+CUYIjFoUvBZs9OgGNeoQZgXuFF4l0ijaIYAEfOIEAURUYhmh?= =?us-ascii?q?1iUWBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208,217";a="384526729" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 16:58:11 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v1FGwBNP015206 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 16:58:11 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 10:58:10 -0600 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 10:58:10 -0600 From: "Sri Gundavelli (sgundave)" To: Dapeng Liu , dmm Thread-Topic: DMM IETF 98 meeting Thread-Index: AQHSh6yw8bJ65vcaHkSKyDypiQoi1g== Date: Wed, 15 Feb 2017 16:58:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.246.215] Content-Type: multipart/alternative; boundary="_000_D4C9C826259E46sgundaveciscocom_" MIME-Version: 1.0 Archived-At: 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: Wed, 15 Feb 2017 16:58:13 -0000 --_000_D4C9C826259E46sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gentle Reminder . Please send your requests for presentation slot by 2/23. = Please include Title: Description: Time: Presenters: Draft Reference (If exists): Regards Sri From: Dapeng Liu > Date: Monday, January 23, 2017 at 2:09 AM To: dmm > Cc: Sri Gundavelli > Subject: DMM IETF 98 meeting 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 --_000_D4C9C826259E46sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Gentle Reminder . Please send your requests for presentation slot by 2= /23. Please include

Title:
Description:
Time: 
Presenters:
Draft Reference (If exists):



Regards
Sri

From: Dapeng Liu <maxpassion@gmail.com>
Date: Monday, January 23, 2017 at 2= :09 AM
To: dmm <dmm@ietf.org>
Cc: Sri Gundavelli <sgundave@cisco.com>
Subject: DMM IETF 98 meeting

Hello all,

IETF 98 meeting is approaching. If you want to request a time slot, pl= ease send request to the chairs before 2017-02-23.<= /div>


Thanks,
Dapeng & Sri
--_000_D4C9C826259E46sgundaveciscocom_-- From nobody Wed Feb 15 16:08:53 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 153B2129C0A; Wed, 15 Feb 2017 16:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 KijG5uVnF8wJ; Wed, 15 Feb 2017 16:08:50 -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 0C23B12997E; Wed, 15 Feb 2017 16:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1487203729; bh=TWgJj2iHDWXuU/BlH+PmG2yUxOSTK1fbmFas zHGwQTs=; 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=AGGjEdI UhIZSGpIM0pfUGRhiYj3mzIJHkUmQf36qYcZvKGJq7JHGMWTMUBO0uKOL2ynUPl9XzY KtvFddwbyv7NDM4ABxk23yUwa6NyYi8kDt4MEicDxAQqGlwcHvE4psUO0FRh38uOv8C hIv+cxGGvZ/loFsQUTuOnO8YfjYvFzsaBEKzAb9Xo2YwCA0YSjquKPYV72ESAKzAhBN +58veBDSZ7xf7yr28oxAVRBtEe/Wn+Q/vWlGRXshLJW+OHTWbkDt+YAJAu3OtHdDuwB yDBFm6mRvObuz1HPzFhSfEDq8Ad9yxGVmBwHYlqHC7p1/GKmwvOdh+Z9NhfAGrLkLvw == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=OCu+taZu31qd8DRWetmtkLZgIykeqszA60+z5bvQ4JFc2wLfpj6rMpRaD2wBb9QClQAsLxvjiKXBdI3lcC1TG7E045e2STkyHCU2jzwqeRxkVY+EPwToCSf0Y/Z+vtDks8wzO+o3Uxej4G3z5wWYD4xEKieBjFSb2dd0rNwCi6XpoTusaKapzcbw5J9LjghwBYlkZ8elutHBzcgI+ruNcLYX/rXQdBCddDu/7aZGQmFQh27xUfrkduY55Z70hBRefhdY77PRiZ3Qs2z+gp7INg8WUFZcTN9MbeUmcrqSnFNgZxKsWsVpoconzoUbBsAUD+OPXC6H6B6TwnagaRCdxQ==; 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 [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ce9ch-0006dG-Q0; Wed, 15 Feb 2017 19:08:35 -0500 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Suresh Krishnan References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> <6a8360d0-f214-3b41-1529-b767e545793c@kuehlewind.net> From: Charlie Perkins Message-ID: <69ea2b13-de60-a8f7-ac48-62280dd93c69@earthlink.net> Date: Wed, 15 Feb 2017 16:08:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6a8360d0-f214-3b41-1529-b767e545793c@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7367dccfe1b9c8747516719a905a6a761350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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: Thu, 16 Feb 2017 00:08:52 -0000 Hello Mirja, My previous answer was intended to mean that I would change to MUST. Would you be willing to suggest some text about the non-leakage? I thought that the point of strengthening to MUST was to ensure that sensitive identifier information was not leaked. If there is something more to be said, I'll be happy to say it. Regards, Charlie P. On 2/15/2017 4:46 AM, Mirja Kühlewind wrote: > Hi Charlie, > > can you please also answer the question below on SHOULD vs. MUST? Thanks! > > Also, does it maybe make sense to then add something in the security > section that information should/must not be leaked to other networks? > > Thanks! > Mirja > > > On 13.02.2017 22:06, Charlie Perkins wrote: >> Hello Mirja and Suresh, >> >> I am happy to make the proposed changes as agreed below. >> >> Regards, >> Charlie P. >> >> >> On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote: >>> Hi Suresh, >>> >>> sounds all good! I’m happy to quickly resolve my discuss if the >>> authors agree! >>> >>> Mirja >>> >>> >>>> Am 11.02.2017 um 05:05 schrieb Suresh Krishnan >>>> : >>>> >>>> HI Mirja, >>>> >>>>> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind >>>>> wrote: >>>>> >>>>> Mirja Kühlewind has entered the following ballot position for >>>>> draft-ietf-dmm-4283mnids-04: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>> this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> >>>>> I would realy like to see the following changes in the security >>>>> considerations section: >>>>> OLD >>>>> "If used in the MNID extension as defined in this >>>>> document, the packet including the MNID extension should be >>>>> encrypted >>>>> so that personal information or trackable identifiers would not be >>>>> inadvertently disclosed to passive observers." >>>>> NEW >>>>> "If used in the MNID extension as defined in this >>>>> document, the packet including the MNID extension SHOULD be >>>>> encrypted >>>>> so that personal information or trackable identifiers would not be >>>>> inadvertently disclosed to passive observers.” >>>> Is this just for changing the "should" to upper case? I think that >>>> makes sense. >>>> >>>>> Or even better make it a MUST? Is there a reason for only having a >>>>> SHOULD? >>>> Authors, any specific reason for this to be a SHOULD? >>>> >>>>> as well as the following change: >>>>> OLD >>>>> "Moreover, MNIDs containing sensitive identifiers might only be used >>>>> for signaling during initial network entry. " >>>>> NEW >>>>> "Moreover, MNIDs containing sensitive identifiers MUST only be used >>>>> for signaling during initial network entry and MUST NOT be >>>>> leaked to >>>>> other networks.” >>>> The statement in OLD: is just a statement of fact that in some >>>> networks use temporary identifiers for reattachment and they use >>>> long term (and hence sensitive) identifiers only at initial attach. >>>> I don’t think it makes sense to change this to 2119 language. >>>> >>>> Thanks >>>> Suresh >>>> >>> >> > From nobody Wed Feb 15 16:12: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 A4AB1129C05; Wed, 15 Feb 2017 16:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 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, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 w_-DOq02oh9L; Wed, 15 Feb 2017 16:12:18 -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 8D608129C04; Wed, 15 Feb 2017 16:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1487203937; bh=6xZt+yDlj3PAWRldWyCmsApEBdF76ryJU6LB bVM8DgI=; 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=hGb9JT+ gO6JsaPeYAo4M4Bu6R+8pwHfrvv5ZI4kdyTtC39VdXjWkWXwBrKholQfMNU6/sB0d5C xryWG8YwCCq9xLJu5GYQq0G0hbztxKosUUFYNESlZjXAzSyq9z+Cj7bDe2IW8YZiF56 K0De4fWpVKtcOoEE3l+qMzayfNMAXHQdGQSY42G0+5MpGH6/5ueav/WDqcmAywLlW2D fZ1sU+yJXMxI3N5PpOKVoNHUvpeVWviH/+MpFwvdvI5BvJNVtk2hHwoCKGaz+RIK+U/ SZJzLxF+gGGmR0MtrbklXCUQvv0UsXGp5qoAHzzk+t+HN0q7gTBSHVkCB8ROi9z25FA == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=NJ9LXRtzCBUu2iOnnG64fGcrPtXAAMzstu/6C+np+x1YvRRFM65Uo8K/BXdcuUQgQWOc6fGPLUqZLxha/BB4xeVdTIFjsZg1IXAQDKFTg1HLDax9Co4P+mYaqBNIzXt+LdjYTcoy92sJYj0PyqB8Gt4eZ0tClUmrOGeL8CCLpoGv+j1J1S3iERUqmFmSy+DpMzOTvY9TQIZBh5UjIhpLin5FeUhezJCUHO3MUizyfNVaGn+SH5/kqxCuObCvXe8xgbl8pEete8lmc1lRTNVNvtEqVjbK/lk4mLHhnTj0PTrF04jO/SXPqN+FDMBd2XPJeCb4uDQgB1Y89viFF0Ty2A==; 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 [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ce9gB-0002ZY-MQ; Wed, 15 Feb 2017 19:12:11 -0500 To: "Dale R. Worley" References: <87o9y4s1rg.fsf@hobgoblin.ariadne.com> From: Charlie Perkins Message-ID: Date: Wed, 15 Feb 2017 16:12:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87o9y4s1rg.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac78030d2dc13a190b468de9a8be97af0f3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org, dmm@ietf.org Subject: Re: [DMM] Review of draft-ietf-dmm-4283mnids-04 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: Thu, 16 Feb 2017 00:12:19 -0000 Hello Dale, O.K. I will take a crack at making this reorganization. If you have text of course that will be appreciated. Right now I don't see why anyone in the WG would object, but I hope at least some people will take a look. I can have the revised draft ready in a few days. I think this resolves the last point of discussion that has been raised about the draft. Regards, Charlie P. On 2/14/2017 5:04 PM, Dale R. Worley wrote: > Charlie Perkins writes: >> I am hesitant to replace so many MNID types by a single URN type with >> substructure. What would you think about replacing the existing >> RFID-*-URI types with a single URN type, but leaving the existing binary >> types? This gets the benefit you suggest for future extensibility, but >> retains the shorter forms that may often be advantageous. > Suddenly today I realized something I should have realized in the > review, which would have saved us much time in discussion. Viz., > consider this proposal: > > - one MNID type for *all* the EPC binary schemes > > - one MNID type for *all* URNs, *including* the EPC URI forms > > This would work, since (1) (not surprisingly) the EPC binary schemes are > all differentiated by their first 8 bits. (see table on page 19 of the > tag-data standard, > http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf) > and (2) all URNs are differentiated by their namespace part. > > (This parallels using one MNID number for all DUID types, since DUIDs > have an internal indicator for the four types.) > > This approach has all the desirable properties anyone has mentioned so > far: > > - includes all EPC binary and URI forms > - automatically includes all existing and future EPC binary forms > - automatically includes all existing and future URN forms *including* > all existing and future EPC URI forms > - doesn't have a proliferation of MNID type numbers which duplicate > information that can be fairly easily extracted from the > identifier itself > - includes all the short EPC forms, allowing brevity when that is > desirable > > This seems to be practical, simple, and almost as elegant as possible. > What do you think? > >> I changed the text as follows: >> >>> Some MNIDs contain sensitive identifiers which, as used in protocols >>> specified by other SDOs, are only used for signaling during initial >>> network entry. In such protocols, subsequent exchanges then rely on >>> a temporary identifier allocated during the initial network entry. >>> Managing the association between long-lived and temporary identifiers >>> is outside the scope of this document. >> I can't remember exactly why this text was added - it was a long time >> ago. But anyway the main point is to simply mention that there may be >> associations between some of the MNID types that might be important from >> a security standpoint, without meaning to go into examples. > Certainly the new text is clear enough. > > Dale > From nobody Wed Feb 15 17:27: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 5AFC7129463; Wed, 15 Feb 2017 17:27:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 17:27:14 -0800 Archived-At: Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) 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, 16 Feb 2017 01:27:14 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dmm-4283mnids-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't consider that merely mentioning that there are some privacy issues (maybe) is nearly sufficient here. Instead I would argue that any of these identifier types that could have privacy implications need to be specifically justified or else dropped. By specifically justified, I mean that there ought be an argument (and a fairly holistic one) that the Internet is better, and not worse, if we define a codepoint that allows MIPv6 (and later, other protocols) to use that identifier. I do accept that my position is perhaps innovative, in terms of IETF processes, so I'll split the discuss into two parts, one process oriented and mostly for the IESG, and the second relating to the content of the draft. (1) For the IESG: is it ok that we introduce (codepoints for) a slew of new long-term stable privacy-sensitive identifiers just because they might someday be needed, or do we need to have specific justification for defining such things? I would argue the latter, but that may need us to validate that there is IETF consensus for that somehow, and perhaps in the meantime hold on to this draft. Part of my reasoning is that once we define such codepoints (e.g. for IMSIs) then that inevitably means that other protocols, and not just MIPv6, will do the same eventually, so accepting this draft basically means accepting that we end up commonly and perhaps carelessly, passing such highly-sensitive information about on the Internet in many protocols and in many contexts. My argument here I think does adhere to various of our BCPs that do argue for security and privacy, but I do also accept that this may be novel and to some extent goes against another of our generally accepted ideas which is that we benefit from folks documenting things even if those things are sub-optimal in various ways. So I'd argue this is a real case for an IESG discussion - I know what I think, but what do the rest of you think? (2) For the authors: to the extent you are willing to, and want to get ahead of the discussion on point (1) above, can you in fact provide an argument, for each of the identifiers here that have privacy-sensitivity, that the Internet is better overall if we define these codepoints knowing that if we do define a way to represent e.g. an IMSI in MIPv6 that is likely to be copied elsewhere? Note for the authors: I think it's entirely fine for you to do nothing pending the discussion of point (1) above, if that's your preference. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I'm entirely sympathetic to Mirja's discuss point, I don't think that a statement here can really constrain how these identifiers, once they are defined, are used in other protocols. While there is a chance that some IESG sometime might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt if identifier is used" the chances that a future IESG notice this isn't that high, but it's also even more likely that the designers of future protocols will successfully argue that since not all identifiers are privacy sensitive, their specific protocol need not adhere to the SHOULD. In the end, I think that should or SHOULD will be ineffective. From nobody Wed Feb 15 17:37:21 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 3E386129442; Wed, 15 Feb 2017 17:37:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148720903524.31628.16535215125562882129.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 17:37:15 -0800 Archived-At: Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] Alissa Cooper's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS) 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, 16 Feb 2017 01:37:15 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dmm-4283mnids-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Stephen's DISCUSS. I'm also wondering, if all of these identifiers are already in common use in MIPv6 without a standard, if there is some privacy improvement that standardization could contribute (e.g., encrypting the identifiers, or requiring transport encryption, or limiting their transmission to the initial binding, or ... other ideas the community may come up with). The benefit of just standardizing the options as-is seems outweighed by the potential privacy risks as this spec is defined. I'm also confused about the identifier types that do not uniquely identify one node, since I thought that was the point of these options. How are they meant to be used in MIPv6? Would you have multiple mobile node identity options in a single packet that, together, uniquely identify a node? I think this requires some elaboration in the text. From nobody Wed Feb 15 19:47:29 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 F18A3129CB0; Wed, 15 Feb 2017 19:47:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721684794.31572.814060328381329269.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 19:47:27 -0800 Archived-At: Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] Ben Campbell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) 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, 16 Feb 2017 03:47:28 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dmm-4283mnids-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The security considerations says some of these identifiers can carry sensitive information, and when they do you should encrypt. This leaves it to the reader to decide which might be sensitive. The draft should tell the reader which ones the working group thinks are sensitive, keeping in mind that if an identifier is sometimes sensitive, it usually needs to be treated as if always sensitive. (It's hard for deployed code to figure out when it is or isn't sensitive.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Stephen's, Alissa's, and Mirja's discusses. I especially agree that we should not standardize new identifiers without justifying each one. Section 5 says this document does not impact existing security mechanisms. But it does add new data elements, and acknowledges some of them may be sensitive. Thus I think the "does not impact" assertion needs some supporting discussion. Are the existing mechanisms still adequate? Why? There are a bunch of acronyms that would benefit from expansion on first mention. From nobody Wed Feb 15 21:18:42 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 C3AF4129991; Wed, 15 Feb 2017 21:18:34 -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.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148722231479.31523.14322647882818288460.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 21:18:34 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-hnprenum-06.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, 16 Feb 2017 05:18:35 -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-06.txt Pages : 9 Date : 2017-02-15 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 has happened (e.g. due to change of service provider, change of site topology, etc.). 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-hnprenum-06 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 Wed Feb 15 21:41:10 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 F1DAB1293FC; Wed, 15 Feb 2017 21:41:04 -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 0smEXSykPyve; Wed, 15 Feb 2017 21:41:03 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 21A41120725; Wed, 15 Feb 2017 21:41:03 -0800 (PST) X-AuditID: c618062d-d5fff700000009d8-f8-58a54b72566c Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id FE.C7.02520.37B45A85; Thu, 16 Feb 2017 07:49:26 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 00:40:58 -0500 From: Suresh Krishnan To: "Stephen Farrell (stephen.farrell@cs.tcd.ie)" Thread-Topic: Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) Thread-Index: AQHSh/PRwQAujh07hES6JsHlZ79hE6FrcmiA Date: Thu, 16 Feb 2017 05:40:57 +0000 Message-ID: <5E7FEA76-F882-425E-98D9-0D48E50E4AE2@ericsson.com> References: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com> In-Reply-To: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; boundary="Apple-Mail=_92CA925C-0EAC-4602-A1B9-D232E3B5803C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyuXSPt26Z99IIg5//pSw6Tm9mtrj/qMbi 1sJDLBYz/kxkttg77SaLxfS919gd2Dwmvv3I4rG2+yqbx5IlP5kCmKO4bFJSczLLUov07RK4 MjY3nmUsuO9W8eLOB/YGxqsOXYycHBICJhLdD7axdTFycQgJrGeUOL3oD5SznFFi1bwdTCBV bEBVG3Z+BrNFBHwl5u55zAxSxCzwhlHi94xOFpCEsECyROfXA2wQRSkSZ57cY4SwjST6Hh5n BbFZBFQlet/1gdXwCthLnDzTDjSIA2ibn8TlfzYgYU4Bf4mDq9eyg9iMAmIS30+tAdvLLCAu cevJfCaIq0UkHl48zQZhi0q8fPyPFcJWkvj4ez47xG1TgB5Y2swIsUtQ4uTMJywTGEVmIZk1 C1ndLCR1EEXaEssWvmaeBXQfs4COxOSFjBBhU4nXRz9C2dYSM34dZIOwFSWmdD9kX8DIsYqR o7S4ICc33chgEyMwEo9JsOnuYLw/3fMQowAHoxIPr8HSJRFCrIllxZW5hxhVgFofbVh9gVGK JS8/L1VJhLeNeWmEEG9KYmVValF+fFFpTmrxIUZpDhYlcd641ffDhQTSE0tSs1NTC1KLYLJM HJxSDYxJTzh+lTy690tOU/KtluG+yyKhMmVLzuvucrxut7LWt+9fRIJd3FWhcmadibvqFgQ4 vvn1kvdBbm7u0Q+Tp0aemCMqoartfcD9qOxyXq3tvLaVHu/YTiV61Z/q2MW+iUc0ZHOx+E6L vXJv10Y+Whtivu+b2vxV/w+dmHBVjnu7JkOdGV+T3FslluKMREMt5qLiRADuHcHLzAIAAA== Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) 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: Thu, 16 Feb 2017 05:41:05 -0000 --Apple-Mail=_92CA925C-0EAC-4602-A1B9-D232E3B5803C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Stephen, > On Feb 15, 2017, at 8:27 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-dmm-4283mnids-04: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > I don't consider that merely mentioning that there are some > privacy issues (maybe) is nearly sufficient here. Instead I > would argue that any of these identifier types that could have > privacy implications need to be specifically justified or else > dropped. By specifically justified, I mean that there ought be > an argument (and a fairly holistic one) that the Internet is > better, and not worse, if we define a codepoint that allows > MIPv6 (and later, other protocols) to use that identifier. I > do accept that my position is perhaps innovative, in terms of > IETF processes, so I'll split the discuss into two parts, one > process oriented and mostly for the IESG, and the second > relating to the content of the draft. >=20 > (1) For the IESG: is it ok that we introduce (codepoints for) > a slew of new long-term stable privacy-sensitive identifiers > just because they might someday be needed, or do we need to > have specific justification for defining such things? I would > argue the latter, but that may need us to validate that there > is IETF consensus for that somehow, and perhaps in the > meantime hold on to this draft. Part of my reasoning is that > once we define such codepoints (e.g. for IMSIs) then that > inevitably means that other protocols, and not just MIPv6, > will do the same eventually, so accepting this draft basically > means accepting that we end up commonly and perhaps > carelessly, passing such highly-sensitive information about on > the Internet in many protocols and in many contexts. My > argument here I think does adhere to various of our BCPs that > do argue for security and privacy, but I do also accept that > this may be novel and to some extent goes against another of > our generally accepted ideas which is that we benefit from > folks documenting things even if those things are sub-optimal > in various ways. So I'd argue this is a real case for an IESG > discussion - I know what I think, but what do the rest of you > think? Yes. I think it is worth having that discussion given that few more ADs = have expressed concerns similar to yours. On the flip side, I think at = least few of these identifiers are already conveyed using other layers = in some of the SDO networks. Regards Suresh --Apple-Mail=_92CA925C-0EAC-4602-A1B9-D232E3B5803C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMszCCBfUw ggPdoAMCAQICEQDBTwyxD9MsGvfXxnk9EeujMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIyMjE5 MjAyMloXDTE3MTIyMjE5MjAyMVowbDERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD1N1cmVz aCBLcmlzaG5hbjErMCkGCSqGSIb3DQEJARYcc3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTEQ MA4GA1UEBRMHbG1jc3VrcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANGcfCXBzd+C oyGibVfWAz/McYUdmPZ2YiTaQk8v/yLaKsKiFBdOZn9ahr9iu6pXz9OEbxH1h3hrudHg6de44JFg ZAHfZii/R+Ard+/7dG1BE7jd1+kuSFDzfLzv/BNY2sHEhPlGks4D/VBoCLwGdopsBvkrp8QKOa6+ SzIGsTCwtVS4qnlcp4Qprmj/KCF2VIEERnMc5F93xXhZa+SDV57JI8ep3psnMy8tAdddKvY/0ZBI MXAD8O1DKhC/SLFLhZQok4JUJBXsjsUGE3+1/D4HG0/johJ8rSGfrMkECgZ8wZZyw0cdM3/cB7+O nN2V1oY2/Xo0dLL3nPtfRZWFQAECAwEAAaOCAcIwggG+MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsG AQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjIuY2VyMCcGA1UdEQQgMB6BHHN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBRTsyLz1xpNDuZ1g4JxlMDczzX4GzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28G yg52cX9LNzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAJqZ/LPXQsxfJkyVbggL B/1m11FTG5OefG+rK3msNbXwEsVBul4MizD6VwCQbLaZK5vt0sm6XhPqBfC2fUICra+YmkuwAhCU Fzgs9d/qg5ubbe6CgD0wIQJpxP66Y2v5Kr2pFVu3ew18X/XnTgYzLo3sUtr7itLfMoy0SMSDCYvc 4lCP0Zo4qOAuEBnFs0IsNSDVRygRcj0+jjEc3WXpKD3XYEo+qTnCV8yvKNRa1LzIg205zFR2bvsG H6GDE5qyYAtTEFLiEmvz+FNaTLlXSIM3gBbgxN4BT5UOeU20CJEww2NtIJrlAlBCm6aD5tu8jKUn 78iWA3Mvk3F2HvxY5KIDH7L1MqJflxBrNMgJ1VQ0IL9DdofOeq5PSh4FGPoc4xpIk+aN9px/ZV2r WyieLB/Pj155yUr3ZtkYXF0VXmeu3S15DCofAHI171Ihsnsm6mamfm8lahLMoGgIMBMz0PS/vqCz Jd92HYlfhg5W6UC/ZRAhsRJsiF7vEADtzlx9wD+hVfIBzkn5wv3GuCwcDsYroj25K8yfiyXFffPO NAjVN1b2kiYLy+Z3RD9CxN1UAxBZANJLu1FfjdvsCHtrq5mLk3QFhf1YpoF51hvEN30ymF9UZQkb Ro9sAC8bULdMRlwNcNeN55Sz2CDW3QNgZNdmLpD2h9Td0FaG0nmODm3uMIIGtjCCBJ6gAwIBAgIR AKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3 MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZp ZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN1 3HgaeXXsMmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE 9N03OsHfOzlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlp usaH07FAcLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1Vq qK0GXSgAmInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um 0zANhenIUwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI 4YXqBXdP5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+N V8VTaTrFnHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwta IHLxBiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCB igYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVy YS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNv bS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50 ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/ SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4H IGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJp Xyfrlzmg36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GG x/KxiIiXg5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj 9GejKXFJ6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55 JE0BIt+kXDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcj SDpKB0M5tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk 9OAijkG6n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7 RcdBjLJh+lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZA Jwoz9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYIC mTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa99fGeT0R66MwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjE2MDU0MDU3WjAjBgkqhkiG9w0B CQQxFgQUY39atLBP5DugUxQIoaKVK4lsi3MwXgYJKwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAMFPDLEP0ywa 99fGeT0R66MwYAYLKoZIhvcNAQkQAgsxUaBPMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEAwU8MsQ/TLBr318Z5PRHrozANBgkqhkiG 9w0BAQEFAASCAQB/9oHBwcjSIkPSdSwWIOIDLFIpts9P4dJeiKx/a7tAZN8jdFB7s5sqTCdmYC8A PJAqSjhbq0enUX23UxSGyChC6IhrzJKo+DpgZAzN0xajGYQ4NN5RGdWniCoRp2PZxlzRpIceVuwS FEmDnY0d8Iuok93lz0lMaswruvopw/vxB2WSX/2PITg0a+n6STX8OCU6h5wrXc/q6syTsKZPZi9W 0ZT7QX9Eumb36FPWQqr1cHY59wwhwckhQyuspCUOmY8x5VzOYJ6DQh3bsDzcnJ1uMfkCqRGiOG5w xHrknF0xtIozx7kDSOsqYR4TEBHK4yxSgIQ/sGJJkTScoMHbKDxMAAAAAAAA --Apple-Mail=_92CA925C-0EAC-4602-A1B9-D232E3B5803C-- From nobody Wed Feb 15 21:47:48 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 6DE271295BC for ; Wed, 15 Feb 2017 21:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 P0jizDwalGRb for ; Wed, 15 Feb 2017 21:47:44 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 814871295AC for ; Wed, 15 Feb 2017 21:47:42 -0800 (PST) Received: from yanzhiwei (unknown [218.241.103.84]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AJEJzzPKVYGGKAKg--.23164S2; Thu, 16 Feb 2017 13:47:31 +0800 (CST) Date: Thu, 16 Feb 2017 13:47:27 +0800 From: "Z.W. Yan" To: "Sri Gundavelli (sgundave)" , "Dapeng Liu" , "dmm" References: Message-ID: <201702161347275821725@cnnic.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon772387233155_=====" X-CM-TRANSID: AQAAf0AJEJzzPKVYGGKAKg--.23164S2 X-Coremail-Antispam: 1UD129KBjvJXoW7KF1UJF48Cw1rXF4ftw4kCrg_yoW8Gr4fpa 1vkw1rWFykZrWxurW8ZF4DJ343Zws3XwsIkryqqr15Zw17KFy09F1j9FZ0vFWkCr1rGw1F qw47Zrn3Zw15ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Fb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E 4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4 IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IE b7IF0Fy26I8I3I1lc2xSY4AK67AK6r4rMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4 AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE 17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI IF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3 Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcS sGvfC2KfnxnUUI43ZEXa7IU8aFAtUUUUU== X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: 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: Thu, 16 Feb 2017 05:47:46 -0000 This is a multi-part message in MIME format. --=====003_Dragon772387233155_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sIFNyaSBhbmQgRGFwZW5nLA0KSSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgdGhlIE1vYmls aXR5IEFiaWxpdHkgTmVnb3RpYXRpb24gZHJhZnQgaW4gdGhlIERNTSBtZWV0aW5nOg0KDQpUaXRs ZTogTW9iaWxpdHkgQWJpbGl0eSBOZWdvdGlhdGlvbg0KRGVzY3JpcHRpb246IERpZmZlcmVudCBt b2JpbGl0eSBtYW5hZ2VtZW50IHByb3RvY29scyBoYXZlIGRpZmZlcmVudCBmdW5jdGlvbmFsIHJl cXVpcmVtZW50cyBvbiANCnRoZSBuZXR3b3JrIGVsZW1lbnQgb3IgdGhlIHRlcm1pbmFsIGFuZCB0 aGVuIGEgc2NoZW1lIHNob3VsZCBiZSB1c2VkIGluIG9yZGVyIHRvIHN1cHBvcnQgdGhlIA0KbmVn b3RpYXRpb24gYW5kIHNlbGVjdGlvbiBvZiBhZG9wdGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQgcHJv dG9jb2wgd2hlbiBhIHRlcm1pbmFsIGFjY2Vzc2VzIA0KdG8gYSBuZXcgbmV0d29yay4gIFRoaXMg ZHJhZnQgYW5hbHl6ZXMgdGhpcyBpc3N1ZS4NClRpbWU6IDEwIG1pbnV0ZXMNClByZXNlbnRlcnM6 IFpoaXdlaSBZYW4NCkRyYWZ0IFJlZmVyZW5jZSAoSWYgZXhpc3RzKTpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQteWFuLWRtbS1tYW4tMDAgDQoNClRoYW5rIHlvdSBzbyBtdWNoIGZv ciB5b3VyIGNvbnNpZGVyYXRpb24uDQpCUiwNClpoaXdlaQ0KDQoyMDE3LTAyLTE2IA0KDQoNCg0K t6K8/sjLo7ogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSANCreiy83Ksbzko7ogMjAxNy0wMi0x NiAgMDA6NTg6MjYgDQrK1bz+yMujuiBEYXBlbmcgTGl1OyBkbW0gDQqzrcvNo7ogDQrW98zio7og UmU6IFtETU1dIERNTSBJRVRGIDk4IG1lZXRpbmcgDQogDQpHZW50bGUgUmVtaW5kZXIgLiBQbGVh c2Ugc2VuZCB5b3VyIHJlcXVlc3RzIGZvciBwcmVzZW50YXRpb24gc2xvdCBieSAyLzIzLiBQbGVh c2UgaW5jbHVkZQ0KDQoNClRpdGxlOg0KRGVzY3JpcHRpb246DQpUaW1lOiANClByZXNlbnRlcnM6 DQpEcmFmdCBSZWZlcmVuY2UgKElmIGV4aXN0cyk6DQoNCg0KDQoNCg0KDQpSZWdhcmRzDQpTcmkN Cg0KDQpGcm9tOiBEYXBlbmcgTGl1IDxtYXhwYXNzaW9uQGdtYWlsLmNvbT4NCkRhdGU6IE1vbmRh eSwgSmFudWFyeSAyMywgMjAxNyBhdCAyOjA5IEFNDQpUbzogZG1tIDxkbW1AaWV0Zi5vcmc+DQpD YzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbT4NClN1YmplY3Q6IERNTSBJRVRG IDk4IG1lZXRpbmcNCg0KDQoNCkhlbGxvIGFsbCwgDQoNCg0KSUVURiA5OCBtZWV0aW5nIGlzIGFw cHJvYWNoaW5nLiBJZiB5b3Ugd2FudCB0byByZXF1ZXN0IGEgdGltZSBzbG90LCBwbGVhc2Ugc2Vu ZCByZXF1ZXN0IHRvIHRoZSBjaGFpcnMgYmVmb3JlIDIwMTctMDItMjMuDQoNCg0KDQoNClRoYW5r cywNCkRhcGVuZyAmIFNyaQ0K --=====003_Dragon772387233155_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAxLjE3NTE0Ij4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElW PkhlbGxvLCZuYnNwO1NyaSZuYnNwO2FuZCZuYnNwO0RhcGVuZyw8L0RJVj4NCjxESVY+SSZuYnNw O3dvdWxkJm5ic3A7bGlrZSZuYnNwO3RvJm5ic3A7cHJlc2VudCZuYnNwO3RoZSZuYnNwO01vYmls aXR5Jm5ic3A7QWJpbGl0eSZuYnNwO05lZ290aWF0aW9uJm5ic3A7ZHJhZnQmbmJzcDtpbiZuYnNw O3RoZSZuYnNwO0RNTSZuYnNwO21lZXRpbmc6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48Rk9O VCBjb2xvcj0jMDAwMDAwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xvcj0j MDAwMDAwPlRpdGxlOiZuYnNwO01vYmlsaXR5Jm5ic3A7QWJpbGl0eSZuYnNwO05lZ290aWF0aW9u PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+RGVzY3JpcHRpb246Jm5i c3A7RGlmZmVyZW50Jm5ic3A7bW9iaWxpdHkmbmJzcDttYW5hZ2VtZW50Jm5ic3A7cHJvdG9jb2xz Jm5ic3A7aGF2ZSZuYnNwO2RpZmZlcmVudCZuYnNwO2Z1bmN0aW9uYWwmbmJzcDtyZXF1aXJlbWVu dHMmbmJzcDtvbiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDAw PnRoZSZuYnNwO25ldHdvcmsmbmJzcDtlbGVtZW50Jm5ic3A7b3ImbmJzcDt0aGUmbmJzcDt0ZXJt aW5hbCZuYnNwO2FuZCZuYnNwO3RoZW4mbmJzcDthJm5ic3A7c2NoZW1lJm5ic3A7c2hvdWxkJm5i c3A7YmUmbmJzcDt1c2VkJm5ic3A7aW4mbmJzcDtvcmRlciZuYnNwO3RvJm5ic3A7c3VwcG9ydCZu YnNwO3RoZSZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPm5l Z290aWF0aW9uJm5ic3A7YW5kJm5ic3A7c2VsZWN0aW9uJm5ic3A7b2YmbmJzcDthZG9wdGVkJm5i c3A7bW9iaWxpdHkmbmJzcDttYW5hZ2VtZW50Jm5ic3A7cHJvdG9jb2wmbmJzcDt3aGVuJm5ic3A7 YSZuYnNwO3Rlcm1pbmFsJm5ic3A7YWNjZXNzZXMmbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIA0KY29sb3I9IzAwMDAwMD50byZuYnNwO2EmbmJzcDtuZXcmbmJzcDtuZXR3b3JrLiZuYnNw OyZuYnNwO1RoaXMmbmJzcDtkcmFmdCZuYnNwO2FuYWx5emVzJm5ic3A7dGhpcyZuYnNwO2lzc3Vl LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMD5UaW1lOiZuYnNwOzEwJm5i c3A7bWludXRlczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMD5QcmVzZW50 ZXJzOiZuYnNwO1poaXdlaSZuYnNwO1lhbjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpjb2xv cj0jMDAwMDAwPkRyYWZ0Jm5ic3A7UmVmZXJlbmNlJm5ic3A7KElmJm5ic3A7ZXhpc3RzKTpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFuLWRtbS1tYW4tMDAmbmJzcDs8L0ZPTlQ+ PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhhbmsmbmJzcDt5 b3UmbmJzcDtzbyZuYnNwO211Y2gmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7Y29uc2lkZXJhdGlv bi48L0RJVj4NCjxESVY+QlIsPC9ESVY+DQo8RElWPlpoaXdlaTwvRElWPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjIw MTctMDItMTYgPC9GT05UPjwvRElWPg0KPEhSIGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KDQo8RElW PjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz63orz+yMujujwvU1RST05HPiBTcmkg R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT1WZXJkYW5hPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiAyMDE3LTAyLTE2Jm5ic3A7 IDAwOjU4OjI2IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5h PjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gRGFwZW5nIExpdTsgZG1tIA0KPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+ IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPtb3 zOKjujwvU1RST05HPiBSZTogW0RNTV0gRE1NIElFVEYgOTggDQptZWV0aW5nIDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+IDwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj5HZW50bGUgUmVtaW5kZXIgLiBQbGVhc2Ug c2VuZCB5b3VyIHJlcXVlc3RzIGZvciBwcmVzZW50YXRpb24gc2xvdCBieSAyLzIzLiANClBsZWFz ZSBpbmNsdWRlPC9ESVY+DQo8RElWPjxCUj48L0RJVj4NCjxESVY+VGl0bGU6PC9ESVY+DQo8RElW PkRlc2NyaXB0aW9uOjwvRElWPg0KPERJVj5UaW1lOiZuYnNwOzwvRElWPg0KPERJVj5QcmVzZW50 ZXJzOjwvRElWPg0KPERJVj5EcmFmdCBSZWZlcmVuY2UgKElmIGV4aXN0cyk6PC9ESVY+DQo8RElW PjxCUj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPERJVj48QlI+PC9ESVY+DQo8RElWPlJlZ2Fy ZHM8L0RJVj4NCjxESVY+U3JpPC9ESVY+DQo8RElWPjxCUj48L0RJVj48U1BBTiBpZD1PTEtfU1JD X0JPRFlfU0VDVElPTj4NCjxESVYgDQpzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IFRFWFQtQUxJR046IGxlZnQ7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgRk9OVC1GQU1J TFk6IENhbGlicmk7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMXB0OyBCT1JERVItVE9QOiAj YjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6 IDNwdCI+PFNQQU4gDQpzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZyb206IDwvU1BBTj5EYXBl bmcgTGl1ICZsdDs8QSANCmhyZWY9Im1haWx0bzptYXhwYXNzaW9uQGdtYWlsLmNvbSI+bWF4cGFz c2lvbkBnbWFpbC5jb208L0E+Jmd0OzxCUj48U1BBTiANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9s ZCI+RGF0ZTogPC9TUEFOPk1vbmRheSwgSmFudWFyeSAyMywgMjAxNyBhdCAyOjA5IA0KQU08QlI+ PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5UbzogPC9TUEFOPmRtbSAmbHQ7PEEgDQpo cmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L0E+Jmd0OzxCUj48U1BBTiAN CnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6IDwvU1BBTj5TcmkgR3VuZGF2ZWxsaSAmbHQ7 PEEgDQpocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208 L0E+Jmd0OzxCUj48U1BBTiANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDogPC9T UEFOPkRNTSBJRVRGIDk4IG1lZXRpbmc8QlI+PC9ESVY+DQo8RElWPjxCUj48L0RJVj4NCjxESVY+ DQo8RElWPg0KPERJViBkaXI9bHRyPkhlbGxvIGFsbCwgDQo8RElWPjxCUj48L0RJVj4NCjxESVY+ SUVURiA5OCBtZWV0aW5nIGlzIGFwcHJvYWNoaW5nLiBJZiB5b3Ugd2FudCB0byByZXF1ZXN0IGEg dGltZSBzbG90LCBwbGVhc2UgDQpzZW5kIHJlcXVlc3QgdG8gdGhlIGNoYWlycyBiZWZvcmUmbmJz cDs8U1RST05HIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiB2ZXJkYW5hLGFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmOyBGT05ULVNJWkU6IDEycHgiPjIwMTctMDItMjMuPC9TVFJPTkc+PC9ESVY+DQo8 RElWPjxTVFJPTkcgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IHZlcmRhbmEsYXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IEZPTlQtU0laRTogMTJweCI+PEJSPjwvU1RST05HPjwvRElWPg0KPERJVj48 QlI+PC9ESVY+DQo8RElWPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHgiPjxCPjxGT05UIA0K ZmFjZT12ZXJkYW5hLHNhbnMtc2VyaWY+VGhhbmtzLDwvRk9OVD48L0I+PC9TUEFOPjwvRElWPg0K PERJVj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB4Ij48Qj48Rk9OVCBmYWNlPXZlcmRhbmEs c2Fucy1zZXJpZj5EYXBlbmcgJmFtcDsgDQpTcmk8L0ZPTlQ+PC9CPjwvU1BBTj48L0RJVj48L0RJ Vj48L0RJVj48L0RJVj48L1NQQU4+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon772387233155_=====-- From nobody Wed Feb 15 22:07:23 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 A5936129539; Wed, 15 Feb 2017 22:07:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148722523765.31523.10607119649998467390.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 22:07:17 -0800 Archived-At: Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] Spencer Dawkins' No Objection on draft-ietf-dmm-4283mnids-04: (with COMMENT) 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, 16 Feb 2017 06:07:17 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dmm-4283mnids-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'll watch the DISCUSSions from other ADs ... From nobody Thu Feb 16 02:05:13 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 0F6D91294DA for ; Thu, 16 Feb 2017 02:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Xal4ogFkQX2O for ; Thu, 16 Feb 2017 02:05:10 -0800 (PST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 9EF3912940E for ; Thu, 16 Feb 2017 02:05:10 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 02:05:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,168,1484035200"; d="scan'208,217";a="1095970068" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 16 Feb 2017 02:05:09 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 16 Feb 2017 02:05:09 -0800 Received: from HASMSX109.ger.corp.intel.com (10.184.198.21) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 16 Feb 2017 02:05:08 -0800 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.19]) by hasmsx109.ger.corp.intel.com ([169.254.3.162]) with mapi id 14.03.0248.002; Thu, 16 Feb 2017 12:05:05 +0200 From: "Moses, Danny" To: "Sri Gundavelli (sgundave)" , Dapeng Liu , dmm Thread-Topic: DMM IETF 98 meeting Thread-Index: AQHSh6y2rwe4di3NYkKCwIzXGRMf4KFrZfbw Date: Thu, 16 Feb 2017 10:05:04 +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_F0CF5715D3D1884BAC731EA1103AC28134AC4218HASMSX106gercor_" MIME-Version: 1.0 Archived-At: 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: Thu, 16 Feb 2017 10:05:12 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134AC4218HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Following is the info for the sessions I have requested: Title: On Demand Mobility Management Socket Extensions Description: Update on changes to the draft since IETF 97 Time: 15 minutes Presenter: Danny Moses Draft Reference: draft-ietf-dmm-ondemand-mobility-10 Title: On Demand DHCPv6 Extensions Description: Update on changes to the draft since IETF 97 Time: 10 minutes Presenter: Danny Moses Draft Reference: draft-moses-dmm-dhcp-ondemand-mobility-05 Thanks, Danny From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda= ve) Sent: Wednesday, February 15, 2017 18:58 To: Dapeng Liu ; dmm Subject: Re: [DMM] DMM IETF 98 meeting Gentle Reminder . Please send your requests for presentation slot by 2/23. = Please include Title: Description: Time: Presenters: Draft Reference (If exists): Regards Sri From: Dapeng Liu > Date: Monday, January 23, 2017 at 2:09 AM To: dmm > Cc: Sri Gundavelli > Subject: DMM IETF 98 meeting 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 --------------------------------------------------------------------- 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_F0CF5715D3D1884BAC731EA1103AC28134AC4218HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,

Following is the info for the session= s I have requested:

 

Title: O= n Demand Mobility Management Socket Extensions

Description: Update on changes to the draft since IETF 97

Time: 15= minutes

Presenter: Danny Moses

Dr= aft Reference: draft-ietf-dmm-ondemand-mobility-10

Title: O= n Demand DHCPv6 Extensions

Description: Update on  changes to the draft since IETF 97

Time: 10= minutes

Presenter: Danny Moses

Dr= aft Reference: draft-moses-dmm-dhcp-ondemand-mobil= ity-05

Thanks,

Danny

 

 

&nbs= p;

From: dmm [mailto:dmm-bounces@ietf.o= rg] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, February 15, 2017 18:58
To: Dapeng Liu <maxpassion@gmail.com>; dmm <dmm@ietf.org>= ;
Subject: Re: [DMM] DMM IETF 98 meeting

 

Gentle Reminder . Please send your requ= ests for presentation slot by 2/23. Please include

 

Title:

Description:

Time: 

Presenters:

Draft Reference (If exists):=

 

 

 

Regards

Sri

 

From: Dapeng Liu <maxpassion@gmail.com>
Date: Monday, January 23, 2017 at 2:09 AM
To: dmm <dmm@ietf.org>
Cc: Sri Gundavelli <sgundav= e@cisco.com>
Subject: DMM IETF 98 meeting

 

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,<= /o:p>

Dapeng & Sri

---------------------------------------------------------------------
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_F0CF5715D3D1884BAC731EA1103AC28134AC4218HASMSX106gercor_-- From nobody Thu Feb 16 04:25:15 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 0DDFA129ABB; Thu, 16 Feb 2017 04:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 M-_MLEy6ZGkE; Thu, 16 Feb 2017 04:25:08 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id A1028129AB8; Thu, 16 Feb 2017 04:25:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F0E562CEB1; Thu, 16 Feb 2017 14:25:06 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFfAbCOkf2kk; Thu, 16 Feb 2017 14:25:06 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 637782CCBA; Thu, 16 Feb 2017 14:25:06 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FBA5DC3F-7D37-4E73-B0E2-F91051675E0D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 14:25:05 +0200 Message-Id: <9FDE8001-485B-47F9-A05A-831680693868@piuha.net> References: <148589124578.6067.10086408452323670298.idtracker@ietfa.amsl.com> To: Dale Worley X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org, dmm@ietf.org Subject: Re: [DMM] [Gen-art] Review of draft-ietf-dmm-4283mnids-04 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: Thu, 16 Feb 2017 12:25:10 -0000 --Apple-Mail=_FBA5DC3F-7D37-4E73-B0E2-F91051675E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dale: Many thanks for this review, which indeed was exceptionally useful. = (=93Super=94 as Charlie put it.) I have placed a no-objection position for this document for tonight=92s = IESG telechat. But I think your discussion on the details of changes = inspired by Dale=92s review probably needs to continue, and I also see = that there are other points made by my AD colleagues =97 that is another = discussion that needs to finish. Jari --Apple-Mail=_FBA5DC3F-7D37-4E73-B0E2-F91051675E0D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYpZoiAAoJEM80gCTQU46qfEUQAKmmOFzjI9bnDohcwkO+U1pa JNE7yIB6O7gL233Mc5rIAXA6HzvuLLf0BEL3oxZMzKitl7gRdxiU+spANxgCr/Gx WpMDNFtXMa1Mh2rET0m2bQNI7/sHTFg14RfeH7PQIcV3jtVXGGhd/Zwou328s3Oo xyj5JNNuX83/FAdqiklk+DTdh80km1yagx3836MVnUaieYCBQrN0XD0odnuKrzRa 14n6Bb6hIsd4O2M3zntwqPM+UAsJVoTgaPmULQnnZ28eky/4ZnuRXYs8iCsaPjGR 0NLjjNqY4Av96qk076YiCB2c+BewRmlND9ZzquHGCpGjCBxAohX0G+8LokNB0rNs YWyT4nvi8i9a/nopFBagf0kLl/eVf6mszObuxU+k1epIUuygzEzJAlPbvGRSuj/p 8+MkKHIbd+gq85fH4tTQYicjxkDLTNUWibJAHIfarFxexYhtEtkQ5tkg+t2fOKwD rNy5+j/3iO+kz11Qv5ouOnu/pHCTKQpyLQTm7DRpNP/Nl96sX+dA/TA9HF2nlWF6 LPp2yr1D0rewYICb5kXXAgvWvey5eReuNUH/GKhQq2RALzpPWZesChiTHeBbMRYn 4P/E5oIhRSXO2Do6BOjakpdo/QJATdZlfRq5vCH3Ji+wcDfvAXWQ3RWu3CAl8KVv Rm2RtfguzVwT/OWQK6lT =R9VL -----END PGP SIGNATURE----- --Apple-Mail=_FBA5DC3F-7D37-4E73-B0E2-F91051675E0D-- From nobody Thu Feb 16 04:56: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 0C08C129495 for ; Thu, 16 Feb 2017 04:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 jarnAvvdfilb for ; Thu, 16 Feb 2017 04:56:23 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B3D129578 for ; Thu, 16 Feb 2017 04:56:23 -0800 (PST) Received: (qmail 30102 invoked from network); 16 Feb 2017 13:56:21 +0100 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Feb 2017 13:56:21 +0100 To: Charlie Perkins , Suresh Krishnan References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> <6a8360d0-f214-3b41-1529-b767e545793c@kuehlewind.net> <69ea2b13-de60-a8f7-ac48-62280dd93c69@earthlink.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 16 Feb 2017 13:56:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <69ea2b13-de60-a8f7-ac48-62280dd93c69@earthlink.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "max.ldp@alibaba-inc.com" , "draft-ietf-dmm-4283mnids@ietf.org" , "dmm-chairs@ietf.org" , The IESG , "dmm@ietf.org" Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-dm?= =?utf-8?q?m-4283mnids-04=3A_=28with_DISCUSS=29?= 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: Thu, 16 Feb 2017 12:56:26 -0000 Hi Charlie, okay, yes I think a MUST is the right thing to do here and I probably already enough. I'll clear my discuss now. Mirja On 16.02.2017 01:08, Charlie Perkins wrote: > Hello Mirja, > > My previous answer was intended to mean that I would change to MUST. > > Would you be willing to suggest some text about the non-leakage? I > thought that the point of strengthening to MUST was to ensure that > sensitive identifier information was not leaked. If there is something > more to be said, I'll be happy to say it. > > Regards, > Charlie P. > > > > On 2/15/2017 4:46 AM, Mirja Kühlewind wrote: >> Hi Charlie, >> >> can you please also answer the question below on SHOULD vs. MUST? Thanks! >> >> Also, does it maybe make sense to then add something in the security >> section that information should/must not be leaked to other networks? >> >> Thanks! >> Mirja >> >> >> On 13.02.2017 22:06, Charlie Perkins wrote: >>> Hello Mirja and Suresh, >>> >>> I am happy to make the proposed changes as agreed below. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote: >>>> Hi Suresh, >>>> >>>> sounds all good! I’m happy to quickly resolve my discuss if the >>>> authors agree! >>>> >>>> Mirja >>>> >>>> >>>>> Am 11.02.2017 um 05:05 schrieb Suresh Krishnan >>>>> : >>>>> >>>>> HI Mirja, >>>>> >>>>>> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind >>>>>> wrote: >>>>>> >>>>>> Mirja Kühlewind has entered the following ballot position for >>>>>> draft-ietf-dmm-4283mnids-04: Discuss >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>> this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> I would realy like to see the following changes in the security >>>>>> considerations section: >>>>>> OLD >>>>>> "If used in the MNID extension as defined in this >>>>>> document, the packet including the MNID extension should be >>>>>> encrypted >>>>>> so that personal information or trackable identifiers would not be >>>>>> inadvertently disclosed to passive observers." >>>>>> NEW >>>>>> "If used in the MNID extension as defined in this >>>>>> document, the packet including the MNID extension SHOULD be >>>>>> encrypted >>>>>> so that personal information or trackable identifiers would not be >>>>>> inadvertently disclosed to passive observers.” >>>>> Is this just for changing the "should" to upper case? I think that >>>>> makes sense. >>>>> >>>>>> Or even better make it a MUST? Is there a reason for only having a >>>>>> SHOULD? >>>>> Authors, any specific reason for this to be a SHOULD? >>>>> >>>>>> as well as the following change: >>>>>> OLD >>>>>> "Moreover, MNIDs containing sensitive identifiers might only be used >>>>>> for signaling during initial network entry. " >>>>>> NEW >>>>>> "Moreover, MNIDs containing sensitive identifiers MUST only be used >>>>>> for signaling during initial network entry and MUST NOT be >>>>>> leaked to >>>>>> other networks.” >>>>> The statement in OLD: is just a statement of fact that in some >>>>> networks use temporary identifiers for reattachment and they use >>>>> long term (and hence sensitive) identifiers only at initial attach. >>>>> I don’t think it makes sense to change this to 2119 language. >>>>> >>>>> Thanks >>>>> Suresh >>>>> >>>> >>> >> > From nobody Thu Feb 16 04:57:29 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 50F8D129495; Thu, 16 Feb 2017 04:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724984830.15981.4360298688629410121.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 04:57:28 -0800 Archived-At: Cc: max.ldp@alibaba-inc.com, draft-ietf-dmm-4283mnids@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org Subject: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-dmm-4283mnids-04=3A_=28with_COMMENT=29?= 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, 16 Feb 2017 12:57:28 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dmm-4283mnids-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Author agreed to do the following change in the security considerations section: OLD "If used in the MNID extension as defined in this document, the packet including the MNID extension should be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers." NEW "If used in the MNID extension as defined in this document, the packet including the MNID extension MUST be encrypted so that personal information or trackable identifiers would not be inadvertently disclosed to passive observers." From nobody Thu Feb 16 14:11:48 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 9C956129577 for ; Thu, 16 Feb 2017 14:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=pdx-edu.20150623.gappssmtp.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 BTmTxL1ECid9 for ; Thu, 16 Feb 2017 14:11:44 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 74DAD129556 for ; Thu, 16 Feb 2017 14:11:44 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id k15so26927221qtg.3 for ; Thu, 16 Feb 2017 14:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pdx-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=j/5YapduC3eia4V64D58ZGS4LfSt++5JX6NxzRB8BuY=; b=xltbxMlpFGaSVWahrl26GRgDrXAN83OfKevd0fBhZWW0i39soGsdoYD1CZHtSJOh5S tr4Eqgcvb42y3mtT43yg/ewJN0iAtCxo6HYlUzhZ5kc88FgF3YFwKBU9E//rzVIbw27d MTSbvdNNa2IOrNgIYg3u/qRbZQ/nWBmTXumTiIqK6CUDMm6iuZEhVaj9e0oY+egcNth/ qD7oU5/jbz4ypycHSfjVYRc+SucKYd9ykftcb/Je5Ql7wPijK2mjwN2SJFUpBi26q4uk IqL6K1odqgLZTopFDyY9BQ6VQSaPbgkQv4UJ7IsbOMJifI2AxBkxClsbSKvsr7aFTUdf jvgA== 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:from:date:message-id:subject :to; bh=j/5YapduC3eia4V64D58ZGS4LfSt++5JX6NxzRB8BuY=; b=NCltdhtAl95AyQClr7zVqaqcIcBLyMgy6tsb0y3Sjda1u/AfrH3EyxHZO5J3JEj81p 2Zr9TsZFco3TUlG2SKV9YFY3OZwRxBeCT3fZ3+Wp9NqGkEfJE9FqWYto8WS584x+zxe+ s3P6OI9OXDZ/JjoONU8xO2ch7UI9f4Y3jdCY/bmmUsOW9rc+Do/Sb9tFVpaV17XfbkA3 fDHvqGWCbgSUZh7bppUWZihGdvmwJEStSf86C05vSni6yjGCRq2CYkMVHaqwoTRfQV/S E12qc3SqlBYQhNrh83lxOUCy6zOkKUbtq1hWpNxkM5oCT5uTk1OJRB4ayCeUDgETqs3p h2cQ== X-Gm-Message-State: AMke39n4LAnqUxhmk2wfXNKjuYXzUeJoSR/aq6CxbolrCl3D0rQq+L3N985PTscFYHUL0tKUf2RlAJrZCvLy1MdO X-Received: by 10.237.38.133 with SMTP id q5mr4230990qtd.21.1487283103501; Thu, 16 Feb 2017 14:11:43 -0800 (PST) MIME-Version: 1.0 Sender: wuchi@pdx.edu Received: by 10.200.43.169 with HTTP; Thu, 16 Feb 2017 14:11:03 -0800 (PST) From: Wu-chi Feng Date: Thu, 16 Feb 2017 14:11:03 -0800 X-Google-Sender-Auth: Y20_gUdef7b4_rpsC_bgsK5ZqNs Message-ID: To: sgundave@cisco.com, maxpassion@gmail.com, dmm@ietf.org Content-Type: multipart/alternative; boundary=001a114dabae10a0d90548ad1546 Archived-At: 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: Thu, 16 Feb 2017 22:11:46 -0000 --001a114dabae10a0d90548ad1546 Content-Type: text/plain; charset=UTF-8 Sri / Dapeng, I would like to allocate a 10 minute slot. Please see the required information below. Title: ICMPv6 RA/RS extensions for On-Demand Mobility Description: To discuss whether there is interest from the group to look at on-demand mobility extensions for the ICMPv6 Router Advertisement / Router Solicitation messages. Time: 10 minutes Presenter: Wu-chi Feng Thanks, Wu-chi --001a114dabae10a0d90548ad1546 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sri / Dapeng,

I would like to allocate a 1= 0 minute slot. Please see the required information below.

= =C2=A0

= Title: ICMPv6 RA/RS extensions for On-Demand Mobility

= Description: To discuss whether there is interest from the group to look at on-demand mobility extensions for the ICMPv6 Router Advertisement / Router Solicitation messages.

= Time: 10 minutes

= Presenter: Wu-chi Feng

= =C2=A0

= Thanks,

= Wu-chi

--001a114dabae10a0d90548ad1546-- From nobody Tue Feb 21 22:58:54 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 DD6D01294D5; Tue, 21 Feb 2017 22:58:52 -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.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148774673290.16706.4569151626444979623.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2017 22:58:52 -0800 Archived-At: Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-deployment-models-01.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, 22 Feb 2017 06:58:53 -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 : DMM Deployment Models and Architectural Considerations Authors : Sri Gundavelli Seil Jeon Filename : draft-ietf-dmm-deployment-models-01.txt Pages : 15 Date : 2017-02-21 Abstract: This document identifies the deployment models for Distributed Mobility Management architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-deployment-models/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmm-deployment-models-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-deployment-models-01 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 Feb 24 16:51:09 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 13F32129609 for ; Fri, 24 Feb 2017 16:51:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TLX_GPyyX9-H for ; Fri, 24 Feb 2017 16:51:06 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 E0010129605 for ; Fri, 24 Feb 2017 16:51:05 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id 1so17762891pgi.1 for ; Fri, 24 Feb 2017 16:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T9V5uFx9Yc7sfFOdDE8VLLvF40KdhLajYAszCmEWU1w=; b=maHPAKQq1dzdKmZXja8+1D+D0AXx0tKtSDuEKo0I36e1kbK6y0pOg2ntLkGl23BYPb OqBj35T5HjkJ+PlNWoXJ0HBd3y4eJN+K8byFKhquKEi2sQbYLkjG7kkxLxKu4kQQ3MdY hiq4n0t3wJ4mdoFm+t4l7lR2xjxioS5GrP++mMnC+pQCvt4dyAuYh5IYehIZ1hODcRkU N8lDUsSCVnf9N/4WexOwSo4iyvzI6TJVBsllKSEYSsECHt36v7VizD1OfmMRaIOLJiPT LTEr4fIxIfcnt4yeHcdY1846j3yZNOSANfH21tpMRl+TI1Uu+/wW/YbsmQqiIQNxUMHM 2G7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T9V5uFx9Yc7sfFOdDE8VLLvF40KdhLajYAszCmEWU1w=; b=BCaXpykQkfHhs+xky3TcH9Q19Z0zIQTP9uZZ51pawBM9O/c8eITJ7Xva6qWeRnFSAC J1khpqStK949bgk+OoqROBwjdPUb5c8D18nvKIfRYWOsznUhdfGLS2Es84hX7WObaABn YawXOB0+rS8hTaoXBGNxowQLe24zQgoHdfbp0O81mpw8tIG9HYujIQZK6R+YGkWgzlH5 WvPsC7KIR6RTZgtavU1O1e6NEU3Ju3IWWV4VbB9k+hwuEnY2GcKwF+BZ+luCmV/snOSz wKJCPejejLax93i+/Ho8UH2FoZiydwj3vgrI4JKyCN8nG9hzPi/VScSkk3BVALFQ+rtp cAHg== X-Gm-Message-State: AMke39nrPYC9/kle7CtqGnTdi8oKW4yPYbML10S/f8ywDp1qDSBmKpD2BmduxcJYZjVfHw== X-Received: by 10.98.137.84 with SMTP id v81mr6935463pfd.93.1487983865476; Fri, 24 Feb 2017 16:51:05 -0800 (PST) Received: from [172.16.102.154] (p202132-ipngn3301niigatani.niigata.ocn.ne.jp. [180.28.197.132]) by smtp.gmail.com with ESMTPSA id 202sm11849039pfw.63.2017.02.24.16.51.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Feb 2017 16:51:04 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: Date: Sat, 25 Feb 2017 09:51:02 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <63B69434-D0AE-4228-897E-6AF482D27926@gmail.com> References: To: Dapeng Liu X-Mailer: Apple Mail (2.3124) 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: Sat, 25 Feb 2017 00:51:08 -0000 Hi, Sorry for the late that I=E2=80=99d request a 10min slot to present fpc = update. Regards, --satoru > 2017/01/23 19:09=E3=80=81Dapeng Liu = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > Hello all, >=20 > IETF 98 meeting is approaching. If you want to request a time slot, = please send request to the chairs before 2017-02-23. >=20 >=20 > Thanks, > Dapeng & Sri > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Feb 28 01:47:32 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 96A50126FDC; Tue, 28 Feb 2017 01:47:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148827524557.30763.8868773089488417428.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 01:47:25 -0800 Archived-At: Cc: draft-ietf-dmm-hnprenum@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, max.ldp@alibaba-inc.com Subject: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-hnprenum-06: (with DISCUSS and COMMENT) 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, 28 Feb 2017 09:47:25 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dmm-hnprenum-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this should be an easy one to resolve: Section 7 says: "The protection of UPN and UPA messages in this document follows [RFC5213] and [RFC7077]." I'm not clear if "follows" means the same as "MUST be protected using end-to-end security association(s) offering integrity and data origin authentication" (RFC5213, section 4). I think it ought really, as otherwise this could subvert the security of PMIPv6. So wouldn't it make sense to be explicit that these new messages have the same MUST requirements as binding updates. Doing that by repeating the quoted text from 5213 would be a fine way to do that, but there may be better options. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - It might also be worth saying in section 7 that to provision a new HNP someone has to have setup all the IPsec stuff for that. From nobody Tue Feb 28 07:14:00 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 1FD22129574; Tue, 28 Feb 2017 07:13:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148829483808.30803.4812519886917921762.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 07:13:58 -0800 Archived-At: Cc: draft-ietf-dmm-hnprenum@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, max.ldp@alibaba-inc.com Subject: [DMM] Alissa Cooper's No Objection on draft-ietf-dmm-hnprenum-06: (with COMMENT) 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, 28 Feb 2017 15:13:58 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dmm-hnprenum-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the abstract, I would suggest s/as an update of the PMIPv6 specification./as an optional extension of the PMIPv6 specification./ to be crystal clear that this is not a formal update. From nobody Tue Feb 28 10:08:16 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 88F611295D2; Tue, 28 Feb 2017 10:08:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148830529153.29560.16824896223628363778.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2017 10:08:11 -0800 Archived-At: Cc: draft-ietf-dmm-hnprenum@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, max.ldp@alibaba-inc.com Subject: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-dmm-hnprenum-06=3A_=28with_COMMENT=29?= 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, 28 Feb 2017 18:08:11 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dmm-hnprenum-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-hnprenum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document has a 2119 boilerplate but doesn't use normative language. I think it would actually be good to use normative language! Minor questions: - secion 4: "This temporary binding should only be used for the downwards packet transmission" By downward you mean 'to the MN', right? Why is this? Does that actually help in any scenario? - I'm not sure why section 3 is titled 'PMIPv6 Extensions'...? From nobody Tue Feb 28 13:32:45 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 30F1F129532; Tue, 28 Feb 2017 13:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] 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 yM0ITcY04gDs; Tue, 28 Feb 2017 13:32:39 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB6C1296FB; Tue, 28 Feb 2017 13:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1488317559; bh=fPffHNMWVirREtcdvQaSolRTQmh+jJi2wab6 n3IkerI=; h=Received:From:Subject:To:References:Cc:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace: X-Originating-IP; b=jOxgeg0C0WWkCfqamnD7ruCqqZGxEvzIgvHoRWwUr3mYsg ANviG1p1gOdd7xfcs5PsVUD6kAFV/ceQOiPS1QPw3vYBx6d/vB86RRtX2yBIWHRuf+6 Qbi9Yh0gBkLqBpJd2kmjyDqVyOysGFc9h2B05YQ91ZxiOo5WNrfAgDjHjCS7gZUJpPW g6FlTcAFgHYAo9Gf1UkJV1OjyhD30Kviv5Mea1aV++OnALm2jf5fR8SGq01s/MnCG3i 2YrpPwLof6qBgsWLDCF3csE9T7R2kOKjFXX+AJ+4cuxnWQ4RWvxCinEPgaGG6DFVlfW +DyrGaGEYF7fX8czBn7ew9954OAw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=jPNoZLRnVFaYjb4dy7k6bQYiSGMYxBAfKFxfpbd5mtGTIyaSxt5kjaV3fGYyfJEftWPE0S395miNEcRPexxTqJf3VXNuNYMeFKKgU1AfqKjpxT4G18NK1AOrsDfDzyMb/hlplGvbIe8fXmvoh5rbA6Aw3ppEAkZ8ZBrw2ijgidt5N5vYsbyD4BFY06s2KRP5XCg6ffvXnAdcJSRKbdNl/GNfs2zNfrlyCcf0K/BxJMEGKT3LKnq2y5B58A72aM/fdx2FdRvKFHU7/BSK3apKkapA31Y233Or4rzGRa9B6qnkvriIlIoECzmns0ABrcCvChF9u3EYZADzt9QkjtI4Kg==; h=Received:From:Subject:To:References:Cc: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-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cipNh-0007q7-TX; Tue, 28 Feb 2017 16:32:26 -0500 From: Charlie Perkins To: dmm@ietf.org References: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com> Message-ID: <8a2e5094-228e-2848-7f6c-a911d3375291@earthlink.net> Date: Tue, 28 Feb 2017 13:32:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148720843433.31432.10415791688976362439.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------149FDB785DEF86B4EA5CD548" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7c48b874c56c2c2fcb81b7508dafb64cb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: dmm-chairs@ietf.org Subject: Re: [DMM] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT) 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, 28 Feb 2017 21:32:42 -0000 This is a multi-part message in MIME format. --------------149FDB785DEF86B4EA5CD548 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello folks, It has been suggested that the dmm WG members should to provide more support for the inclusion of the MNIDs that are listed in draft-ietf-dmm-4283mnids-04. In order to resolve this issue, please send discussion to the [dmm] mailing list with thoughts about which of the types proposed in the draft are likely to require considerations about privacy when used in the Mobile Node Identifier option. Also, for the proposed types, it has been requested to make some discussion about how their inclusion will help to improve the Internet. Thanks in advance, Charlie P. On 2/15/2017 5:27 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-dmm-4283mnids-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I don't consider that merely mentioning that there are some > privacy issues (maybe) is nearly sufficient here. Instead I > would argue that any of these identifier types that could have > privacy implications need to be specifically justified or else > dropped. By specifically justified, I mean that there ought be > an argument (and a fairly holistic one) that the Internet is > better, and not worse, if we define a codepoint that allows > MIPv6 (and later, other protocols) to use that identifier. I > do accept that my position is perhaps innovative, in terms of > IETF processes, so I'll split the discuss into two parts, one > process oriented and mostly for the IESG, and the second > relating to the content of the draft. > > (1) For the IESG: is it ok that we introduce (codepoints for) > a slew of new long-term stable privacy-sensitive identifiers > just because they might someday be needed, or do we need to > have specific justification for defining such things? I would > argue the latter, but that may need us to validate that there > is IETF consensus for that somehow, and perhaps in the > meantime hold on to this draft. Part of my reasoning is that > once we define such codepoints (e.g. for IMSIs) then that > inevitably means that other protocols, and not just MIPv6, > will do the same eventually, so accepting this draft basically > means accepting that we end up commonly and perhaps > carelessly, passing such highly-sensitive information about on > the Internet in many protocols and in many contexts. My > argument here I think does adhere to various of our BCPs that > do argue for security and privacy, but I do also accept that > this may be novel and to some extent goes against another of > our generally accepted ideas which is that we benefit from > folks documenting things even if those things are sub-optimal > in various ways. So I'd argue this is a real case for an IESG > discussion - I know what I think, but what do the rest of you > think? > > (2) For the authors: to the extent you are willing to, and > want to get ahead of the discussion on point (1) above, can > you in fact provide an argument, for each of the identifiers > here that have privacy-sensitivity, that the Internet is better > overall if we define these codepoints knowing that if we do > define a way to represent e.g. an IMSI in MIPv6 that is likely > to be copied elsewhere? Note for the authors: I think it's > entirely fine for you to do nothing pending the discussion of > point (1) above, if that's your preference. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > While I'm entirely sympathetic to Mirja's discuss point, I > don't think that a statement here can really constrain how > these identifiers, once they are defined, are used in other > protocols. While there is a chance that some IESG sometime > might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt > if identifier is used" the chances that a future IESG > notice this isn't that high, but it's also even more likely > that the designers of future protocols will successfully argue > that since not all identifiers are privacy sensitive, their > specific protocol need not adhere to the SHOULD. In the end, I > think that should or SHOULD will be ineffective. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --------------149FDB785DEF86B4EA5CD548 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello folks,

It has been suggested that the dmm WG members should to provide more support for the inclusion of the MNIDs that are listed in draft-ietf-dmm-4283mnids-04.

In order to resolve this issue, please send discussion to the [dmm] mailing list with thoughts about which of the types proposed in the draft are likely to require considerations about privacy when used in the Mobile Node Identifier option. Also, for the proposed types, it has been requested to make some discussion about how their inclusion will help to improve the Internet.

Thanks in advance,
Charlie P.

On 2/15/2017 5:27 PM, Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-dmm-4283mnids-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I don't consider that merely mentioning that there are some
privacy issues (maybe) is nearly sufficient here.  Instead I
would argue that any of these identifier types that could have
privacy implications need to be specifically justified or else
dropped. By specifically justified, I mean that there ought be
an argument (and a fairly holistic one) that the Internet is
better, and not worse, if we define a codepoint that allows
MIPv6 (and later, other protocols) to use that identifier.  I
do accept that my position is perhaps innovative, in terms of
IETF processes, so I'll split the discuss into two parts, one
process oriented and mostly for the IESG, and the second
relating to the content of the draft.

(1) For the IESG: is it ok that we introduce (codepoints for)
a slew of new long-term stable privacy-sensitive identifiers
just because they might someday be needed, or do we need to
have specific justification for defining such things? I would
argue the latter, but that may need us to validate that there
is IETF consensus for that somehow, and perhaps in the
meantime hold on to this draft. Part of my reasoning is that
once we define such codepoints (e.g. for IMSIs) then that
inevitably means that other protocols, and not just MIPv6,
will do the same eventually, so accepting this draft basically
means accepting that we end up commonly and perhaps
carelessly, passing such highly-sensitive information about on
the Internet in many protocols and in many contexts.  My
argument here I think does adhere to various of our BCPs that
do argue for security and privacy, but I do also accept that
this may be novel and to some extent goes against another of
our generally accepted ideas which is that we benefit from
folks documenting things even if those things are sub-optimal
in various ways. So I'd argue this is a real case for an IESG
discussion - I know what I think, but what do the rest of you
think?

(2) For the authors: to the extent you are willing to, and
want to get ahead of the discussion on point (1) above, can
you in fact provide an argument, for each of the identifiers
here that have privacy-sensitivity, that the Internet is better
overall if we define these codepoints knowing that if we do
define a way to represent e.g. an IMSI in MIPv6 that is likely
to be copied elsewhere? Note for the authors: I think it's
entirely fine for you to do nothing pending the discussion of
point (1) above, if that's your preference.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


While I'm entirely sympathetic to Mirja's discuss point, I
don't think that a statement here can really constrain how
these identifiers, once they are defined, are used in other
protocols. While there is a chance that some IESG sometime
might say "hold on, RFCxxxx (this doc) says you SHOULD encrypt
if <that> identifier is used" the chances that a future IESG
notice this isn't that high, but it's also even more likely
that the designers of future protocols will successfully argue
that since not all identifiers are privacy sensitive, their
specific protocol need not adhere to the SHOULD. In the end, I
think that should or SHOULD will be ineffective.


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

--------------149FDB785DEF86B4EA5CD548--