From fred@cisco.com Sun Sep 1 11:00:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8933811E8218 for ; Sun, 1 Sep 2013 11:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZtTssXikvVZ for ; Sun, 1 Sep 2013 11:00:16 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6B11E8217 for ; Sun, 1 Sep 2013 11:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=628; q=dns/txt; s=iport; t=1378058416; x=1379268016; h=date:from:message-id:to:subject:cc; bh=u8mF6lf4rLYP9xt4DrQzx8Te4Nsew4b+d/Qu8Wm8nmc=; b=mlYbgs24fGNQ4LuzRb2Pq5N57F8illYveGH9sod/ebcLekA/BufJ/7RC 3ktZuGhuqhUygjh8rACqolQeodlxK8utIs9qAaF1YQFr5oBh0hBfCtV+M wGmlfBLyYNW9d2BSTgLmlsbOiJSet3mdJYq4+9Up3ORcbLjdA3PQj+iS/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEKAPl/I1KrRDoG/2dsb2JhbABZgwc1gzGraQGSIoEeFnSDJDw0iGINuSaPfx2EBwOJNY9vkDeDQA X-IronPort-AV: E=Sophos;i="4.89,1002,1367971200"; d="scan'208";a="88234127" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 01 Sep 2013 18:00:13 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r81I0C9G008265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Sep 2013 18:00:12 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r81I0ATI006747; Sun, 1 Sep 2013 11:00:11 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r81I0Ao1006741; Sun, 1 Sep 2013 11:00:10 -0700 (PDT) Date: Sun, 1 Sep 2013 11:00:10 -0700 (PDT) From: Fred Baker Message-Id: <201309011800.r81I0Ao1006741@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-nat64-experience WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 18:00:21 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From internet-drafts@ietf.org Mon Sep 2 00:33:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D136311E811D; Mon, 2 Sep 2013 00:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWfc6oou9Mwz; Mon, 2 Sep 2013 00:33:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B725C11E80E7; Mon, 2 Sep 2013 00:33:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130902073311.11904.66391.idtracker@ietfa.amsl.com> Date: Mon, 02 Sep 2013 00:33:11 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 07:33:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-04.txt Pages : 19 Date : 2013-09-02 Abstract: As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From randy@psg.com Mon Sep 2 02:39:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CC211E81D9; Mon, 2 Sep 2013 02:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UT0WNCjF9TN; Mon, 2 Sep 2013 02:39:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id E576D21E80A1; Mon, 2 Sep 2013 02:39:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VGQbJ-0000G3-5Y; Mon, 02 Sep 2013 09:39:13 +0000 Date: Mon, 02 Sep 2013 18:39:12 +0900 Message-ID: From: Randy Bush To: IPv6 Deployment Prevention , V6 Ops List User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [v6ops] frag success, or not X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 09:39:32 -0000 be sure to understand footnote. almost 10% of the atlas probes which think they have ipv6 connectivity actually do not. so one has to subtract that 9.94% from all entries in fail% column. if you are unfamiliar with the ncc atlas project, grab your board and go to https://atlas.ripe.net/ randy --- Message-ID: <5223A4CE.9090505@ripe.net> Date: Sun, 01 Sep 2013 22:34:22 +0200 From: Emile Aben To: Randy Bush CC: nanog@nanog.org Subject: Re: IP Fragmentation - Not reliable over the Internet? On 31/08/2013 13:13, Randy Bush wrote: > could you please test with ipv6? This is what I see for various IPv6 payloads (large ICMPv6 echo requests) from all RIPE Atlas probes that where available at the time to a single "known good" MTU 1500 destination: plen fail% nr_probes 100 9.64 1266 500 9.34 1039 1000 9.94 1298 1240 9.94 1308 1241 11.62 1300 1440 12.70 890 1441 14.70 1306 1460 15.18 1304 1461 19.84 1290 1462 22.02 1294 plen: IPv6 payload length (ie. not including 40byte IPv6 header) fail%: percentage of probes that didn't get any of the 5 pkts that were sent. Note that there is a large baseline failure rate in IPv6 on RIPE Atlas probes [1], which would explain the ~10% failure rate for the smaller packets. I plan to do more analysis and start writing this up on RIPE Labs over the next few days. cheers, Emile Aben RIPE NCC [1] https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-believe-they-have-ipv6-but-are-wrong From otroan@employees.org Mon Sep 2 02:48:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE021E80E7; Mon, 2 Sep 2013 02:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL0Xnu9879wS; Mon, 2 Sep 2013 02:48:21 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D37D821E80CA; Mon, 2 Sep 2013 02:48:20 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAHxdJFKQ/khM/2dsb2JhbABagwc1wUWBIhZ0giQBAQEDAQEBAWsLBQsLEQMBAgEuJygIBhOHfAYMuREEj24RBwaDF4EAA5AjmTiDIjo X-IronPort-AV: E=Sophos;i="4.89,1006,1367971200"; d="asc'?scan'208";a="86333354" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Sep 2013 09:48:19 +0000 Received: from dhcp-lys01-vla250-10-147-113-165.cisco.com (dhcp-lys01-vla250-10-147-113-165.cisco.com [10.147.113.165]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r829mHS7029240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Sep 2013 09:48:17 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_6EE7D9B2-E036-40C3-9232-515B6D5DC20D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: Date: Mon, 2 Sep 2013 11:48:17 +0200 Message-Id: <4C136504-0D56-4B14-83C8-B1C5F0160630@employees.org> References: To: Randy Bush X-Mailer: Apple Mail (2.1508) Cc: V6 Ops List , IPv6 Deployment Prevention Subject: Re: [v6ops] frag success, or not X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 09:48:27 -0000 --Apple-Mail=_6EE7D9B2-E036-40C3-9232-515B6D5DC20D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > be sure to understand footnote. almost 10% of the atlas probes which > think they have ipv6 connectivity actually do not. so one has to > subtract that 9.94% from all entries in fail% column. >=20 > if you are unfamiliar with the ncc atlas project, grab your board and = go > to https://atlas.ripe.net/ I don't quite understand what he is testing? just sending large packets? or as the subject says, fragmented packets? or path MTU discovery? cheers, Ole > Message-ID: <5223A4CE.9090505@ripe.net> > Date: Sun, 01 Sep 2013 22:34:22 +0200 > From: Emile Aben > To: Randy Bush > CC: nanog@nanog.org > Subject: Re: IP Fragmentation - Not reliable over the Internet? >=20 > On 31/08/2013 13:13, Randy Bush wrote: >> could you please test with ipv6? >=20 > This is what I see for various IPv6 payloads (large ICMPv6 echo > requests) from all RIPE Atlas probes that where available at the time = to > a single "known good" MTU 1500 destination: >=20 > plen fail% nr_probes > 100 9.64 1266 > 500 9.34 1039 > 1000 9.94 1298 > 1240 9.94 1308 > 1241 11.62 1300 > 1440 12.70 890 > 1441 14.70 1306 > 1460 15.18 1304 > 1461 19.84 1290 > 1462 22.02 1294 >=20 > plen: IPv6 payload length (ie. not including 40byte IPv6 header) > fail%: percentage of probes that didn't get any of the 5 pkts that = were > sent. Note that there is a large baseline failure rate in IPv6 on RIPE > Atlas probes [1], which would explain the ~10% failure rate for the > smaller packets. >=20 > I plan to do more analysis and start writing this up on RIPE Labs over > the next few days. >=20 > cheers, > Emile Aben > RIPE NCC >=20 >=20 > [1] > = https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-be= lieve-they-have-ipv6-but-are-wrong > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_6EE7D9B2-E036-40C3-9232-515B6D5DC20D 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 iQEcBAEBCgAGBQJSJF7hAAoJEFuJXizso86gGRsIAIk6oCaBmTak5r12cZFKpkQT KDmW+6ebUpHi2i+57wE8JFXw6vAX74mhIp3niRffTyzmeBzjjwkTBAhnI595ScGK R6K9FNnBPfg50BXDpEhH6k8kQdi7Ve0alfFQvyaBl5Xvo5lTuBpESSoF8FcarE/j Lq/Z7feIjY2S81DeZ7k0P8baV863xV0wZRJ6PNvQEEm4dpORSnU6mtko1KILVHjx BgT8UWZVh9Nr4UKbGyuP9ObtZ8uY8QuCp9oveIW2qarCGHtEiMKab61JSQ+oUwnd lnmTCt4IR/0U1fuJWsaKyzE5IZUfycCEAeb1QyvtnNSCIoCv5vIoxPfdJhmaGn0= =ziPl -----END PGP SIGNATURE----- --Apple-Mail=_6EE7D9B2-E036-40C3-9232-515B6D5DC20D-- From randy@psg.com Mon Sep 2 02:51:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B77221F8948; Mon, 2 Sep 2013 02:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAEKdt4fp9yJ; Mon, 2 Sep 2013 02:51:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 236CB21E80EC; Mon, 2 Sep 2013 02:51:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VGQmk-0000HC-Ug; Mon, 02 Sep 2013 09:51:03 +0000 Date: Mon, 02 Sep 2013 18:51:01 +0900 Message-ID: From: Randy Bush To: Ole Troan In-Reply-To: <4C136504-0D56-4B14-83C8-B1C5F0160630@employees.org> References: <4C136504-0D56-4B14-83C8-B1C5F0160630@employees.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: V6 Ops List , IPv6 Deployment Prevention Subject: Re: [v6ops] frag success, or not X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 09:51:13 -0000 > I don't quite understand what he is testing? > just sending large packets? > or as the subject says, fragmented packets? > or path MTU discovery? >> This is what I see for various IPv6 payloads (large ICMPv6 echo >> requests) beyond that, emile would have to speak for himself randy From nalini.elkins@insidethestack.com Mon Sep 2 10:58:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A563421F9AA2 for ; Mon, 2 Sep 2013 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04lsf9qWjASD for ; Mon, 2 Sep 2013 10:58:15 -0700 (PDT) Received: from nm18-vm7.access.bullet.mail.gq1.yahoo.com (nm18-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.196]) by ietfa.amsl.com (Postfix) with ESMTP id A312011E8138 for ; Mon, 2 Sep 2013 10:58:10 -0700 (PDT) Received: from [216.39.60.172] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 02 Sep 2013 17:58:10 -0000 Received: from [216.39.60.242] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 02 Sep 2013 17:58:10 -0000 Received: from [127.0.0.1] by omp1013.access.mail.gq1.yahoo.com with NNFMP; 02 Sep 2013 17:58:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 130393.53613.bm@omp1013.access.mail.gq1.yahoo.com Received: (qmail 3526 invoked by uid 60001); 2 Sep 2013 17:58:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1378144689; bh=A8Wtbu1hIbH1XBykvuMTxWsRBVOwfS5O5gGu69oP6/0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zAouAm6nnjxNGuSBSjyY/fTyym5ysPsGaE3g8qjmIZNgwDiAQODKQHOuu5IDhUPlL9aqqTGgemf6s1aD9ekTIuQBJLz83R4r9USpGZ6JH0gIm1Ahv+UtRGxd17aJGe7xFfarXLH22ReW/n+n0nM1+qODVq/r1u0/BGS2w1qeIDs= X-YMail-OSG: 4xMlHQQVM1n7FC6OD0nGiOqz3PEnt.npqE1w05812pyhfk6 M8FIY7vqo5.jkhnJmgeMiF.1abGB4zxa0mrCZoreN2SGrVQRmBvOxPkJwe8B YXVNJrx._B1fcTzWGIgXRQxlDEY1gmfOk_hObTZuKoCiutFeYOAvk_U0EyLh lKT5S_p30VgfFX3kaF68jzs24ShWDAOBfR.0N_O6tWpgNHq6NupBLPnrQh5z PAIm9Lwz.EIt0YlsBhjDwrGIaUBeBnaWuQ.PhxCnEqYcrbxVkx13tB7NGSH3 gLnyJoBiU7FeXapXKf1A9Xz9BIsFvaaHVALSadxihGx8eCqJoijrx9zuX5oK 0IUlEuKdLa_IXGuk1.8YEXT6G3JBV0ki3MbKPoYFZf7MlSGKWBUx5yikP4PF vKd6DzuW5EiSdio0C80Gm.OHLW0kgFgQu9Xts6WCsV1GzR_dX7VEnlKi4nKO uYPAi5I1aDsatR_5BWxHsmcp5i.lk3R1gDl.4MohnTILeopKkatTtRMowVx0 L.CGa5qP_LXp32ijtpB7EXcJmryxQqCFWtMtC4v0Wasmop6hGmS95WuxkQI1 SC7rFw.ze1A-- Received: from [70.198.67.136] by web2805.biz.mail.ne1.yahoo.com via HTTP; Mon, 02 Sep 2013 10:58:09 PDT X-Rocket-MIMEInfo: 002.001, Cgo.Cj5UaGUgaXNzdWUgaXMgYWxsIG9mIHRoZSBzeXN0ZW1zIHdoZXJlIHJlc3BvbnNlIHRpbWVzIERPIG1hdHRlci7CoCBUaG9zZSBjbG9ja3MgZG8gZ2V0IHN5bmNocm9uaXplZCBhbHJlYWR5LCBiZWNhdXNlIHRoZXJlIGlzIGEgbmVlZCB0aGF0IGp1c3RpZmllcyB0aGUgZWZmb3J0IHJlcXVpcmVkIHRvIGRvIHNvLsKgIFRoZSBjaGFsbGVuZ2UgdGhlbiBiZWNvbWVzLCBIb3cgZG8gd2UgbWVhc3VyZSB0cmFuc21pc3Npb24gdGltZXMgYmV0d2VlbiB0aG9zZSBzeXN0ZW1zIG9uY2UgdGhleSBjb252ZXJ0IHQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1377967684.21896.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1378008571.34695.YahooMailNeo@web142506.mail.bf1.yahoo.com> Message-ID: <1378144689.2775.YahooMailNeo@web2805.biz.mail.ne1.yahoo.com> Date: Mon, 2 Sep 2013 10:58:09 -0700 (PDT) From: Nalini Elkins To: Mark ZZZ Smith , Bill Jouris , Randy Bush In-Reply-To: <1378008571.34695.YahooMailNeo@web142506.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1619178251-578216388-1378144689=:2775" Cc: IPv6 Ops WG , Al Morton Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Nalini Elkins List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 17:58:21 -0000 --1619178251-578216388-1378144689=:2775 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A>=0A>The issue is all of the systems where response times DO matter.= =A0 Those clocks do get synchronized already, because there is a need that = justifies the effort required to do so.=A0 The challenge then becomes, How = do we measure transmission times between those systems once they convert to= IPv6?=A0 When there is no way in IPv6 to record those times, that is a pro= blem.=A0 =0A>=0A=0A>As far as I'm aware there is no way to record those tim= es specifically in IPv4.=0A=0AYes. =A0I know. =A0And, those times are very = important for diagnostics. =A0That is the point of our proposal. =A0 If we = could backport this proposal to IPv4, that would be also great.=0A=0AOne of= the other guys on the team will be responding soon about NTP and the curre= nt monitoring tools he uses. =A0=A0 --1619178251-578216388-1378144689=:2775 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

>
>The issue is all of the systems wh= ere response times DO matter.  Those clocks do get synchronized alread= y, because there is a need that justifies the effort required to do so.&nbs= p; The challenge then becomes, How do we measure transmission times between= those systems once they convert to IPv6?  When there is no way in IPv= 6 to record those times, that is a problem. 
>

>As fa= r as I'm aware there is no way to record those times specifically in IPv4.<= br>
Yes.  I know.  And, those times are very important for dia= gnostics.  That is the point of our proposal.   If we could backport this proposal to IPv4, that would be also great.

One of the ot= her guys on the team will be responding soon about NTP and the current moni= toring tools he uses.   
  
--1619178251-578216388-1378144689=:2775-- From mackermann@bcbsm.com Mon Sep 2 15:27:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19521F9C6B for ; Mon, 2 Sep 2013 15:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJrAXxPrFinO for ; Mon, 2 Sep 2013 15:27:53 -0700 (PDT) Received: from mx.z120.zixworks.com (mx.z120.zixworks.com [199.30.235.120]) by ietfa.amsl.com (Postfix) with ESMTP id B799D21F9C6A for ; Mon, 2 Sep 2013 15:27:53 -0700 (PDT) Received: from vmvpm01.z120.zixworks.com (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with ESMTP id 5F47A9AD9EC for ; Mon, 2 Sep 2013 17:27:52 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 000F39AD9D8; Mon, 2 Sep 2013 17:27:50 -0500 (CDT) Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 08C422F0043; Mon, 2 Sep 2013 18:19:30 -0400 (EDT) Received: from pwn401ea100.ent.corp.bcbsm.com (unknown [10.64.80.217]) by imsva2.bcbsm.com (Postfix) with ESMTP id EDC052F0040; Mon, 2 Sep 2013 18:19:29 -0400 (EDT) Received: from PWN401EA160.ent.corp.bcbsm.com ([fe80::fdcb:603d:469e:b1db]) by PWN401EA100.ent.corp.bcbsm.com ([fe80::8db:9ce7:e2cf:8565%13]) with mapi id 14.01.0438.000; Mon, 2 Sep 2013 18:27:50 -0400 From: "Ackermann, Michael" To: Mark ZZZ Smith , Bill Jouris , Randy Bush Thread-Topic: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 Thread-Index: AQHOpN/24Toj+UMKpk6NXKBhM7GJu5mtO+4AgAEfsYCAASZQAIAAC9OAgAA/RQCAAL5lgIACf9og Date: Mon, 2 Sep 2013 22:27:49 +0000 Message-ID: <4FC37E442D05A748896589E468752CAA0C670152@PWN401EA160.ent.corp.bcbsm.com> References: <51FA6667.4010200@bogus.com> <1377607721.23313.YahooMailNeo@web2806.biz.mail.ne1.yahoo.com> <1377967684.21896.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <1378008571.34695.YahooMailNeo@web142506.mail.bf1.yahoo.com> In-Reply-To: <1378008571.34695.YahooMailNeo@web142506.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.10.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG , Al Morton Subject: Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 22:27:58 -0000 Hi Mark, =20 Regards to what is being done to track response times in today's V4 = networks. The solutions I am aware of and that are currently run by many = enterprises, including my own, are proprietary solutions offered by = several different vendors. All are expensive, complex and require a = significant hardware/software infrastructure. These tools require = substantial training and usually protracted professional services = contracts to design, set up and customize, for maximum effectiveness = within any specific environment. And of course as others have said, = the effectiveness of ALL these tools depends upon accurate time = synchronization. =20 =20 It is certainly not my position to denigrate these tools, as we use them = and depend upon them for critical network management information. = However, they are expensive to acquire and operate, and the costs go far = beyond financial. =20 To add to the effort, expense and overhead, those of us in our 2nd and = third generations with these tools, realize what huge scalability issues = exist as we add additional regions, sites, nodes and applications to the = mix. Each requires agents, collectors, and possibly multiple server/DW = components. =20 Now Imagine the simplicity, efficiency, accuracy and affordability of = something baked right into the protocol as is being proposed in the PDM = for IPV6.=20 =20 My final comment is on the time synchronization we use for these tools = today. In most cases we utilize NTP, which has worked fine for us since = we optimized our NTP architecture several years ago. Not all nodes need = to have highly accurate levels of time synchronization. Some do not need = it at all. NTP lends itself well to these various situations, and = enterprises just need to design a NTP infrastructure that achieves the = various required Stratum levels for each respective node being monitored. = That can be as easy/cheap as a 3rd level reference clock in a Windows = Domain. Or as accurate as a directly connect Stratum 1 clock source. = Build whatever is required for each needed situation/node. =20 =20 Hope the above hits on some of the areas you were citing. In any event I = would look forward to exploring some of these areas with you and others = jointly. =20 Thanks Mike -----Original Message----- From: v6ops-bounces=40ietf.org =5Bmailto:v6ops-bounces=40ietf.org=5D On = Behalf Of Mark ZZZ Smith Sent: Sunday, September 01, 2013 12:10 AM To: Bill Jouris; Randy Bush Cc: IPv6 Ops WG; Al Morton Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 >________________________________ > From: Bill Jouris >To: Randy Bush =20 >Cc: IPv6 Ops WG ; Al Morton =20 >Sent: Sunday, 1 September 2013 2:48 AM >Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 >=20 > > >No question that there are lots of systems which do not have their clocks = synchronized.=A0 Indeed, a lot of PCs aren't even synchronized to the = nearest 10 seconds, let alone anything finer. > > >But then, a lot of PCs aren't in need of synchronization.=A0 Nobody = (except maybe the individual user) is concerned about response time for = them -- or going to consider doing anything about response times that = aren't a matter of tens of minutes, and on an on-going basis. =A0=20 > > > >The issue is all of the systems where response times DO matter.=A0 Those = clocks do get synchronized already, because there is a need that justifies = the effort required to do so.=A0 The challenge then becomes, How do we = measure transmission times between those systems once they convert to = IPv6?=A0 When there is no way in IPv6 to record those times, that is a = problem.=A0=20 > As far as I'm aware there is no way to record those times specifically in = IPv4. So how is it being done now in IPv4, =22before IPv6=22? I don't think the answer isn't NTP, because NTP runs over UDP, and = therefore can and does run over both IPv4 and IPv6. I don't think the answer is =A0PTP/IEEE 1588 because that's both a fairly = recent development and is only single LAN rather than Internet scale. > > >And this isn't the only approach that is being considered -- just the = only one (that I am aware of) which doesn't involve adding extra hardware = at the end-points.=A0 (Hardware which will also require some kind of clock = synchronization.) > >=A0 >Bill Jouris >Inside Products, Inc. >www.insidethestack.com >831-659-8360 >925-855-9512 (direct) > > > > >________________________________ > From: Randy Bush >To: Nalini Elkins =20 >Cc: IPv6 Ops WG ; Al Morton =20 >Sent: Saturday, August 31, 2013 6:01 AM >Subject: Re: =5Bv6ops=5D draft-elkins-v6ops-ipv6-pdm-recommended-usage-00 >=20 > >> If you are arguing that time synchronization cannot be done to the >> millisecond or microsecond level > >not arguing.=A0 just trying to explain to you that a lot of engineering >and research have shown that ntp, pee cees running unix or linux with >gps, ... do not have millisecond accuracy on stamping packets over the >net.=A0 folk are trying to save you wasted effort.=A0=20 > >randy >_______________________________________________ >v6ops mailing list >v6ops=40ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > > > >_______________________________________________ >v6ops mailing list >v6ops=40ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ v6ops mailing list v6ops=40ietf.org https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From jiangsheng@huawei.com Tue Sep 3 00:35:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09DF11E81AB for ; Tue, 3 Sep 2013 00:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i6vDITkMb9N for ; Tue, 3 Sep 2013 00:35:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF13811E81AC for ; Tue, 3 Sep 2013 00:35:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUZ60582; Tue, 03 Sep 2013 07:35:24 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 08:34:43 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Sep 2013 08:34:54 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.66]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Tue, 3 Sep 2013 15:34:45 +0800 From: Sheng Jiang To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-experience WGLC Thread-Index: AQHOpz0vWCDAHDiqKkSa1e+LJBgdQJmznjkA Date: Tue, 3 Sep 2013 07:34:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD05610@nkgeml512-mbx.china.huawei.com> References: <201309011800.r81I0Ao1006741@irp-view13.cisco.com> In-Reply-To: <201309011800.r81I0Ao1006741@irp-view13.cisco.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 07:35:37 -0000 SGksIHY2b3BzIGFuZCBhdXRob3JzLA0KDQpJIHZvbHVudGVlcmVkIHRvIHJldmlldyB0aGlzIGRv Y3VtZW50IGR1cmluZyBJRVRGODcgbWVldGluZy4gVGhlIGJlbG93IGlzIG15IGNvbW1lbnRzLg0K DQpJbiBnZW5lcmFsLCB0aGlzIGRvY3VtZW50IGhhdmUgZG9uZSBhIGdvb2Qgam9iIG9uIHNoYXJp bmcgdGhlaXIgTkFUNjQgZXhwZXJpZW5jZS4gVGhlIGluZm9ybWF0aW9uIGlzIHVzZWZ1bCBmb3Ig SVB2NiBzb2NpZXR5IGFuZCB0aGUgZG9jdW1lbnQgaGFzIG9yZ2FuaXplZCBpbiBhIGZvcm0gZWFz eSB0byByZWFkIGFuZCB1bmRlcnN0YW5kLg0KDQpTbyBJIHN1cHBvcnQgdGhpcyBXR0xDLg0KDQpT b21lIG5pdHMgYXJlIGFzIGZvbGxvd2luZy4gDQoNClRoZSBzZWNvbmQgYW5kIGZvdXJ0aCBwYXJh Z3JhcGhzIGFyZSBib3RoIGRlc2NyaWJlIHRoZSBjb2V4aXN0ZW5jZSBiZXR3ZWVuIElQdjQgYW5k IElQdjYuIE1lcmdpbmcgdGhlbSB0b2dldGhlciB3b3VsZCBnZXQgYmV0dGVyIGxvZ2ljYWxpdHku DQoNClNlY3Rpb24gMy4xIGNvbnRhaW5zIGZhaXJseSBsb25nIHN0YXRlbWVudHMuIEl0IG1heSBi ZSBiZXR0ZXIgdG8gY3JlYXRlIHN1Yi1zZWN0aW9ucyB0byBnYXVnZSB0aGUgZGlzY3Vzc2lvbi4N Cg0KRm9yIHRoZSBzdGF0ZW1lbnQsDQogICANCiAgIFRoZXJlZm9yZSwgTkFUNjQgbWF5IHNlcnZl IGRvdWJsZSByb2xlcyBpbiBzb21lIGNhc2VzLA0KICAgaS5lLiBhIHRyYW5zbGF0b3IgYW5kIElQ djYgZm9yd2FyZGVyLiAgU29tZSBmYWlsdXJlIGNhc2VzIG1heSBvY2N1cg0KICAgb25jZSBOQVQ2 NCBzZXJ2ZXMgYSBJUHY2IGdhdGV3YXkgYnV0IGlzIGNvbmZpZ3VyZWQgb25seSB3aXRoIElQdjQg b24NCg0KSXQgc2hvdWxkIGJlIG5vdGVkIG5hdGl2ZSBJUHY2IHBhdGhzIG1heSBub3QgdHJhdmVy c2UgTkFUNjQuIFlvdSBtYXkgYWRkIHNvbWUgZGlzY3Vzc2lvbnMgcmVnYXJkaW5nIHRoaXMgcG9p bnQuDQoNClNlY3Rpb24gNC4xIGhhcyBkb25lIGEgZ29vZCBkaXNjdXNzaW9uIG9uIHRoZSBkaWZm ZXJlbnQgZmxhdm9ycyBvZiByZWR1bmRhbmN5LiBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gbW92ZSB0 aGUgdGVzdGluZyB0YWJsZSBpbnRvIHRoZSBhcHBlbmRpeC4gWW91IGNvdWxkIGRldGFpbCB0aGUg dGVzdGluZyBjb25kaXRpb24gc28gYXVkaWVuY2VzIGNvdWxkIGNvbXBhcmUgaXQgd2l0aCB0aGVp ci1vd24gc2l0dWF0aW9uLg0KDQpJbiBzZWN0aW9uIDQuMiwgeW91IGhhdmUgdGhlIGJlbG93IHRl eHQNCg0KICAgICAgV2l0aCB0aGUgYWJzZW5jZSBvZiBETlM2NCwgaW50ZXJuYWwNCiAgICAgIGhv c3RzIGNvdWxkIGxlYXJuIG11bHRpcGxlIElQdjYgcHJlZml4ZXMgdGhyb3VnaCB0aGUgYXBwcm9h Y2hlcw0KICAgICAgZGVmaW5lZCBpbltJLUQuaWV0Zi1iZWhhdmUtbmF0NjQtZGlzY292ZXJ5LWhl dXJpc3RpY10uLi4NCg0KSG93ZXZlciwgSS1ELmlldGYtYmVoYXZlLW5hdDY0LWRpc2NvdmVyeS1o ZXVyaXN0aWMgYWxzbyByZXF1ZXN0cyBETlM2NCBpbnZvbHZlbWVudC4gSXQgbWF5IG5lZWQgc29t ZSBjbGFyaWZpY2F0aW9ucyA/ICANCg0KSW4gc2VjdGlvbiA1LjIsIGl0IG1heSBiZSB3b3J0aCB0 byBhZGQgYSBxdW90YSBvciByZWZlcmVuY2UgdG8gcmZjNjk2Ny4gSXQgYW5hbHl6ZXMgc2V2ZXJh bCBwb3RlbnRpYWwgc29sdXRpb25zIGluIGdlby1sb2NhdGlvbiBhcmVhLiANCg0KQmVzdCByZWdh cmRz77yMDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYNCj5PZiBGcmVkIEJha2VyDQo+U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTMg MjowMCBBTQ0KPlRvOiB2Nm9wc0BpZXRmLm9yZw0KPlN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtaWV0 Zi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlIFdHTEMNCj4NCj5UaGlzIGlzIHRvIGluaXRpYXRlIGEg dHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb2YNCj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UuICBQbGVhc2UgcmVhZCBp dA0KPm5vdy4gSWYgeW91IGZpbmQgbml0cw0KPihzcGVsbGluZyBlcnJvcnMsIG1pbm9yIHN1Z2dl c3RlZCB3b3JkaW5nIGNoYW5nZXMsIGV0YyksIGNvbW1lbnQgdG8gdGhlDQo+YXV0aG9yczsgaWYg eW91IGZpbmQgZ3JlYXRlciBpc3N1ZXMsIHN1Y2ggYXMgZGlzYWdyZWVpbmcgd2l0aCBhDQo+c3Rh dGVtZW50IG9yIGZpbmRpbmcgYWRkaXRpb25hbCBpc3N1ZXMgdGhhdCBuZWVkIHRvIGJlIGFkZHJl c3NlZCwNCj5wbGVhc2UgcG9zdCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0KPg0KPldlIGFy ZSBsb29raW5nIHNwZWNpZmljYWxseSBmb3IgY29tbWVudHMgb24gdGhlIGltcG9ydGFuY2Ugb2Yg dGhlDQo+ZG9jdW1lbnQgYXMgd2VsbCBhcyBpdHMgY29udGVudC4gSWYgeW91IGhhdmUgcmVhZCB0 aGUgZG9jdW1lbnQgYW5kDQo+YmVsaWV2ZSBpdCB0byBiZSBvZiBvcGVyYXRpb25hbCB1dGlsaXR5 LCB0aGF0IGlzIGFsc28gYW4gaW1wb3J0YW50DQo+Y29tbWVudCB0byBtYWtlLg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+djZvcHMgbWFpbGluZyBs aXN0DQo+djZvcHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQo= From internet-drafts@ietf.org Tue Sep 3 22:58:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE2B11E81CB; Tue, 3 Sep 2013 22:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev5sJsew6TlA; Tue, 3 Sep 2013 22:58:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5511E8122; Tue, 3 Sep 2013 22:58:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130904055809.20006.73390.idtracker@ietfa.amsl.com> Date: Tue, 03 Sep 2013 22:58:09 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 05:58:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP M= obile Devices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-05.txt Pages : 17 Date : 2013-09-03 Abstract: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Sep 3 23:09:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D13311E80C5 for ; Tue, 3 Sep 2013 23:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSfoHmHILsyT for ; Tue, 3 Sep 2013 23:09:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4FA21F9E6C for ; Tue, 3 Sep 2013 23:09:25 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id ACE493B4350 for ; Wed, 4 Sep 2013 08:09:23 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 96559238048 for ; Wed, 4 Sep 2013 08:09:23 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Wed, 4 Sep 2013 08:09:23 +0200 From: To: "v6ops@ietf.org" Date: Wed, 4 Sep 2013 08:09:22 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-05.txt Thread-Index: Ac6pM9EasTodcZY+RoqiR0FF4Ydk0wAABOlQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0336380@PUEXCB1B.nanterre.francetelecom.fr> References: <20130904055809.20006.73390.idtracker@ietfa.amsl.com> In-Reply-To: <20130904055809.20006.73390.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 06:09:43 -0000 Dear all, This new version integrates the comments received during the IETF LC, in pa= rticular: * A comment from N. Heatley on roaming (see REQ#19) * Comments from S. Josefsson (sec directorate) * Comments from E. Kline * Comments from Y. Baryun * Tweak the text of the introduction as per a comment from L. Colitti. A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-v6ops-mobile-device-profile-05=20 Cheers, Med=20 >-----Message d'origine----- >De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e >internet-drafts@ietf.org >Envoy=E9=A0: mercredi 4 septembre 2013 07:58 >=C0=A0: i-d-announce@ietf.org >Cc=A0: v6ops@ietf.org >Objet=A0: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-05.tx= t > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IPv6 Operations Working Group of the >IETF. > > Title : An Internet Protocol Version 6 (IPv6) Profile for >3GPP Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-05.txt > Pages : 17 > Date : 2013-09-03 > >Abstract: > This document defines an IPv6 profile for 3GPP mobile devices. It > lists the set of features a 3GPP mobile device is to be compliant > with to connect to an IPv6-only or dual-stack wireless network > (including 3GPP cellular network and IEEE 802.11 network). > > This document defines a different profile than the one for general > connection to IPv6 cellular networks defined in > [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies > also features to deliver IPv4 connectivity service over an IPv6-only > transport. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-= 05 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From mohamed.boucadair@orange.com Tue Sep 3 23:32:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A24B21F9ADA; Tue, 3 Sep 2013 23:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id notuNRqNHDsf; Tue, 3 Sep 2013 23:32:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B042F21F9A98; Tue, 3 Sep 2013 23:32:00 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E2C542DC2BE; Wed, 4 Sep 2013 08:31:57 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C276A4C066; Wed, 4 Sep 2013 08:31:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 4 Sep 2013 08:31:57 +0200 From: To: Lorenzo Colitti , IETF Discussion Date: Wed, 4 Sep 2013 08:31:55 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6diT9DxP1klHJCQXid5jg5Ad/NKALrB0Dw Message-ID: <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF033638DPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 06:32:06 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF033638DPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lorenzo, We already answered to several of the points in previous discussions (durin= g the call for adoption and also during the WGLC). We also made some change= s in the last version to make the language clear (http://tools.ietf.org/htm= l/draft-ietf-v6ops-mobile-device-profile-05): it is about ** a ** profile f= or mobile devices. The scope covers mobile hosts, hosts with wan sharing ca= pabilities (e.g., mobile CPE) and the also those with wi-fi interfaces. The= motivations for this effort and scope are explained in the introduction. Cheers, Med De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de L= orenzo Colitti Envoy=E9 : mardi 20 ao=FBt 2013 11:39 =C0 : IETF Discussion Cc : v6ops@ietf.org WG Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Mon, Aug 19, 2013 at 10:52 PM, The IESG > wrote: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). I object to this document on the grounds that it is little more than a list= of (34!) features with little technical justification. I see this as a pro= blem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify whi= ch features or protocols should or should not be implemented in hosts. Even= the hosts requirements RFCs are careful and sparing in their language. The= IETF is certainly not in the business of rubberstamping feature wishlists = without good technical reasons. I would challenge the authors to find a pre= cedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necess= ary to build a mobile device that works well over IPv6. Today, the overwhel= ming majority of mobile device traffic comes from devices that implement on= ly a handful of these requirements. More specifically, requirements #3, #9,= #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24,= #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applicat= ions running on the device - yes, all of them), and #34, are not necessary = to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would c= hallenge the authors to find a single product today that implements all, or= even a substantial majority, of these requirements. It seems to me that th= e sheer length of the list, and the fact that is not prioritized, create a = real risk that implementors will simply write it off as wishful thinking or= even shy away in terror. 4. The document has few technical contributions of its own. Most of the req= uirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what s= eems like all the features that the IETF has ever developed, and then sayin= g that they all need to be implemented, is not the way to get there. The wa= y to do it is to document use cases and working scenarios gleaned from oper= ational experience. Regards, Lorenzo --_000_94C682931C08B048B7A8645303FDC9F36EF033638DPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lorenzo,

 

We already answered to several of the points in previous discussions = (during the call for adoption and also during the WGLC). We also made some = changes in the last version to make the language clear (http://tools.= ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05): it is about *= * a ** profile for mobile devices. The scope covers mobile hosts, hosts wit= h wan sharing capabilities (e.g., mobile CPE) and the also those with wi-fi= interfaces. The motivations for this effort and scope are explained in the= introduction.

 

Cheers,

Med

 

De : v6ops-bounces@ietf.org [mailto:v6o= ps-bounces@ietf.org] De la part de Lorenzo Colitti
Envoy=E9&nb= sp;: mardi 20 ao=FBt 2013 11:39
=C0 : IETF DiscussionCc : v6ops@ietf.org WG
Objet : Re: [v6ops] Last= Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Prot= ocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC=

 

On Mon, Aug 19, 2013 at 10:52 PM, The IESG <<= a href=3D"mailto:iesg-secretary@ietf.org" target=3D"_blank">iesg-secretary@= ietf.org> wrote:

   This document sp= ecifies an IPv6 profile for 3GPP mobile devices.  It
   l= ists the set of features a 3GPP mobile device is to be compliant
  =  with to connect to an IPv6-only or dual-stack wireless network
&nb= sp;  (including 3GPP cellular network and IEEE 802.11 network).

 

<= div>

I object to this document on the grounds that it i= s little more than a list of (34!) features with little technical justifica= tion. I see this as a problem because:

 

1. It is out= of the IETF's mandate. It is not the IETF's job to specify which features = or protocols should or should not be implemented in hosts. Even the hosts r= equirements RFCs are careful and sparing in their language. The IETF is cer= tainly not in the business of rubberstamping feature wishlists without good= technical reasons. I would challenge the authors to find a precedent RFC c= ontaining such broad requirements.

 

2. It is over-br= oad. The vast majority of the features are in no way necessary to build a m= obile device that works well over IPv6. Today, the overwhelming majority of= mobile device traffic comes from devices that implement only a handful of = these requirements. More specifically, requirements #3, #9, #10, #11, #12, = #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (= a whole RFC!), #28, #29, #31, #32 (which cover all applications running on = the device - yes, all of them), and #34, are not necessary to connect to IP= v6 mobile networks.

&nbs= p;

3. It is so daunting as to act = as a deterrent to IPv6 deployment. I would challenge the authors to find a = single product today that implements all, or even a substantial majority, o= f these requirements. It seems to me that the sheer length of the list, and= the fact that is not prioritized, create a real risk that implementors wil= l simply write it off as wishful thinking or even shy away in terror.<= o:p>

 

4. The document has few technical contributions of = its own. Most of the requirements are simply listed one after another.=

 

<= p class=3DMsoNormal>I'm all for IPv6 deployment in mobile networks, but mak= ing a list of what seems like all the features that the IETF has ever devel= oped, and then saying that they all need to be implemented, is not the way = to get there. The way to do it is to document use cases and working scenari= os gleaned from operational experience.

 

Regards,<= o:p>

Lorenzo

<= /div>
= --_000_94C682931C08B048B7A8645303FDC9F36EF033638DPUEXCB1Bnante_-- From phdgang@gmail.com Wed Sep 4 01:02:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D72021E80AE for ; Wed, 4 Sep 2013 01:02:58 -0700 (PDT) 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=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIsnuk+6xn1X for ; Wed, 4 Sep 2013 01:02:57 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1B21E8168 for ; Wed, 4 Sep 2013 01:02:57 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id bv4so1849232qab.9 for ; Wed, 04 Sep 2013 01:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0MbU12a2EC0cWfaGOCdVY3Namg6j0qnSJoxJY7nNyiI=; b=zwa481DJrxKW3KlmQ1hJfjxCvfM6X6xNaedOEnvBau406GwnaLF7xW4bMDxOVSOZKw PTy+NODj/aQuc5FULtm4tzizHz0tYm08VQnNKFVP6XJwwMHY14Rgo4sDDR1C4lZ8dm2Y Jo1/xxuuyDXDWDVW3nk7hCurJQaJTRpP4J+48wje7g7CtsFxBnTRqqcwW78uSICPHoI6 G3bt+hkrWYyPb1lAWfe1olmi8j77hYdhBXc9aCEffdOlgOHKEtwdQjqDrfieZRQTs0fO 7sTYYuOEusvMKKjEa9b5OGecYBDeKKutsFLoal5nZb8Lt8URLgtQmGDIjRIuc7muPEqq OqYQ== MIME-Version: 1.0 X-Received: by 10.224.160.130 with SMTP id n2mr1801292qax.68.1378281776669; Wed, 04 Sep 2013 01:02:56 -0700 (PDT) Received: by 10.49.81.171 with HTTP; Wed, 4 Sep 2013 01:02:56 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AD05610@nkgeml512-mbx.china.huawei.com> References: <201309011800.r81I0Ao1006741@irp-view13.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD05610@nkgeml512-mbx.china.huawei.com> Date: Wed, 4 Sep 2013 16:02:56 +0800 Message-ID: From: GangChen To: Sheng Jiang Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:02:58 -0000 Hi Sheng, Thank you for your detailed review. Please see my reply inline. 2013/9/3, Sheng Jiang : > Hi, v6ops and authors, > > I volunteered to review this document during IETF87 meeting. The below is= my > comments. > > In general, this document have done a good job on sharing their NAT64 > experience. The information is useful for IPv6 society and the document h= as > organized in a form easy to read and understand. > > So I support this WGLC. > > Some nits are as following. > > The second and fourth paragraphs are both describe the coexistence betwee= n > IPv4 and IPv6. Merging them together would get better logicality. > > Section 3.1 contains fairly long statements. It may be better to create > sub-sections to gauge the discussion. We will address that at the next update. > For the statement, > > Therefore, NAT64 may serve double roles in some cases, > i.e. a translator and IPv6 forwarder. Some failure cases may occur > once NAT64 serves a IPv6 gateway but is configured only with IPv4 on > > It should be noted native IPv6 paths may not traverse NAT64. You may add > some discussions regarding this point. I would make following changes on this point OLD --------------- Operators should not expect to access IPv4 parts of a dual-stack server using NAT64/DNS64. NAT64 would forwards all the traffic on IPv6 paths if dual-stack servers are targeted. In some sense, it encourages IPv6 transmission and restrains NAT uses compared to NAT44(if used), on which all traffic flows have to traverse. Therefore, NAT64 may serve double roles in some cases, i.e. a translator and IPv6 forwarder. Some failure cases may occur once NAT64 serves a IPv6 gateway but is configured only with IPv4 on WAN links. We tested on Top100 websites (referring to [Alexa] statistics) in such condition. 43% of websites are failed to be connected since those websites have both AAAA and A records. To be reliable, it's recommended to enable NAT64 WAN links with dual-stack connections in the deployment. NEW ----------------- Operators should not expect to access IPv4 parts of a dual-stack server using NAT64/DNS64. The traffic is forwarded on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may be ro= uted not going through NAT64. Only the traffic going to IPv4-only service would traverse NAT64. In some sense, it encourages IPv6 transmission and restrains NAT uses compared to NAT44(if used), on which all traffic flows have to be traversed and translated. In some cases, NAT64-CGN may serve double roles, i.e. a translator and IPv6 forwarder. Some failure cases may be occured once NAT64 serves a IPv6 gateway while is configure= d only with IPv4 on WAN links. We tested on Top100 websites (referring to [Alexa] statistics) in such condition. 43% of websites are failed to be connected since those websites have both AAAA and A records. Therefore, = it's recommended to enable NAT64 WAN links with dual-stack connections in such case. > Section 4.1 has done a good discussion on the different flavors of > redundancy. It would be better to move the testing table into the appendi= x. > You could detail the testing condition so audiences could compare it with > their-own situation. It will be done at the next update. > In section 4.2, you have the below text > > With the absence of DNS64, internal > hosts could learn multiple IPv6 prefixes through the approaches > defined in[I-D.ietf-behave-nat64-discovery-heuristic]... > > However, I-D.ietf-behave-nat64-discovery-heuristic also requests DNS64 > involvement. It may need some clarifications ? Thank you for pointing me this issue. I would make following change For the applications not requiring DNS resolver, internal hosts could learn multiple IPv6 prefixes through the approaches defined in[I-D.ietf-behave-nat64-discovery-heuristic] and then select one based on a given prefix selection policy. > In section 5.2, it may be worth to add a quota or reference to rfc6967. I= t > analyzes several potential solutions in geo-location area. It was mentioned at http://www.ietf.org/mail-archive/web/v6ops/current/msg17131.html. The new text for the statement is o The NAT64-CGN equipments may not implement XFF. Geo-location based on shared IPv4 address is rather inaccurate in that case. [RFC6967] analyzed several options to reveal the host identifier. Each one may have their-own specific usage. With regards to NAT64 deployment, it's desirable to offer geo-location system the internal IPv6 address, which has the meaning in global scale. For the geo-location systems relying on a Radius database[RFC5580], w= e have investigated to deliver NAT64 BIBs and Session Table Entrys (STE= s) to a Radius server[I-D.chen-behave-nat64-radius-extension]. This method could get along with [RFC5580] to convey original source address through same message bus. Best Regards Gang > Best regards=A3=AC > > Sheng > >>-----Original Message----- >>From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of Fred Baker >>Sent: Monday, September 02, 2013 2:00 AM >>To: v6ops@ietf.org >>Subject: [v6ops] draft-ietf-v6ops-nat64-experience WGLC >> >>This is to initiate a two week working group last call of >>http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience. Please rea= d >> it >>now. If you find nits >>(spelling errors, minor suggested wording changes, etc), comment to the >>authors; if you find greater issues, such as disagreeing with a >>statement or finding additional issues that need to be addressed, >>please post your comments to the list. >> >>We are looking specifically for comments on the importance of the >>document as well as its content. If you have read the document and >>believe it to be of operational utility, that is also an important >>comment to make. >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Wed Sep 4 01:04:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849D021E80AB for ; Wed, 4 Sep 2013 01:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW-W7iSjQSNY for ; Wed, 4 Sep 2013 01:04:45 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 825E221E8089 for ; Wed, 4 Sep 2013 01:04:45 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k14so12377730iea.19 for ; Wed, 04 Sep 2013 01:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5iR8FZC77MBqZ2QeSf35DNiabXfqza7H7wu6N2ilBTk=; b=Wejkvz01QLb7vhwAkTCPqOuIDI0Qu+vLLZ5uiJ4WBPg46KysZ5qIz/RvjRKloapu6s aRwDOPRcA/NvKH+RjLkJEQ3MWsaREeeGXJ5PV+bsRxda2dsx3RHAXmulFR1ZXUDnmWLc eUIyeMGn7nNL0QCGoHI9tKe6yl7GESlxFjeNtou9AmHsoXQhSK4zcJRMvt3va+/UscRs 48jlrnD/y39a78OtB/spfsaLR80WZJ08QivrbKy7G5kNHyCSj6P6ybMzpsJEQ/PxzcLM QQBoVOfZdy4AQvWXb7DAVzLu4qDeQeaceiLvEEKL8pFBRpmQdReZzHqzOytO47pnWIMh Y6Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5iR8FZC77MBqZ2QeSf35DNiabXfqza7H7wu6N2ilBTk=; b=T9pg3mjR4Ecyl+w8qf0bTSp9EabSs7THgRlwQxsXl4ZkOtZBjG8JCqE3mubgnxz56E 55oSy61A1f1i9YN4RRBLyTF9czXQwBgDW00K4Ev502dSzj61hvE8zS6bkWnntzIRm3QB NrmGnDpxJ/idBlImPPSx6AFa2iIjNEJf+Ez3aLz5TvH0Meq7r/ghFJuNliChw0zX4Zwm sadAEwDvSs1VNsCJ/zjrlL1cxWtn5H44vTCjRmQlnFEfojbnV9HHmZUuKIXs72CVaZnp trWxdFMeb11ELkr4Nnc+mekjFN4lIY0jAcKEhGmPHztpWY0nrZZnK2bkkT5EpkRAYTEz wMLQ== X-Gm-Message-State: ALoCoQlmbxdWD3xNtiHktQzFKCYxnY4WKaexExk2sVCxa0E/NN5zak66ZjI53LcBWPbeP6ucu7QEF5DK/Oaofphk/UcygZBu76py1O7H185cAq5CVMiY6L7PC2MZm2En29gR6a/cFaQlL7KMrOKPjvhimModiiILBOCkQOOwDBQeEbwExx3u72E3ZkIweR8Y162CHw3W1J6A X-Received: by 10.50.66.163 with SMTP id g3mr910174igt.20.1378281885025; Wed, 04 Sep 2013 01:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Wed, 4 Sep 2013 01:04:24 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Wed, 4 Sep 2013 17:04:24 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdca31c2884d804e58a42d4 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:04:49 -0000 --047d7bdca31c2884d804e58a42d4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 4, 2013 at 3:31 PM, wrote: > it is about ** a ** profile for mobile devices. > But wait... if it's just *a* profile, then why is the IETF publishing this particular profile, and not any other profile? Is this an IETF recommended profile? If, so then the document should state why. If not, then the document should state that this is just one possible profile, and that the IETF does not recommend for or against it. I think the fundamental problem with this document is that it does not provide solid reasons for why all 34 requirements need to be implemented (and personally, I think that's because it just can't - there *are* no solid reasons). The draft seems implies that all these requirements must be met to deploy IPv6 on mobile devices, but that's not true. A great example is the statement in the abstract which says that this document "lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network". This statement is false: there are tens of millions of mobile devices using IPv6 every day, and none of them meet more than a minority of the requirements in this document. I know we've already gone over this in the WG, but since this is IETF last call, I think the rest of the community should see this discussion so that we collectively know what the arguments for and against this proposal and can reach informed consensus. Oh, and I know it's a bit out of fashion, but: what happened to "running code"? Are there *any* implementations of all this? --047d7bdca31c2884d804e58a42d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 4, 2013 at 3:31 PM, <mohamed.bouc= adair@orange.com> wrote:

it is about ** a ** profile for mobile devices.

But wait... if it's just *a* profile, then why = is the IETF publishing this particular profile, and not any other profile? = Is this an IETF recommended profile? If, so then the document should state = why. If not, then the document should state that this is just one possible = profile, and that the IETF does not recommend for or against it.

I think the fundamental problem with this document is t= hat it does not provide solid reasons for why all 34 requirements need to b= e implemented (and personally, I think that's because it just can't= - there *are* no solid reasons). The draft seems implies that all these re= quirements must be met to deploy IPv6 on mobile devices, but that's not= true. A great example is the statement in the abstract which says that thi= s document "lists the set of features a 3GPP mobile device is to be co= mpliant with to connect to an IPv6-only or dual-stack wireless network"= ;. This statement is false: there are tens of millions of mobile devices us= ing IPv6 every day, and none of them meet more than a minority of the requi= rements in this document.

I know we've already gone over this in the WG,= but since this is IETF last call, I think the rest of the community should= see this discussion so that we collectively know what the arguments for an= d against this proposal and can reach informed consensus.

Oh, and I know it's a bit out of fashion, but= : what happened to "running code"? Are there *any* implementation= s of all this?
--047d7bdca31c2884d804e58a42d4-- From david.binet@orange.com Wed Sep 4 01:29:23 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48111E817C; Wed, 4 Sep 2013 01:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJKec1pSkLK6; Wed, 4 Sep 2013 01:29:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8821C11E811D; Wed, 4 Sep 2013 01:29:17 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7A85A3B4175; Wed, 4 Sep 2013 10:29:16 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 585AB4C024; Wed, 4 Sep 2013 10:29:16 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 4 Sep 2013 10:29:11 +0200 From: To: Lorenzo Colitti , BOUCADAIR Mohamed IMT/OLN Date: Wed, 4 Sep 2013 10:29:09 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6pRXaRl/h3ZIeFSoiMkkh2JcA8dAAASOwg Message-ID: <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_1B2E7539FECD9048B261B791B1B24A7C511C52CE60PUEXCB1Anante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:29:23 -0000 --_000_1B2E7539FECD9048B261B791B1B24A7C511C52CE60PUEXCB1Anante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lorenzo Answers below David ________________________________ De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de L= orenzo Colitti Envoy=E9 : mercredi 4 septembre 2013 10:04 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : v6ops@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Wed, Sep 4, 2013 at 3:31 PM, > wrote: it is about ** a ** profile for mobile devices. But wait... if it's just *a* profile, then why is the IETF publishing this = particular profile, and not any other profile? Is this an IETF recommended = profile? If, so then the document should state why. If not, then the docume= nt should state that this is just one possible profile, and that the IETF d= oes not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by ot= her ones. Maybe you have some other proposition for mobile profile but as o= perators, this list of requirements fits our needs. I think the fundamental problem with this document is that it does not prov= ide solid reasons for why all 34 requirements need to be implemented (and p= ersonally, I think that's because it just can't - there *are* no solid reas= ons). [[david]] Did you mention that not all requirements are mandatory ? It give= s flexibility to operators to define what they are expecting from vendors. The draft seems implies that all these requirements must be met to deploy = IPv6 on mobile devices, but that's not true. A great example is the stateme= nt in the abstract which says that this document "lists the set of features= a 3GPP mobile device is to be compliant with to connect to an IPv6-only or= dual-stack wireless network". This statement is false: there are tens of m= illions of mobile devices using IPv6 every day, and none of them meet more = than a minority of the requirements in this document. [[david]] Do you mean that the current status regarding IPv6 support in dev= ices is fine and that there is no need for other features in mobile devices= ? Some devices have been connected to IP networks for tens of years now an= d it does not mean we should not add new features to these devices to enabl= e new services. We are considering, as operators, that current IPv6 feature= s in mobile devices do not satisfy all our needs as mentioned in the docume= nt. I know we've already gone over this in the WG, but since this is IETF last = call, I think the rest of the community should see this discussion so that = we collectively know what the arguments for and against this proposal and c= an reach informed consensus. [[david]] OK Oh, and I know it's a bit out of fashion, but: what happened to "running co= de"? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind= of document may be useful to get some. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_1B2E7539FECD9048B261B791B1B24A7C511C52CE60PUEXCB1Anante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Lorenzo
 
Answers below
 
David

De : v6ops-bounces@ietf.org=20 [mailto:v6ops-bounces@ietf.org] De la part de Lorenzo=20 Colitti
Envoy=E9 : mercredi 4 septembre 2013=20 10:04
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc := =20 v6ops@ietf.org WG; IETF Discussion
Objet : Re: [v6ops] Las= t=20 Call: <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Pro= tocol=20 Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational=20 RFC

On Wed, Sep 4, 2013 at 3:31 PM, <mohamed.boucadair@orange.com> wrote:

it=20 is about ** a ** profile for mobile devices.

But wait... if it's just *a* profile, then why is the IETF publishin= g=20 this particular profile, and not any other profile? Is this an IETF=20 recommended profile? If, so then the document should state why. If not, t= hen=20 the document should state that this is just one possible profile, and tha= t the=20 IETF does not recommend for or against it.
[[david]] It = is a=20 profile proposed by several operators and supported by other ones. M= aybe=20 you have some other proposition for mobile profile but as=20 operators, this list of requirements fits our needs.=20  

I think the fundamental problem with this document is that it does n= ot=20 provide solid reasons for why all 34 requirements need to be implemented = (and=20 personally, I think that's because it just can't - there *are* no solid= =20 reasons).
[[david]] Did you mention that not all requirements are man= datory=20 ? It gives flexibility to operators to define what they are expectin= g=20 from vendors.
 The draft seems implie= s that=20 all these requirements must be met to deploy IPv6 on mobile devices, but= =20 that's not true. A great example is the statement in the abstract which s= ays=20 that this document "lists the set of features a 3GPP mobile device is to = be=20 compliant with to connect to an IPv6-only or dual-stack wireless network"= .=20 This statement is false: there are tens of millions of mobile devices usi= ng=20 IPv6 every day, and none of them meet more than a minority of the require= ments=20 in this document.
[[david]] Do you mean that the current status regarding IPv= 6=20 support in devices is fine and that there is no need for other featu= res=20 in mobile devices ? Some devices have been connected to IP networks = for=20 tens of years now and it does not mean we should not add new features to = these=20 devices to enable new services. We are considering, as operators, that=20 current IPv6 features in mobile devices do not satisfy all our = needs=20 as mentioned in the document.  

I know we've already gone over this in the WG, but since this is IET= F=20 last call, I think the rest of the community should see this discussion s= o=20 that we collectively know what the arguments for and against this proposa= l and=20 can reach informed consensus.
[[david]] OK 

Oh, and I know it's a bit out of fashion, but: what happened to "run= ning=20 code"? Are there *any* implementations of all this?
[[david]] We = expect some=20 implementations and we are thinking that such kind of document may b= e=20 useful to get some.=20  
_____________=
___________________________________________________________________________=
_________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_1B2E7539FECD9048B261B791B1B24A7C511C52CE60PUEXCB1Anante_-- From lorenzo@google.com Wed Sep 4 01:50:54 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42C621E80B1 for ; Wed, 4 Sep 2013 01:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Hq4mPrinJoR for ; Wed, 4 Sep 2013 01:50:53 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0A21E80AB for ; Wed, 4 Sep 2013 01:50:52 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so20133iec.41 for ; Wed, 04 Sep 2013 01:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mSOT87OwbY2OWDeLZdcxYjWsSo/IGlI19PjiBwzRJmU=; b=axIh9M9Bq/lSrN7Aua8EGQJrG120hRB/f/IgJ4FGt5xh1Aza/E9XZ2y6xzRdw11/Vz efehcIYvQKmVJbbrrPynFxts82rS4R0fwjtb5h17BnpudGbc5sWZkNrrpfB/ehdlCQrc HkGEchD53U4O7wX5bvz5DceYnL18ZC+/8aOokhMQLwkFuTT2lzZPsSMDzXGoeGkk5Gpd 18mr4B8TZ2kSXDXvPYiXWcIQRt3yWqL/P1lefYtQmN7Z+ceic1ZhcWbQrAH+k5zvxCDM qWiJQoZfojt/93LH4MyM0osPOJ9VojUjnFfxtngGHKOSGHqcszM3ses5zYeIRHJfPH05 BfLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mSOT87OwbY2OWDeLZdcxYjWsSo/IGlI19PjiBwzRJmU=; b=Uw309F36HYXzreZOc2NqaF/Y2DFEBlRnyFBgOwQvbIcLDwxb/CWRG/0Qy4GJ3DABxY BdbK23FVofUkGHAG0HLKdxn2iTuhLBYlcs72TfmZ31GSQSTpJlf7or09OH77ReJGh1mT TG6P83jrf3yXNXqn+L71YDvsyTlKyl0lZ8DyKt9DAQLa5gmDjw/Q4Xtc/D3PVOFnd2iH pc5sJnvJtBtoMwIP4Ex22x+Qe3+AJVhfB5G45ZsVuy65WsT5+AiuROemU/gSrIlgk00x ubdzJbd1TwX44y/qQdT/Ai3tgaCz0g/UlOHMGShRgzInvr/iUyoYOmJ6hfm06NRUHT8O s5+Q== X-Gm-Message-State: ALoCoQnILD5Swpk39bHaHmL5S8XYxjfj8MFt3kTc5fTBGlZoaY2l3/JcC7PKUfUrmHz9octv2eq7PQiVZmM7FvxRxfh35cQXnSMODHEILjX78OkQ7qQ/3aLNSpRE6qXA+vrHIiuSlaxPUeISxgW9AN3G3SvTMpN8DrT2vS8PXtu6RMQOh1AlQe6UtReA6oeIF3+s8HTN7Zx/ X-Received: by 10.50.66.163 with SMTP id g3mr1026643igt.20.1378284652434; Wed, 04 Sep 2013 01:50:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Wed, 4 Sep 2013 01:50:32 -0700 (PDT) In-Reply-To: <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Wed, 4 Sep 2013 17:50:32 +0900 Message-ID: To: david.binet@orange.com Content-Type: multipart/alternative; boundary=047d7bdca31c1bd74204e58ae769 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:50:55 -0000 --047d7bdca31c1bd74204e58ae769 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 4, 2013 at 5:29 PM, wrote: > ** > > But wait... if it's just *a* profile, then why is the IETF publishing this > particular profile, and not any other profile? Is this an IETF recommended > profile? If, so then the document should state why. If not, then the > document should state that this is just one possible profile, and that the > IETF does not recommend for or against it. > [[david]] It is a profile proposed by several operators and supported by > other ones. Maybe you have some other proposition for mobile profile but as > operators, this list of requirements fits our needs. > > Ok. So maybe you can put in the draft that this profile is a profile supported by several operators, but not necessarily endorsed by the IETF? > I think the fundamental problem with this document is that it does not > provide solid reasons for why all 34 requirements need to be implemented > (and personally, I think that's because it just can't - there *are* no > solid reasons). > [[david]] Did you mention that not all requirements are mandatory ? It > gives flexibility to operators to define what they are expecting from > vendors. > > Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and "we want this stuff from our vendors" is not a technical issue. > Some devices have been connected to IP networks for tens of years now > and it does not mean we should not add new features to these devices to > enable new services. We are considering, as operators, that current IPv6 > features in mobile devices do not satisfy all our needs as mentioned in the > document. > > And how is it that you as an operator need all devices to meet requirement #28 (a cellphone MUST also be a CPE router)? How can you say that it's necessary to facilitate deployment? > Oh, and I know it's a bit out of fashion, but: what happened to "running > code"? Are there *any* implementations of all this? > [[david]] We expect some implementations and we are thinking that such > kind of document may be useful to get some. > > Remember, the IETF is supposed to be about rough consensus and running code. Can we wait until there is at least one implementation that does all this before we publish the document? --047d7bdca31c1bd74204e58ae769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 4, 2013 at 5:29 PM, <david.binet@orange= .com> wrote:
But wait... if it= 's just *a* profile, then why is the IETF publishing=20 this particular profile, and not any other profile? Is this an IETF=20 recommended profile? If, so then the document should state why. If not, t= hen=20 the document should state that this is just one possible profile, and tha= t the=20 IETF does not recommend for or against it.
[[david]]=A0It is a=20 profile proposed by several operators and supported by other ones.=A0Mayb= e=20 you have some other=A0proposition=A0for mobile profile but as=20 operators,=A0this list of requirements=A0fits our needs. =A0 =A0=A0
Ok. So= maybe you can put in the draft that this profile is a profile supported by= several operators, but not necessarily endorsed by the IETF?
=
I think the fundamental problem w= ith this document is that it does not=20 provide solid reasons for why all 34 requirements need to be implemented = (and=20 personally, I think that's because it just can't - there *are* no= solid=20 reasons).=A0
[[david]]=A0= Did you mention that not all requirements are mandatory=20 ?=A0It gives flexibility to operators to define what they are expecting= =20 from vendors.
Sure, but the majority are mandatory, and don't forget t= hat some of them are quite large (e.g., "implement RFC 6204"). Al= so, I believe it's not the IETF's role to produce vendor requiremen= ts documents. The considerations that the IETF deals with are primarily tec= hnical, and "we want this stuff from our vendors" is not a techni= cal issue.
=A0Some devices have been connected to IP networks for=20 tens of years now and it does not mean we should not add new features to = these=20 devices to enable new services. We are considering, as operators, that=20 current=A0IPv6 features in mobile devices=A0do not satisfy all our needs= =20 as mentioned in the document. =A0
And how is it that you as an operator need = all devices to meet requirement #28 (a cellphone MUST also be a CPE router)= ? How can you say that it's necessary to facilitate deployment?
Oh, and I know it's a bit out of fashion, but: what happened to "= ;running=20 code"? Are there *any* implementations of all this?
<= font face=3D"Arial">[[david]]=A0We expect some=20 implementations and we are thinking that=A0such kind of document may be= =20 useful to get some.
Remember, the IETF is supposed to be about rough consensus a= nd running code. Can we wait until there is at least one implementation tha= t does all this before we publish the document?
--047d7bdca31c1bd74204e58ae769-- From mohamed.boucadair@orange.com Wed Sep 4 02:07:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC3021F9A99; Wed, 4 Sep 2013 02:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVkGhPd5Cpgz; Wed, 4 Sep 2013 02:07:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13F11E8196; Wed, 4 Sep 2013 02:07:41 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id B5C9D2AC4E8; Wed, 4 Sep 2013 11:07:32 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 8D2D615805E; Wed, 4 Sep 2013 11:07:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 4 Sep 2013 11:07:32 +0200 From: To: Lorenzo Colitti , BINET David IMT/OLN Date: Wed, 4 Sep 2013 11:07:30 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6pS99MiEW+JsEkR4Kely1UT5ef/gAAJt9Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF033645APUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:07:51 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF033645APUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, See inline. Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : mercredi 4 septembre 2013 10:51 =C0 : BINET David IMT/OLN Cc : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Wed, Sep 4, 2013 at 5:29 PM, > wrote: But wait... if it's just *a* profile, then why is the IETF publishing this = particular profile, and not any other profile? Is this an IETF recommended = profile? If, so then the document should state why. If not, then the docume= nt should state that this is just one possible profile, and that the IETF d= oes not recommend for or against it. [[david]] It is a profile proposed by several operators and supported by ot= her ones. Maybe you have some other proposition for mobile profile but as o= perators, this list of requirements fits our needs. Ok. So maybe you can put in the draft that this profile is a profile suppor= ted by several operators, but not necessarily endorsed by the IETF? [Med] The document followed the IETF procedures and was benefited from the = inputs and review of IETF participants; and as such it is an IETF document.= We included text to precise this is not a standard but an informational do= cument. FWIW, we formally asked for guidance from the wg in Orlando (see ht= tp://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment w= as made at that time. I think the fundamental problem with this document is that it does not prov= ide solid reasons for why all 34 requirements need to be implemented (and p= ersonally, I think that's because it just can't - there *are* no solid reas= ons). [[david]] Did you mention that not all requirements are mandatory ? It give= s flexibility to operators to define what they are expecting from vendors. Sure, but the majority are mandatory, and don't forget that some of them ar= e quite large (e.g., "implement RFC 6204"). Also, I believe it's not the IE= TF's role to produce vendor requirements documents. The considerations that= the IETF deals with are primarily technical, and "we want this stuff from = our vendors" is not a technical issue. [Med] With all due respect, you are keeping the same argument since the ini= tial call for adoption and you seem ignore we are not in that stage. That's= not fair at all. Some devices have been connected to IP networks for tens of years now and = it does not mean we should not add new features to these devices to enable = new services. We are considering, as operators, that current IPv6 features = in mobile devices do not satisfy all our needs as mentioned in the document= . And how is it that you as an operator need all devices to meet requirement = #28 (a cellphone MUST also be a CPE router)? How can you say that it's nece= ssary to facilitate deployment? [Med] This is not for all mobile hosts but for those acting as mobile CPEs.= The text is clear. There are plenty deployments relying on the mobile netw= orks to provide broadband services. Device vendors people involved in discu= ssion with operators in this field are quite aware of this model. You can c= heck for instance: http://www.orange.tn/fixe-et-internet/pid382-la-flybox-o= range.html Oh, and I know it's a bit out of fashion, but: what happened to "running co= de"? Are there *any* implementations of all this? [[david]] We expect some implementations and we are thinking that such kind= of document may be useful to get some. Remember, the IETF is supposed to be about rough consensus and running code= . Can we wait until there is at least one implementation that does all this= before we publish the document? [Med] There is running code for several features listed in this document. B= ecause we don't have "decent" implementations which meet the minimal set of= requirements from operators, a group of these operators decided to carry o= n this effort to define a common profile. Saying that, it seems to me you w= ant to impose specific rules only for this document!! --_000_94C682931C08B048B7A8645303FDC9F36EF033645APUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

S= ee inline.

 =

Cheers,

Med<= o:p>

 

=

De : Lorenzo Coli= tti [mailto:lorenzo@google.com]
Envoy=E9 : mercredi 4 septe= mbre 2013 10:51
=C0 : BINET David IMT/OLN
Cc : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org WG; IETF Discussion
Objet=  : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profi= le-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile D= evices) to Informational RFC

 

On Wed, Sep 4, 2013 = at 5:29 PM, <david.binet@orange.com> wrote:

But wait... if it's just *a* profile, then why= is the IETF publishing this particular profile, and not any other profile?= Is this an IETF recommended profile? If, so then the document should state= why. If not, then the document should state that this is just one possible= profile, and that the IETF does not recommend for or against it.

[[david]] It is a profile proposed by several operators and supp= orted by other ones. Maybe you have some other proposition f= or mobile profile but as operators, this list of requirements fit= s our needs.     

Ok. So maybe y= ou can put in the draft that this profile is a profile supported by several= operators, but not necessarily endorsed by the IETF?

[Med] The document followed the IETF procedures and was b= enefited from the inputs and review of IETF participants; and as such it is= an IETF document. We included text to precise this is not a standard but a= n informational document. FWIW, we formally asked for guidance from the wg = in Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment was made at that time.

 Some devices have been connect= ed to IP networks for tens of years now and it does not mean we should not = add new features to these devices to enable new services. We are considerin= g, as operators, that current IPv6 features in mobile devices do = not satisfy all our needs as mentioned in the document.  <= /o:p>

Oh, and I know it's a bit out of fashion, b= ut: what happened to "running code"? Are there *any* implementati= ons of all this?

[[david]] We expect some implementatio= ns and we are thinking that such kind of document may be useful to get= some.

Remember, the IETF is supposed to be about rou= gh consensus and running code. Can we wait until there is at least one impl= ementation that does all this before we publish the document?

[Med] There is running code for several features = listed in this document. Because we don’t have “decent” i= mplementations which meet the minimal set of requirements from operators, a= group of these operators decided to carry on this effort to define a commo= n profile. Saying that, it seems to me you want to impose specific rules on= ly for this document!!

=
= --_000_94C682931C08B048B7A8645303FDC9F36EF033645APUEXCB1Bnante_-- From lorenzo@google.com Wed Sep 4 02:25:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D621E80AB for ; Wed, 4 Sep 2013 02:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-DZAbjZoo-r for ; Wed, 4 Sep 2013 02:25:41 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9E811E8192 for ; Wed, 4 Sep 2013 02:25:38 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id 16so71723iea.1 for ; Wed, 04 Sep 2013 02:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5uFTqPgo/occq2vGachxAh8SuyT0HDtsSSQmAy0dhwY=; b=PLrupMSbLxtjMu+rGuPWUYwZUEjNLtW+5jDxv3ftGvyxLAXsGofZbacrVRajaBPxOz JGzXVPd64WOtBSO3fwGyCkvn0YaKmgPpmIzfTRMM14SOy0g2Ijt8xucb6KO5zBBHxMJ+ zHtwm0Z+N6+Kzgh1E/ZcIiywrO25L/nHjPf/kmqba34xgqobrdj3icm+7V/j/9nUOGYG UJqx3pXiwr6Yo9lW2Y8MB4J13mEmYyJLyIIeTiYBSuT6xkJHWUZpPONPCxBdzoR4xdv9 Av1Zbef4yECPEwX3kDrHx0qpYTyNCRiKULrX6a+ZIKpfOrfOQ3wcs0deuGlFRIpHBlho boxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5uFTqPgo/occq2vGachxAh8SuyT0HDtsSSQmAy0dhwY=; b=RevBDU+6XtzXBjogocGIVpzPVP1WZ1/hrlWU/ridgHWDiH4hYE9pBntyt+x3DkaMd0 RBnH8zkyc351vANtV6DIKP1OygzNXJayOZk6ewFIFeZeuzsOiXBZDuQ4uYLim5DQSr8W 5onAECPCiS6sDjf78RBS5hO5VQN9HSLC9FSefI//zEyMTp7+o8NndpfrcWlsEHCITcOp qKr/KuM4Bc6BV2fwvrwVZ+jfg/CwH3vrwkFoZBxqGIRiBGKTacdmmAkpkr+SHuZB0xyt 9xUWsrfOcUp6Y+vT5/Ep5uuojtRnrMgrh8GDclLASEe477oycDJgexnS0UXN404He3Xo zLkA== X-Gm-Message-State: ALoCoQkZGIUHeAWZ58FMZO1j57sJ7/rwsb1bm7pHDGgAIccNvN2gnXztvzmD9G32tZANlidtDJPXaga8B3uZm+wpI85PYEHxYVRVdZDxQNN/hrmF1QUq4bKdzDKTj9H+3JuVyK/g/QOfJBShg1/SjLHaON4Hg8ggCjaNwJReemg2ilmkxI6OVcRQki7FsHiNR0HAP64I9NjL X-Received: by 10.50.119.42 with SMTP id kr10mr1138006igb.20.1378286737740; Wed, 04 Sep 2013 02:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Wed, 4 Sep 2013 02:25:17 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Wed, 4 Sep 2013 18:25:17 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=089e013c64aa66f78904e58b6367 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:25:42 -0000 --089e013c64aa66f78904e58b6367 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2013 at 6:07 PM, wrote: > Ok. So maybe you can put in the draft that this profile is a profile > supported by several operators, but not necessarily endorsed by the IETF? > ** > > *[Med] The document followed the IETF procedures and was benefited from > the inputs and review of IETF participants; and as such it is an IETF > document. We included text to precise this is not a standard but an > informational document. FWIW, we formally asked for guidance from the wg = in > Orlando (see http://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) > but no comment was made at that time.* > Then state in the document that this profile is recommended by the IETF, and if you get consensus on that, great. But the document should say *something* about this. > Sure, but the majority are mandatory, and don't forget that some of them > are quite large (e.g., "implement RFC 6204"). Also, I believe it's not th= e > IETF's role to produce vendor requirements documents. The considerations > that the IETF deals with are primarily technical, and "we want this stuff > from our vendors" is not a technical issue.**** > > *[Med] With all due respect, you are keeping the same argument since the > initial call for adoption and you seem ignore we are not in that stage. > That=92s not fair at all.* > I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. > *[Med] This is not for all mobile hosts but for those acting as mobile > CPEs. The text is clear.* > True. The document does define "cellular device" as something that's capable of sharing WAN connectivity. I don't suppose you could pick another word than "device" here? It's confusing, because "device" usually refers to any engineered object. Maybe use the word "sharing" or tethering" in the name? > *[Med] There is running code for several features listed in this > document. Because we don=92t have =93decent=94 implementations which meet= the > minimal set of requirements from operators, a group of these operators > decided to carry on this effort to define a common profile. Saying that, = it > seems to me you want to impose specific rules only for this document!!* > But the IETF doesn't define profile documents. The IETF defines technical standards on the basis of rough consensus and running code. What you're saying is "since we don't have running code that does what we want, we're trying to define a profile in the hope that someone will write the code". That's not the way it works. --089e013c64aa66f78904e58b6367 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 4, 2013 at 6:07 PM, <mohamed.bouc= adair@orange.com> wrote:

Ok. So maybe you can put in the draft = that this profile is a profile supported by several operators, but not nece= ssarily endorsed by the IETF?

[Med] The document followed the IETF procedures and was benefited fro= m the inputs and review of IETF participants; and as such it is an IETF doc= ument. We included text to precise this is not a standard but an informatio= nal document. FWIW, we formally asked for guidance from the wg in Orlando (= see http://www.ietf.org/proceedings/86/slides/slides-86-v6op= s-9) but no comment was made at that time.

Then state in the document that this pr= ofile is recommended by the IETF, and if you get consensus on that, great. = But the document should say *something* about this.

Sure, but the maj= ority are mandatory, and don't forget that some of them are quite large= (e.g., "implement RFC 6204"). Also, I believe it's not the I= ETF's role to produce vendor requirements documents. The considerations= that the IETF deals with are primarily technical, and "we want this s= tuff from our vendors" is not a technical issue.

[Med] With all due respect, you are ke= eping the same argument since the initial call for adoption and you seem ig= nore we are not in that stage. That=92s not fair at all.

I'm just saying it here so that eve= ryone in the community can see it. If it's an IETF document it has to h= ave IETF consensus, and since I feel that the arguments were not properly t= aken into account in the WG (read: ignored), I think it's important tha= t the community see them before we publish this document.

[Med] This is not for all mobile hosts but for those acting as mobile C= PEs. The text is clear.

True. The document does define &quo= t;cellular device" as something that's capable of sharing WAN conn= ectivity. I don't suppose you could pick another word than "device= " here? It's confusing, because "device" usually refers = to any engineered object. Maybe use the word "sharing" or tetheri= ng" in the name?

[Med] There is running code for several= features listed in this document. Because we don=92t have =93decent=94 imp= lementations which meet the minimal set of requirements from operators, a g= roup of these operators decided to carry on this effort to define a common = profile. Saying that, it seems to me you want to impose specific rules only= for this document!!

But the IETF doesn't define pr= ofile documents. The IETF defines technical standards on the basis of rough= consensus and running code. What you're saying is "since we don&#= 39;t have running code that does what we want, we're trying to define a= profile in the hope that someone will write the code". That's not= the way it works.
--089e013c64aa66f78904e58b6367-- From gert@space.net Wed Sep 4 02:31:09 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92B11E8190 for ; Wed, 4 Sep 2013 02:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3F4EmVM3S4o for ; Wed, 4 Sep 2013 02:31:08 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 684E111E818F for ; Wed, 4 Sep 2013 02:31:08 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 25DB760B0D for ; Wed, 4 Sep 2013 11:31:06 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 0A58560AEF for ; Wed, 4 Sep 2013 11:31:06 +0200 (CEST) Received: (qmail 89902 invoked by uid 1007); 4 Sep 2013 11:31:05 +0200 Date: Wed, 4 Sep 2013 11:31:05 +0200 From: Gert Doering To: Lorenzo Colitti Message-ID: <20130904093105.GM65295@Space.Net> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:31:09 -0000 Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: > > Sure, but the majority are mandatory, and don't forget that some of them > > are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the > > IETF's role to produce vendor requirements documents. The considerations > > that the IETF deals with are primarily technical, and "we want this stuff > > from our vendors" is not a technical issue.**** > > > > *[Med] With all due respect, you are keeping the same argument since the > > initial call for adoption and you seem ignore we are not in that stage. > > That?s not fair at all.* > > > I'm just saying it here so that everyone in the community can see it. If > it's an IETF document it has to have IETF consensus, and since I feel that > the arguments were not properly taken into account in the WG (read: > ignored), I think it's important that the community see them before we > publish this document. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From mohamed.boucadair@orange.com Wed Sep 4 02:43:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104E811E80E3; Wed, 4 Sep 2013 02:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbdtiBbMed+z; Wed, 4 Sep 2013 02:43:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7B511E812A; Wed, 4 Sep 2013 02:43:38 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A4D71324112; Wed, 4 Sep 2013 11:43:37 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 818E135C064; Wed, 4 Sep 2013 11:43:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 4 Sep 2013 11:43:34 +0200 From: To: Lorenzo Colitti Date: Wed, 4 Sep 2013 11:43:29 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6pULkLnE/PAMgNQcS/FNg0F0fa7QAAIK2g Message-ID: <94C682931C08B048B7A8645303FDC9F36EF033649B@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF033649BPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.90030 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:43:50 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF033649BPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : mercredi 4 septembre 2013 11:25 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : BINET David IMT/OLN; v6ops@ietf.org WG; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Wed, Sep 4, 2013 at 6:07 PM, > wrote: Ok. So maybe you can put in the draft that this profile is a profile suppor= ted by several operators, but not necessarily endorsed by the IETF? [Med] The document followed the IETF procedures and was benefited from the = inputs and review of IETF participants; and as such it is an IETF document.= We included text to precise this is not a standard but an informational do= cument. FWIW, we formally asked for guidance from the wg in Orlando (see ht= tp://www.ietf.org/proceedings/86/slides/slides-86-v6ops-9) but no comment w= as made at that time. Then state in the document that this profile is recommended by the IETF, an= d if you get consensus on that, great. But the document should say *somethi= ng* about this. [Med] What statement you would like to see added? Thanks. Sure, but the majority are mandatory, and don't forget that some of them ar= e quite large (e.g., "implement RFC 6204"). Also, I believe it's not the IE= TF's role to produce vendor requirements documents. The considerations that= the IETF deals with are primarily technical, and "we want this stuff from = our vendors" is not a technical issue. [Med] With all due respect, you are keeping the same argument since the ini= tial call for adoption and you seem ignore we are not in that stage. That's= not fair at all. I'm just saying it here so that everyone in the community can see it. If it= 's an IETF document it has to have IETF consensus, and since I feel that th= e arguments were not properly taken into account in the WG (read: ignored),= I think it's important that the community see them before we publish this = document. [Med] This is not for all mobile hosts but for those acting as mobile CPEs.= The text is clear. True. The document does define "cellular device" as something that's capabl= e of sharing WAN connectivity. I don't suppose you could pick another word = than "device" here? It's confusing, because "device" usually refers to any = engineered object. Maybe use the word "sharing" or tethering" in the name? [Med] The use of "cellular device" is governed by the definition included i= n the document: o "3GPP cellular host" (or cellular host for short) denotes a 3GPP device which can be connected to 3GPP mobile networks or IEEE 802.11 networks. o "3GPP cellular device" (or cellular device for short) refers to a cellular host which supports the capability to share its WAN (Wide Area Network) connectivity. and ... This section focuses on cellular devices (e.g., CPE, smartphones or dongles with tethering features) which provide IP connectivity to other devices connected to them. In such case, all connected devices are sharing the same 2G, 3G or LTE connection. In addition to the generic requirements listed in Section 2, these cellular devices ha= ve to meet the requirements listed below. Because I'm naively assuming the reader interprets this term according to = the definition provided in the document, I don't see what is confusing in s= uch wording. [Med] There is running code for several features listed in this document. B= ecause we don't have "decent" implementations which meet the minimal set of= requirements from operators, a group of these operators decided to carry o= n this effort to define a common profile. Saying that, it seems to me you w= ant to impose specific rules only for this document!! But the IETF doesn't define profile documents. The IETF defines technical s= tandards on the basis of rough consensus and running code. What you're sayi= ng is "since we don't have running code that does what we want, we're tryin= g to define a profile in the hope that someone will write the code". That's= not the way it works. [Med] This document is not a standard. This is explicitly mentioned in the = document. --_000_94C682931C08B048B7A8645303FDC9F36EF033649BPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

P= lease see inline.

 =

Cheers,

Med

 

=

De : Loren= zo Colitti [mailto:lorenzo@google.com]
Envoy=E9 : mercredi = 4 septembre 2013 11:25
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc : BINET David IMT/OLN; v6ops@ietf.org WG; IETF Discussion
<= b>Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-devic= e-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP M= obile Devices) to Informational RFC

 

On Wed, Sep 4= , 2013 at 6:07 PM, <mohamed.boucadair@orange.com> wrote:

Ok. So maybe you can put in the draft that this profile is a = profile supported by several operators, but not necessarily endorsed by the= IETF?

[Med] The document followed the IETF = procedures and was benefited from the inputs and review of IETF participant= s; and as such it is an IETF document. We included text to precise this is = not a standard but an informational document. FWIW, we formally asked for g= uidance from the wg in Orlando (see http://www.ietf.org/proc= eedings/86/slides/slides-86-v6ops-9) but no comment was made at that ti= me.

Then state in the document that this profile is recommended = by the IETF, and if you get consensus on that, great. But the document shou= ld say *something* about this.

[Med]= What statement you would like to see added? Thanks.

=

Sure, but the majority are mandatory, and don't for= get that some of them are quite large (e.g., "implement RFC 6204"= ). Also, I believe it's not the IETF's role to produce vendor requirements = documents. The considerations that the IETF deals with are primarily techni= cal, and "we want this stuff from our vendors" is not a technical= issue.

[Med] With all due respect, you are = keeping the same argument since the initial call for adoption and you seem = ignore we are not in that stage. That’s not fair at all.

I= 'm just saying it here so that everyone in the community can see it. If it'= s an IETF document it has to have IETF consensus, and since I feel that the= arguments were not properly taken into account in the WG (read: ignored), = I think it's important that the community see them before we publish this d= ocument.

[Med] This is not for all mobile hosts bu= t for those acting as mobile CPEs. The text is clear.

True. The = document does define "cellular device" as something that's capabl= e of sharing WAN connectivity. I don't suppose you could pick another word = than "device" here? It's confusing, because "device" us= ually refers to any engineered object. Maybe use the word "sharing&quo= t; or tethering" in the name?

[= Med] The use of “cellular device” is governed by the definition= included in the document:

 

=A0=A0 o=A0 "3GPP cell= ular host" (or cellular host for short) denotes a 3GPP

=A0=A0=A0=A0=A0 device which can be connected to 3GPP mobile net= works or IEEE

=A0=A0=A0=A0=A0 802.11 networks.

 

=A0=A0 o=A0 "= 3GPP cellular device" (or cellular device for short) refers to a<= /o:p>

=A0=A0=A0=A0=A0 cellular host which supports the capab= ility to share its WAN (Wide

=A0=A0=A0=A0=A0 Area= Network) connectivity.

=  

and …

 
=A0=A0 This section =
focuses on cellular devices (e.g., CPE, smartphones or
=A0=A0 dongles with tethering features) which provide IP connectivity to
=A0=A0 other devices connected to them.=A0 In such case=
, all connected devices
=A0=A0 are sharing the same 2G=
, 3G or LTE connection.=A0 In addition to the
=A0=A0 g=
eneric requirements listed in Section 2, these cellular=
 devices have
=A0=A0 to meet the requirements listed b=
elow.

 =

=A0Because I’m naively assuming the reade= r interprets this term according to the definition provided in the document= , I don’t see what is confusing in such wording.

[Med] There is running code for several features listed in thi= s document. Because we don’t have “decent” implementation= s which meet the minimal set of requirements from operators, a group of the= se operators decided to carry on this effort to define a common profile. Sa= ying that, it seems to me you want to impose specific rules only for this d= ocument!!

But the IETF doesn't define profile documents. The IE= TF defines technical standards on the basis of rough consensus and running = code. What you're saying is "since we don't have running code that doe= s what we want, we're trying to define a profile in the hope that someone w= ill write the code". That's not the way it works.

[Med] This document is not a standard. This is explicitl= y mentioned in the document.

= = --_000_94C682931C08B048B7A8645303FDC9F36EF033649BPUEXCB1Bnante_-- From jiangsheng@huawei.com Wed Sep 4 03:00:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E83821F9DBA for ; Wed, 4 Sep 2013 03:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol0P7zytPH+I for ; Wed, 4 Sep 2013 03:00:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D28B21E8086 for ; Wed, 4 Sep 2013 03:00:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWW82389; Wed, 04 Sep 2013 10:00:40 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 11:00:11 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Sep 2013 11:00:25 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.66]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Wed, 4 Sep 2013 18:00:16 +0800 From: Sheng Jiang To: GangChen Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-experience WGLC Thread-Index: AQHOpz0vWCDAHDiqKkSa1e+LJBgdQJmznjkAgAEXhACAAKbD4A== Date: Wed, 4 Sep 2013 10:00:15 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD05DFE@nkgeml512-mbx.china.huawei.com> References: <201309011800.r81I0Ao1006741@irp-view13.cisco.com> <5D36713D8A4E7348A7E10DF7437A4B923AD05610@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 10:00:51 -0000 WW91IHJlc3BvbnNlIGxvb2tzIHByb3BlciBmb3IgbWUuDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEdhbmdDaGVuIFttYWlsdG86cGhkZ2FuZ0BnbWFpbC5j b21dDQo+U2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTMgNDowMyBQTQ0KPlRvOiBT aGVuZyBKaWFuZw0KPkNjOiBGcmVkIEJha2VyOyB2Nm9wc0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJl OiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtbmF0NjQtZXhwZXJpZW5jZSBXR0xDDQo+DQo+SGkg U2hlbmcsDQo+DQo+VGhhbmsgeW91IGZvciB5b3VyIGRldGFpbGVkIHJldmlldy4gUGxlYXNlIHNl ZSBteSByZXBseSBpbmxpbmUuDQo+DQo+MjAxMy85LzMsIFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5n QGh1YXdlaS5jb20+Og0KPj4gSGksIHY2b3BzIGFuZCBhdXRob3JzLA0KPj4NCj4+IEkgdm9sdW50 ZWVyZWQgdG8gcmV2aWV3IHRoaXMgZG9jdW1lbnQgZHVyaW5nIElFVEY4NyBtZWV0aW5nLiBUaGUg YmVsb3cgaXMNCj5teQ0KPj4gY29tbWVudHMuDQo+Pg0KPj4gSW4gZ2VuZXJhbCwgdGhpcyBkb2N1 bWVudCBoYXZlIGRvbmUgYSBnb29kIGpvYiBvbiBzaGFyaW5nIHRoZWlyIE5BVDY0DQo+PiBleHBl cmllbmNlLiBUaGUgaW5mb3JtYXRpb24gaXMgdXNlZnVsIGZvciBJUHY2IHNvY2lldHkgYW5kIHRo ZSBkb2N1bWVudCBoYXMNCj4+IG9yZ2FuaXplZCBpbiBhIGZvcm0gZWFzeSB0byByZWFkIGFuZCB1 bmRlcnN0YW5kLg0KPj4NCj4+IFNvIEkgc3VwcG9ydCB0aGlzIFdHTEMuDQo+Pg0KPj4gU29tZSBu aXRzIGFyZSBhcyBmb2xsb3dpbmcuDQo+Pg0KPj4gVGhlIHNlY29uZCBhbmQgZm91cnRoIHBhcmFn cmFwaHMgYXJlIGJvdGggZGVzY3JpYmUgdGhlIGNvZXhpc3RlbmNlDQo+YmV0d2Vlbg0KPj4gSVB2 NCBhbmQgSVB2Ni4gTWVyZ2luZyB0aGVtIHRvZ2V0aGVyIHdvdWxkIGdldCBiZXR0ZXIgbG9naWNh bGl0eS4NCj4+DQo+PiBTZWN0aW9uIDMuMSBjb250YWlucyBmYWlybHkgbG9uZyBzdGF0ZW1lbnRz LiBJdCBtYXkgYmUgYmV0dGVyIHRvIGNyZWF0ZQ0KPj4gc3ViLXNlY3Rpb25zIHRvIGdhdWdlIHRo ZSBkaXNjdXNzaW9uLg0KPg0KPldlIHdpbGwgYWRkcmVzcyB0aGF0IGF0IHRoZSBuZXh0IHVwZGF0 ZS4NCj4NCj4+IEZvciB0aGUgc3RhdGVtZW50LA0KPj4NCj4+ICAgIFRoZXJlZm9yZSwgTkFUNjQg bWF5IHNlcnZlIGRvdWJsZSByb2xlcyBpbiBzb21lIGNhc2VzLA0KPj4gICAgaS5lLiBhIHRyYW5z bGF0b3IgYW5kIElQdjYgZm9yd2FyZGVyLiAgU29tZSBmYWlsdXJlIGNhc2VzIG1heSBvY2N1cg0K Pj4gICAgb25jZSBOQVQ2NCBzZXJ2ZXMgYSBJUHY2IGdhdGV3YXkgYnV0IGlzIGNvbmZpZ3VyZWQg b25seSB3aXRoIElQdjQgb24NCj4+DQo+PiBJdCBzaG91bGQgYmUgbm90ZWQgbmF0aXZlIElQdjYg cGF0aHMgbWF5IG5vdCB0cmF2ZXJzZSBOQVQ2NC4gWW91IG1heSBhZGQNCj4+IHNvbWUgZGlzY3Vz c2lvbnMgcmVnYXJkaW5nIHRoaXMgcG9pbnQuDQo+DQo+SSB3b3VsZCBtYWtlIGZvbGxvd2luZyBj aGFuZ2VzIG9uIHRoaXMgcG9pbnQNCj4NCj5PTEQNCj4tLS0tLS0tLS0tLS0tLS0NCj4gICBPcGVy YXRvcnMgc2hvdWxkIG5vdCBleHBlY3QgdG8gYWNjZXNzIElQdjQgcGFydHMNCj4gICBvZiBhIGR1 YWwtc3RhY2sgc2VydmVyIHVzaW5nIE5BVDY0L0ROUzY0LiAgTkFUNjQgd291bGQgZm9yd2FyZHMg YWxsDQo+ICAgdGhlIHRyYWZmaWMgb24gSVB2NiBwYXRocyBpZiBkdWFsLXN0YWNrIHNlcnZlcnMg YXJlIHRhcmdldGVkLiAgSW4NCj4gICBzb21lIHNlbnNlLCBpdCBlbmNvdXJhZ2VzIElQdjYgdHJh bnNtaXNzaW9uIGFuZCByZXN0cmFpbnMgTkFUIHVzZXMNCj4gICBjb21wYXJlZCB0byBOQVQ0NChp ZiB1c2VkKSwgb24gd2hpY2ggYWxsIHRyYWZmaWMgZmxvd3MgaGF2ZSB0bw0KPiAgIHRyYXZlcnNl LiAgVGhlcmVmb3JlLCBOQVQ2NCBtYXkgc2VydmUgZG91YmxlIHJvbGVzIGluIHNvbWUgY2FzZXMs DQo+ICAgaS5lLiBhIHRyYW5zbGF0b3IgYW5kIElQdjYgZm9yd2FyZGVyLiAgU29tZSBmYWlsdXJl IGNhc2VzIG1heSBvY2N1cg0KPiAgIG9uY2UgTkFUNjQgc2VydmVzIGEgSVB2NiBnYXRld2F5IGJ1 dCBpcyBjb25maWd1cmVkIG9ubHkgd2l0aCBJUHY0IG9uDQo+ICAgV0FOIGxpbmtzLiAgV2UgdGVz dGVkIG9uIFRvcDEwMCB3ZWJzaXRlcyAocmVmZXJyaW5nIHRvIFtBbGV4YV0NCj4gICBzdGF0aXN0 aWNzKSBpbiBzdWNoIGNvbmRpdGlvbi4gNDMlIG9mIHdlYnNpdGVzIGFyZSBmYWlsZWQgdG8gYmUN Cj4gICBjb25uZWN0ZWQgc2luY2UgdGhvc2Ugd2Vic2l0ZXMgaGF2ZSBib3RoIEFBQUEgYW5kIEEg cmVjb3Jkcy4gIFRvIGJlDQo+ICAgcmVsaWFibGUsIGl0J3MgcmVjb21tZW5kZWQgdG8gZW5hYmxl IE5BVDY0IFdBTiBsaW5rcyB3aXRoIGR1YWwtc3RhY2sNCj4gICBjb25uZWN0aW9ucyBpbiB0aGUg ZGVwbG95bWVudC4NCj4NCj5ORVcNCj4tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgIE9wZXJhdG9ycyBz aG91bGQgbm90IGV4cGVjdCB0byBhY2Nlc3MgSVB2NCBwYXJ0cw0KPiAgIG9mIGEgZHVhbC1zdGFj ayBzZXJ2ZXIgdXNpbmcgTkFUNjQvRE5TNjQuIFRoZSB0cmFmZmljIGlzIGZvcndhcmRlZA0KPiAg IG9uIElQdjYgcGF0aHMgaWYgZHVhbC1zdGFjayBzZXJ2ZXJzIGFyZSB0YXJnZXRlZC4gSVB2NiB0 cmFmZmljIG1heSBiZSByb3V0ZWQNCj4gICBub3QgZ29pbmcgdGhyb3VnaCBOQVQ2NC4gT25seSB0 aGUgdHJhZmZpYyBnb2luZyB0byBJUHY0LW9ubHkgc2VydmljZQ0KPiAgIHdvdWxkIHRyYXZlcnNl IE5BVDY0LiBJbiBzb21lIHNlbnNlLCBpdCBlbmNvdXJhZ2VzIElQdjYgdHJhbnNtaXNzaW9uDQo+ ICAgYW5kIHJlc3RyYWlucyBOQVQgdXNlcyBjb21wYXJlZCB0byBOQVQ0NChpZiB1c2VkKSwgb24g d2hpY2ggYWxsIHRyYWZmaWMNCj4gICBmbG93cyBoYXZlIHRvIGJlIHRyYXZlcnNlZCBhbmQgdHJh bnNsYXRlZC4gSW4gc29tZSBjYXNlcywgTkFUNjQtQ0dODQo+bWF5DQo+ICAgc2VydmUgZG91Ymxl IHJvbGVzLCBpLmUuIGEgdHJhbnNsYXRvciBhbmQgSVB2NiBmb3J3YXJkZXIuIFNvbWUgZmFpbHVy ZQ0KPiAgIGNhc2VzIG1heSBiZSBvY2N1cmVkIG9uY2UgTkFUNjQgc2VydmVzIGEgSVB2NiBnYXRl d2F5IHdoaWxlIGlzDQo+Y29uZmlndXJlZA0KPiAgIG9ubHkgd2l0aCBJUHY0IG9uIFdBTiBsaW5r cy4gIFdlIHRlc3RlZCBvbiBUb3AxMDAgd2Vic2l0ZXMNCj4ocmVmZXJyaW5nIHRvIFtBbGV4YV0N Cj4gICBzdGF0aXN0aWNzKSBpbiBzdWNoIGNvbmRpdGlvbi4gNDMlIG9mIHdlYnNpdGVzIGFyZSBm YWlsZWQgdG8gYmUNCj4gICBjb25uZWN0ZWQgc2luY2UgdGhvc2Ugd2Vic2l0ZXMgaGF2ZSBib3Ro IEFBQUEgYW5kIEEgcmVjb3Jkcy4gVGhlcmVmb3JlLA0KPml0J3MNCj4gICByZWNvbW1lbmRlZCB0 byBlbmFibGUgTkFUNjQgV0FOIGxpbmtzIHdpdGggZHVhbC1zdGFjayBjb25uZWN0aW9ucw0KPmlu IHN1Y2ggY2FzZS4NCj4NCj4NCj4+IFNlY3Rpb24gNC4xIGhhcyBkb25lIGEgZ29vZCBkaXNjdXNz aW9uIG9uIHRoZSBkaWZmZXJlbnQgZmxhdm9ycyBvZg0KPj4gcmVkdW5kYW5jeS4gSXQgd291bGQg YmUgYmV0dGVyIHRvIG1vdmUgdGhlIHRlc3RpbmcgdGFibGUgaW50byB0aGUgYXBwZW5kaXguDQo+ PiBZb3UgY291bGQgZGV0YWlsIHRoZSB0ZXN0aW5nIGNvbmRpdGlvbiBzbyBhdWRpZW5jZXMgY291 bGQgY29tcGFyZSBpdCB3aXRoDQo+PiB0aGVpci1vd24gc2l0dWF0aW9uLg0KPg0KPkl0IHdpbGwg YmUgZG9uZSBhdCB0aGUgbmV4dCB1cGRhdGUuDQo+DQo+DQo+PiBJbiBzZWN0aW9uIDQuMiwgeW91 IGhhdmUgdGhlIGJlbG93IHRleHQNCj4+DQo+PiAgICAgICBXaXRoIHRoZSBhYnNlbmNlIG9mIERO UzY0LCBpbnRlcm5hbA0KPj4gICAgICAgaG9zdHMgY291bGQgbGVhcm4gbXVsdGlwbGUgSVB2NiBw cmVmaXhlcyB0aHJvdWdoIHRoZSBhcHByb2FjaGVzDQo+PiAgICAgICBkZWZpbmVkIGluW0ktRC5p ZXRmLWJlaGF2ZS1uYXQ2NC1kaXNjb3ZlcnktaGV1cmlzdGljXS4uLg0KPj4NCj4+IEhvd2V2ZXIs IEktRC5pZXRmLWJlaGF2ZS1uYXQ2NC1kaXNjb3ZlcnktaGV1cmlzdGljIGFsc28gcmVxdWVzdHMg RE5TNjQNCj4+IGludm9sdmVtZW50LiBJdCBtYXkgbmVlZCBzb21lIGNsYXJpZmljYXRpb25zID8N Cj4NCj5UaGFuayB5b3UgZm9yIHBvaW50aW5nIG1lIHRoaXMgaXNzdWUuIEkgd291bGQgbWFrZSBm b2xsb3dpbmcgY2hhbmdlDQo+DQo+ICAgICAgRm9yIHRoZSBhcHBsaWNhdGlvbnMgbm90IHJlcXVp cmluZyBETlMgcmVzb2x2ZXIsIGludGVybmFsDQo+ICAgICAgaG9zdHMgY291bGQgbGVhcm4gbXVs dGlwbGUgSVB2NiBwcmVmaXhlcyB0aHJvdWdoIHRoZSBhcHByb2FjaGVzDQo+ICAgICAgZGVmaW5l ZCBpbltJLUQuaWV0Zi1iZWhhdmUtbmF0NjQtZGlzY292ZXJ5LWhldXJpc3RpY10gYW5kIHRoZW4N Cj4gICAgICBzZWxlY3Qgb25lIGJhc2VkIG9uIGEgZ2l2ZW4gcHJlZml4IHNlbGVjdGlvbiBwb2xp Y3kuDQo+DQo+DQo+PiBJbiBzZWN0aW9uIDUuMiwgaXQgbWF5IGJlIHdvcnRoIHRvIGFkZCBhIHF1 b3RhIG9yIHJlZmVyZW5jZSB0byByZmM2OTY3LiBJdA0KPj4gYW5hbHl6ZXMgc2V2ZXJhbCBwb3Rl bnRpYWwgc29sdXRpb25zIGluIGdlby1sb2NhdGlvbiBhcmVhLg0KPg0KPkl0IHdhcyBtZW50aW9u ZWQgYXQNCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVu dC9tc2cxNzEzMS5odG1sLg0KPlRoZSBuZXcgdGV4dCBmb3IgdGhlIHN0YXRlbWVudCBpcw0KPg0K PiAgIG8gIFRoZSBOQVQ2NC1DR04gZXF1aXBtZW50cyBtYXkgbm90IGltcGxlbWVudCBYRkYuICBH ZW8tbG9jYXRpb24NCj4gICAgICBiYXNlZCBvbiBzaGFyZWQgSVB2NCBhZGRyZXNzIGlzIHJhdGhl ciBpbmFjY3VyYXRlIGluIHRoYXQgY2FzZS4NCj4gICAgICBbUkZDNjk2N10gYW5hbHl6ZWQgc2V2 ZXJhbCBvcHRpb25zIHRvIHJldmVhbCB0aGUgaG9zdCBpZGVudGlmaWVyLg0KPiAgICAgIEVhY2gg b25lIG1heSBoYXZlIHRoZWlyLW93biBzcGVjaWZpYyB1c2FnZS4gV2l0aCByZWdhcmRzIHRvDQo+ ICAgICAgTkFUNjQgZGVwbG95bWVudCwgaXQncyBkZXNpcmFibGUgdG8gb2ZmZXIgZ2VvLWxvY2F0 aW9uIHN5c3RlbQ0KPiAgICAgIHRoZSBpbnRlcm5hbCBJUHY2IGFkZHJlc3MsIHdoaWNoIGhhcyB0 aGUgbWVhbmluZyBpbiBnbG9iYWwgc2NhbGUuDQo+ICAgICAgRm9yIHRoZSBnZW8tbG9jYXRpb24g c3lzdGVtcyByZWx5aW5nIG9uIGEgUmFkaXVzIGRhdGFiYXNlW1JGQzU1ODBdLA0KPndlDQo+ICAg ICAgaGF2ZSBpbnZlc3RpZ2F0ZWQgdG8gZGVsaXZlciBOQVQ2NCBCSUJzIGFuZCBTZXNzaW9uIFRh YmxlIEVudHJ5cw0KPihTVEVzKQ0KPiAgICAgIHRvIGEgUmFkaXVzIHNlcnZlcltJLUQuY2hlbi1i ZWhhdmUtbmF0NjQtcmFkaXVzLWV4dGVuc2lvbl0uDQo+ICAgICAgVGhpcyBtZXRob2QgY291bGQg Z2V0IGFsb25nIHdpdGggW1JGQzU1ODBdIHRvIGNvbnZleSBvcmlnaW5hbCBzb3VyY2UNCj4gICAg ICBhZGRyZXNzIHRocm91Z2ggc2FtZSBtZXNzYWdlIGJ1cy4NCj4NCj5CZXN0IFJlZ2FyZHMNCj4N Cj5HYW5nDQo+DQo+PiBCZXN0IHJlZ2FyZHPvvIwNCj4+DQo+PiBTaGVuZw0KPj4NCj4+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj5PZiBGcmVkIEJha2Vy DQo+Pj5TZW50OiBNb25kYXksIFNlcHRlbWJlciAwMiwgMjAxMyAyOjAwIEFNDQo+Pj5UbzogdjZv cHNAaWV0Zi5vcmcNCj4+PlN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1uYXQ2NC1l eHBlcmllbmNlIFdHTEMNCj4+Pg0KPj4+VGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9mDQo+Pj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UuICBQbGVhc2UgcmVhZA0KPj4+IGl0DQo+ Pj5ub3cuIElmIHlvdSBmaW5kIG5pdHMNCj4+PihzcGVsbGluZyBlcnJvcnMsIG1pbm9yIHN1Z2dl c3RlZCB3b3JkaW5nIGNoYW5nZXMsIGV0YyksIGNvbW1lbnQgdG8gdGhlDQo+Pj5hdXRob3JzOyBp ZiB5b3UgZmluZCBncmVhdGVyIGlzc3Vlcywgc3VjaCBhcyBkaXNhZ3JlZWluZyB3aXRoIGENCj4+ PnN0YXRlbWVudCBvciBmaW5kaW5nIGFkZGl0aW9uYWwgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBh ZGRyZXNzZWQsDQo+Pj5wbGVhc2UgcG9zdCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0Lg0KPj4+ DQo+Pj5XZSBhcmUgbG9va2luZyBzcGVjaWZpY2FsbHkgZm9yIGNvbW1lbnRzIG9uIHRoZSBpbXBv cnRhbmNlIG9mIHRoZQ0KPj4+ZG9jdW1lbnQgYXMgd2VsbCBhcyBpdHMgY29udGVudC4gSWYgeW91 IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kDQo+Pj5iZWxpZXZlIGl0IHRvIGJlIG9mIG9wZXJh dGlvbmFsIHV0aWxpdHksIHRoYXQgaXMgYWxzbyBhbiBpbXBvcnRhbnQNCj4+PmNvbW1lbnQgdG8g bWFrZS4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj52Nm9wcyBtYWlsaW5nIGxpc3QNCj4+PnY2b3BzQGlldGYub3JnDQo+Pj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+PiB2 Nm9wc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPj4NCg== From mohamed.boucadair@orange.com Wed Sep 4 04:05:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B781711E819E; Wed, 4 Sep 2013 04:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJCsPQ9UdZMS; Wed, 4 Sep 2013 04:05:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D4A9011E819B; Wed, 4 Sep 2013 04:05:23 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 914A626416F; Wed, 4 Sep 2013 13:05:22 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6F9164C056; Wed, 4 Sep 2013 13:05:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 4 Sep 2013 13:05:22 +0200 From: To: Abdussalam Baryun , ietf Date: Wed, 4 Sep 2013 13:05:21 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6kyWWc5+dIVOJWRauiW/ek7K88aQEk/8cQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF03364ED@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF03364EDPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.4.90627 Cc: "v6ops@ietf.org" , "iesg@ietf.org" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 11:05:30 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF03364EDPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Abdussalam, Many thanks for your review and suggestions. The changes you proposed have been integrated in -05 (see http://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-05). As for your question about IP mobility, this is not relevant in the context= of this document. Mobility is managed following 3GGP specific procedures. Cheers, Med De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de A= bdussalam Baryun Envoy=E9 : mardi 27 ao=FBt 2013 13:05 =C0 : ietf Cc : v6ops@ietf.org; iesg@ietf.org Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC Reviewer: Abdussalam Baryun Date: 26.08.2013 As per the IESG request for review dated 19.08.2013 ++++++++++++++++++++++++++++++++++++ I support the draft, thanks, below are my comments, Overall> The draft is about 3GPP Mobile Devices but the draft has no normat= ive reference to such device. The title of the draft SHOULD mention that it= is general profile or a proposal, where the abstract says *specifies an IP= v6 profile* which means not general, so the title SHOULD say *An IPv6 profi= le*. Also the draft does not consider Mobile IP issues nor RFC5213 into req= uirements. From the doc the reviewer is not sure does the draft consider MA= NET issues or not needed for such devices or such connections? Abstract> This document specifies an IPv6 profile for 3GPP mobile devices. AB> suggest> this document defines an IPv6 profile.... The document is missing an applicability statement section, which may be fo= und in one paragraph in section 1.1, but the reviewer would like more detai= ls because the document is some how saying it is general requirements. AB On Mon, Aug 19, 2013 at 11:52 PM, The IESG > wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptiona= lly, comments may be sent to iesg@ietf.org instead. In either case, please= retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ball= ot/ No IPR declarations have been submitted directly on this I-D. --_000_94C682931C08B048B7A8645303FDC9F36EF03364EDPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Abdussalam, <= o:p>

 

Many thanks for your review and suggestions.<= /p>

The changes you proposed have been integrated in -05 = (see http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6o= ps-mobile-device-profile-05).

=  

As for your question about IP = mobility, this is not relevant in the context of this document. Mobility is= managed following 3GGP specific procedures.

 

Cheers,

Med

=  

 

=

De : v6ops-bounces@ietf.org [m= ailto:v6ops-bounces@ietf.org] De la part de Abdussalam Baryun
= Envoy=E9 : mardi 27 ao=FBt 2013 13:05
=C0 : ietf
Cc : v6ops@ietf.org; iesg@ietf.orgObjet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-dev= ice-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP= Mobile Devices) to Informational RFC

 

Review= er: Abdussalam Baryun

Date: 2= 6.08.2013

 

As per the IESG request for review dated = 19.08.2013

++++++++++++++++++= ++++++++++++++++++

 = ;

I support the draft, thanks, bel= ow are my comments,

&nbs= p;

Overall> The draft is about = 3GPP Mobile Devices but the draft has no normative reference to such device= . The title of the draft SHOULD mention that it is general profile or a pro= posal, where the abstract says *specifies an IPv6 profile* which means not = general, so the title SHOULD say *An IPv6 profile*. Also the draft does not= consider Mobile IP issues nor RFC5213 into requirements. From the doc the = reviewer is not sure does the draft consider MANET issues or not needed for= such devices or such connections?

 
 
=
 
= 
Abstract> This documen=
t specifies an IPv6 profile for 3GPP mobile devices.
 =

 
 

AB> suggest> this doc= ument defines an IPv6 profile....

 

The document is m= issing an applicability statement section, which may be found in one paragr= aph in section 1.1, but the reviewer would like more details because the do= cument is some how saying it is general requirements.

<= div>

 

AB

 

On Mon, Aug 19= , 2013 at 11:52 PM, The IESG <iesg-secretary@ietf.org> wrote:


The IESG has received = a request from the IPv6 Operations WG (v6ops) to
consider the following = document:
- 'Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile = Devices'
  <draft-ietf-v6ops-mobile-device-profile-04.txt> as= Informational RFC

The IESG plans to make a decision in the next few= weeks, and solicits
final comments on this action. Please send substant= ive comments to the
ietf@ietf.org m= ailing lists by 2013-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, plea= se retain the
beginning of the Subject line to allow automated sorting.<= br>
Abstract


   This document specifies an IPv6 pro= file for 3GPP mobile devices.  It
   lists the set of fea= tures a 3GPP mobile device is to be compliant
   with to conne= ct to an IPv6-only or dual-stack wireless network
   (includin= g 3GPP cellular network and IEEE 802.11 network).

   This = document defines a different profile than the one for general
  &nb= sp;connection to IPv6 cellular networks defined in
   [I-D.iet= f-v6ops-rfc3316bis].  In particular, this document identifies
 = ;  also features to deliver IPv4 connectivity service over an IPv6-onl= y
   transport.

   Both hosts and devices wit= h capability to share their WAN (Wide Area
   Network) connect= ivity are in scope.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-mob= ile-device-profile/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6op= s-mobile-device-profile/ballot/


No IPR declarations have bee= n submitted directly on this I-D.

 

= --_000_94C682931C08B048B7A8645303FDC9F36EF03364EDPUEXCB1Bnante_-- From v6ops@globis.net Fri Sep 6 07:33:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935C911E82BF; Fri, 6 Sep 2013 07:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00fyEd49yMOa; Fri, 6 Sep 2013 07:33:12 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A77411E82C2; Fri, 6 Sep 2013 07:33:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9619087007D; Fri, 6 Sep 2013 16:32:46 +0200 (CEST) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5PiRlQ5ro0E; Fri, 6 Sep 2013 16:32:46 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 62BA4870076; Fri, 6 Sep 2013 16:32:46 +0200 (CEST) Message-ID: <5229E788.5030805@globis.net> Date: Fri, 06 Sep 2013 16:32:40 +0200 From: Ray Hunter User-Agent: Postbox 3.0.8 (Macintosh/20130427) MIME-Version: 1.0 To: Gert Doering References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <20130904093105.GM65295@Space.Net> In-Reply-To: <20130904093105.GM65295@Space.Net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:33:12 -0000 Gert Doering wrote: > Hi, > > On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: >>> Sure, but the majority are mandatory, and don't forget that some of them >>> are quite large (e.g., "implement RFC 6204"). Also, I believe it's not the >>> IETF's role to produce vendor requirements documents. The considerations >>> that the IETF deals with are primarily technical, and "we want this stuff >>> from our vendors" is not a technical issue.**** >>> >>> *[Med] With all due respect, you are keeping the same argument since the >>> initial call for adoption and you seem ignore we are not in that stage. >>> That?s not fair at all.* >>> >> I'm just saying it here so that everyone in the community can see it. If >> it's an IETF document it has to have IETF consensus, and since I feel that >> the arguments were not properly taken into account in the WG (read: >> ignored), I think it's important that the community see them before we >> publish this document. > > +1 > > Gert Doering > -- NetMaster I know I'm formally a couple of days late on the WGLC (work!). I agree with Lorenzo. And in any case it isn't ready to ship IMHO. e.g. How can REQ#33 and REQ#34 be enforced by a manufacturer (during compliance testing)? -- Regards, RayH From fred@cisco.com Sun Sep 8 11:00:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1533C21E80B3 for ; Sun, 8 Sep 2013 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNp9CUusz+ux for ; Sun, 8 Sep 2013 11:00:16 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 37F4C21E80A9 for ; Sun, 8 Sep 2013 11:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1378663216; x=1379872816; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=VGxTLR+HgE34HQbbmyY1tJl/AVLvgMbQWs1bTigoeEIS/+sUHQzQtnli mq2jW8PV5CnBG+l96lQwrYvfvY1lSM+vth3s+xHXjddcKu4IiQbtIzfo0 qIYZ5/iNhLQZvK6i36ldaFySvnYvw9dOtfD2kljcfUxRVGTU6+2TOSC75 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYIAIO6LFKrRDoJ/2dsb2JhbABagwewewGSFYEkFnSCSVw8NIhixj2QAB2EBwOJNaAmg0A X-IronPort-AV: E=Sophos;i="4.90,864,1371081600"; d="scan'208";a="91282990" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 08 Sep 2013 18:00:12 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r88I0Bbs015797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Sep 2013 18:00:11 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r88I0BXs006938; Sun, 8 Sep 2013 11:00:11 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r88I0Arb006933; Sun, 8 Sep 2013 11:00:10 -0700 (PDT) Date: Sun, 8 Sep 2013 11:00:10 -0700 (PDT) From: Fred Baker Message-Id: <201309081800.r88I0Arb006933@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-nat64-experience WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 18:00:22 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From mohamed.boucadair@orange.com Sun Sep 8 23:59:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2557F21E8146; Sun, 8 Sep 2013 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, J_CHICKENPOX_41=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2KcEqyPIHxF; Sun, 8 Sep 2013 23:59:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18121E8143; Sun, 8 Sep 2013 23:59:12 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5711818C1DD; Mon, 9 Sep 2013 08:59:11 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 39A0335C045; Mon, 9 Sep 2013 08:59:11 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 9 Sep 2013 08:59:11 +0200 From: To: Ray Hunter , Gert Doering Date: Mon, 9 Sep 2013 08:59:08 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6rDhrKs243fmBlQUKJqNPGizeitQCGeh0g Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D08C8@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <20130904093105.GM65295@Space.Net> <5229E788.5030805@globis.net> In-Reply-To: <5229E788.5030805@globis.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.9.60318 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:59:27 -0000 Hi Ray, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e >Ray Hunter >Envoy=E9=A0: vendredi 6 septembre 2013 16:33 >=C0=A0: Gert Doering >Cc=A0: v6ops@ietf.org WG; IETF Discussion >Objet=A0: Re: [v6ops] Last Call: 04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile >Devices) to Informational RFC > > >Gert Doering wrote: >> Hi, >> >> On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: >>>> Sure, but the majority are mandatory, and don't forget that some of >them >>>> are quite large (e.g., "implement RFC 6204"). Also, I believe it's not >the >>>> IETF's role to produce vendor requirements documents. The >considerations >>>> that the IETF deals with are primarily technical, and "we want this >stuff >>>> from our vendors" is not a technical issue.**** >>>> >>>> *[Med] With all due respect, you are keeping the same argument since >the >>>> initial call for adoption and you seem ignore we are not in that stage= . >>>> That?s not fair at all.* >>>> >>> I'm just saying it here so that everyone in the community can see it. I= f >>> it's an IETF document it has to have IETF consensus, and since I feel >that >>> the arguments were not properly taken into account in the WG (read: >>> ignored), I think it's important that the community see them before we >>> publish this document. >> >> +1 >> >> Gert Doering >> -- NetMaster > >I know I'm formally a couple of days late on the WGLC (work!). [Med] This was an IETF LC not WGLC...=20 > >I agree with Lorenzo. > >And in any case it isn't ready to ship IMHO. e.g. How can REQ#33 and >REQ#34 be enforced by a manufacturer (during compliance testing)? [Med] This can be part of the test campaigns to assess the behavior of appl= ications shipped with the device. This is in particular important for the a= pplications made available by the device vendor itself. For example, our te= ams tested a device which can get IPv6 connectivity...but the user cannot u= se the store from that vendor to get applications in IPv6-mode. There are o= ther applications which make use of IPv4 address literals, etc. The require= ments is valid for applications dev'ed by the vendor or a third-party. From lorenzo@google.com Mon Sep 9 04:01:50 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0866E21E815D for ; Mon, 9 Sep 2013 04:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5z9P6Vuiet5 for ; Mon, 9 Sep 2013 04:01:41 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6143821F9D9A for ; Mon, 9 Sep 2013 04:01:36 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id m16so9651814ieq.24 for ; Mon, 09 Sep 2013 04:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zuu+sY3srYBnEBRPYwnUIQcj9LUh3lFgcbPeFKUYRuc=; b=cp+F3XOK6SGd27Y6M+gwGkO502ZC1zy7rLxQ4JPFuIfoyyhZPdsshzkXcd40j5m6he YsW6HMzIM8srZ1g+B6l5Jo23ezCMNBMk7szL1x8gSgdjTH2NrzILMtgv1n/R3j/reJqV 6PEDq+9qXMal9y+YnVl08udkCjEQXauWWANbmh8TRi8ekUB6PXKtzfWHPubPVg4E9Lf/ oGAHcM08Ve2RD9czieR+nuy7eyAV4CpG7LshC56o9DMqnLONxY/TfkiS1HelQTBngJJ9 +rDZmrAF6pc+ukOGhlxSHLASDgqVr7GzXhrdLqjo3G4/8AM3acys/eAkrGHydNxX28Ax As4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Zuu+sY3srYBnEBRPYwnUIQcj9LUh3lFgcbPeFKUYRuc=; b=T/VZWcD1rExawmzAhaf/A/gmVwtcw6xfV2AiYpkVHrVLofC7vozBKIKiMWg/5T054j C9VxYTZF7EiiR35s2EUAz4mUVEJH+SmqLzYWsBJtcLroyT4QYJa+RWvL5xEaUWfjrXQH SrDcTpHUYHkyd49/HGxDy+h16IdSbY9AmuhO1UukehDI3fkMXRElZB7OqGJ+S+ncgi6j zYrYC0p1fmRhBQhFHCfHPpU9WOItJtabrOv0yrK9cSynZQYFZkmJzTfU2i66cy42BRF6 YY74lxPHWM2yl7pghz8ZZ3AN+wSxezlnZj4i5AyPBf2+Ft2mlixXs6tS7uKsccWrM3ix y3mw== X-Gm-Message-State: ALoCoQnMbVGJud9oB53VFFQ8LMe20AlBHPGHz3PkoVEQcesIlF8uIgKNbrlJ9OBYBEEfUxe5fHHesBcel1922HjACbTMTnjOmH+CWWg57CqEnkqs7tDEGw0MgOeOTgcAwHWCuPRSK8EsE8MC/Vw1V4HydERHVgyJiPUReMhPyo59roKuxHgarNuoI0DeJBoYQhXJtl+WdRxw X-Received: by 10.43.172.2 with SMTP id nw2mr9509893icc.9.1378724495798; Mon, 09 Sep 2013 04:01:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Mon, 9 Sep 2013 04:01:14 -0700 (PDT) In-Reply-To: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Mon, 9 Sep 2013 20:01:14 +0900 Message-ID: To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c2fcd2d120b604e5f14fbb Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:01:50 -0000 --001a11c2fcd2d120b604e5f14fbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland wrote: > I'm not sure the consensus requirement you're suggesting actually exists. > This is aiming at Informational, and as such: > > An "Informational" specification is published for the general > information of the Internet community, and does not represent an > Internet community consensus or recommendation. The Informational > > [RFC 2026 =A74.2.2] > Fair enough. But the document then proceeds to use RFC2119 normative language, which is not appropriate because it's not a standards track document. Normative language is not appropriate for informational documents; there was a big discussion over that for RFC6092, and that ended up being published with a note well saying, "this document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6." You may note that no such "conformance is not required" text is present here. This is at best confusing and at worst misleading. If this document were to plainly state that it simply represents the set of features that a particular set of operators feels is necessary for IPv6 deployment on mobile networks, but that it is not an IETF standard, and compliance with it is not necessary to deploy IPv6 on mobile networks or to claim conformance with IETF standards, I would have no objection to it. But the IETF doesn't define profile documents. The IETF defines technical >> standards on the basis of rough consensus and running code. What you're >> saying is "since we don't have running code that does what we want, we'r= e >> trying to define a profile in the hope that someone will write the code"= . >> That's not the way it works. >> > > No, the IETF has published profile documents in a number of cases. One > could argue that RFC 1122 and RFC 1123 are both profile documents, > actually, but there are other specific examples, like the Lemonade profil= e, > for example. > I had written a few paragraphs explaining why this document and RFC 1122 / 1123 are not even remotely comparable, but I think that's beside the point of this discussion. I think the main point is that RFC 1122/1123 are standards and this document is not intended to be one. I suspect, however, that this document is actually a standard, or intended > as one. There's discussion about conformance, about testing for > conformance, and so on, which suggests that an operator (in particular) > might treat any resultant RFC as a standard without regard for its IETF > status. > Absolutely. Such an operator might well decide to say that the requirements for all devices on their network are captured in this standard, and the IETF would have nothing to say about it. But the point is that it would be the operator setting the requirements, not the IETF. The IETF cannot set requirements in an informational document. That's a concern, though in practise, if this is to be a document detailing > "what operators want", I'd be happier that it's published through the IET= F > as Informational than not published at all - and in any case, no amount o= f > pretence will alter the fact that people will treat any RFC as a standard > if it suits them anyway. > Sure, but if said document said "this is not a standard" in so many words, then that would be a difficult position to convince others of. --001a11c2fcd2d120b604e5f14fbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland <dave@cridl= and.net> wrote:
I'm not sure the consensus requirement you're suggesting actua= lly exists. This is aiming at Informational, and as such:

   An &quo=
t;Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
[RFC 2026 =A74.2.2]
Fair enough. But the document then proceeds to use RFC2119 norm= ative language, which is not appropriate because it's not a standards t= rack document. Normative language is not appropriate for informational docu= ments; there was a big discussion over that for RFC6092, and that ended up = being published with a note well saying, "this document is not a stand= ard, and conformance with it is not required in order to claim conformance = with IETF standards for IPv6." You may note that no such "conform= ance is not required" text is present here. This is at best confusing = and at worst misleading.

If this document were to plainly state that it simply r= epresents the set of features that a particular set of operators feels is n= ecessary for IPv6 deployment on mobile networks, but that it is not an IETF= standard, and compliance with it is not necessary to deploy IPv6 on mobile= networks or to claim conformance with IETF standards, I would have no obje= ction to it.

But the IETF doesn't define profile documents. The IETF defines tec= hnical standards on the basis of rough consensus and running code. What you= 're saying is "since we don't have running code that does what= we want, we're trying to define a profile in the hope that someone wil= l write the code". That's not the way it works.

No, the IETF = has published profile documents in a number of cases. One could argue that = RFC 1122 and RFC 1123 are both profile documents, actually, but there are o= ther specific examples, like the Lemonade profile, for example.

I had written a few paragraphs expla= ining why this document and RFC 1122 / 1123 are not even remotely comparabl= e, but I think that's beside the point of this discussion. I think the = main point is that RFC 1122/1123 are standards and this document is not int= ended to be one.

I suspect, however, that this document is actually a standard, or intended= as one. There's discussion about conformance, about testing for confor= mance, and so on, which suggests that an operator (in particular) might tre= at any resultant RFC as a standard without regard for its IETF status.

Absolutely. Such an operator might w= ell decide to say that the requirements for all devices on their network ar= e captured in this standard, and the IETF would have nothing to say about i= t. But the point is that it would be the operator setting the requirements,= not the IETF. The IETF cannot set requirements in an informational documen= t.

That's a concern, though in practise, if this is to be a document deta= iling "what operators want", I'd be happier that it's pub= lished through the IETF as Informational than not published at all - and in= any case, no amount of pretence will alter the fact that people will treat= any RFC as a standard if it suits them anyway.

Sure, but if said document said &quo= t;this is not a standard" in so many words, then that would be a diffi= cult position to convince others of.
--001a11c2fcd2d120b604e5f14fbb-- From mohamed.boucadair@orange.com Mon Sep 9 04:07:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8A811E81B7; Mon, 9 Sep 2013 04:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuM9NPaZQtxD; Mon, 9 Sep 2013 04:07:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADF811E81A8; Mon, 9 Sep 2013 04:07:00 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 603342AC369; Mon, 9 Sep 2013 13:06:59 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D667A18004B; Mon, 9 Sep 2013 13:06:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 9 Sep 2013 13:06:55 +0200 From: To: Lorenzo Colitti , Dave Cridland Date: Mon, 9 Sep 2013 13:06:51 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6tS/UBx6T8iIGoRS+D5AVwlHl3owAACQRQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF06D0A6FPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.9.92414 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:07:27 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF06D0A6FPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lorenzo, The document explicitly says "This document is not a standard." since versi= on -00. What additional statement you would like to see added? Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : lundi 9 septembre 2013 13:01 =C0 : Dave Cridland Cc : BOUCADAIR Mohamed IMT/OLN; v6ops@ietf.org WG; BINET David IMT/OLN; IET= F Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland > wrote: I'm not sure the consensus requirement you're suggesting actually exists. T= his is aiming at Informational, and as such: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 =A74.2.2] Fair enough. But the document then proceeds to use RFC2119 normative langua= ge, which is not appropriate because it's not a standards track document. N= ormative language is not appropriate for informational documents; there was= a big discussion over that for RFC6092, and that ended up being published = with a note well saying, "this document is not a standard, and conformance = with it is not required in order to claim conformance with IETF standards f= or IPv6." You may note that no such "conformance is not required" text is p= resent here. This is at best confusing and at worst misleading. If this document were to plainly state that it simply represents the set of= features that a particular set of operators feels is necessary for IPv6 de= ployment on mobile networks, but that it is not an IETF standard, and compl= iance with it is not necessary to deploy IPv6 on mobile networks or to clai= m conformance with IETF standards, I would have no objection to it. --_000_94C682931C08B048B7A8645303FDC9F36EF06D0A6FPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lorenzo,

 

The document explicitly says “This documen=
t is not a standard.” since version -00=
.
 
What additional statement=
 you would like to see added?
 
Cheers,
Med
 

 

De : Lorenzo Colitti [mailt= o:lorenzo@google.com]
Envoy=E9 : lundi 9 septembre 2013 13:= 01
=C0 : Dave Cridland
Cc : BOUCADAIR Mohamed= IMT/OLN; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussion
Obj= et : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-pro= file-04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile= Devices) to Informational RFC

 

On Mon, Sep 9, 201= 3 at 7:19 PM, Dave Cridland <dave@cridland.net> wrote:

I'm not sure the consensus requirement you're suggesting actua= lly exists. This is aiming at Informational, and as such:

 

=A0=A0 An "Informational" specification is pub=
lished for the general
=A0=A0 information of the Internet community, and does not represe=
nt an
=A0=A0 I=
nternet community consensus or recommendation.=A0 The Informational

[RFC 2026 =A74.2.2]

 =

Fair enough. But the document the= n proceeds to use RFC2119 normative language, which is not appropriate beca= use it's not a standards track document. Normative language is not appropri= ate for informational documents; there was a big discussion over that for R= FC6092, and that ended up being published with a note well saying, "th= is document is not a standard, and conformance with it is not required in o= rder to claim conformance with IETF standards for IPv6." You may note = that no such "conformance is not required" text is present here. = This is at best confusing and at worst misleading.

 

= If this document were to plainly state that it simply represents the set of= features that a particular set of operators feels is necessary for IPv6 de= ployment on mobile networks, but that it is not an IETF standard, and compl= iance with it is not necessary to deploy IPv6 on mobile networks or to clai= m conformance with IETF standards, I would have no objection to it.

= --_000_94C682931C08B048B7A8645303FDC9F36EF06D0A6FPUEXCB1Bnante_-- From dave@cridland.net Mon Sep 9 03:20:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A841621E815D for ; Mon, 9 Sep 2013 03:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV9CWThGm-0b for ; Mon, 9 Sep 2013 03:20:05 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id D6D4021F883D for ; Mon, 9 Sep 2013 03:19:43 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so6316706oag.10 for ; Mon, 09 Sep 2013 03:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BKyjsphzECN8rY6BweQf98qe3vaeUEkRbdeqLF7ijMs=; b=JVi+wm9qfzszgp7Jwz8+RukP0g4UyCGGEqbtepujRVYbBgh6KeG55a7oLmaaxyb2yt kEJgK2cj+jnT2tzpqVWsgNbgWGPBHdordRShqmXo/O6lyWKlLalUMY2HSc0+O2bx1FJS 7nBucc3hVQuHsBGBIb6z4gEsRGpKU54+OXIik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BKyjsphzECN8rY6BweQf98qe3vaeUEkRbdeqLF7ijMs=; b=SyNlLNVPbzAPWgFhGQAXtoDJfh58pLvls2GeZVvT4+FpApVazc189SKY67OLrNaAt/ 19NXVcdl5iEq4bxokkQPMAVsOWN0Zpsxu2/fOX7K/CfQ8HpyMRZAhtA0LrsFrCFf+s9w lDSzm5+M1cmsbD9S9fQlAqv8z2frGkIBCOAosGS/JngVVhLLrbmeSHpImKz21q2aKIko SgKsAyaMBTW2mJ0AlBUaGzZi68W0SGEcYwJQvEccwkZMKsg4tdpNjKrjeKsP0cu8iMZm e61zkVkwHrXmWNGWRxrTT1eeMq7bMkOiXvfIAqLu1b0MIjdrxDj5wTpSKQLBH52kkeEQ U/ng== X-Gm-Message-State: ALoCoQknVVAl7fm2rNyNzM3/yKRXMs19h1RJZhch5p6SCw8H19lQgzesFYuqzhIu7WgeaoJgCyvg MIME-Version: 1.0 X-Received: by 10.60.65.227 with SMTP id a3mr10700386oet.13.1378721982334; Mon, 09 Sep 2013 03:19:42 -0700 (PDT) Received: by 10.60.121.97 with HTTP; Mon, 9 Sep 2013 03:19:42 -0700 (PDT) In-Reply-To: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 9 Sep 2013 11:19:42 +0100 Message-ID: From: Dave Cridland To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a11c2570000604404e5f0ba16 X-Mailman-Approved-At: Mon, 09 Sep 2013 04:24:32 -0700 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 10:20:13 -0000 --001a11c2570000604404e5f0ba16 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti wrote= : > I'm just saying it here so that everyone in the community can see it. If > it's an IETF document it has to have IETF consensus, and since I feel tha= t > the arguments were not properly taken into account in the WG (read: > ignored), I think it's important that the community see them before we > publish this document. > I'm not sure the consensus requirement you're suggesting actually exists. This is aiming at Informational, and as such: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational [RFC 2026 =A74.2.2] But the IETF doesn't define profile documents. The IETF defines technical > standards on the basis of rough consensus and running code. What you're > saying is "since we don't have running code that does what we want, we're > trying to define a profile in the hope that someone will write the code". > That's not the way it works. > No, the IETF has published profile documents in a number of cases. One could argue that RFC 1122 and RFC 1123 are both profile documents, actually, but there are other specific examples, like the Lemonade profile, for example. I suspect, however, that this document is actually a standard, or intended as one. There's discussion about conformance, about testing for conformance, and so on, which suggests that an operator (in particular) might treat any resultant RFC as a standard without regard for its IETF status. That's a concern, though in practise, if this is to be a document detailing "what operators want", I'd be happier that it's published through the IETF as Informational than not published at all - and in any case, no amount of pretence will alter the fact that people will treat any RFC as a standard if it suits them anyway. What may be more useful, though, would be to get more stakeholders involved in a commonly agreed profile, and supercede this. Dave. --001a11c2570000604404e5f0ba16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
I'm just saying it here so that everyone in the community = can see it. If it's an IETF document it has to have IETF consensus, and= since I feel that the arguments were not properly taken into account in th= e WG (read: ignored), I think it's important that the community see the= m before we publish this document.

I'm not sure the consensus requi= rement you're suggesting actually exists. This is aiming at Information= al, and as such:

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
[RFC 2026 =A74.2.2]

But the IETF doesn't define profile document= s. The IETF defines technical standards on the basis of rough consensus and= running code. What you're saying is "since we don't have runn= ing code that does what we want, we're trying to define a profile in th= e hope that someone will write the code". That's not the way it wo= rks.

No, the IETF has pu= blished profile documents in a number of cases. One could argue that RFC 11= 22 and RFC 1123 are both profile documents, actually, but there are other s= pecific examples, like the Lemonade profile, for example.

I suspect, = however, that this document is actually a standard, or intended as one. The= re's discussion about conformance, about testing for conformance, and s= o on, which suggests that an operator (in particular) might treat any resul= tant RFC as a standard without regard for its IETF status. That's a con= cern, though in practise, if this is to be a document detailing "what = operators want", I'd be happier that it's published through th= e IETF as Informational than not published at all - and in any case, no amo= unt of pretence will alter the fact that people will treat any RFC as a sta= ndard if it suits them anyway.

What may be= more useful, though, would be to get more stakeholders involved in a commo= nly agreed profile, and supercede this.
Dave.
--001a11c2570000604404e5f0ba16-- From hannes.tschofenig@gmx.net Mon Sep 9 03:58:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCAC21F8EB5 for ; Mon, 9 Sep 2013 03:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3kqqEovhikQ for ; Mon, 9 Sep 2013 03:58:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 117F121E816A for ; Mon, 9 Sep 2013 03:57:09 -0700 (PDT) Received: from [10.255.133.212] ([194.251.119.201]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lx8vJ-1W2oOJ2vCz-016f8J for ; Mon, 09 Sep 2013 12:57:07 +0200 Message-ID: <522DA977.4010807@gmx.net> Date: Mon, 09 Sep 2013 13:56:55 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dave Cridland References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:bWXasJD//YXQOjdEpgBZItRazULxwxJOZIdRMuu4MXuhq2WSyet i/oRplwgCO3ajAH5GllZ7SGItujpRb+NdzXfBg0NbfU1maccBbWC+p8KIodYkJQZhgOKtcH 4dcZ8g7Pk+c74K/ZPOE5tHvyXzyDdyYmwp50rr7ONUfIkzcVvLlw5RzHRxNGm62YpbSNe6L J4pByHho/LYQB9iWpyrZw== X-Mailman-Approved-At: Mon, 09 Sep 2013 04:24:32 -0700 Cc: "v6ops@ietf.org WG" , IETF Discussion , hannes.tschofenig@gmx.net Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 10:58:41 -0000 Browsing through the document I am not sure how much weight is carries when an IETF working group defines what 3GPP networks should be doing, particularly when talking about protocols the 3GPP has not really expressed an opinion about. From the document it is unclear to me what requirements are directly taken from 3GPP specifications and what additional requirements the authors have added. On 09.09.2013 13:19, Dave Cridland wrote: > > > > On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti > wrote: > > I'm just saying it here so that everyone in the community can see > it. If it's an IETF document it has to have IETF consensus, and > since I feel that the arguments were not properly taken into account > in the WG (read: ignored), I think it's important that the community > see them before we publish this document. > > > I'm not sure the consensus requirement you're suggesting actually > exists. This is aiming at Informational, and as such: > > An"Informational" specification is published for the general > information of the Internet community, and does not represent an > Internet community consensus or recommendation. The Informational > > [RFC 2026 §4.2.2] > > But the IETF doesn't define profile documents. The IETF defines > technical standards on the basis of rough consensus and running > code. What you're saying is "since we don't have running code that > does what we want, we're trying to define a profile in the hope that > someone will write the code". That's not the way it works. > > > No, the IETF has published profile documents in a number of cases. One > could argue that RFC 1122 and RFC 1123 are both profile documents, > actually, but there are other specific examples, like the Lemonade > profile, for example. > > I suspect, however, that this document is actually a standard, or > intended as one. There's discussion about conformance, about testing for > conformance, and so on, which suggests that an operator (in particular) > might treat any resultant RFC as a standard without regard for its IETF > status. That's a concern, though in practise, if this is to be a > document detailing "what operators want", I'd be happier that it's > published through the IETF as Informational than not published at all - > and in any case, no amount of pretence will alter the fact that people > will treat any RFC as a standard if it suits them anyway. > > What may be more useful, though, would be to get more stakeholders > involved in a commonly agreed profile, and supercede this. > > Dave. From lorenzo@google.com Mon Sep 9 04:24:47 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9621F8459 for ; Mon, 9 Sep 2013 04:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8d5OWhcnHr7 for ; Mon, 9 Sep 2013 04:24:38 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B720321E818F for ; Mon, 9 Sep 2013 04:24:36 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id qa5so10125095ieb.18 for ; Mon, 09 Sep 2013 04:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/oj67akPhSH0yIeLryGFqjS/mAVDF9RXXnxgrI7kHD8=; b=mC/P9dnh0NdP4o9NTwRSGk6P16rAcKZ6oaE+UO0cOBnp/acpvrRsmNVOenAov+Auwc Gbovt7YPyRLSZlhzvQjQ+uTA3RGD/nkrDgrgdMaqhfUAOOxDR+U5IhfquqJCmVPb7FT3 71v5oQwnX1oCLjf9AmV2o2t6zw65L/YZt/C82Go2r/Lnn43z94jbmlX2Da4LspMsxJEJ LEKC4/6vlOF8VwG2zAmMw7684jdYtvvO7xfpFizepU/gVHgu40zVBlRvRJSMiZHzg/9U MnuOd559aTGRtH49atvb0ZH8tLxcP4gYFXZ4zE6shzJ7/RO8pzPigoY4WpC3dw+t/btD aGiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/oj67akPhSH0yIeLryGFqjS/mAVDF9RXXnxgrI7kHD8=; b=kfHAD387f0xfXfRPlM3fMDHX2iqHuJOufX5S78Hfq26SVv/dAQvrKa9dn9Doi7QrH/ UdZeZsumvmKKCXcgINpLnqMYASfbr/+DzKPLSWrB26xc3eLHT5nDVdBUu8z460t7jZxM /uH9xG2aDGoewyQy+tYRAMNE4tuZEWoCkoBviRGx+3odT2hj8c8sO5/4nVYWtIeWP8WI mybwG7OjYx8eHOs6RGmcSFMFY6BTyCDwicmEuQb/QKyvvg/6iX4AZJA0AgyXKMhtDW4h PWTMLuX6TI/VDRq5n9LOdDyTneWkRz/5DA9c/DfVhNR9I2oY/2PRLVFIRTsNxF+fpfuy 2FaQ== X-Gm-Message-State: ALoCoQkOlJHr/eMZQk3zocwVOZOqlNKv94hyd+bEuFbBFTrO4Ja9AMNNebKEj1+zNuqz+utR8csKlc7uduBBJSawfNYS223z/2C3AJZr0CwkJNy37Tul4IXgp5aRJAG5HFk4NkhV6UOMJllrOriCIFnKw/VtuRgcRuLOQvjYUiRu0uiY3b5H5Jrv/nhRdE3Zgv1m9swy/Cm5 X-Received: by 10.50.13.66 with SMTP id f2mr7639404igc.17.1378725875998; Mon, 09 Sep 2013 04:24:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Mon, 9 Sep 2013 04:24:14 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Mon, 9 Sep 2013 20:24:14 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=089e0118460e15078904e5f1a2d7 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:24:47 -0000 --089e0118460e15078904e5f1a2d7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Sep 9, 2013 at 8:06 PM, wrote: > The document explicitly says =93This document is not a standard.=94 since > version -00. > > ** ** > > What additional statement you would like to see added? > > I think the high-order points are: 1. The text "This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network" should be replaced with "This document defines an IPv6 profile for 3GPP mobile devices that a number of operators believe is necessary to deploy IPv6 on an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network)." In place of "a number of operators believe is necessary to deploy" you could have "intend to deploy" or "require". I'd guess that as long as it's clear that the requirements don't come from the IETF but from a number of operators (not all of them, or a majority of them), it doesn't matter exactly what you say. 2. In the normative language section, I'd like to see a statement similar to what's in RFC 6092. Perhaps something like this? 1.3. Use of Normative Keywords NOTE WELL: This document is not a standard. Conformance with it is not required to deploy IPv6 in mobile networks or to claim conformanc= e with IETFstandards for IPv6. It uses the normative keywords defined in the previous section only for precision. Regards, Lorenzo --089e0118460e15078904e5f1a2d7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 9, 2013 at 8:06 PM, <mohamed.bouc= adair@orange.com> wrote:

The document explicitly says =93This document is not a standard.=94 s= ince version -00.

=A0
What additional statement you wo=
uld like to see added?

I= think the high-order points are:

1. The text "This document defines an IPv6 profile= for 3GPP mobile devices. It lists the set of features a 3GPP mobile device= is to be compliant with to connect to an IPv6-only or dual-stack wireless = network" should be replaced with "This document defines an IPv6 p= rofile for 3GPP mobile devices that a number of operators believe is necess= ary to deploy IPv6 on an IPv6-only or dual-stack wireless network (includin= g 3GPP cellular network and IEEE 802.11 network)."

In place of "a number of operators believe is nece= ssary to deploy" you could have "intend to deploy" or "= require". I'd guess that as long as it's clear that the requir= ements don't come from the IETF but from a number of operators (not all= of them, or a majority of them), it doesn't matter exactly what you sa= y.

2. In the normative language section, I'd like to s= ee a statement similar to what's in RFC 6092. Perhaps something like th= is?

1.3. =A0Use of Normative Keywords

=A0 =A0 =A0 NOTE WELL: This document is not a standard.= Conformance with it is
=A0 =A0 =A0 not required to deploy IPv6 i= n mobile networks or to claim conformance
=A0 =A0 =A0 with IETFst= andards for IPv6. =A0It uses the normative keywords defined in the
=A0 =A0 =A0 previous section only for precision.

<= /div>
Regards,
Lorenzo
--089e0118460e15078904e5f1a2d7-- From mohamed.boucadair@orange.com Mon Sep 9 05:17:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731B321E81A4; Mon, 9 Sep 2013 05:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBBetwkvVJRE; Mon, 9 Sep 2013 05:17:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9947D21E81A9; Mon, 9 Sep 2013 05:17:02 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B33242640BF; Mon, 9 Sep 2013 14:17:01 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8999A27C046; Mon, 9 Sep 2013 14:17:01 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 9 Sep 2013 14:16:58 +0200 From: To: Lorenzo Colitti Date: Mon, 9 Sep 2013 14:16:54 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6tTyxqdA2CYiNsRk23VfmuTdCSHQABsB5Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF06D0AF5PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 12:17:41 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF06D0AF5PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : lundi 9 septembre 2013 13:24 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Mon, Sep 9, 2013 at 8:06 PM, > wrote: The document explicitly says "This document is not a standard." since versi= on -00. What additional statement you would like to see added? I think the high-order points are: 1. The text "This document defines an IPv6 profile for 3GPP mobile devices.= It lists the set of features a 3GPP mobile device is to be compliant with = to connect to an IPv6-only or dual-stack wireless network" should be replac= ed with "This document defines an IPv6 profile for 3GPP mobile devices that= a number of operators believe is necessary to deploy IPv6 on an IPv6-only = or dual-stack wireless network (including 3GPP cellular network and IEEE 80= 2.11 network)." In place of "a number of operators believe is necessary to deploy" you coul= d have "intend to deploy" or "require". I'd guess that as long as it's clea= r that the requirements don't come from the IETF but from a number of opera= tors (not all of them, or a majority of them), it doesn't matter exactly wh= at you say. [Med] I made this change: OLD: This document defines an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). New: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). 2. In the normative language section, I'd like to see a statement similar t= o what's in RFC 6092. Perhaps something like this? [Med] I used the same wording as in RFC6092. The change is as follows: OLD: This document is not a standard. It uses the normative keywords only for precision. NEW: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision. --_000_94C682931C08B048B7A8645303FDC9F36EF06D0AF5PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

P= lease see inline.

 =

Cheers,

Med

 

=

De : Loren= zo Colitti [mailto:lorenzo@google.com]
Envoy=E9 : lundi 9 s= eptembre 2013 13:24
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc=  : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Dis= cussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-= mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profil= e for 3GPP Mobile Devices) to Informational RFC

=

 

O= n Mon, Sep 9, 2013 at 8:06 PM, <mohamed.boucadair@orange.com> wrote:<= /o:p>

The document explicitly says “<= /span>This document is not a standard.”= since version -00.

 
What addi=
tional statement you would like to see added?
=

 

I think the high-order points are:

 

1. The text "This document defines an IPv6 profile for 3GPP mobile de= vices. It lists the set of features a 3GPP mobile device is to be compliant= with to connect to an IPv6-only or dual-stack wireless network" shoul= d be replaced with "This document defines an IPv6 profile for 3GPP mob= ile devices that a number of operators believe is necessary to deploy IPv6 = on an IPv6-only or dual-stack wireless network (including 3GPP cellular net= work and IEEE 802.11 network)."

 

In place of &q= uot;a number of operators believe is necessary to deploy" you could ha= ve "intend to deploy" or "require". I'd guess that as l= ong as it's clear that the requirements don't come from the IETF but from a= number of operators (not all of them, or a majority of them), it doesn't m= atter exactly what you say.

[Med] I = made this change:

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'> 

OLD:

 <= /p>

=A0=A0 This document defines an IPv6 profile for 3GPP mobile device= s.=A0 It

=A0=A0 lists the set of features a 3GPP = mobile device is to be compliant

= =A0=A0 with to c= onnect to an IPv6-only or dual-stack wireless network

=

=A0=A0 (including 3GPP cellular network and IEEE 802.11 network).=

 <= /p>

New:

 

=A0=A0 This document defines an IPv6 profile that a n= umber of operators

=A0=A0 require in order to connect 3GPP mobile devices to an I= Pv6-only or

=A0=A0 dual-stack wireless network (including 3GPP cellular network a= nd IEEE

=A0=A0 802.11 network).



=

2. In the normative l= anguage section, I'd like to see a statement similar to what's in RFC 6092.= Perhaps something like this?

[Med] = I used the same wording as in RFC6092. The change is as follows:=

 

OLD:

 

=A0=A0 This document= is not a standard.=A0 It uses the normative keywords only

=A0=A0 for precision.

<= b> 

NEW:

 

=A0=A0=A0=A0=A0 NO= TE WELL: This document is not a standard, and conformance with

=A0 =A0=A0=A0=A0it= is not required in order to claim conformance with IETF<= /p>

=A0=A0=A0=A0=A0 standard= s for IPv6.=A0 It uses the normative keywords defined in the

=A0=A0=A0=A0=A0 previous section only for precisi= on.

 <= /i>

= --_000_94C682931C08B048B7A8645303FDC9F36EF06D0AF5PUEXCB1Bnante_-- From jhw@apple.com Mon Sep 9 09:15:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D61B21F9FAE for ; Mon, 9 Sep 2013 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2k4sYlb7M+N for ; Mon, 9 Sep 2013 09:15:39 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8E11E80F9 for ; Mon, 9 Sep 2013 08:59:09 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3516dw2+mKxo/q1wlRAYmQ)" Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSV00CM28DSMDH1@mail-out.apple.com> for v6ops@ietf.org; Mon, 09 Sep 2013 08:59:04 -0700 (PDT) X-AuditID: 11807166-b7fd66d000006a64-cd-522df0481dbb Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 66.82.27236.840FD225; Mon, 09 Sep 2013 08:59:04 -0700 (PDT) Received: from [17.113.34.106] (unknown [17.113.34.106]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MSV002278EF7N50@aniseed.apple.com> for v6ops@ietf.org; Mon, 09 Sep 2013 08:59:04 -0700 (PDT) From: james woodyatt Message-id: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> Date: Mon, 09 Sep 2013 08:59:04 -0700 To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1807) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FAsruvxQTfIoPuFrsXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8aP7L3vBsoCK310L2BsY/zt2MXJySAiYSOzvm8wIYYtJXLi3 nq2LkYtDSKCfSWLpo3nsEM48JokPx04yg1SxCahIfLt8lwnEZhZIkrh4uhmsW1jAVGLngidA cQ4OXgEbiffT/UHCLAKqEl/XfWMFsUUENCS6tvxhA7F5BfQkHjafYoFYLCtxvPEQ+wRGnllI ps5CUgYR15ZYtvA1M4RtIPG08xUrpri+xJt3c5gWMLKtYhQoSs1JrLTQSywoyEnVS87P3cQI DrDCtB2MTcutDjEKcDAq8fAGHNMNEmJNLCuuzD3EKMHBrCTCa/YOKMSbklhZlVqUH19UmpNa fIhRmoNFSZz3opxWkJBAemJJanZqakFqEUyWiYNTqoExsj7BlT33bZvgunWhDH1mFm1Vzud8 /fUcK/25GgTfFO5q0yuv5rjNtfX7oVNffy7Zt1xVy/bbzzURTcKNt697eNvLVvDszy1MmMd1 5evZ+1qxDdOtH7CsOJO1YGnmkxrpDNErTDOb305l23mQaW7Duu69yi3uefXmEyvX/563OvSA 8don54uUWIozEg21mIuKEwFkIMPMLAIAAA== Subject: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:15:45 -0000 --Boundary_(ID_3516dw2+mKxo/q1wlRAYmQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable everyone=97 I haven=92t prepared an exhaustive criticism of this draft, but I do = have one concern in particular I would like to highlight. The = recommendations (for they are not requirements) REQ#12 and REQ#15 = discussing matters related to the Port Control Protocol (PCP) and = traversal of NAT and firewalls is troubling to me. REQ#12: The cellular host SHOULD support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to learn PREFIX64 SHOULD be supported by the cellular host. This solves the issue when applications use IPv4 referrals on IPv6-only access networks. In PCP-based environments, cellular hosts SHOULD follow [I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used by an upstream PCP-controlled NAT64 device. If PCP is not enabled, the cellular host SHOULD implement the method specified in [I-D.ietf-behave-nat64-discovery-heuristic] to retrieve the PREFIX64. REQ#15: The cellular host SHOULD support PCP [RFC6887]. The support of PCP is seen as a driver to save battery consumption exacerbated by keepalive messages. PCP also gives the possibility of enabling incoming connections to the cellular device. Indeed, because several stateful devices may be deployed in wireless networks (e.g., NAT and/or Firewalls), PCP can be used by the cellular host to control network-based NAT and Firewall functions which will reduce per-application signaling and save battery consumption. It seems to me that these recommendations are only worth following if = there are to be PCP servers in *all* of the network elements in the = paths between cellular hosts and the default free zone that implement = stateful firewall (and NAT) functions. Indeed, in at least one common = cellular host architecture, there is a stateful filter in the baseband = chipset firmware that blocks all inbound packets that it decides are = unsolicited by applications on the main system CPU. There is no PCP = service in those chipset firmware implementations, and no practical way = to turn off the filtering, because it is tied up with tricky power = consumption issues, and without either of those things, there is pretty = much no good reason to implement a PCP client on the main system CPU. It = does not matter whether there are PCP servers in the firewalls further = upstream, if there is a firewall in the baseband chipset that you can=92t = disable or control. I recommend dropping these recommendations and replacing them with text = that recognizes the present reality that cellular hosts are simply not = expected ever to receive unsolicited inbound connection flows from = arbitrary remote Internet addresses. It would simplify the document and = it would be a more honest appraisal of the situation. -- james woodyatt core os networking --Boundary_(ID_3516dw2+mKxo/q1wlRAYmQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable everyone=97

I haven=92t prepared = an exhaustive criticism of this draft, but I do have one concern in = particular I would like to highlight. The recommendations (for they are = not requirements) REQ#12 and REQ#15 discussing matters related to the = Port Control Protocol (PCP) and traversal of NAT and firewalls is = troubling to me.

REQ#12:  The cellular host SHOULD support a =
method to locally
        construct IPv4-embedded IPv6 addresses [RFC6052].  A method to
        learn PREFIX64 SHOULD be supported by the cellular host.

           This solves the issue when applications use IPv4 referrals on
           IPv6-only access networks.

           In PCP-based environments, cellular hosts SHOULD follow
           [I-D.ietf-pcp-nat64-prefix64] to =
learn the IPv6 Prefix used
           by an upstream PCP-controlled NAT64 device.  If PCP is not
           enabled, the cellular host SHOULD implement the method
           specified in [I-D.ietf-behave-nat64-di=
scovery-heuristic] to
           retrieve the PREFIX64.

REQ#15:  The cellular =
host SHOULD support PCP [RFC6887].

           The support of PCP is seen as a driver to save battery
           consumption exacerbated by keepalive messages.  PCP also
           gives the possibility of enabling incoming connections to the
           cellular device.  Indeed, because several stateful devices
           may be deployed in wireless networks (e.g., NAT and/or
           Firewalls), PCP can be used by the cellular host to control
           network-based NAT and Firewall functions which will reduce
           per-application signaling and save battery =
consumption.

It seems to me that these = recommendations are only worth following if there are to be PCP servers = in *all* of the network elements in the paths between cellular hosts and = the default free zone that implement stateful firewall (and NAT) = functions.  Indeed, in at least one common cellular host = architecture, there is a stateful filter in the baseband chipset = firmware that blocks all inbound packets that it decides are unsolicited = by applications on the main system CPU. There is no PCP service in those = chipset firmware implementations, and no practical way to turn off the = filtering, because it is tied up with tricky power consumption issues, = and without either of those things, there is pretty much no good reason = to implement a PCP client on the main system CPU. It does not matter = whether there are PCP servers in the firewalls further upstream, if = there is a firewall in the baseband chipset that you can=92t disable or = control.

I recommend dropping these = recommendations and replacing them with text that recognizes the present = reality that cellular hosts are simply not expected ever to receive = unsolicited inbound connection flows from arbitrary remote Internet = addresses. It would simplify the document and it would be a more honest = appraisal of the situation.


--
james woodyatt <jhw@apple.com>
core os networking

= --Boundary_(ID_3516dw2+mKxo/q1wlRAYmQ)-- From owen@delong.com Mon Sep 9 13:11:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34E621E80BA; Mon, 9 Sep 2013 13:11:00 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbJv2DhHyQLl; Mon, 9 Sep 2013 13:10:59 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 66FE721E80AB; Mon, 9 Sep 2013 13:10:58 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r89K6n19019178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Sep 2013 13:06:49 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r89K6n19019178 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378757210; bh=+2dReEGzxsDVWC3q2uU/cLftiZQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=eI+nMPYme102b21yrwGGbVor9WPvHOL8rxN4GXNeypImMI/j8qWKUw9S4jzBH9d0O FDju27zK0j0tYe7yt3kb8PSkp84iTQ71RAY3VW3LRs0QvYpUBGFxwFAgDKYqjMTcQ+ VrBZ0KhwgjCHuzmMcM5+XEtP8HikwO7myPlGy/gM= Content-Type: multipart/alternative; boundary="Apple-Mail=_BE8E33A7-EC9D-420B-AA72-052590785087" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 9 Sep 2013 13:06:48 -0700 Message-Id: <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 09 Sep 2013 13:06:50 -0700 (PDT) Cc: "v6ops@ietf.org WG" , Dave Cridland , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:11:00 -0000 --Apple-Mail=_BE8E33A7-EC9D-420B-AA72-052590785087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have to agree with Lorenzo here again. This document seems to me to be: 1. Out of scope for the IETF. 2. So watered down in its language as to use many words to = say nearly nothing. 3. Claims to be informational, but with so many caveats = about the nature of that information that it's hard to imagine what meaningful = information an independent reader could glean from the document. Finally, given the spirited debate that has extended into this last call = (which I honestly wonder how this ever saw last call over the sustained objections) definitely = does not appear to have even rough consensus, nor does it appear to have running code. Why is there such a push to do this? Owen On Sep 9, 2013, at 05:16 , wrote: > Re-, > =20 > Please see inline. > =20 > Cheers, > Med > =20 > De : Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Envoy=E9 : lundi 9 septembre 2013 13:24 > =C0 : BOUCADAIR Mohamed IMT/OLN > Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF = Discussion > Objet : Re: [v6ops] Last Call: = (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > On Mon, Sep 9, 2013 at 8:06 PM, wrote: > The document explicitly says =93This document is not a standard.=94 = since version -00. > =20 > What additional statement you would like to see added? > =20 > I think the high-order points are: > =20 > 1. The text "This document defines an IPv6 profile for 3GPP mobile = devices. It lists the set of features a 3GPP mobile device is to be = compliant with to connect to an IPv6-only or dual-stack wireless = network" should be replaced with "This document defines an IPv6 profile = for 3GPP mobile devices that a number of operators believe is necessary = to deploy IPv6 on an IPv6-only or dual-stack wireless network (including = 3GPP cellular network and IEEE 802.11 network)." > =20 > In place of "a number of operators believe is necessary to deploy" you = could have "intend to deploy" or "require". I'd guess that as long as = it's clear that the requirements don't come from the IETF but from a = number of operators (not all of them, or a majority of them), it doesn't = matter exactly what you say. > [Med] I made this change: > =20 > OLD: > =20 > This document defines an IPv6 profile for 3GPP mobile devices. It > lists the set of features a 3GPP mobile device is to be compliant > with to connect to an IPv6-only or dual-stack wireless network > (including 3GPP cellular network and IEEE 802.11 network). > =20 > New: > =20 > This document defines an IPv6 profile that a number of operators > require in order to connect 3GPP mobile devices to an IPv6-only or > dual-stack wireless network (including 3GPP cellular network and = IEEE > 802.11 network). >=20 >=20 > 2. In the normative language section, I'd like to see a statement = similar to what's in RFC 6092. Perhaps something like this? > [Med] I used the same wording as in RFC6092. The change is as follows: > =20 > OLD: > =20 > This document is not a standard. It uses the normative keywords = only > for precision. > =20 > NEW: > =20 > NOTE WELL: This document is not a standard, and conformance with > it is not required in order to claim conformance with IETF > standards for IPv6. It uses the normative keywords defined in = the > previous section only for precision. > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_BE8E33A7-EC9D-420B-AA72-052590785087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = have to agree with Lorenzo here again.

This document = seems to me to be:

1. Out of scope for the = IETF.
= 2. = So watered down in its language as to use many words to say = nearly nothing.
3. Claims to be informational, but = with so many caveats about the nature of that
= information that it's hard to imagine what meaningful information = an independent
reader could glean from = the document.

Finally, given the spirited = debate that has extended into this last call (which I honestly = wonder
how this ever saw last call over the sustained = objections) definitely does not appear to have
even rough = consensus, nor does it appear to have running = code.

Why is there such a push to do = this?

Owen

On Sep 9, = 2013, at 05:16 , <mohamed.boucadair@orange.com<= /a>> wrote:

 
Please see inline.
 
Cheers,
Med
 
De : Lorenzo Colitti = [mailto:lorenzo@google.com] 
Envoy=E9 : lundi 9 septembre 2013 = 13:24
=C0 : BOUCADAIR Mohamed = IMT/OLN
Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; = IETF Discussion
Objet : Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational = RFC
On Mon, Sep 9, = 2013 at 8:06 PM, <=94 since version = -00.
 
What additional statement you would =
like to see added?


v6ops@ietf.org
Date: Mon, 9 Sep 2013 22:36:51 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6tmNJIr4OArRarQzWLZpkLOAfjCwAAeW8Q Message-ID: <1808340F7EC362469DDFFB112B37E2FCD2BABB5CCD@SRVHKE02.rdm.cz> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> In-Reply-To: <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCD2BABB5CCDSRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:37:25 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCD2BABB5CCDSRVHKE02rdmcz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCkFsZXMNCg0KRnJvbTogdjZvcHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBPd2VuIERlTG9u Zw0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDksIDIwMTMgMTA6MDcgUE0NClRvOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQpDYzogdjZvcHNAaWV0Zi5vcmcgV0c7IERhdmUgQ3JpZGxh bmQ7IElFVEYgRGlzY3Vzc2lvbg0KU3ViamVjdDogUmU6IFt2Nm9wc10gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMDQudHh0PiAoSW50ZXJuZXQgUHJv dG9jb2wgVmVyc2lvbiA2IChJUHY2KSBQcm9maWxlIGZvciAzR1BQIE1vYmlsZSBEZXZpY2VzKSB0 byBJbmZvcm1hdGlvbmFsIFJGQw0KDQpJIGhhdmUgdG8gYWdyZWUgd2l0aCBMb3JlbnpvIGhlcmUg YWdhaW4uDQoNClRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gbWUgdG8gYmU6DQoNCg0KMS4gICAgICAg ICAgICAgICAgICBPdXQgb2Ygc2NvcGUgZm9yIHRoZSBJRVRGLg0KW2F2XSBTdHJvbmdseSBkaXNh Z3JlZS4gVGhlIElFVEYgYXMgdGhlIElQdjYgb3duZXIgaXMgdGhlIHJpZ2h0IHBsYWNlIHRvIGRl ZmluZSB3aGF0IHF1YWxpZmllcyBhIGRldmljZSB0byBiZSBJUHY2IGNvbXBsaWFudC4gKGEgbW9i aWxlIG9uZSBpbiB0aGlzIGNhc2UpDQoNCg0KMi4gICAgICAgICAgICAgICAgICBTbyB3YXRlcmVk IGRvd24gaW4gaXRzIGxhbmd1YWdlIGFzIHRvIHVzZSBtYW55IHdvcmRzIHRvIHNheSBuZWFybHkg bm90aGluZy4NClthdl0gSGludHMgb24gaG93IHRoZSB0ZXh0IHNoYWxsIGJlIGNoYW5nZWQgYXJl IGFsd2F5cyB3ZWxjb21lLg0KDQogICAgICAgICAgMy4gICAgICAgICBDbGFpbXMgdG8gYmUgaW5m b3JtYXRpb25hbCwgYnV0IHdpdGggc28gbWFueSBjYXZlYXRzIGFib3V0IHRoZSBuYXR1cmUgb2Yg dGhhdA0KICAgICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uIHRoYXQgaXQncyBoYXJkIHRv IGltYWdpbmUgd2hhdCBtZWFuaW5nZnVsIGluZm9ybWF0aW9uIGFuIGluZGVwZW5kZW50DQogICAg ICAgICAgICAgICAgICAgICAgcmVhZGVyIGNvdWxkIGdsZWFuIGZyb20gdGhlIGRvY3VtZW50Lg0K ICAgICAgICAgICAgICAgICAgW2F2XSBUaGUgcmVhZGVyIHdpbGwgbGVhcm4gd2hhdCBtdXN0L3No b3VsZC9tYXkgYmUgaW1wbGVtZW50ZWQgaW4gYSBtb2JpbGUgZGV2aWNlIHRvIHN1cHBvcnQgSVB2 Ni4NCg0KRmluYWxseSwgZ2l2ZW4gdGhlIHNwaXJpdGVkIGRlYmF0ZSB0aGF0IGhhcyBleHRlbmRl ZCBpbnRvIHRoaXMgbGFzdCBjYWxsICh3aGljaCBJIGhvbmVzdGx5IHdvbmRlcg0KaG93IHRoaXMg ZXZlciBzYXcgbGFzdCBjYWxsIG92ZXIgdGhlIHN1c3RhaW5lZCBvYmplY3Rpb25zKSBkZWZpbml0 ZWx5IGRvZXMgbm90IGFwcGVhciB0byBoYXZlDQpldmVuIHJvdWdoIGNvbnNlbnN1cywgbm9yIGRv ZXMgaXQgYXBwZWFyIHRvIGhhdmUgcnVubmluZyBjb2RlLg0KW2F2XSBNZWQgaGFzIHBvc3RlZCBh biBhbnN3ZXIgb24gdGhpcyBvbmUgZWFybGllciBpbiB0aGUgdGhyZWFkLg0KDQpXaHkgaXMgdGhl cmUgc3VjaCBhIHB1c2ggdG8gZG8gdGhpcz8NClthdl0gQmVjYXVzZSB0aGUgT3BlcmF0b3JzIGFy ZSBjdXJyZW50bHkgbWlzc2luZyBzdWNoIGEgZG9jdW1lbnQsIHNvIHRoZXkgd2VudCB0byB0aGUg SUVURiB0byB3b3JrIG9uIG9uZS4NCkFzIHdyaXR0ZW4gaW4gdGhlIGRvY3VtZW50IHRoZSBudW1i ZXIgb2Ygd2VsbCBiZWhhdmluZyBJUHY2IGNhcGFibGUgbW9iaWxlIGRldmljZXMgaXMgbm90IHZl cnkgaGlnaCBhdCB0aGUgbW9tZW50Lg0KVGhpcyBpbml0aWF0aXZlIGlzIGludGVuZGVkIHRvIGhl bHAgdGhlIGRldmVsb3BlcnMuDQoNCk93ZW4NCg0KT24gU2VwIDksIDIwMTMsIGF0IDA1OjE2ICwg PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+PiB3cm90ZToNCg0KDQpSZS0sDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVl cnMsDQpNZWQNCg0KRGUgOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2dsZS5j b208aHR0cDovL2dvb2dsZS5jb20vPl0NCkVudm95w6kgOiBsdW5kaSA5IHNlcHRlbWJyZSAyMDEz IDEzOjI0DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogRGF2ZSBDcmlkbGFu ZDsgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPiBXRzsgQklORVQgRGF2aWQg SU1UL09MTjsgSUVURiBEaXNjdXNzaW9uDQpPYmpldCA6IFJlOiBbdjZvcHNdIExhc3QgQ2FsbDog PGRyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9maWxlLTA0LnR4dD4gKEludGVybmV0 IFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmlsZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNl cykgdG8gSW5mb3JtYXRpb25hbCBSRkMNCg0KT24gTW9uLCBTZXAgOSwgMjAxMyBhdCA4OjA2IFBN LCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbT4+IHdyb3RlOg0KVGhlIGRvY3VtZW50IGV4cGxpY2l0bHkgc2F5cyDigJxUaGlz IGRvY3VtZW50IGlzIG5vdCBhIHN0YW5kYXJkLuKAnSBzaW5jZSB2ZXJzaW9uIC0wMC4NCg0KDQoN CldoYXQgYWRkaXRpb25hbCBzdGF0ZW1lbnQgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGFkZGVkPw0K DQpJIHRoaW5rIHRoZSBoaWdoLW9yZGVyIHBvaW50cyBhcmU6DQoNCjEuIFRoZSB0ZXh0ICJUaGlz IGRvY3VtZW50IGRlZmluZXMgYW4gSVB2NiBwcm9maWxlIGZvciAzR1BQIG1vYmlsZSBkZXZpY2Vz LiBJdCBsaXN0cyB0aGUgc2V0IG9mIGZlYXR1cmVzIGEgM0dQUCBtb2JpbGUgZGV2aWNlIGlzIHRv IGJlIGNvbXBsaWFudCB3aXRoIHRvIGNvbm5lY3QgdG8gYW4gSVB2Ni1vbmx5IG9yIGR1YWwtc3Rh Y2sgd2lyZWxlc3MgbmV0d29yayIgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggIlRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhbiBJUHY2IHByb2ZpbGUgZm9yIDNHUFAgbW9iaWxlIGRldmljZXMgdGhhdCBh IG51bWJlciBvZiBvcGVyYXRvcnMgYmVsaWV2ZSBpcyBuZWNlc3NhcnkgdG8gZGVwbG95IElQdjYg b24gYW4gSVB2Ni1vbmx5IG9yIGR1YWwtc3RhY2sgd2lyZWxlc3MgbmV0d29yayAoaW5jbHVkaW5n IDNHUFAgY2VsbHVsYXIgbmV0d29yayBhbmQgSUVFRSA4MDIuMTEgbmV0d29yaykuIg0KDQpJbiBw bGFjZSBvZiAiYSBudW1iZXIgb2Ygb3BlcmF0b3JzIGJlbGlldmUgaXMgbmVjZXNzYXJ5IHRvIGRl cGxveSIgeW91IGNvdWxkIGhhdmUgImludGVuZCB0byBkZXBsb3kiIG9yICJyZXF1aXJlIi4gSSdk IGd1ZXNzIHRoYXQgYXMgbG9uZyBhcyBpdCdzIGNsZWFyIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBk b24ndCBjb21lIGZyb20gdGhlIElFVEYgYnV0IGZyb20gYSBudW1iZXIgb2Ygb3BlcmF0b3JzIChu b3QgYWxsIG9mIHRoZW0sIG9yIGEgbWFqb3JpdHkgb2YgdGhlbSksIGl0IGRvZXNuJ3QgbWF0dGVy IGV4YWN0bHkgd2hhdCB5b3Ugc2F5Lg0KW01lZF0gSSBtYWRlIHRoaXMgY2hhbmdlOg0KDQpPTEQ6 DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBJUHY2IHByb2ZpbGUgZm9yIDNHUFAgbW9i aWxlIGRldmljZXMuICBJdA0KICAgbGlzdHMgdGhlIHNldCBvZiBmZWF0dXJlcyBhIDNHUFAgbW9i aWxlIGRldmljZSBpcyB0byBiZSBjb21wbGlhbnQNCiAgIHdpdGggdG8gY29ubmVjdCB0byBhbiBJ UHY2LW9ubHkgb3IgZHVhbC1zdGFjayB3aXJlbGVzcyBuZXR3b3JrDQogICAoaW5jbHVkaW5nIDNH UFAgY2VsbHVsYXIgbmV0d29yayBhbmQgSUVFRSA4MDIuMTEgbmV0d29yaykuDQoNCk5ldzoNCg0K ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFuIElQdjYgcHJvZmlsZSB0aGF0IGEgbnVtYmVyIG9m IG9wZXJhdG9ycw0KICAgcmVxdWlyZSBpbiBvcmRlciB0byBjb25uZWN0IDNHUFAgbW9iaWxlIGRl dmljZXMgdG8gYW4gSVB2Ni1vbmx5IG9yDQogICBkdWFsLXN0YWNrIHdpcmVsZXNzIG5ldHdvcmsg KGluY2x1ZGluZyAzR1BQIGNlbGx1bGFyIG5ldHdvcmsgYW5kIElFRUUNCiAgIDgwMi4xMSBuZXR3 b3JrKS4NCg0KDQoNCjIuIEluIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugc2VjdGlvbiwgSSdkIGxp a2UgdG8gc2VlIGEgc3RhdGVtZW50IHNpbWlsYXIgdG8gd2hhdCdzIGluIFJGQyA2MDkyLiBQZXJo YXBzIHNvbWV0aGluZyBsaWtlIHRoaXM/DQpbTWVkXSBJIHVzZWQgdGhlIHNhbWUgd29yZGluZyBh cyBpbiBSRkM2MDkyLiBUaGUgY2hhbmdlIGlzIGFzIGZvbGxvd3M6DQoNCk9MRDoNCg0KICAgVGhp cyBkb2N1bWVudCBpcyBub3QgYSBzdGFuZGFyZC4gIEl0IHVzZXMgdGhlIG5vcm1hdGl2ZSBrZXl3 b3JkcyBvbmx5DQogICBmb3IgcHJlY2lzaW9uLg0KDQpORVc6DQoNCiAgICAgIE5PVEUgV0VMTDog VGhpcyBkb2N1bWVudCBpcyBub3QgYSBzdGFuZGFyZCwgYW5kIGNvbmZvcm1hbmNlIHdpdGgNCiAg ICAgIGl0IGlzIG5vdCByZXF1aXJlZCBpbiBvcmRlciB0byBjbGFpbSBjb25mb3JtYW5jZSB3aXRo IElFVEYNCiAgICAgIHN0YW5kYXJkcyBmb3IgSVB2Ni4gIEl0IHVzZXMgdGhlIG5vcm1hdGl2ZSBr ZXl3b3JkcyBkZWZpbmVkIGluIHRoZQ0KICAgICAgcHJldmlvdXMgc2VjdGlvbiBvbmx5IGZvciBw cmVjaXNpb24uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K --_000_1808340F7EC362469DDFFB112B37E2FCD2BABB5CCDSRVHKE02rdmcz_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1u YW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MzE5MDM5ODYxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotODY4NzMyMTEwIDE1MjU4Mzk5NjQgMTM0ODA3NTc3IDEz NDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3 IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjY2Ljc1cHQ7 DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tR0IgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkFsZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10g PGI+T24gQmVoYWxmIE9mIDwvYj5Pd2VuIERlTG9uZzxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBT ZXB0ZW1iZXIgMDksIDIwMTMgMTA6MDcgUE08YnI+PGI+VG86PC9iPiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPGJyPjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmcgV0c7IERhdmUgQ3JpZGxh bmQ7IElFVEYgRGlzY3Vzc2lvbjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gTGFzdCBD YWxsOiAmbHQ7ZHJhZnQtaWV0Zi12Nm9wcy1tb2JpbGUtZGV2aWNlLXByb2ZpbGUtMDQudHh0Jmd0 OyAoSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2IChJUHY2KSBQcm9maWxlIGZvciAzR1BQIE1v YmlsZSBEZXZpY2VzKSB0byBJbmZvcm1hdGlvbmFsIFJGQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPkkgaGF2ZSB0byBhZ3JlZSB3aXRoIExvcmVuem8gaGVyZSBhZ2Fpbi48bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGlzIGRvY3VtZW50IHNlZW1zIHRvIG1lIHRv IGJlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0n bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0zNi4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk91dCBvZiBzY29wZSBmb3IgdGhl IElFVEYuPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdCc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5bYXZdIFN0cm9uZ2x5IGRpc2FncmVlLiBUaGUgSUVURiBhcyB0aGUgSVB2NiBv d25lciBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gZGVmaW5lIHdoYXQgcXVhbGlmaWVzIGEgZGV2aWNl IHRvIGJlIElQdjYgY29tcGxpYW50LiAoYSBtb2JpbGUgb25lIGluIHRoaXMgY2FzZSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NjYuNzVwdDt0ZXh0LWluZGVudDotMzYuMHB0O21z by1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz4yLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+U28gd2F0ZXJlZCBkb3duIGluIGl0cyBsYW5ndWFnZSBhcyB0byB1 c2UgbWFueSB3b3JkcyB0byBzYXkgbmVhcmx5IG5vdGhpbmcuPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+W2F2XSBIaW50cyBvbiBob3cgdGhlIHRleHQgc2hhbGwgYmUgY2hhbmdlZCBhcmUgYWx3 YXlzIHdlbGNvbWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS10YWItc3Bhbj7CoMKgwqDCoMKg wqDCoMKgwqAgPC9zcGFuPjMuPHNwYW4gY2xhc3M9YXBwbGUtdGFiLXNwYW4+wqDCoMKgwqDCoMKg wqDCoCA8L3NwYW4+Q2xhaW1zIHRvIGJlIGluZm9ybWF0aW9uYWwsIGJ1dCB3aXRoIHNvIG1hbnkg Y2F2ZWF0cyBhYm91dCB0aGUgbmF0dXJlIG9mIHRoYXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS10YWItc3Bhbj7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPC9zcGFuPmluZm9ybWF0aW9uIHRoYXQg aXQncyBoYXJkIHRvIGltYWdpbmUgd2hhdCBtZWFuaW5nZnVsIGluZm9ybWF0aW9uIGFuIGluZGVw ZW5kZW50PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g Y2xhc3M9YXBwbGUtdGFiLXNwYW4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDwvc3Bhbj5yZWFkZXIgY291bGQgZ2xlYW4gZnJvbSB0aGUgZG9jdW1lbnQuPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbYXZdIFRoZSByZWFkZXIgd2lsbCBsZWFybiB3 aGF0IG11c3Qvc2hvdWxkL21heSBiZSBpbXBsZW1lbnRlZCBpbiBhIG1vYmlsZSBkZXZpY2UgdG8g c3VwcG9ydCBJUHY2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5GaW5hbGx5LCBnaXZlbiB0aGUgc3Bpcml0ZWQgZGViYXRlIHRoYXQgaGFzIGV4dGVuZGVkIGlu dG8gdGhpcyBsYXN0IGNhbGwgKHdoaWNoIEkgaG9uZXN0bHkgd29uZGVyPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+aG93IHRoaXMgZXZlciBzYXcgbGFzdCBjYWxs IG92ZXIgdGhlIHN1c3RhaW5lZCBvYmplY3Rpb25zKSBkZWZpbml0ZWx5IGRvZXMgbm90IGFwcGVh ciB0byBoYXZlPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ZXZl biByb3VnaCBjb25zZW5zdXMsIG5vciBkb2VzIGl0IGFwcGVhciB0byBoYXZlIHJ1bm5pbmcgY29k ZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPlthdl0gTWVkIGhhcyBwb3N0ZWQgYW4gYW5zd2VyIG9uIHRoaXMgb25lIGVh cmxpZXIgaW4gdGhlIHRocmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPldoeSBpcyB0aGVyZSBzdWNoIGEgcHVzaCB0byBk byB0aGlzPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+W2F2XSBCZWNhdXNlIHRoZSBPcGVyYXRvcnMgYXJlIGN1cnJlbnRs eSBtaXNzaW5nIHN1Y2ggYSBkb2N1bWVudCwgc28gdGhleSB3ZW50IHRvIHRoZSBJRVRGIHRvIHdv cmsgb24gb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5BcyB3cml0dGVuIGluIHRoZSBkb2N1bWVudCB0aGUgbnVtYmVyIG9m IHdlbGwgYmVoYXZpbmcgSVB2NiBjYXBhYmxlIG1vYmlsZSBkZXZpY2VzIGlzIG5vdCB2ZXJ5IGhp Z2ggYXQgdGhlIG1vbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyBpbml0aWF0aXZlIGlzIGludGVuZGVkIHRvIGhl bHAgdGhlIGRldmVsb3BlcnMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5Pd2VuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5PbiBTZXAgOSwgMjAxMywgYXQgMDU6MTYgLCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijtjb2xvcjojMUY0OTdEJz5SZS0sPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5 N0QnPlBsZWFzZSBzZWUgaW5saW5lLjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdE Jz5DaGVlcnMsPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5NZWQ8 L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+TG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0A8YSBocmVm PSJodHRwOi8vZ29vZ2xlLmNvbS8iPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPmdvb2dsZS5j b208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z cGFuPjxicj48Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt c3BhY2U+Jm5ic3A7PC9zcGFuPmx1bmRpIDkgc2VwdGVtYnJlIDIwMTMgMTM6MjQ8YnI+PGI+w4Am bmJzcDs6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+ Qk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjxicj48Yj5DYyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9 YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5EYXZlIENyaWRsYW5kOzxzcGFuIGNs YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nY29sb3I6cHVycGxlJz52Nm9wc0BpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5X RzsgQklORVQgRGF2aWQgSU1UL09MTjsgSUVURiBEaXNjdXNzaW9uPGJyPjxiPk9iamV0Jm5ic3A7 OjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPlJlOiBb djZvcHNdIExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtdjZvcHMtbW9iaWxlLWRldmljZS1wcm9m aWxlLTA0LnR4dCZndDsgKEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNiAoSVB2NikgUHJvZmls ZSBmb3IgM0dQUCBNb2JpbGUgRGV2aWNlcykgdG8gSW5mb3JtYXRpb25hbCBSRkM8L3NwYW4+PHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTPk9uIE1vbiwgU2VwIDksIDIwMTMgYXQgODowNiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 J2NvbG9yOnB1cnBsZSc+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvc3Bhbj48L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgZG9jdW1lbnQgZXhwbGlj aXRseSBzYXlzIOKAnDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPlRoaXMgZG9jdW1lbnQgaXMgbm90 IGEgc3RhbmRhcmQuPHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPuKAnSBzaW5jZSB2ZXJzaW9u IC0wMC48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwcmU+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+ PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5XaGF0IGFkZGl0aW9uYWwgc3RhdGVtZW50IHlvdSB3b3VsZCBsaWtlIHRvIHNl ZSBhZGRlZD88L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48 L2Jsb2NrcXVvdGU+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SSB0aGluayB0aGUgaGlnaC1vcmRlciBwb2lu dHMgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V Uz4xLiBUaGUgdGV4dCAmcXVvdDtUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gSVB2NiBwcm9maWxl IGZvciAzR1BQIG1vYmlsZSBkZXZpY2VzLiBJdCBsaXN0cyB0aGUgc2V0IG9mIGZlYXR1cmVzIGEg M0dQUCBtb2JpbGUgZGV2aWNlIGlzIHRvIGJlIGNvbXBsaWFudCB3aXRoIHRvIGNvbm5lY3QgdG8g YW4gSVB2Ni1vbmx5IG9yIGR1YWwtc3RhY2sgd2lyZWxlc3MgbmV0d29yayZxdW90OyBzaG91bGQg YmUgcmVwbGFjZWQgd2l0aCAmcXVvdDtUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4gSVB2NiBwcm9m aWxlIGZvciAzR1BQIG1vYmlsZSBkZXZpY2VzIHRoYXQgYSBudW1iZXIgb2Ygb3BlcmF0b3JzIGJl bGlldmUgaXMgbmVjZXNzYXJ5IHRvIGRlcGxveSBJUHY2IG9uIGFuIElQdjYtb25seSBvciBkdWFs LXN0YWNrIHdpcmVsZXNzIG5ldHdvcmsgKGluY2x1ZGluZyAzR1BQIGNlbGx1bGFyIG5ldHdvcmsg YW5kIElFRUUgODAyLjExIG5ldHdvcmspLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5JbiBwbGFjZSBvZiAmcXVvdDthIG51bWJlciBvZiBv cGVyYXRvcnMgYmVsaWV2ZSBpcyBuZWNlc3NhcnkgdG8gZGVwbG95JnF1b3Q7IHlvdSBjb3VsZCBo YXZlICZxdW90O2ludGVuZCB0byBkZXBsb3kmcXVvdDsgb3IgJnF1b3Q7cmVxdWlyZSZxdW90Oy4g SSdkIGd1ZXNzIHRoYXQgYXMgbG9uZyBhcyBpdCdzIGNsZWFyIHRoYXQgdGhlIHJlcXVpcmVtZW50 cyBkb24ndCBjb21lIGZyb20gdGhlIElFVEYgYnV0IGZyb20gYSBudW1iZXIgb2Ygb3BlcmF0b3Jz IChub3QgYWxsIG9mIHRoZW0sIG9yIGEgbWFqb3JpdHkgb2YgdGhlbSksIGl0IGRvZXNuJ3QgbWF0 dGVyIGV4YWN0bHkgd2hhdCB5b3Ugc2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+W01lZF0g SSBtYWRlIHRoaXMgY2hhbmdlOjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 aT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+T0xEOjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9 RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxpPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3Bh biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgYW4g SVB2NiBwcm9maWxlIGZvciAzR1BQIG1vYmlsZSBkZXZpY2VzLiZuYnNwOyBJdDwvc3Bhbj48c3Bh biBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyBsaXN0cyB0aGUgc2V0IG9mIGZlYXR1cmVz IGEgM0dQUCBtb2JpbGUgZGV2aWNlIGlzIHRvIGJlIGNvbXBsaWFudDwvc3Bhbj48c3BhbiBsYW5n PUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyB3aXRoIHRvIGNvbm5lY3QgdG8gYW4gSVB2Ni1vbmx5 IG9yIGR1YWwtc3RhY2sgd2lyZWxlc3MgbmV0d29yazwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyZuYnNwOyAoaW5jbHVkaW5nIDNHUFAgY2VsbHVsYXIgbmV0d29yayBhbmQgSUVF RSA4MDIuMTEgbmV0d29yaykuPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6IzFGNDk3RCc+TmV3Ojwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPUVO LVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDo1 LjI1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7 Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBJUHY2IHByb2ZpbGUgdGhhdCBhIG51bWJl ciBvZiBvcGVyYXRvcnM8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWxlZnQ6NS4yNXB0Jz48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyByZXF1aXJlIGluIG9yZGVy IHRvIGNvbm5lY3QgM0dQUCBtb2JpbGUgZGV2aWNlcyB0byBhbiBJUHY2LW9ubHkgb3I8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0n bWFyZ2luLWxlZnQ6NS4yNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMx RjQ5N0QnPiZuYnNwOyZuYnNwOyBkdWFsLXN0YWNrIHdpcmVsZXNzIG5ldHdvcmsgKGluY2x1ZGlu ZyAzR1BQIGNlbGx1bGFyIG5ldHdvcmsgYW5kIElFRUU8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyA4MDIuMTEgbmV0d29yaykuPC9zcGFuPjxz cGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGk+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxicj48 YnI+PGJyPjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUz4yLiBJbiB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIHNlY3Rpb24sIEknZCBsaWtlIHRvIHNl ZSBhIHN0YXRlbWVudCBzaW1pbGFyIHRvIHdoYXQncyBpbiBSRkMgNjA5Mi4gUGVyaGFwcyBzb21l dGhpbmcgbGlrZSB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48Yj48aT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+W01lZF0gSSB1c2VkIHRo ZSBzYW1lIHdvcmRpbmcgYXMgaW4gUkZDNjA5Mi4gVGhlIGNoYW5nZSBpcyBhcyBmb2xsb3dzOjwv c3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4m bmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFG NDk3RCc+T0xEOjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xv cjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZu YnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGlzIG5vdCBhIHN0YW5kYXJkLiZuYnNwOyBJdCB1c2Vz IHRoZSBub3JtYXRpdmUga2V5d29yZHMgb25seTwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZuYnNwOyZuYnNwOyBmb3IgcHJlY2lzaW9uLjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PGk+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPk5FVzo8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5n PUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48Yj48aT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PHNw YW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nbWFy Z2luLWxlZnQ6NS4yNXB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5 N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOT1RFIFdFTEw6IFRoaXMgZG9jdW1l bnQgaXMgbm90IGEgc3RhbmRhcmQsIGFuZCBjb25mb3JtYW5jZSB3aXRoPC9zcGFuPjxzcGFuIGxh bmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1s ZWZ0OjUuMjVwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4m bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXQgaXMgbm90IHJlcXVpcmVkIGluIG9yZGVy IHRvIGNsYWltIGNvbmZvcm1hbmNlIHdpdGggSUVURjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tbGVmdDo1LjI1cHQn PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YW5kYXJkcyBmb3IgSVB2Ni4mbmJzcDsgSXQgdXNlcyB0aGUg bm9ybWF0aXZlIGtleXdvcmRzIGRlZmluZWQgaW4gdGhlPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJldmlv dXMgc2VjdGlvbiBvbmx5IGZvciBwcmVjaXNpb24uPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPUVO LVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnY2b3BzIG1haWxpbmcgbGlzdDxicj48 YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUn PnY2b3BzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+PHNwYW4gc3R5bGU9J2NvbG9yOnB1cnBsZSc+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_1808340F7EC362469DDFFB112B37E2FCD2BABB5CCDSRVHKE02rdmcz_-- From owen@delong.com Mon Sep 9 14:06:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7846011E80F8; Mon, 9 Sep 2013 14:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kU22Hnko+rX; Mon, 9 Sep 2013 14:06:11 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4557C11E8141; Mon, 9 Sep 2013 14:05:47 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r89L4x1a026167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Sep 2013 14:04:59 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r89L4x1a026167 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378760699; bh=OhTu1h8gaC6kkcnetJS+V/MrNfo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=bIuLKkGnTRav7ytPNNFewPwvxUwl/sE6PnMaPALVhWpAE2qnRoXqVDI+EEwHLguK0 F7h7LavGZQYOz0kDEq4eBGoebBoMlY4K2yJnh7GWfYqipFyiwqcjcZlnYf/9E/h5t0 TIQvS6uBvaKmoROzwgfXd4tAADl93zgMYrUz1FKo= Content-Type: multipart/alternative; boundary="Apple-Mail=_38E27E03-218D-4AA7-8FB0-CCB6FDEEE743" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCD2BABB5CCD@SRVHKE02.rdm.cz> Date: Mon, 9 Sep 2013 14:04:57 -0700 Message-Id: <36E78FC1-5CC3-4A22-B231-6E3E10963836@delong.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <17! 9F53B5-6217-49A0-B5FE-A88011533860@delong.com> <1808340F7EC362469DDFFB112B37E2FCD2BABB5CCD@SRVHKE02.rdm.cz> To: =?windows-1252?Q?V=EDzdal_Ale=9A?= X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 09 Sep 2013 14:04:59 -0700 (PDT) Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:06:13 -0000 --Apple-Mail=_38E27E03-218D-4AA7-8FB0-CCB6FDEEE743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 9, 2013, at 13:36 , V=EDzdal Ale=9A = wrote: > Please see inline. > =20 > Ales > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Owen DeLong > Sent: Monday, September 09, 2013 10:07 PM > To: mohamed.boucadair@orange.com > Cc: v6ops@ietf.org WG; Dave Cridland; IETF Discussion > Subject: Re: [v6ops] Last Call: = (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > I have to agree with Lorenzo here again. > =20 > This document seems to me to be: > =20 > 1. Out of scope for the IETF. > [av] Strongly disagree. The IETF as the IPv6 owner is the right place = to define what qualifies a device to be IPv6 compliant. (a mobile one in = this case) > =20 This is intended as "informational", not a standards track document, so = it does not do that. > 2. So watered down in its language as to use many = words to say nearly nothing. > [av] Hints on how the text shall be changed are always welcome. If you don't leave it watered down, it becomes a standards track = document. There appears to be even greater resistance to that, so I = don't see such a document as being likely to achieve any greater degree = of consensus. > =20 > 3. Claims to be informational, but with so many = caveats about the nature of that > information that it's hard to imagine what = meaningful information an independent > reader could glean from the document. > [av] The reader will learn what must/should/may be = implemented in a mobile device to support IPv6. Except that this document is clearly marked as informational and not = standards track and there fore the application of must/should/may to it = is seemingly rather absurd. > =20 > Finally, given the spirited debate that has extended into this last = call (which I honestly wonder > how this ever saw last call over the sustained objections) definitely = does not appear to have > even rough consensus, nor does it appear to have running code. > [av] Med has posted an answer on this one earlier in the thread. > =20 I was not entirely satisfied with his answer. > Why is there such a push to do this? > [av] Because the Operators are currently missing such a document, so = they went to the IETF to work on one. > As written in the document the number of well behaving IPv6 capable = mobile devices is not very high at the moment. > This initiative is intended to help the developers. Is there any reason a cellphone shouldn't just meet the standard = requirements like any other router? Owen > =20 > Owen > =20 > On Sep 9, 2013, at 05:16 , wrote: >=20 >=20 > Re-, > =20 > Please see inline. > =20 > Cheers, > Med > =20 > De : Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Envoy=E9 : lundi 9 septembre 2013 13:24 > =C0 : BOUCADAIR Mohamed IMT/OLN > Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF = Discussion > Objet : Re: [v6ops] Last Call: = (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > On Mon, Sep 9, 2013 at 8:06 PM, wrote: > The document explicitly says =93This document is not a standard.=94 = since version -00. > =20 > What additional statement you would like to see added? > =20 > I think the high-order points are: > =20 > 1. The text "This document defines an IPv6 profile for 3GPP mobile = devices. It lists the set of features a 3GPP mobile device is to be = compliant with to connect to an IPv6-only or dual-stack wireless = network" should be replaced with "This document defines an IPv6 profile = for 3GPP mobile devices that a number of operators believe is necessary = to deploy IPv6 on an IPv6-only or dual-stack wireless network (including = 3GPP cellular network and IEEE 802.11 network)." > =20 > In place of "a number of operators believe is necessary to deploy" you = could have "intend to deploy" or "require". I'd guess that as long as = it's clear that the requirements don't come from the IETF but from a = number of operators (not all of them, or a majority of them), it doesn't = matter exactly what you say. > [Med] I made this change: > =20 > OLD: > =20 > This document defines an IPv6 profile for 3GPP mobile devices. It > lists the set of features a 3GPP mobile device is to be compliant > with to connect to an IPv6-only or dual-stack wireless network > (including 3GPP cellular network and IEEE 802.11 network). > =20 > New: > =20 > This document defines an IPv6 profile that a number of operators > require in order to connect 3GPP mobile devices to an IPv6-only or > dual-stack wireless network (including 3GPP cellular network and = IEEE > 802.11 network). >=20 >=20 >=20 > 2. In the normative language section, I'd like to see a statement = similar to what's in RFC 6092. Perhaps something like this? > [Med] I used the same wording as in RFC6092. The change is as follows: > =20 > OLD: > =20 > This document is not a standard. It uses the normative keywords = only > for precision. > =20 > NEW: > =20 > NOTE WELL: This document is not a standard, and conformance with > it is not required in order to claim conformance with IETF > standards for IPv6. It uses the normative keywords defined in = the > previous section only for precision. > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_38E27E03-218D-4AA7-8FB0-CCB6FDEEE743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 ales.vizdal@t-mobile.cz> = wrote:

Please see = inline.
 
Ales
 
 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Owen = DeLong
Sent: Monday, September 09, 2013 = 10:07 PM
To:  v6ops@ietf.org WG; Dave Cridland; IETF = Discussion
Subject: Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational = RFC
I have to = agree with Lorenzo here again.
 
This = document seems to me to be:
 
1. Out of = scope for the IETF.[av] Strongly disagree. The IETF as the IPv6 owner = is the right place to define what qualifies a device to be IPv6 = compliant. (a mobile one in this case)

2. So watered = down in its language as to use many words to say nearly = nothing.
[av] Hints on how the text shall be changed are = always welcome.
        &= nbsp; 3.        <= span class=3D"Apple-converted-space"> Claims to be = informational, but with so many caveats about the nature of = that
        &= nbsp;           &nb= sp; information = that it's hard to imagine what meaningful information an = independent
        &= nbsp;           &nb= sp; reader = could glean from the document.
how this ever saw last call over the sustained = objections) definitely does not appear to = have
even rough = consensus, nor does it appear to have running = code.
[av] Med has posted an answer on this one earlier in = the thread.
Why is there such a push = to do this?
[av] Because the Operators are currently = missing such a document, so they went to the IETF to work on = one.
As written in the document the number of well = behaving IPv6 capable mobile devices is not very high at the = moment.
This initiative is intended to help the = developers.

Is there any reason a cellphone shouldn't just meet the standard = requirements like any other = router?

Owen

 
Owen
On = Sep 9, 2013, at 05:16 , <mohamed.boucadair@orange.com> = wrote:
Re-,
 
Please see inline.
 
Cheers,
Med
 
The document = explicitly says =93This document is not a = standard.=94 since version = -00.
 
What additional =
statement you would like to see added?
 
I think the high-order points = are:
 
1. The text "This document = defines an IPv6 profile for 3GPP mobile devices. It lists the set of = features a 3GPP mobile device is to be compliant with to connect to an = IPv6-only or dual-stack wireless network" should be replaced with "This = document defines an IPv6 profile for 3GPP mobile devices that a number = of operators believe is necessary to deploy IPv6 on an IPv6-only or = dual-stack wireless network (including 3GPP cellular network and IEEE = 802.11 network)."
 
In place of "a number of = operators believe is necessary to deploy" you could have "intend to = deploy" or "require". I'd guess that as long as it's clear that the = requirements don't come from the IETF but from a number of operators = (not all of them, or a majority of them), it doesn't matter exactly what = you say.
[Med] I made this = change:
   This document defines an IPv6 profile for = 3GPP mobile devices.  It
   lists the set of features a 3GPP mobile = device is to be compliant
   with to connect to an IPv6-only or = dual-stack wireless network
   (including 3GPP cellular network and IEEE = 802.11 network).
   This document defines an IPv6 profile that a number = of operators
   require in order to connect 3GPP = mobile devices to an IPv6-only or
   dual-stack wireless network (including 3GPP = cellular network and IEEE
   802.11 = network).
2. In the normative language = section, I'd like to see a statement similar to what's in RFC 6092. = Perhaps something like this?
[Med] I = used the same wording as in RFC6092. The change is as = follows:
   This document is not a standard.  It = uses the normative keywords only
   for precision.
      NOTE WELL: This document is not a = standard, and conformance with
      it is not required in order to = claim conformance with IETF
      standards for IPv6.  It uses = the normative keywords defined in the
      = previous section only for precision.
To: Owen DeLong Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHOraCxfmd6tFh7TEyulzq88K5MgJm+XraA Date: Mon, 9 Sep 2013 21:19:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077527D9A6@mbx-01.win.nominum.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <17! 9F53B5-6217-49A0-B5FE-A88011533860@delong.com> <1808340F7EC362469DDFFB112B37E2FCD2BABB5CCD@SRVHKE02.rdm.cz> <36E78FC1-5CC3-4A22-B231-6E3E10963836@delong.com> In-Reply-To: <36E78FC1-5CC3-4A22-B231-6E3E10963836@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:20:51 -0000 Owen, do you have any technical objection to raise about this document, or = are you just replying because you like the sound the keys make as you type? The working group adopted the document, so it's too late to object that the= working group shouldn't be working on it. You can object by pointing out= that it doesn't do what it says it's going to do, but if so you'd need to = actually make the case that it doesn't do that, not just assert that it doe= sn't do that. Your point about RFC 2119 language has been addressed, so there's no sense = in re-raising it unless you have some specific objection to state about the= way in which it was addressed ("I'm not satisfied" is not a specific objec= tion). Etc. From markzzzsmith@yahoo.com.au Mon Sep 9 14:26:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D6211E815A for ; Mon, 9 Sep 2013 14:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yng-XeigbOf for ; Mon, 9 Sep 2013 14:26:05 -0700 (PDT) Received: from nm45-vm5.bullet.mail.bf1.yahoo.com (nm45-vm5.bullet.mail.bf1.yahoo.com [216.109.115.76]) by ietfa.amsl.com (Postfix) with ESMTP id DA18611E8153 for ; Mon, 9 Sep 2013 14:25:50 -0700 (PDT) Received: from [98.139.212.153] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2013 21:25:49 -0000 Received: from [98.139.212.213] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 09 Sep 2013 21:25:49 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 09 Sep 2013 21:25:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 364892.55428.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 55613 invoked by uid 60001); 9 Sep 2013 21:25:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1378761949; bh=YUrqtFFeMaB5CrgOgTFph7GPWNBQOmMP013mhmaY04A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QIqBT4qh77I/K3D9CvpcyOpWwT85y7ir/Y/bR/UaJwQF0ErC/oqc6jYpUUd4aIfarHK61eCdtt9GVhnlqf05LTVTqHSZpdBbMAy4zKTYgsEqFDAMGKefwCgyHaaNLpbXgPMOP+slA79YXkFG+/taE28kGKH107hZVQb8Ybm2aKA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tmbI2mdVBXWSldNpNo7WVtL3f9ZMiJyhcF3igUrsgwwEgZiDeDlpY9esbkNqNseFpIP5Qpzp9I2ZVH8ENF/wR+2yGhm8+6TgAyTTmUGbLoLrES4LGNg/0XdnDKJqk+LXQjZF9oAg/rS3lRcmW+5lyzDOVNJ9eujPY2hKTUJQnn4=; X-YMail-OSG: 2NG5PJsVM1k6tmPCykamZtOe_krTi2.9MUTEoiDQvE83h.q gMvblUTavg_CewAP9.BeJzRuibWQKdBDpNRhoj4hYIsSKIHjKY_8OHQtNV0_ DewxmUOQlvuK0CjHHOXjqpcRpru4OkUMWDLSIBGs53MPNha0iqXVBWE.40mK wTN8bcqj3id3ueiX88_XZmCaKJtKRESAdaQQNZmaTQt1iM6.KcTSsVrBeLG8 h6zN5CLyWG2GgGHyABwkshs4sf0pXCx19PyvfnQw5f9jx39UDZUZScIvG5qx eq99mrtzrrfOg5aLvXxeItfu1vPhMP5km0B0Gf7P7NtCg4bNrKWe2wMiyfNq fxvBj8vw5FAcy6wWLEW_T5ajquc4lfcchaNEu.o9C5z7Md73_6dKaTK8zzXq oeca3_DfidyUUh4xGzOb6tC57pkh0j1z.WtignprQkPnb3hEC2ULtkrgv73I HO_m6iO0qkdg9vyEh4NCOLQdTzTv.xtRg.HRJfxQzKRBm1NVkOrreZoqo5AO 4_daSGbne3qoOd9KrgW5VLv.idukaUhVWNprthWhfgWNzavApmFBh.oMRvdT nlBUXkWXvHjsqv1ojU74G2g2zh6zZDgULnLMOEimFWDw8ovrL4DaZdHBOQcx batzOJow5_Zfw0SLFLi2D2Pp2w_QDWQBdOTyxo8lCNbNgpSrmBRt4RMSvZuj VKLA4miNhdQ_LKVoB_y_NKPiL7Szq Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 09 Sep 2013 14:25:49 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29tPgo.VG86IFbDrXpkYWwgQWxlxaEgPGFsZXMudml6ZGFsQHQtbW9iaWxlLmN6PiAKPkNjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz47IElFVEYgRGlzY3Vzc2lvbiA8aWV0ZkBpZXRmLm9yZz47IERhdmUgQ3JpZGxhbmQgPGRhdmVAY3JpZGxhbmQubmV0PiAKPlNlbnQ6IFR1ZXNkYXksIDEwIFNlcHRlbWJlciAyMDEzIDc6MDQgQU0KPlN1YmplY3Q6IFJlOiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <17! 9F53B5-6217-49A0-B5FE-A88011533860@delong.com> <1808340F7EC362469DDFFB112B37E2FCD2BABB5CCD@SRVHKE02.rdm.cz> <36E78FC1-5CC3-4A22-B231-6E3E10963836@delong.com> Message-ID: <1378761949.55183.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 9 Sep 2013 14:25:49 -0700 (PDT) From: Mark ZZZ Smith To: Owen DeLong , =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= In-Reply-To: <36E78FC1-5CC3-4A22-B231-6E3E10963836@delong.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:26:11 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Owen DeLong =0A>To: V=C3=ADzdal Ale=C5=A1 =0A>Cc= : "v6ops@ietf.org WG" ; IETF Discussion ; Da= ve Cridland =0A>Sent: Tuesday, 10 September 2013 7:04 A= M=0A>Subject: Re: [v6ops] Last Call:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(Internet=C2=A0=C2= =A0=C2=A0=C2=A0Protocol Version 6 (IPv6) Profile for 3GPP Mobile=C2=A0=C2= =A0=C2=A0=C2=A0Devices) to=C2=A0=C2=A0=C2=A0=C2=A0Informational RFC=0A> =0A= >=0A>=0A=0A=0A=0A>=0A>Why is there such a push to do this?=0A>>[av] B= ecause the Operators are currently missing such a document, so they went to= the IETF to work on one.=0A>>As written in the document the number of well= behaving IPv6 capable mobile devices is not very high at the moment.=0A>>T= his initiative is intended to help the developers.=0A>=0A>Is there any reas= on a cellphone shouldn't just meet the standard requirements like any other= router?=0A>=0A=0AI agree with this view. I don't think there is anything t= hat special about portable computers that =C2=A0that can make phone calls= =C2=A0("mobile multihomed hosts"*).=0A=0AIt seems to me the only thing spec= ial here is that one of the links the MMHH has is a 3G/4G etc. one, and the= operators of those networks have certain views on how those networks shoul= d operate. That would seem to me to give them the ability to select what pa= rameters are chosen for IPv6 operation over their networks e.g., stateful D= HCPv6 only, prefix lifetimes of 2/1 hours etc., but to extend that to listi= ng IPv6 protocol implementation requirements across the whole MMHH seems ex= cessive and unnecessary. Surely the existing IPv6 node requirements RFC is = enough for that?=0A=0ARegards,=0AMark.=0A=0A=0A=0A*"The Rapid Rise of the M= obile=C2=A0Multihomed Host,=C2=A0and what it might mean to the network"=0Ah= ttp://www.users.on.net/~markachy/The_Rapid_Rise_of_the_MMHH.pdf=0A From Ted.Lemon@nominum.com Mon Sep 9 18:26:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE8C11E810D; Mon, 9 Sep 2013 18:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.176 X-Spam-Level: X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvpEKr2u-Dto; Mon, 9 Sep 2013 18:26:11 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6E11E80D1; Mon, 9 Sep 2013 18:26:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUi51J/7XiYUdhpUXr96YzZyY9HivQJyY@postini.com; Mon, 09 Sep 2013 18:26:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6524B1B823A; Mon, 9 Sep 2013 18:25:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5EDDE19006D; Mon, 9 Sep 2013 18:25:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 18:25:59 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHOrcS0l0yCK38ebUaBnfdZ84Ci6w== Date: Tue, 10 Sep 2013 01:25:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077527E349@mbx-01.win.nominum.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <17! 9F53B5-6217-49A0-B5FE-A88011533860@delong.com> <1808340F7EC362469DDFFB112B37E2FCD2BABB5CCD@SRVHKE02.rdm.cz> <36E78FC1-5CC3-4A22-B231-6E3E10963836@delong.com> <8D23D4052ABE7A4490E77B1A012B63077527D9A6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077527D9A6@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <817484EBC5C58543A2A74EF1F8E63ED3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:26:18 -0000 It has been pointed out to me that I went overboard in my response to you. = I will state what was obvious to me as I wrote my response, but may not h= ave been obvious to other readers: I am not the responsible AD for v6ops. = My response was that of a participant in v6ops. I didn't find what you wrote helpful, but what I like isn't particularly im= portant in this case, unless you decide it is. I did not intend to sugges= t that you should not criticize this document. I would like to see more s= ubstance to the criticism. But the way I expressed that desire was (a) overly sarcastic and (b) not co= nstructive, and I apologize for that. From joelja@bogus.com Mon Sep 9 21:41:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244EB21E8114; Mon, 9 Sep 2013 21:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6qnsnPmKl0r; Mon, 9 Sep 2013 21:41:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9809421E80FD; Mon, 9 Sep 2013 21:41:51 -0700 (PDT) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r8A4fmuY055247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 10 Sep 2013 04:41:48 GMT (envelope-from joelja@bogus.com) Message-ID: <522EA306.9010103@bogus.com> Date: Mon, 09 Sep 2013 21:41:42 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Lorenzo Colitti , "" References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 10 Sep 2013 04:41:49 +0000 (UTC) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 04:41:52 -0000 On 9/9/13 4:24 AM, Lorenzo Colitti wrote: > On Mon, Sep 9, 2013 at 8:06 PM, > wrote: > > The document explicitly says “This document is not a standard.” > since version -00. > > __ __ > > What additional statement you would like to see added? > > > I think the high-order points are: > > 1. The text "This document defines an IPv6 profile for 3GPP mobile > devices. It lists the set of features a 3GPP mobile device is to be > compliant with to connect to an IPv6-only or dual-stack wireless > network" should be replaced with "This document defines an IPv6 profile > for 3GPP mobile devices that a number of operators believe is necessary > to deploy IPv6 on an IPv6-only or dual-stack wireless network (including > 3GPP cellular network and IEEE 802.11 network)." > > In place of "a number of operators believe is necessary to deploy" you > could have "intend to deploy" or "require". I'd guess that as long as > it's clear that the requirements don't come from the IETF but from a > number of operators (not all of them, or a majority of them), it doesn't > matter exactly what you say. So this is a problem, and part of the reason I had enough concern about this document to not take it forward. being genereous the consensus on this document is pretty rough. if the outcome doesn't include the consent of implementors it's not very good advice. > 2. In the normative language section, I'd like to see a statement > similar to what's in RFC 6092. Perhaps something like this? > > 1.3. Use of Normative Keywords > > NOTE WELL: This document is not a standard. Conformance with it is > not required to deploy IPv6 in mobile networks or to claim conformance > with IETFstandards for IPv6. It uses the normative keywords > defined in the > previous section only for precision. > > Regards, > Lorenzo From mohamed.boucadair@orange.com Mon Sep 9 23:27:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1790A11E817B; Mon, 9 Sep 2013 23:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSqHq2EsoUds; Mon, 9 Sep 2013 23:27:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CED4411E8162; Mon, 9 Sep 2013 23:27:18 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2340322C422; Tue, 10 Sep 2013 08:27:17 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 075454C015; Tue, 10 Sep 2013 08:27:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 10 Sep 2013 08:27:13 +0200 From: To: joel jaeggli , Lorenzo Colitti Date: Tue, 10 Sep 2013 08:27:09 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6t4BPt4rQy07DORSyr1fOC7MOEOAADBTsQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE7D30@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <522EA306.9010103@bogus.com> In-Reply-To: <522EA306.9010103@bogus.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.9.225415 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 06:27:25 -0000 Hi Joel, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: joel jaeggli [mailto:joelja@bogus.com] >Envoy=E9=A0: mardi 10 septembre 2013 06:42 >=C0=A0: Lorenzo Colitti; BOUCADAIR Mohamed IMT/OLN >Cc=A0: v6ops@ietf.org WG; IETF Discussion; BINET David IMT/OLN >Objet=A0: Re: [v6ops] Last Call: 04.txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile >Devices) to Informational RFC > >On 9/9/13 4:24 AM, Lorenzo Colitti wrote: >> On Mon, Sep 9, 2013 at 8:06 PM, > > wrote: >> >> The document explicitly says "This document is not a standard." >> since version -00. >> >> __ __ >> >> What additional statement you would like to see added? >> >> >> I think the high-order points are: >> >> 1. The text "This document defines an IPv6 profile for 3GPP mobile >> devices. It lists the set of features a 3GPP mobile device is to be >> compliant with to connect to an IPv6-only or dual-stack wireless >> network" should be replaced with "This document defines an IPv6 profile >> for 3GPP mobile devices that a number of operators believe is necessary >> to deploy IPv6 on an IPv6-only or dual-stack wireless network (including >> 3GPP cellular network and IEEE 802.11 network)." >> >> In place of "a number of operators believe is necessary to deploy" you >> could have "intend to deploy" or "require". I'd guess that as long as >> it's clear that the requirements don't come from the IETF but from a >> number of operators (not all of them, or a majority of them), it doesn't >> matter exactly what you say. > >So this is a problem, and part of the reason I had enough concern about >this document to not take it forward. being genereous the consensus on >this document is pretty rough. if the outcome doesn't include the >consent of implementors it's not very good advice. [Med] Joel, the intent of the document is clear: the goals and scope are un= changed since the individual submission. You can read the following in the= introduction:=20 " This document specifies an IPv6 profile for mobile devices listing specifications produced by various Standards Developing Organizations (in particular 3GPP and IETF). The objectives of this effort are: 1. List in one single document a comprehensive list of IPv6 features for a mobile device, including both IPv6-only and dual-stack mobile deployment contexts. These features cover various network types such as GPRS (General Packet Radio Service), EPC (Evolved Packet Core) or IEEE 802.11 network. 2. Help Operators with the detailed device requirement list preparation (to be exchanged with device suppliers). This is also a contribution to harmonize Operators' requirements towards device vendors. 3. Vendors to be aware of a set of features to allow for IPv6 connectivity and IPv4 service continuity (over an IPv6-only transport)." Operators will use this profile (or some part of it (context-based: ipv6-o= nly, DS, CPE model, etc.)) for further discussion with their vendors. We ar= e not changing that process. This document is a contribution to have non br= oken IPv6 implementations.=20 For instance, our device partners will see in our 500 pages device requirem= ents document (OGDR) pointers to this profile document. So adding the text = suggested by Lorenzo is fine by me. This is the change added to my local co= py: This document defines an IPv6 profile that a number of operators require in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). Having consent form all vendors is valuable but I'm afraid this is not the = goal of this document.=20 How can we ensure every implementers will agree with this list? For instanc= e we have two detailed technical reviewers from vendors who are happy with = the content of the document ... but in the meantime I have two reviewers fr= om the same company: one of them suggested to make some edits to enhance th= e document while the other reviewer have some concerns. The concerns of the= second reviewer were addressed and changes were added to my local copy. > >> 2. In the normative language section, I'd like to see a statement >> similar to what's in RFC 6092. Perhaps something like this? >> >> 1.3. Use of Normative Keywords >> >> NOTE WELL: This document is not a standard. Conformance with it is >> not required to deploy IPv6 in mobile networks or to claim >conformance >> with IETFstandards for IPv6. It uses the normative keywords >> defined in the >> previous section only for precision. >> >> Regards, >> Lorenzo From lorenzo@google.com Mon Sep 9 23:43:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46911E8188 for ; Mon, 9 Sep 2013 23:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEA4uuGgItWB for ; Mon, 9 Sep 2013 23:43:09 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A72F111E817A for ; Mon, 9 Sep 2013 23:43:08 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id 16so4162567iea.2 for ; Mon, 09 Sep 2013 23:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XjsrMpl2UQTFMn033At9XPVHcGxnxfalNsIYzUl2k8g=; b=gLeXDX1s8WJ09GDSGQGIpXm9GpB9Uu583MYyb8w4cg5TX2vL6VzZqO/tk0i0bIi768 Yz1VyLHjNCDTLgCxyhwv5bRuSc0Dnod9CQ7BeOQf/E8DvSrFlzSXkhW+qXVNR924/JFp LddPbBibup+ApQEVpDR2BSjuTRHXLtDvgVkw3gxTQR2lmP0ODJaTEnoWqv9ptumVvvSm OirLN9O5j5bU6gQYgG6VJt+2thcKN0diRLdaMmgEHyE4P/r7UHm/CXRok4L5wB6pCa5+ 7RJA9F4ZTPMESPrGAIZ57rnGMhLTC0oyexlVhrOBYuUZw1Blz0S9I9Pu2muOtPxzBe8o u91Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XjsrMpl2UQTFMn033At9XPVHcGxnxfalNsIYzUl2k8g=; b=LmDXzk6guIrWuIoDqmEjDQy7NBBO77ZdIIN8GNwTQ9TRPEkpRJcQ0hfh6+ioJx+fhs nd7Fnyd4JKKvinLYkUMIM8wouwdK68lIBpafWZPR7dA6utVXKv0lH/R7N0z/XC85uT4m nzY1mibzB2fvUmQoaI9PbzjINTS9h3gPJO1cMzsPWw++b/ScPvy+P29Wh86f6SJAxAfG +mQfKLKPQZMCqZ2UnmKFPigd/jHwNSmhKdihbW7FIFxUi9JuG/oh93gNlvh4jICnFgRn kKX7l/mOA5a3PrmXGQTiE5N2h5+rCM7oYCI4aXETlXzguM2KdG/FNfp+JjDnjsb9CMmi 54aA== X-Gm-Message-State: ALoCoQl2AfNfMWeV9Wl2LdSkyVDE9D519hwNjF9FN/abd/BlyZzWDlFlX2KhMRUp5/xsHS0cvlA9cgd+lr5NvrtKH9IzOJqfNCzMe9RUB2tfNbW+9sSHXfwBEyM/J6nri6mkmH6TiCZYgLXesvDW2Uf5GWO06O5oSzVZjHXcSv/OLXuEm9v/F5K4fuS3O6iYpxZEpJ2UacI4 X-Received: by 10.50.73.194 with SMTP id n2mr10371522igv.6.1378795386883; Mon, 09 Sep 2013 23:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Mon, 9 Sep 2013 23:42:46 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7D30@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <522EA306.9010103@bogus.com> <94C682931C08B048B7A8645303FDC9F36EF0EE7D30@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 15:42:46 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=089e0122ee3240f72704e601d175 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 06:43:11 -0000 --089e0122ee3240f72704e601d175 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 3:27 PM, wrote: > Having consent form all vendors is valuable but I'm afraid this is not the > goal of this document. > If not "all vendors", then what about "some vendors"? Is it a goal of this document to have consensus from some implementors? Or is consensus from implementors a non-goal? --089e0122ee3240f72704e601d175 Content-Type: text/html; charset=ISO-8859-1
On Tue, Sep 10, 2013 at 3:27 PM, <mohamed.boucadair@orange.com> wrote:
Having consent form all vendors is valuable but I'm afraid this is not the goal of this document.

If not "all vendors", then what about "some vendors"? Is it a goal of this document to have consensus from some implementors? Or is consensus from implementors a non-goal?
--089e0122ee3240f72704e601d175-- From lorenzo@google.com Mon Sep 9 23:48:53 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E4811E8194 for ; Mon, 9 Sep 2013 23:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6EJP8rIffFb for ; Mon, 9 Sep 2013 23:48:52 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0F11E81C3 for ; Mon, 9 Sep 2013 23:48:52 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id 9so1020208iec.6 for ; Mon, 09 Sep 2013 23:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TYfQ8CdCE983m24RKr1EJ35PUf3M3NDMKq8Tvanhns4=; b=JvZGL1cdmbplxLjdcOY9f5kMdTIloF8M1P8T50/cFCrAATeWEPFXCizZRtTSozaR4w 4Ff3qHPpCPgMSby+8HgmNl8CqCFxqEtwus3cju0wIDgHRG0z8N7cTnAWPfUYvHkZ4dxs vXDqqEbv5FiVwqcJZcGBKqHjCKnB1SllkOutChx531IkdG1vczpiZly9Hw6z61+tDwvF VelSN0H1V2SrmxyHMyrcfbi8yLUtgO96UQcBHWSaatFRLE1xcwX62wanD61RmWa6Wwop iBNP+8nki4f5+D4jgmridASI0myoNvNwF63QpAtf1z+gP6FZiGDvmu5DUp+XPk60LumQ 6RuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TYfQ8CdCE983m24RKr1EJ35PUf3M3NDMKq8Tvanhns4=; b=PcNNiRHm03ib9J2GHKJq+CEpKvJ7EEHOU9t9bV2aL9VFCsz1M+DpbP3N+mG4eSxt6P v5KdXW9uI0+kDbUw6taOeiP6i6rn+m4Vg87VhDBbz+qF8gbOmqK7F8rdgeOA8aXAxXFn pwwzMe+sP6ytmPjxiqY43d6GinGSItYFvQdcDy1W5fnCo7B3LUqTwlw4rCb5XObPIqO2 ADgLEE+bK2RU0Ddi8HJ7xh5M1ArBM6ZYQeoLeVe86K4zuq99fh4CRYRB9bZlpApnKlBU GDJXGr1r8U8/NH67x8K4mjHFICsuGZuUS2Yqe5gN85v9FoKAWpix1jzJVsTIsIajHBXL AeEg== X-Gm-Message-State: ALoCoQk9+BrrN8MilgeP8z7c01C60APz08rtmvov4lk5Xn+YzaYVhmk8lW/dL/qvtS3tHi3/fMSJAO3JDkqDPWauBMuDNhf0sj0Vv1sPkfQ/4/p8dA4q2M0d9KRCX4cTlqbairnFVUIdXwkBxml8cZBIJH9j8bBrGRpAPebnuBZbZN4JnmwgQfqreqY2Oi5zn4LwGS1OZPWw X-Received: by 10.50.114.168 with SMTP id jh8mr10370947igb.6.1378795731640; Mon, 09 Sep 2013 23:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Mon, 9 Sep 2013 23:48:31 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 15:48:31 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=089e01229f86cd930c04e601e549 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 06:48:53 -0000 --089e01229f86cd930c04e601e549 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 9, 2013 at 9:16 PM, wrote: > * > NEW:* > > * * > > NOTE WELL: This document is not a standard, and conformance with**** > > it is not required in order to claim conformance with IETF**** > > standards for IPv6. It uses the normative keywords defined in the** > ** > > previous section only for precision.**** > > * * > That's better, thanks. I still think it's important for the document to say that it's not necessary to do all mountain of work to deploy IPv6, because otherwise there's the risk that product managers/implementors will say, "Wait, are you're saying that to deploy IPv6 we have to do all that work? We can't do all that. Let's focus on something else instead." How about changing "is not required in order to claim conformance with IETF standards for IPv6" to "is not required to deploy IPv6 on other networks or to claim conformance with IETF standards for IPv6"? --089e01229f86cd930c04e601e549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 9, 2013 at 9:16 PM, <mohamed.bouc= adair@orange.com> wrote:


NEW:

=A0

=A0=A0=A0=A0=A0 NOTE = WELL: This document is not a standard, and conformance with

=A0 =A0=A0=A0=A0it is= not required in order to claim conformance with IETF<= /p>

=A0=A0=A0=A0=A0 standards for IPv6.=A0 It uses the normative key= words defined in the

=A0=A0=A0=A0=A0 previous section only for precision.=

=A0


That'= s better, thanks. I still think it's important for the document to say = that it's not necessary to do all mountain of work to deploy IPv6, beca= use otherwise there's the risk that product managers/implementors will = say, "Wait, are you're saying that to deploy IPv6 we have to do al= l that work? We can't do all that. Let's focus on something else in= stead."

How about c= hanging "is not required in order to claim conformance with IETF stand= ards for IPv6" to "is not required to deploy IPv6 on other networ= ks or to=A0claim conformance with IETF standards for IPv6"?
--089e01229f86cd930c04e601e549-- From mohamed.boucadair@orange.com Mon Sep 9 23:58:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44C21E811E; Mon, 9 Sep 2013 23:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn9PnQmgRsCF; Mon, 9 Sep 2013 23:58:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66B21F8756; Mon, 9 Sep 2013 23:58:02 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0DDFE18C13C; Tue, 10 Sep 2013 08:57:59 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E1D43238055; Tue, 10 Sep 2013 08:57:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 10 Sep 2013 08:57:54 +0200 From: To: Lorenzo Colitti Date: Tue, 10 Sep 2013 08:57:52 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6t8dDQE0Ex3P6GRNOi1org5og3jQAAGhpw Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF0EE7D57PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.55415 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 06:58:11 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7D57PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re, I have considered that Lorenzo. "is not required to deploy IPv6" would be a= ccurate if this document is dealing only with dual-stack, but this is not t= rue for the IPv6-only mode. The set of SHOULD recommendations are targeting= that deployment model. Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : mardi 10 septembre 2013 08:49 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Mon, Sep 9, 2013 at 9:16 PM, > wrote: NEW: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision. That's better, thanks. I still think it's important for the document to say= that it's not necessary to do all mountain of work to deploy IPv6, because= otherwise there's the risk that product managers/implementors will say, "W= ait, are you're saying that to deploy IPv6 we have to do all that work? We = can't do all that. Let's focus on something else instead." How about changing "is not required in order to claim conformance with IETF= standards for IPv6" to "is not required to deploy IPv6 on other networks o= r to claim conformance with IETF standards for IPv6"? --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7D57PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re,

 

= I = have considered that Lorenzo. “is not required to deploy IPv6<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>= 221; would be accurate if this document is dealing only with dual-stack, bu= t this is not true for the IPv6-only mode. The set of SHOULD recommendation= s are targeting that deployment model.

 

Cheers,

Med

&n= bsp;

 

=

De : Lorenzo Coli= tti [mailto:lorenzo@google.com]
Envoy=E9 : mardi 10 septemb= re 2013 08:49
=C0 : BOUCADAIR Mohamed IMT/OLN
Cc = : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussio= n
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile= -device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile for = 3GPP Mobile Devices) to Informational RFC

=

 

On Mon,= Sep 9, 2013 at 9:16 PM, <mohamed.boucadair@orange.com> wrote:<= /p>


NEW:

 =

    &nbs= p; NOTE WELL: This document is not a standard, and conformance with<= o:p>

      i= t is not required in order to claim conformance with IETF=

      standards = for IPv6.  It uses the normative keywords defined in the

      previous section only for = precision.

 =

 

That's better, thanks. I still thin= k it's important for the document to say that it's not necessary to do all = mountain of work to deploy IPv6, because otherwise there's the risk that pr= oduct managers/implementors will say, "Wait, are you're saying that to= deploy IPv6 we have to do all that work? We can't do all that. Let's focus= on something else instead."

 

How about changin= g "is not required in order to claim conformance with IETF standards f= or IPv6" to "is not required to deploy IPv6 on other networks or = to claim conformance with IETF standards for IPv6"?

= --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7D57PUEXCB1Bnante_-- From lorenzo@google.com Tue Sep 10 00:20:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7556321E8128 for ; Tue, 10 Sep 2013 00:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b2OURckaC1w for ; Tue, 10 Sep 2013 00:20:57 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CA81D21E80FB for ; Tue, 10 Sep 2013 00:20:57 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so15240195ieb.14 for ; Tue, 10 Sep 2013 00:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8fv2VoS1X8S64+oAwLXLDiadURpnoVHuylDiwpc3DEc=; b=hGg0v6AzMVELdfHZNLsPK7ssYrFVhH55ZOLXrfl7vX/v8xTfrwJh1/ZONFee7y2zKV Fv009aBdQgnQYrVaJC+9NaZWidxTq3lKJjPj6imkzSKuT/OiRwuE6oRR/KQl8HNkw/8I 5mwdQ9/fyediiYxJY+/ey3sjDioyos/hACcoN3TFrhD+QowKoHqKU9qx+XMGuNl9YXg2 zAHU/S41ZiHWp700FWIuKrAzCfa43oYW1+FUah452LbiQG4kGcPXSpUQDrzFtx3q5Lri x38g52rM2VHXkqwCeOQjsGQzI5oHIl3TRE+vhWkLo0SYKzraLIJO6qlF7ndnlIrGz/y6 FsWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8fv2VoS1X8S64+oAwLXLDiadURpnoVHuylDiwpc3DEc=; b=iVcOv+Z071ImscY0oj+aMsnQ7vzaSZZouIM5iUkKT0nuSCWcuEQ6tW0eWXFRWXLTfJ XGAOLoQH0AHTXfIjCZ/WTpL8SpaNdAYfyHpDNYVgExTIvb2807zLD04C7c/Q5rTukQJ8 44O2XyvuOe6AiB3fF4OeT7sSKjh1K4YnjAHmaGZABlaQ7fpmujVXfeWWQ82N9dDZ63dY EiNpXcS368AhIRgoqijkbm8sh+Dq8Uxd4xCxuAgl+ty5WEFyZ/oz/nG3EkgDrvI/qb9n WxyzacidYKwa8/UZfxdWSuo24F4iRoalAyF/9tRaWFyCgI3aJINi7iuySKvZoIrDVCbX 4NdA== X-Gm-Message-State: ALoCoQkEjDmnjomLf7MTjjFzgUDT6aBu3BliJpZaKinmlDyqfYRtSDLLBdPEKCNDiLAp0K952HRP/prqFtF4sXbfso5BG7QmdOhil4JtsWky6KFix6ON+4+3ORRNxfLMMtflo+mOIJPRA9BC7REayxvfLpfLCCgdxOj4QGUXcuSlMEPGRVuk9j3hGWCDrWToD7u8drxsexZQ X-Received: by 10.50.66.163 with SMTP id g3mr10595007igt.20.1378797657361; Tue, 10 Sep 2013 00:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Tue, 10 Sep 2013 00:20:37 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 16:20:37 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdca31c95b2ac04e6025876 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 07:20:58 -0000 --047d7bdca31c95b2ac04e6025876 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2013 at 3:57 PM, wrote: > I have considered that Lorenzo. =93is not required to deploy IPv6=94 woul= d be > accurate if this document is dealing only with dual-stack, but this is no= t > true for the IPv6-only mode. The set of SHOULD recommendations are > targeting that deployment model. > I disagree. By my reading, you can make a phone that works perfectly well on an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23). But the other ones are not necessary to deploy an IPv6-only phone. One of your co-authors will be able to confirm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of them implement all the requirements in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements document? Of course implementors MAY do anything they want, unless they SHOULD NOT or MUST NOT. --047d7bdca31c95b2ac04e6025876 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

 

On Tue, Sep 10, 2013 at 3:5= 7 PM, <mohamed.boucadair@orange.com> wrote:

I have considered t= hat Lorenzo. “is not required to deploy IPv6” would be acc= urate if this document is dealing only with dual-stack, but this is not tru= e for the IPv6-only mode. The set of SHOULD recommendations are targeting t= hat deployment model.

On Tue, Sep 10, 2013 at 3:57 PM, <mohamed.bou= cadair@orange.com> wrote:

I have considered that Lorenzo. =93is not required to dep= loy IPv6=94 would be accurate if this document is dealing only w= ith dual-stack, but this is not true for the IPv6-only mode. The set of SHO= ULD recommendations are targeting that deployment model.


I disagree. By my reading, you can m= ake a phone that works perfectly well on an IPv6-only carrier network witho= ut implementing #2, #3, #9, #10, #11, #12, #14, $15, #16, #17, #18*, #20, #= 21, #22, #23, #24, #26, #33, and #36. Some of those are MUSTs in this docum= ent.

If you want to do IPv6-only on wifi you need either #9 = and #10 (or both plus #11 as well), and either #20 or #21 (or both plus #23= ). But the other ones are not necessary to deploy an IPv6-only phone. One o= f your co-authors will be able to confirm this: I'm told there are mult= iple IPv6-only phones on T-Mobile USA today, and I'm sure none of them = implement all the requirements in this document (or even all the MUSTs).


[*] How did #18 even make it in? What us= e is a MAY in a requirements document? Of course implementors MAY do anythi= ng they want, unless they SHOULD NOT or MUST NOT.
--047d7bdca31c95b2ac04e6025876-- From lorenzo@google.com Tue Sep 10 00:23:31 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4543B21E8128 for ; Tue, 10 Sep 2013 00:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXv3FCLv4VuD for ; Tue, 10 Sep 2013 00:23:30 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECD21E80A6 for ; Tue, 10 Sep 2013 00:23:30 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y16so10352657ieg.12 for ; Tue, 10 Sep 2013 00:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RvxpKpYDpWFk2Tdk2wBzYsiEuC718YmZ84Rmb4IYV+c=; b=SKfsO8tsZf8MWTKbb5ISN48GRhnKRe7CoHeO9ANh2A3d3f08ece0YY93bmxb90yvhG Ssi4V+46fb86Md2gln1YhQxcXL1/8ne45UyG4ZM/ealewkV4GADYR45ccbhjv/cWbXWY S5xOvuUmHT2rKiMtEnRikUClctqXb2P9v6Lk/oT8O4NfzKXYDR8BEjQ2XQcfC+LkVyAw Limp/za0Y6vA1QDC0NLBRXVi2roAFymq2xZHY2k1axd3RlsEvSA8u8pWoggPbrh6HPeZ tfkDlONGZLIGZ7zlK2wzo/fuR+5cChEc7Gr72f4Va2maNdrgQ0eYjorv4cN7957qh9OX hNyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RvxpKpYDpWFk2Tdk2wBzYsiEuC718YmZ84Rmb4IYV+c=; b=Df45y7Jxc/YrRkHndwtNSolrjjobwc7tNrPN3zcljB6tHEcpyCsEEPsph0fwe3Gh6Q lik9HsvCHVRPePmgASmb/+lf0CLG9Dgp1dX7c75JzSuCpRK125aBKD7NQI3/n/oRvxhX s/wweYc8iZAyVMbI6b8OSluUx5svuNKckrTA17NZOMMcuvbyXpIIWd3S0pv7A6R9pfs5 TGfFJF3vZMTulIHHMfYX4PRUaELHpR7TTQV4otyhCJR9ExmZRBduCB4MjCZ1w52hB7Iq dG/3bs0Sa+GB5O3Fcv9iTBwYOj9SCULYHYKB8wtIlG00CsblsDNc/rQ3IXEXrA91JQtq caeA== X-Gm-Message-State: ALoCoQkR/34tvLkcmd0wv1+oM0a3a7uFs8vDom1gTrcwZO1MvN77++3d76zt7Hw8N7FQZinaq1UZnQeXmOAAET1bmt0zrSVeXMojLOQvqEIrTa7dciHq/A6y951tiEdqrwcstnedDmCHYWKPl6zhZRaqSM+q0kxH9LKEtcY5xsATaDiUxk3m8HDX9JUXyuvOgCZCIi+Not1O X-Received: by 10.50.1.84 with SMTP id 20mr10454443igk.17.1378797810063; Tue, 10 Sep 2013 00:23:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Tue, 10 Sep 2013 00:23:09 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7D30@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <522EA306.9010103@bogus.com> <94C682931C08B048B7A8645303FDC9F36EF0EE7D30@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 16:23:09 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdc188cafc7b404e602616c Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 07:23:31 -0000 --047d7bdc188cafc7b404e602616c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 3:27 PM, wrote: > How can we ensure every implementers will agree with this list? For > instance we have two detailed technical reviewers Are reviews still appropriate? I think there are a lot of things left to say about this document beyond the high-order points we're discussing at the moment. If I write them down, will they be considered or will the answer be that it's too late to accept feedback because the document is already in last call? --047d7bdc188cafc7b404e602616c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10, 2013 at 3:27 PM, <mohamed.bou= cadair@orange.com> wrote:
How can we ensure every implementers will ag= ree with this list? For instance we have two detailed technical reviewers

Are reviews still appropriate? I think there are a lot = of things left to say about this document beyond the high-order points we&#= 39;re discussing at the moment.

If I write them do= wn, will they be considered or will the answer be that it's too late to= accept feedback because the document is already in last call?
--047d7bdc188cafc7b404e602616c-- From lorenzo@google.com Tue Sep 10 01:11:15 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0A21F9BEF for ; Tue, 10 Sep 2013 01:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws3CdlDyQvOp for ; Tue, 10 Sep 2013 01:11:14 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 12EFE21E8157 for ; Tue, 10 Sep 2013 01:10:54 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id s9so15711912iec.35 for ; Tue, 10 Sep 2013 01:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rXoGCx3wAAxB3UAkeQkOwUtnBqcEMWC44ca2AK70jw8=; b=ZiUVT+E6zcUg0qpeIf4uCZDUDT6MUlcf+NsoaVNxr4wzlhFQr1nIyw6de2ADKgsvox eN1mGJUr83p5gUxaL/pFVKAV/QgbxmEh7340jiNgKAPnlpRRSS5DfwzK1aomXYyulGKx J6h/C2nduBVXsmROP1fUYyKYFGO+W42eQbv9y57/DSfC3tXLKtExVIEzM5tg9PxFYCvZ TGXTdZ8VSjpjqPX0e6Oasw5Or2tgLkFARm2/BD+qZojtVVNXGVZRf/HB9konRfG3e0jc ify55Vl/C5bM+4JUS9ExWth5WhZnswD1S2tpYhKTfqEyCkQArJIiwQLxG2DaYgs+ZJib vqeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rXoGCx3wAAxB3UAkeQkOwUtnBqcEMWC44ca2AK70jw8=; b=jUp5km7Dq49JEt1pZ5a78FnJPk3pVj4rCOgu2siNgOBsAo02ZRZV7ODLgvFXJKqi6i TYB6yiOgYFmi3MgEtOi5FsSd15uILmOe/oS5V0FvgtDcbmj6z6gbCFOq7O/AuxbGeJLA YPLE8DshSl0ZKIQ5qnk5wyQ3YxHulxpt2f5/3o2h6AQAlydBbw69LBI6WSBhPL68PjVu RS6D8O/JQa+RZ+uxL7uHN5mXiZcYx2eHaF5COUfsSXqpFIZMXL5Qc2vBpRczbQ2s2Gc8 MKEXjO4894MzglzxPUvR9SfV2UVtWBuF3faFnOXn+sDczXyCNJdsOnQ1cgGsDTU5ID6B Jy2w== X-Gm-Message-State: ALoCoQmv8TjrtSqZuFVW1UOSrPqQhbTyAxtPhU4fDfjVHSO37l2l+i+iD1SKYXLlk/QShuNyQIWwC4WmEozQX/ruJrzsKN4P+uINS0YpQNzZHC6a8SJvaEGC7DPVt82bS+4dsoiNNWfjENxvODmOQeK7JdyrjJLFWVvgtCTAEn2S2BfkUX3gFCENRIJBzurrAwVdJ3jzmFXy X-Received: by 10.50.114.168 with SMTP id jh8mr10456255igb.6.1378800650934; Tue, 10 Sep 2013 01:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Tue, 10 Sep 2013 01:10:30 -0700 (PDT) In-Reply-To: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 17:10:30 +0900 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=089e01229f86040c2b04e6030b72 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:11:15 -0000 --089e01229f86040c2b04e6030b72 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 12:59 AM, james woodyatt wrote: > I recommend dropping these recommendations and replacing them with text > that recognizes the present reality that cellular hosts are simply not > expected ever to receive unsolicited inbound connection flows from > arbitrary remote Internet addresses. It would simplify the document and it > would be a more honest appraisal of the situation. > To be fair, that doesn't happen on all devices. For example, my Nexus 7 LTE on Docomo's business APN appears to have real Internet access. I can ping it, and when I attempt to connect to it, I get a TCP reset back. tcpdump running on the phone shows: 17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length 64 17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 > 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, length 64 17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win 14400 17:06:26.366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win 0 Now, the battery life implications of such a setup are debatable, but it does suggest that there is no stateful filtering going on in the baseband. Or did I misunderstand what you wrote? --089e01229f86040c2b04e6030b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10, 2013 at 12:59 AM, james woodyatt <jhw@apple.c= om> wrote:
I recommend dropping these re= commendations and replacing them with text that recognizes the present real= ity that cellular hosts are simply not expected ever to receive unsolicited= inbound connection flows from arbitrary remote Internet addresses. It woul= d simplify the document and it would be a more honest appraisal of the situ= ation.

To be fair, that doesn't h= appen on all devices. For example, my Nexus 7 LTE on Docomo's business = APN appears to have real Internet access. I can ping it, and when I attempt= to connect to it, I get a TCP reset back. tcpdump running on the phone sho= ws:

17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4= f:c028 > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1= , length 64
17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:463= 8:a4b4 > 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1,= length 64
17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > 24= 0a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win 14400 = <mss 1394,sackOK,timestamp 9349082 0,nop,wscale 7>
17:06:26= .366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > 2401:fa00:4:1012:ad= e4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win 0

Now, the battery life implications of such a setu= p are debatable, but it does suggest that there is no stateful filtering go= ing on in the baseband. Or did I misunderstand what you wrote?
--089e01229f86040c2b04e6030b72-- From mohamed.boucadair@orange.com Tue Sep 10 01:19:06 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB53C11E8196; Tue, 10 Sep 2013 01:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBVhnP9B7t7m; Tue, 10 Sep 2013 01:19:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 262A611E819C; Tue, 10 Sep 2013 01:18:54 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id B065837432C; Tue, 10 Sep 2013 10:18:52 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 91A5F18003E; Tue, 10 Sep 2013 10:18:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 10 Sep 2013 10:18:50 +0200 From: To: Lorenzo Colitti Date: Tue, 10 Sep 2013 10:18:49 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6t9kyHhofc5mTMSHqxfmhFmHNmbQABcrnQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DEFPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.55415 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:19:06 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DEFPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I really don't see how you can have a phone that "make a phone that works p= erfectly well on an IPv6-only" if you don't support IPv6/IPv4v6 PDP context= , you don't have a means to make work broken applications when IPv6-only is= enabled, if the phone does not follow the procedure for requesting the PDP= context, how you can be compatible with DNSSEC, etc. If what you mean by "perfect" is a degraded level of service, then you are = right. I update the text to reflect this: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This document uses the normative keywords defined in the previous section only for precision. Is this better? Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : mardi 10 septembre 2013 09:21 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Tue, Sep 10, 2013 at 3:57 PM, > wrote: I have considered that Lorenzo. "is not required to deploy IPv6" would be a= ccurate if this document is dealing only with dual-stack, but this is not t= rue for the IPv6-only mode. The set of SHOULD recommendations are targeting= that deployment model. I disagree. By my reading, you can make a phone that works perfectly well o= n an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #= 12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. S= ome of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plu= s #11 as well), and either #20 or #21 (or both plus #23). But the other one= s are not necessary to deploy an IPv6-only phone. One of your co-authors wi= ll be able to confirm this: I'm told there are multiple IPv6-only phones on= T-Mobile USA today, and I'm sure none of them implement all the requiremen= ts in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements docume= nt? Of course implementors MAY do anything they want, unless they SHOULD NO= T or MUST NOT. --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DEFPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I really don’t see how you can have a phone that ̶=
0;make a phone that works perfectly well on an IPv6-only” if you don’t support IPv6/IPv4v6 PDP context, you don’t have a means to ma=
ke work broken applications when IPv6-only is enabled, if the phone does no=
t follow the procedure for requesting the PDP context, how you can be compa=
tible with DNSSEC, etc. 
 
If=
 what you mean by “perfect” is a degraded level of service, the=
n you are right. 
 
I update =
the text to reflect this:
 
=
=A0=A0=A0=A0=A0 NOTE WELL: This document is not a standard, and conformance=
 with
=A0=A0=A0=
=A0=A0 it is not required in order to claim conformance with IETF
=A0=A0=A0=A0=A0 standards =
for IPv6.=A0 The support of the full set of features may<=
/pre>
=A0=A0=A0=A0=A0 not be required in =
some contexts (e.g. dual-stack).=A0 The support
=A0=A0=A0=A0=A0 of a subset of the features =
included in this profile may lead to
=A0=A0=A0=A0=A0 degraded level of service (e.g., IPv6-o=
nly mode).
&=
nbsp;
=A0=A0=A0=A0=A0 =
This document uses the normative keywords defined in the previous
=A0=A0=A0=A0=A0 section on=
ly for precision.
 
Is this b=
etter?
 =
;
Cheers,
Med
De : Lorenzo Colitti [mailto:lorenzo@go= ogle.com]
Envoy=E9 : mardi 10 septembre 2013 09:21
= =C0 : BOUCADAIR Mohamed IMT/OLN
Cc : Dave Cridland;= v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussion
Objet := Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.t= xt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices)= to Informational RFC

 

I disagre= e. By my reading, you can make a phone that works perfectly well on an IPv6= -only carrier network without implementing #2, #3, #9, #10, #11, #12, #14, = $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of th= ose are MUSTs in this document.

 

If you want to do I= Pv6-only on wifi you need either #9 and #10 (or both plus #11 as well), and= either #20 or #21 (or both plus #23). But the other ones are not necessary= to deploy an IPv6-only phone. One of your co-authors will be able to confi= rm this: I'm told there are multiple IPv6-only phones on T-Mobile USA today= , and I'm sure none of them implement all the requirements in this document= (or even all the MUSTs).

 

 

[*] How did #18 even make it in? What use is a = MAY in a requirements document? Of course implementors MAY do anything they= want, unless they SHOULD NOT or MUST NOT.

=
= --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DEFPUEXCB1Bnante_-- From swmike@swm.pp.se Tue Sep 10 01:27:49 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1B221E816B for ; Tue, 10 Sep 2013 01:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH9EN+QVgCtB for ; Tue, 10 Sep 2013 01:27:49 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 453A321E8161 for ; Tue, 10 Sep 2013 01:27:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CE4239C; Tue, 10 Sep 2013 10:27:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C60539A; Tue, 10 Sep 2013 10:27:28 +0200 (CEST) Date: Tue, 10 Sep 2013 10:27:28 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> Message-ID: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:27:50 -0000 On Mon, 9 Sep 2013, james woodyatt wrote: > I recommend dropping these recommendations and replacing them with text > that recognizes the present reality that cellular hosts are simply not > expected ever to receive unsolicited inbound connection flows from > arbitrary remote Internet addresses. It would simplify the document and > it would be a more honest appraisal of the situation. At my previous employer we ran unfiltered Internet access to all mobile customers, and they all had IPv4 GUA addresses. We had to stop doing that due to IPv4 runout in RIPE region, otherwise we would have continued. So your presumption above isn't true. It might be like that in some or even most parts of the world, but it's not in all of it. -- Mikael Abrahamsson email: swmike@swm.pp.se From mohamed.boucadair@orange.com Tue Sep 10 01:28:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99821E817A for ; Tue, 10 Sep 2013 01:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Smyvb0HPWCZR for ; Tue, 10 Sep 2013 01:27:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 332FF21E8156 for ; Tue, 10 Sep 2013 01:27:48 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 386F922C40B; Tue, 10 Sep 2013 10:27:45 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 155074C06C; Tue, 10 Sep 2013 10:27:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 10 Sep 2013 10:27:45 +0200 From: To: james woodyatt , "v6ops@ietf.org WG" Date: Tue, 10 Sep 2013 10:27:43 +0200 Thread-Topic: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile Thread-Index: Ac6td/8+oqaMCKkqR5qrc6AszGJyfQAeAPbA Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE7DFA@PUEXCB1B.nanterre.francetelecom.fr> References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> In-Reply-To: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DFAPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.55415 Cc: "Reinaldo Penno \(repenno\) \(repenno@cisco.com\)" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:28:02 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DFAPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi James, I appreciate your effort for reading and raising a technical point. I reall= y don't care if you shared this comment during the WGLC or now once the IET= F LC is over. Some general answers: * This document does not aim to provide a static picture of what current im= plementations are doing but we are listing also features to ease adoption o= f the IPv6-only model. For this reason, there is a list of feature that are= needed for that model: these recommendations are all SHOULD ones and not M= UST. FWIW, the document included some details on broken implementations and= tests but that text was removed as suggested by some reviewers. The docume= nt is not intended to ACK the current broken implementations but to list of= features to have more and more implementations that can be connected in IP= v6-only and DS modes without service degradation. * The feature of retrieving the PREFIX64 using PCP has been implemented and= tested (see for example http://tools.ietf.org/html/draft-boucadair-pcp-nat= 64-experiments-00) * Motivations for PCP from a provider perspective are mentioned in the docu= ment. No need to re-iterate that. From a customer standpoint, some users ar= e using their mobile connection as their main line. As such, they have the = same requirements as for fixed services. I have been told that there are cu= stomers running game consoles using their mobile connection (If I'm not mis= taken, Reinaldo has mentioned this case in an e-mail. I will let him confir= m/infirm). * The document includes the following: Some of the features listed in this profile document require to activate dedicated functions at the network side. It is out of scope of this document to list these network-side functions. * Some operators have included PCP as a requirement for their NAT64 in the = context of ongoing RFPs. For those operators, the client-side functionalit= y is needed. Cheers, Med De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de j= ames woodyatt Envoy=E9 : lundi 9 septembre 2013 17:59 =C0 : v6ops@ietf.org WG Objet : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile everyone- I haven't prepared an exhaustive criticism of this draft, but I do have one= concern in particular I would like to highlight. The recommendations (for = they are not requirements) REQ#12 and REQ#15 discussing matters related to = the Port Control Protocol (PCP) and traversal of NAT and firewalls is troub= ling to me. REQ#12: The cellular host SHOULD support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to learn PREFIX64 SHOULD be supported by the cellular host. This solves the issue when applications use IPv4 referrals on IPv6-only access networks. In PCP-based environments, cellular hosts SHOULD follow [I-D.ietf-pcp-nat64-prefix64] to lear= n the IPv6 Prefix used by an upstream PCP-controlled NAT64 device. If PCP is not enabled, the cellular host SHOULD implement the method specified in [I-D.ietf-behave-nat64-discovery-heuristic] to retrieve the PREFIX64. REQ#15: The cellular host SHOULD support PCP [RFC6887]. The support of PCP is seen as a driver to save battery consumption exacerbated by keepalive messages. PCP also gives the possibility of enabling incoming connections to the cellular device. Indeed, because several stateful devices may be deployed in wireless networks (e.g., NAT and/or Firewalls), PCP can be used by the cellular host to control network-based NAT and Firewall functions which will reduce per-application signaling and save battery consumption. It seems to me that these recommendations are only worth following if there= are to be PCP servers in *all* of the network elements in the paths betwee= n cellular hosts and the default free zone that implement stateful firewall= (and NAT) functions. Indeed, in at least one common cellular host archite= cture, there is a stateful filter in the baseband chipset firmware that blo= cks all inbound packets that it decides are unsolicited by applications on = the main system CPU. There is no PCP service in those chipset firmware impl= ementations, and no practical way to turn off the filtering, because it is = tied up with tricky power consumption issues, and without either of those t= hings, there is pretty much no good reason to implement a PCP client on the= main system CPU. It does not matter whether there are PCP servers in the f= irewalls further upstream, if there is a firewall in the baseband chipset t= hat you can't disable or control. I recommend dropping these recommendations and replacing them with text tha= t recognizes the present reality that cellular hosts are simply not expecte= d ever to receive unsolicited inbound connection flows from arbitrary remot= e Internet addresses. It would simplify the document and it would be a more= honest appraisal of the situation. -- james woodyatt > core os networking --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DFAPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi James,

 

I appreciate your effort for reading and raising a technical point. I r= eally don’t care if you shared this comment during the WGLC or now on= ce the IETF LC is over.

 = ;

Some general answers:

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>* T= his document does not aim to provide a static picture of what current imple= mentations are doing but we are listing also features to ease adoption of t= he IPv6-only model. For this reason, there is a list of feature that are ne= eded for that model: these recommendations are all SHOULD ones and not MUST= . FWIW, the document included some details on broken implementations and te= sts but that text was removed as suggested by some reviewers. The document = is not intended to ACK the current broken implementations but to list of fe= atures to have more and more implementations that can be connected in IPv6-= only and DS modes without service degradation.

 

* The feature of= retrieving the PREFIX64 using PCP has been implemented and tested (see for= example http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experime= nts-00)

 

* Motivations for PCP from a provider perspective a= re mentioned in the document. No need to re-iterate that. From a customer s= tandpoint, some users are using their mobile connection as their main line.= As such, they have the same requirements as for fixed services. I have bee= n told that there are customers running game consoles using their mobile co= nnection (If I’m not mistaken, Reinaldo has mentioned this case in an= e-mail. I will let him confirm/infirm).

 

* The document include= s the following:

 <= /span>

=A0=A0 Some of the features listed in this profile document = require to

=A0=A0 activate dedicated functions at= the network side.=A0 It is out of scope

=A0=A0 o= f this document to list these network-side functions.

=

 

* Some op= erators have included PCP as a requirement for their NAT64 in the context o= f ongoing RFPs. For those =A0operators, the client-side functionality is ne= eded.

 

=

Cheers,

Med=

 

 

De : v6ops-bounces@ietf.org [mailto:v6ops-bounces= @ietf.org] De la part de james woodyatt
Envoy=E9 : lu= ndi 9 septembre 2013 17:59
=C0 : v6ops@ietf.org WG
Obj= et : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

 

everyone—

&= nbsp;

I haven’t prepared an = exhaustive criticism of this draft, but I do have one concern in particular= I would like to highlight. The recommendations (for they are not requireme= nts) REQ#12 and REQ#15 discussing matters related to the Port Control Proto= col (PCP) and traversal of NAT and firewalls is troubling to me.=

 

REQ#12:=
=A0 The cellular host SHOULD support a method to locally<=
/pre>
=A0=A0=A0=A0=A0=A0=A0 construct IPv4-embedded IPv6 addresses [RFC6052].=A0 A method to
=
=A0=A0=A0=A0=A0=A0=A0 learn PREFIX64 SHOULD be supported by the cellular ho=
st.
 
=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 This solves the issue when applications use IPv4 referrals on
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IPv6-only access networks.=

 
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 In PCP-based environments, cellular hosts SHOULD follow
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 by an upstream PCP-controlled N=
AT64 device.=A0 If PCP is not
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 enabled, the cellular host SHOULD implement the method
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 specified in [I-D.ietf-behave-nat64-discovery-heuristic=
] to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 retrieve the PREFI=
X64.

 

REQ#15:=A0 The cellular host SHOULD support PCP [RFC6887].
 
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The support of PCP is seen as a driver to sa=
ve battery
<=
span style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 consumption =
exacerbated by keepalive messages.=A0 PCP also
=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 gives the possibility of enabling incoming connect=
ions to the
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cellular de=
vice.=A0 Indeed, because several stateful devices
=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 may be deployed in wireless networks (e.g., NAT=
 and/or
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Firewalls), PCP=
 can be used by the cellular host to control
=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 network-based NAT and Firewall functions which will r=
educe
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 per-application s=
ignaling and save battery consumption.

 

It seems = to me that these recommendations are only worth following if there are to b= e PCP servers in *all* of the network elements in the paths between cellula= r hosts and the default free zone that implement stateful firewall (and NAT= ) functions.  Indeed, in at least one common cellular host architectur= e, there is a stateful filter in the baseband chipset firmware that blocks = all inbound packets that it decides are unsolicited by applications on the = main system CPU. There is no PCP service in those chipset firmware implemen= tations, and no practical way to turn off the filtering, because it is tied= up with tricky power consumption issues, and without either of those thing= s, there is pretty much no good reason to implement a PCP client on the mai= n system CPU. It does not matter whether there are PCP servers in the firew= alls further upstream, if there is a firewall in the baseband chipset that = you can’t disable or control.

 

I recommend dro= pping these recommendations and replacing them with text that recognizes th= e present reality that cellular hosts are simply not expected ever to recei= ve unsolicited inbound connection flows from arbitrary remote Internet addr= esses. It would simplify the document and it would be a more honest apprais= al of the situation.

&nb= sp;


--
james woodyatt <jhw@apple.com>
core= os networking

 =

= --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7DFAPUEXCB1Bnante_-- From swmike@swm.pp.se Tue Sep 10 01:29:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7A21E8157 for ; Tue, 10 Sep 2013 01:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvSUE0z7o2C3 for ; Tue, 10 Sep 2013 01:29:36 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3049021E812C for ; Tue, 10 Sep 2013 01:29:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E9F6A9C; Tue, 10 Sep 2013 10:29:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E0F9A9A; Tue, 10 Sep 2013 10:29:34 +0200 (CEST) Date: Tue, 10 Sep 2013 10:29:34 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:29:42 -0000 On Tue, 10 Sep 2013, Lorenzo Colitti wrote: > > Now, the battery life implications of such a setup are debatable, but it > does suggest that there is no stateful filtering going on in the > baseband. Or did I misunderstand what you wrote? My guess is that a lot of mobile Internet providers have a stateful firewall on Gi interface that filters connection initiation attempts towards the mobile devices. As you see yourself, this isn't universal. Considering all rooted iPhones out there that were "hacked" by default ssh password a few years back, I imagine it's quite common that no Gi firewall is precent. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Tue Sep 10 01:32:42 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE6A21E812C for ; Tue, 10 Sep 2013 01:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+FIYUy0w4hU for ; Tue, 10 Sep 2013 01:32:41 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6C21F9FC3 for ; Tue, 10 Sep 2013 01:32:41 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id 10so12337017ied.39 for ; Tue, 10 Sep 2013 01:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TbX9hRZBqKCSEAZWBc6g4FgcuT1rKr7Rztxko3ktJAY=; b=YkJ2JOVLRa85RQUppS+lPqQcd4bBcBurtwjaTWWJKunnKFl7MtwLHYcB5LHfboX4wy 4P+Iqe6Jyb5hsKndejyEUvaD7LeVpKDdCBvgRdfGKHwsfSWcWF5XAfstKL8rgkt37Ljt jKIx0U1phtTN/9ch9NIl4Sw7cbwQjWJaWHwPZAmXZUZntT6IDOHgmE69EAZc++EuooS0 2VKEijjGBAX1GG9oUyWc9dmDcWm2TQ3Hz1kYTQ5oSaH85Sza61RjyAGkrFDO4/QPRmMk R8Lb8CaIlZh7wIYTVW2CpaZ9UFUA0AvupEAROecPrztjADUEJhpGMRBHPqxqLcGi4w8r e/Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TbX9hRZBqKCSEAZWBc6g4FgcuT1rKr7Rztxko3ktJAY=; b=bbjtEgVzpm48zbkUheb8mtHMys1SbVIG91UMo2EwEejkr5169oD83pS+cvJYIK0QDL +wF/b0rh1iMJretieK9u8q4hC4WryIPS1h4eproZOxIUY0SoPx3jKW7UsnGOzux72f9j vrP4NLjxnx2DHOLsglih8MSy8goFVsFTWfDycDimsQuD/GeYO23pX0Tj/VVRBkeQQ6No BDVHkhQ7STLtmNaGDHPAV9wbDRESRDzvPN/jOlwzDS6YXG372GrxHtetmrEATFCZO3KV PrvmAb4x5GA2B7LL7O8x1DGi+PnQ7CyS3xjl/DKVAGuewhakgtkOJiOLUOqedmrEX9oo 3U0A== X-Gm-Message-State: ALoCoQna68//YpRAQBmZbVoC0bhBroYHTfS1fefDqriOkqJRVmxw3P12CxYOq9IpbGAWxe3UlUHxv89cS8M7cAWjlLx6U23pjc64KFfR63RjnfFL4FauG24Or+N0LVvjp/gpArPD0vlO5o08ebFfp/juLMZsfINo5H3IbdXS96TNRKH6xFffzcloCPgLhjObpe8qanC6FZPH X-Received: by 10.50.1.84 with SMTP id 20mr10528441igk.17.1378801960983; Tue, 10 Sep 2013 01:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Tue, 10 Sep 2013 01:32:20 -0700 (PDT) In-Reply-To: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 17:32:20 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=047d7bdc188c19bf7f04e6035963 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:32:42 -0000 --047d7bdc188c19bf7f04e6035963 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 5:29 PM, Mikael Abrahamsson wrote: > Considering all rooted iPhones out there that were "hacked" by default ssh > password a few years back, I imagine it's quite common that no Gi firewall > is precent. > What James said is "in at least one common cellular host architecture, there is a stateful filter in the baseband chipset firmware that blocks all inbound packets that it decides are unsolicited". So he's probably talking about a firewall in the phone baseband (i.e., on the processor that deals with the radio), not on the network or on the phone's main processor. --047d7bdc188c19bf7f04e6035963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10, 2013 at 5:29 PM, Mikael Abrahamsson <swmik= e@swm.pp.se> wrote:
Cons= idering all rooted iPhones out there that were "hacked" by defaul= t ssh password a few years back, I imagine it's quite common that no Gi= firewall is precent.

What James said is "in at least one c= ommon cellular host architecture, there is a stateful filter in the baseban= d chipset firmware that blocks all inbound packets that it decides are unso= licited".

So he's probably talking about a firewall in the ph= one baseband (i.e., on the processor that deals with the radio), not on the= network or on the phone's main processor.
--047d7bdc188c19bf7f04e6035963-- From swmike@swm.pp.se Tue Sep 10 01:37:19 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713C721E811E for ; Tue, 10 Sep 2013 01:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC5tsGqaWfZD for ; Tue, 10 Sep 2013 01:37:19 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D25FF21E80B9 for ; Tue, 10 Sep 2013 01:37:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E344D9C; Tue, 10 Sep 2013 10:37:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DB3849A; Tue, 10 Sep 2013 10:37:17 +0200 (CEST) Date: Tue, 10 Sep 2013 10:37:17 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:37:19 -0000 On Tue, 10 Sep 2013, Lorenzo Colitti wrote: > So he's probably talking about a firewall in the phone baseband (i.e., > on the processor that deals with the radio), not on the network or on > the phone's main processor. Check. Well, since I have experience with other devices that do not implement this functionality I don't subscribe to that world view. -- Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Tue Sep 10 02:27:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583FD11E8113 for ; Tue, 10 Sep 2013 02:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oNlZi9FSnD7 for ; Tue, 10 Sep 2013 02:27:16 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4B21E80F3 for ; Tue, 10 Sep 2013 02:27:15 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id ff1so4132753qeb.28 for ; Tue, 10 Sep 2013 02:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=riFD59ZKWJcphaZNJbwuiyevzevti+ZX399AqX668eE=; b=mlInJ8R17PkYUynQ+FTJh9mK+LXdJaQeYYn9Jsdgrehl/hc1eTVrcHikNpIWb5JY00 cXvcyOI53MwVC0ZIgb3MGwQhcgK2F84F7QULdyy4t9hBN5t3A8C8WiFTsL+FeRV+BoZP sPThu6ppibyT9/zTaZff2Ql4ouIQtO+r/FfSzMCWUwg8CQSiYSxgRrPeuvcGPUTmJxlC MOWJTjq20VMH92O5Dfq3yEab6CHMgwY06N81GEKUYfEoG+QqhT0CNN4acMOwvYMspczS RoRaeJ1poyq/30BS18JOrjna3PJbZJT+jyITpMTvrOHexpfJhM/LJgASU3bV3htFDfD9 z3EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=riFD59ZKWJcphaZNJbwuiyevzevti+ZX399AqX668eE=; b=hPdbk+5sL9Pt9b4a2m/J3YJ/75pKsLDFwLlmOz0IRlx3CinWWqNLuDFUpGceL/ADUL yN0TWySwIdfNx8A11ukM9Fwq08mfKCD8D22IlTKWChJSbGwNFQ/ro2LHH3CRtt2USfpJ UmnzynSMOO677vb+IdO8FRivsxJaDln118rt7gtOjvqAWySgfQyOcpwFfNPYCnd/ugJE q6/nARtV6eAEwJah0p2tdGo2cAKUQJfDtb29w7GATwciHcG8tUuqG8/cUxjtAjcAJwnH uQj8zNfBJMIeH3X+kMCGdGOFtf6C7hr5IZMy6WM6YKN921v2FTeXrsW51K+9d0mRtgWa xTmg== X-Gm-Message-State: ALoCoQlSTkC+M4z01ZsITqZau0ruuGEsA3JeBBYsQx2ZRdBXfggs8D/RHrow/cWupMTnit4XuhUTp2RtGe0IOKSbFglo04od8nLx5DlIQ6fUqYWKkbDpShoakcFFJZylZbJMbxSYy8qu6EIsbWPTpq2nyGoy6ZfkJjGUAcsh//B745qicW2QLDVosw0KCJeth8VrUfPl8uVM X-Received: by 10.49.127.116 with SMTP id nf20mr1216992qeb.90.1378805234664; Tue, 10 Sep 2013 02:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.47.137 with HTTP; Tue, 10 Sep 2013 02:26:53 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 18:26:53 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b5d8d5f3a478004e6041c53 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:27:18 -0000 --047d7b5d8d5f3a478004e6041c53 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2013 at 5:18 PM, wrote: > I really don=92t see how you can have a phone that =93make a phone that w= orks > perfectly well on an IPv6-only=94 if you don=92t support IPv6/IPv4v6 PDP > context > You don't need to support IPV4V6 if all you need to do is work on an IPv6-only network. That might seem like a stupid answer, but the point I'm trying to make is that while you and I know that supporting only IPV6 will result in the phone being incompatible with some networks *the document doesn't say that*. The document says you MUST support all this stuff, without saying why, and without giving any information to operators, implementers, or anyone else on why this particular laundry list of features was selected. That's not a good way to specify things. Look at RFC1122, for example: every requirement is carefully articulated, with rationale and everything else. > you don=92t have a means to make work broken applications when IPv6-only = is > enabled > Nobody can control third party-applications, not even the phone manufacturer (which is why REQ#33 doesn't make sense). The manufacturer can provide something like 464xlat, which I agree is necessary for IPv6-only operation. > if the phone does not follow the procedure for requesting the PDP context= , > You don't need to do that if you have an APN database that's configured with what the operator supports, or if you don't support IPV4V6. (Straying back into technical discussion for a bit - from a technical point of view, having seen the wide variety of behaviours and result codes that basebands typically exhibit when you ask them to do something that they or the network doesn't support, I think relying on this fallback is a terrible idea.) > how you can be compatible with DNSSEC, etc. > How many phones today support DNSSEC? > NOTE WELL: This document is not a standard, and conformance with > > it is not required in order to claim conformance with IETF**** > > standards for IPv6. The support of the full set of features may***= * > > not be required in some contexts (e.g. dual-stack). The support***= * > > of a subset of the features included in this profile may lead to***= * > > degraded level of service (e.g., IPv6-only mode). > > This is not about IPv6-only mode. That's a useful feature, and as I'm sure you know, it's been implemented by a number of manufacturers. Consider an implementation that implements IPv6 tethering without including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. Or consider a 464xlat implementation without a local DNS64 implementation. I don't consider these to be degraded service, I consider them to be a lot better than what we have today. But someone taking this document as a guide to what needs to be implemented to deploy IPv6 would consider them to be incomplete or broken implementations. Such a person might look at the 34 requirements and just give up, when in fact such an implementation is perfectly capable of doing IPv6 today. --047d7b5d8d5f3a478004e6041c53 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10, 2013 at 5:18 PM, <mohamed.bou= cadair@orange.com> wrote:

I really don=92t see how you can have = a phone that =93make a phone that works perfectly well on an IPv6-on= ly=94 if you don=92t support IPv6/IPv4v6 PDP context

You don't need to support IPV4V6 if all you nee= d to do is work on an IPv6-only network. That might seem like a stupid answ= er, but the point I'm trying to make is that while you and I know that = supporting only IPV6 will result in the phone being incompatible with some = networks *the document doesn't say that*. The document says you MUST su= pport all this stuff, without saying why, and without giving any informatio= n to operators, implementers, or anyone else on why this particular laundry= list of features was selected. That's not a good way to specify things= . Look at RFC1122, for example: every requirement is carefully articulated,= with rationale and everything else.

you don=92t have a means to make work = broken applications when IPv6-only is enabled

Nobody can control third party-applications, not ev= en the phone manufacturer (which is why REQ#33 doesn't make sense). The= manufacturer can provide something like 464xlat, which I agree is necessar= y for IPv6-only operation.

if the phone does not follow the proce= dure for requesting the PDP context,

You don't need to do that if you have an APN da= tabase that's configured with what the operator supports, or if you don= 't support IPV4V6. (Straying back into technical discussion for a bit -= from a technical point of view, having seen the wide variety of behaviours= and result codes that basebands typically exhibit when you ask them to do = something that they or the network doesn't support, I think relying on = this fallback is a terrible idea.)

how you can be compatible with DNSSEC= , etc.=A0

How many phones today support DNSSEC?
=A0=

=A0 =A0 =A0 NOTE WELL: This document is not a st= andard, and conformance with

=A0=A0=A0=A0=A0 it is not required in order to =
claim conformance with IETF
=A0=A0=A0=A0=A0 standards f=
or IPv6.=A0 The support of the full set of features may
=A0=A0=A0=A0=A0 not be req=
uired in some contexts (e.g. dual-stack).=A0 The support
=A0=A0=A0=A0=A0 of a subset of th=
e features included in this profile may lead to
<= pre>=A0=A0=A0=A0=A0 degraded level of = service (e.g., IPv6-only mode).

This is not about IPv6-only mode. Th= at's a useful feature, and as I'm sure you know, it's been impl= emented by a number of manufacturers.

Consider an = implementation that implements IPv6 tethering without including a full RFC6= 204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCPv6 and a= ll the bells and whistles built in. Or consider a 464xlat implementation wi= thout a local DNS64 implementation.

I don't consider these to be degraded service, I co= nsider them to be a lot better than what we have today. But someone taking = this document as a guide to what needs to be implemented to deploy IPv6 wou= ld consider them to be incomplete or broken implementations. Such a person = might look at the 34 requirements and just give up, when in fact such an im= plementation is perfectly capable of doing IPv6 today.
--047d7b5d8d5f3a478004e6041c53-- From owen@delong.com Tue Sep 10 02:40:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6C721F9DCB for ; Tue, 10 Sep 2013 02:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whig7BYP7kwn for ; Tue, 10 Sep 2013 02:40:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D692321F9C7B for ; Tue, 10 Sep 2013 02:40:34 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r8A9ZBKT013385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Sep 2013 02:35:11 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r8A9ZBKT013385 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378805711; bh=fxEuOJk8z3eV0r1uDuJbc5XO7lw=; h=From:Content-Type:Message-Id:Mime-Version:Subject:Date:References: To:In-Reply-To; b=N9owHr4ljfdzZm2mhVXJaYY/ZI46r5V5QU/4zXtXhKAzSRw7xKAAT+sSrO/OX5sSC 4XeQ7S6g3X/B48CUQ8Gew405IhypJNgPii+pCw0L37j1W9pXazfDDZPMiffW+ICtXt MqvdIEWHNDodP8xvddoEkLxvZeFzBFxOq7j4zR2w= From: Owen DeLong Content-Type: multipart/alternative; boundary="Apple-Mail=_F118429F-E8A0-4F97-BA8E-921BF85D187B" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 10 Sep 2013 02:35:08 -0700 References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> To: "v6ops@ietf.org WG" In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 10 Sep 2013 02:35:11 -0700 (PDT) Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:40:36 -0000 --Apple-Mail=_F118429F-E8A0-4F97-BA8E-921BF85D187B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Perhaps I'm still confused or truly don't understand all of the = IP-specific implications of 3g/4g/other cellular protocols. However, it seems to me that from an IETF perspective, the various = interfaces on a cell phone (802.11, 3gpp, LTE, etc.) are just various = layer 2 media. The phone itself is just another host and/or router. Most of what is contained in this document strikes me as an effort to = shift the work in media adaptation out of the media standards bodies and = into the IETF solely because the cellular standards bodies, vendors, et. = al. don't seem to be able to come together and build reasonable working = documents. Unfortunately, the result is an I-D/RFC that is slightly less = complicated than the Bluetooth specification and nearly as legible. PDP contexts are a media adaptation problem unique to the (bizarre) = choices of the cellular industry in order to support their arcane = billing and licensing schemes. Every other media, it has been left to the media standards group to = develop the necessary media adaptation layers for IP. This document = seems to be trying to shift that role into the IETF for this particular = implementation of a combination of media types, some of which already = have adaptation layers specified in their respective standards group, = some of which may not, and many of which are made unusually complex and = twisted by the unique nature of the accounting systems that are = involved. I haven't seen an IETF profile document for Ethernet, Token Ring, PPP, = HDLC, FDDI, Firewire, USB, ATM, etc. The requirements documents for hosts and routers are already in = reasonably good shape. Efforts are already underway to update them with = operational experience and more recent lessons learned. It is my opinion that this document will, in the long run, merely create = additional confusion as it is likely to conflict with future output from = 3GPP and other standards bodies responsible for the media that is unique = to the cellular world and overlaps and may also conflict with documents = from IEEE and other standards bodies that control some of the other = network interfaces currently present on cellular devices and/or likely = to be present in the future (such as BLE and 802.16). Yes, the 3GPP standards are currently rather lacking in their IP = adaptation guidance and the cellular industry is a quagmire of competing = interests and malformed overly-political standards processes. I do not = believe that bringing that into the IETF will do anything to reduce the = quagmire in the cellular industry, nor will it do anything to benefit = IPv6 or IPv6 deployment. Owen On Sep 10, 2013, at 01:18 , mohamed.boucadair@orange.com wrote: > Re-, > =20 > I really don=92t see how you can have a phone that =93make a phone = that works perfectly well on an IPv6-only=94 if you don=92t support = IPv6/IPv4v6 PDP context, you don=92t have a means to make work broken = applications when IPv6-only is enabled, if the phone does not follow the = procedure for requesting the PDP context, how you can be compatible with = DNSSEC, etc.=20 > =20 > If what you mean by =93perfect=94 is a degraded level of service, then = you are right.=20 > =20 > I update the text to reflect this: > =20 > NOTE WELL: This document is not a standard, and conformance with > it is not required in order to claim conformance with IETF > standards for IPv6. The support of the full set of features may > not be required in some contexts (e.g. dual-stack). The support > of a subset of the features included in this profile may lead to > degraded level of service (e.g., IPv6-only mode). > =20 > This document uses the normative keywords defined in the = previous > section only for precision. > =20 > Is this better? > =20 > Cheers, > Med > =20 > De : Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Envoy=E9 : mardi 10 septembre 2013 09:21 > =C0 : BOUCADAIR Mohamed IMT/OLN > Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF = Discussion > Objet : Re: [v6ops] Last Call: = (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > On Tue, Sep 10, 2013 at 3:57 PM, wrote: > I have considered that Lorenzo. =93is not required to deploy IPv6=94 = would be accurate if this document is dealing only with dual-stack, but = this is not true for the IPv6-only mode. The set of SHOULD = recommendations are targeting that deployment model. > =20 > I disagree. By my reading, you can make a phone that works perfectly = well on an IPv6-only carrier network without implementing #2, #3, #9, = #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, = #33, and #36. Some of those are MUSTs in this document. > =20 > If you want to do IPv6-only on wifi you need either #9 and #10 (or = both plus #11 as well), and either #20 or #21 (or both plus #23). But = the other ones are not necessary to deploy an IPv6-only phone. One of = your co-authors will be able to confirm this: I'm told there are = multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of = them implement all the requirements in this document (or even all the = MUSTs). > =20 > =20 > [*] How did #18 even make it in? What use is a MAY in a requirements = document? Of course implementors MAY do anything they want, unless they = SHOULD NOT or MUST NOT. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_F118429F-E8A0-4F97-BA8E-921BF85D187B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Perhaps I'm still confused or = truly don't understand all of the IP-specific implications of = 3g/4g/other cellular protocols.

However, it seems to me = that from an IETF perspective, the various interfaces on a cell phone = (802.11, 3gpp, LTE, etc.) are just various layer 2 media. The phone = itself is just another host and/or router.

Most = of what is contained in this document strikes me as an effort to shift = the work in media adaptation out of the media standards bodies and into = the IETF solely because the cellular standards bodies, vendors, et. al. = don't seem to be able to come together and build reasonable working = documents.

Unfortunately, the result is an = I-D/RFC that is slightly less complicated than the Bluetooth = specification and nearly as legible.

PDP = contexts are a media adaptation problem unique to the (bizarre) choices = of the cellular industry in order to support their arcane billing and = licensing schemes.

Every other media, it has = been left to the media standards group to develop the necessary media = adaptation layers for IP. This document seems to be trying to shift that = role into the IETF for this particular implementation of a combination = of media types, some of which already have adaptation layers specified = in their respective standards group, some of which may not, and many of = which are made unusually complex and twisted by the unique nature of the = accounting systems that are involved.

I haven't = seen an IETF profile document for Ethernet, Token Ring, PPP, HDLC, FDDI, = Firewire, USB, ATM, etc.

The requirements = documents for hosts and routers are already in reasonably good shape. = Efforts are already underway to update them with operational experience = and more recent lessons learned.

It is my = opinion that this document will, in the long run, merely create = additional confusion as it is likely to conflict with future output from = 3GPP and other standards bodies responsible for the media that is unique = to the cellular world and overlaps and may also conflict with documents = from IEEE and other standards bodies that control some of the other = network interfaces currently present on cellular devices and/or likely = to be present in the future (such as BLE and = 802.16).

Yes, the 3GPP standards are currently = rather lacking in their IP adaptation guidance and the cellular industry = is a quagmire of competing interests and malformed overly-political = standards processes. I do not believe that bringing that into the IETF = will do anything to reduce the quagmire in the cellular industry, nor = will it do anything to benefit IPv6 or IPv6 = deployment.

Owen

On Sep = 10, 2013, at 01:18 , mohamed.boucadair@orange.com<= /a> wrote:

 
I really don=92t see how you can have a phone that =
=93make a phone that works perfectly well on an IPv6-only=94 if you don=92t support =
IPv6/IPv4v6 PDP =
context, you don=92t have a means to make work broken applications when =
IPv6-only is enabled, if the phone does not follow the procedure for =
requesting the PDP context, how you can be compatible with DNSSEC, etc. =

 
If what you mean by =93perfect=94 is =
a degraded level of service, then you are right. =

 
I update the text to reflect =
this:
 
      NOTE =
WELL: This document is not a standard, and conformance =
with
      it is not required in =
order to claim conformance with IETF
      =
degraded level of service (e.g., IPv6-only =
mode).
 
      This =
document uses the normative keywords defined in the =
previous
      section only for =
precision.
 
Is this =
better?
 
Cheers,
 
 Lorenzo Colitti = [mailto:lorenzo@google.com] 
Envoy=E9 : mardi 10 septembre 2013 = 09:21
=C0 : BOUCADAIR Mohamed = IMT/OLN
Cc : Dave Cridland; v6ops@ietf.org WG; BINET David = IMT/OLN; IETF Discussion
Objet : Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational = RFC
_______________________= ________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= = --Apple-Mail=_F118429F-E8A0-4F97-BA8E-921BF85D187B-- From mohamed.boucadair@orange.com Tue Sep 10 04:12:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2557B11E819D; Tue, 10 Sep 2013 04:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au7DTk44jnRV; Tue, 10 Sep 2013 04:12:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7664B11E810B; Tue, 10 Sep 2013 04:12:39 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 5AD273B43C3; Tue, 10 Sep 2013 13:12:38 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3DD43384049; Tue, 10 Sep 2013 13:12:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 10 Sep 2013 13:12:37 +0200 From: To: Lorenzo Colitti Date: Tue, 10 Sep 2013 13:12:35 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6uB/ES7N1cCFY9SHS+YvcvOVXoKwAC6S/A Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE7EFE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF0EE7EFEPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.91515 Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:12:45 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7EFEPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : mardi 10 septembre 2013 11:27 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Tue, Sep 10, 2013 at 5:18 PM, > wrote: I really don't see how you can have a phone that "make a phone that works p= erfectly well on an IPv6-only" if you don't support IPv6/IPv4v6 PDP context You don't need to support IPV4V6 if all you need to do is work on an IPv6-o= nly network. [Med] UEs that will provided with IPv6-only or DS is up to the provider. No= te also that the requirement is worded to let the decision to each provider= . The document explicitly says: This allows each operator to select their own strategy regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP- Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends on the cellular network configuration. That might seem like a stupid answer, but the point I'm trying to make is t= hat while you and I know that supporting only IPV6 will result in the phone= being incompatible with some networks *the document doesn't say that*. The= document says you MUST support all this stuff [Med] No. no, no the document indicates the language for each feature: ther= e are MUST, SHOULD, etc. This is not the first time a document makes such c= lassification of the features. , without saying why, and without giving any information to operators, impl= ementers, or anyone else on why this particular laundry list of features wa= s selected. [Med] There is already motivations text for most of features, rationale and= scope of the overall effort in the draft. You are continuing ignore it. Th= at's not fair. That's not a good way to specify things. Look at RFC1122, for example: ever= y requirement is carefully articulated, with rationale and everything else. [Med] This document is not a standard. This document does not ambition to h= ave the same level as RFC1122. you don't have a means to make work broken applications when IPv6-only is e= nabled Nobody can control third party-applications, not even the phone manufacture= r (which is why REQ#33 doesn't make sense). [Med] There are API, there applications shipped by device vendors themselve= s, etc. Our teams already tested applications provided by vendors devices w= hich are broken when IPv6-only mode. The manufacturer can provide something like 464xlat, which I agree is neces= sary for IPv6-only operation. [Med] Are you saying this is a MUST? if the phone does not follow the procedure for requesting the PDP context, You don't need to do that if you have an APN database that's configured wit= h what the operator supports, or if you don't support IPV4V6. (Straying bac= k into technical discussion for a bit - from a technical point of view, hav= ing seen the wide variety of behaviours and result codes that basebands typ= ically exhibit when you ask them to do something that they or the network d= oesn't support, I think relying on this fallback is a terrible idea.) how you can be compatible with DNSSEC, etc. How many phones today support DNSSEC? [Med] How many device support IPv6 today? We can play that game endlessly..= . NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This is not about IPv6-only mode. [Med] What is wrong in that text? Can we focus on the exact text change? That's a useful feature, and as I'm sure you know, it's been implemented by= a number of manufacturers. Consider an implementation that implements IPv6 tethering without including= a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful = DHCPv6 and all the bells and whistles built in. Or consider a 464xlat imple= mentation without a local DNS64 implementation. [Med] You still do that. These features are not MUST in this document. It i= s your right to ignore them but you need to be aware this may have some neg= ative impact. It seems you understand the list as MUST ones...while this is= not true. I don't consider these to be degraded service, I consider them to be a lot = better than what we have today. [Med] I'm sorry to say that a customer with IPv6-only connectivity that can= not use some applications available for an IPv4 customer is a degraded serv= ice. This is seen by some operators as a barrier for that mode. --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7EFEPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7F11PUEXCB1Bnante_-- From lorenzo@google.com Tue Sep 10 04:55:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFA211E8132 for ; Tue, 10 Sep 2013 04:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfKC8Hutnf6A for ; Tue, 10 Sep 2013 04:55:10 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id EF5D111E81A0 for ; Tue, 10 Sep 2013 04:55:07 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id ff1so4257791qeb.28 for ; Tue, 10 Sep 2013 04:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8h6oJsSSFcOD3seqfipAECjFb573y5YPfezA4A0nQ9s=; b=EBy/CnSpZeTTFi3oIiJuEskay2WADs5BfLsIr4JuP/wwcq/jfQ8waFY9gN4MFFFtgv md2xbzClHydOkiC5fJBtVanND+0tSwJ4FVCIXjktVFCzFltpsMb9k6EhMc0Ck5r2vuRQ 0vmXLVPdcxL7jQOjatPiSkwxWtQ6FK7cF9o0ZwPGbvDoSlLyVu9aOIwWOF0hY+WR0FUT uOO7a4SE26ejhUt9D6a7A7veB0kdDQN9K6/rkhOJldagIxUjyb1dzLI2jBDQymbXNGb9 aCnD/oIGHijbZQY3/zfdSqKveI85jaYLv2CqJvx1HBkMz3aDWNhR2zIKLCbcrmETgYS0 uJFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8h6oJsSSFcOD3seqfipAECjFb573y5YPfezA4A0nQ9s=; b=SnUy9l/fuR8QKlkEEX933bwJ+ucdthTtGFgUjKtBsZqBNaDdnn1u+PWwI2Gs4L4a2e Qm7VsotHFmssOrSp8hxL4UiFMjNBJ2H3CwdCGGr40VccMWV1cxrNyzxu1AyVPePt3jcY SSVxbnmTD4Q0wsJHVbCaQwYy9Z0raD7reh7HSJLTR/SGkJro9PZ1CQFs3/WKhBTgW8a2 S1fkvM9GWnTv+2NF0iy30MiR485RQpoICp5WX9Yx1ab090nwSTfqW7/paY4XshcR592X wO3BI2qvnH9cCMr/Azwj2mtzDNL71Cf+2HCafZ98i3s4fdzqy4pvm6vrLi7ncZDaVREW dOag== X-Gm-Message-State: ALoCoQm2sTaNUsv7/WB7O+YQkMSrJKUDG0k46dtbYowMPF2GsT9QmvRcGjtjTb7Ma+Oqk64U+tJXVOPmiICKMcw9MM79CgsVEzwN6P7FCqQn/1CvIn8kVhiCUBGE05fDgUadMTjuD0KT//9MKZm7Bv5J0oZMvPqpJUVLuYfjczbyVUzBjJPYSqXjFZWjs+4Wbv6Ms9h/rc9I X-Received: by 10.49.84.6 with SMTP id u6mr18152114qey.79.1378814104952; Tue, 10 Sep 2013 04:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.47.137 with HTTP; Tue, 10 Sep 2013 04:54:44 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7EFE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7EFE@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Tue, 10 Sep 2013 20:54:44 +0900 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7bdc0934f01e6404e6062c3b Cc: "v6ops@ietf.org WG" , IETF Discussion , Dave Cridland Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:55:14 -0000 --047d7bdc0934f01e6404e6062c3b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2013 at 8:12 PM, wrote: > *[Med] No. no, no the document indicates the language for each feature: > there are MUST, SHOULD, etc. This is not the first time a document makes > such classification of the features.* > Sorry - what I meant is: "most of the text in the document says that devices MUST support this, SHOULD support that, SHOULD support the other", but not much time saying why. ** > > *[Med] There is already motivations text for most of features, rationale > and scope of the overall effort in the draft. You are continuing ignore i= t. > That=92s not fair.* > Isn't it? For example, look at RFC1122 and compare it to this document. Compare the percentage of text used to state requirements and the percentage of text used for rationale. If anything, an informational document should have fewer requirements and more rationale than a standard, not the other way around. > Nobody can control third party-applications, not even the phone > manufacturer (which is why REQ#33 doesn't make sense).**** > > *[Med] There are API, there applications shipped by device vendors > themselves, etc. Our teams already tested applications provided by vendor= s > devices which are broken when IPv6-only mode.* > Then change the requirement to say vendor applications must not be IPv4-only. At least it's a reasonable request (though one that's unlikely to happen before IPv6 is widely deployed). "All apps" is not a reasonable request. * * > > The manufacturer can provide something like 464xlat, which I agree is > necessary for IPv6-only operation. > > ** > > *[Med] Are you saying this is a MUST?* > I don't think this document should be a bunch of "MUST this", "SHOULD that", "MUST the other". As regards 464xlat, I think that shipping an IPv6-only phone without 464xlat or something equivalent equals shipping a phone that's not useful, and that doesn't happen in the real world. So if you want to ship IPv6-only, you need something like 464xlat. Does it follow that a phone MUST implement 464xlat? No, it does not. > ** > > *[Med] How many device support IPv6 today? We can play that game > endlessly...* > Not really, because upwards of 30 million mobile devices are using IPv6 every day on Verizon Wireless alone. See: http://conference.apnic.net/__data/assets/pdf_file/0017/50813/vzw_apnic_134= 62152832-2.pdf http://www.worldipv6launch.org/measurements/ Those phones do not meet the requirements of this draft. They violate at least MUSTs in #16, #20, #24, #27, #28, plus a large number of SHOULDs. According to the text in -05, that means they cannot "connect to an IPv6-only or dual-stack wireless network including 3GPP cellular network and IEEE 802.11 network)." I know that text won't be there in the next version, but the point I'm trying to make is that the document made it all the way to IETF last call while claiming that largest deployment of IPv6 in a mobile network was not possible. I don't want that to be the message coming out of this document. NOTE WELL: This document is not a standard, and conformance with**** > > it is not required in order to claim conformance with IETF**** > > standards for IPv6. The support of the full set of features may***= * > > not be required in some contexts (e.g. dual-stack). The support***= * > > of a subset of the features included in this profile may lead to***= * > > degraded level of service (e.g., IPv6-only mode). > > ** > > This is not about IPv6-only mode.**** > > *[Med] What is wrong in that text? Can we focus on the exact text change?= * > "The operators proposing this profile believe that the support of a subset of the features included in this protocol may lead to degraded level of service." * * > > Consider an implementation that implements IPv6 tethering without > including a full RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD= , > stateful DHCPv6 and all the bells and whistles built in. Or consider a > 464xlat implementation without a local DNS64 implementation. > > ** > > *[Med] You still do that. These features are not MUST in this document. > It is your right to ignore them but you need to be aware this may have so= me > negative impact. It seems you understand the list as MUST ones=85while th= is > is not true.* > Per the document, if you implement IPv6 tethering you MUST implement a full RFC 6204 router in the device (req#28). * ***** > > ** I don't consider these to be degraded service, I consider them to be a > lot better than what we have today. > > *[Med] I=92m sorry to say that a customer with IPv6-only connectivity tha= t > cannot use some applications available for an IPv4 customer is a degraded > service. This is seen by some operators as a barrier for that mode. ****= * > I stand by my opinion that IPv6 tethering without a full RFC6204 implementation and that 464xlat without a local DNS64 implementation are not degraded. --047d7bdc0934f01e6404e6062c3b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10, 2013 at 8:12 PM, <mohamed.bou= cadair@orange.com> wrote:

[Med] No. no, no the document indicates the language for each feature: = there are MUST, SHOULD, etc. This is not the first time a document makes su= ch classification of the features.

Sorry - what I meant is: "most of = the text in the document says that devices MUST support this, SHOULD suppor= t that, SHOULD support the other", but not much time saying why.

[Med] There is already motivations text for most of features, rationale= and scope of the overall effort in the draft. You are continuing ignore it= . That=92s not fair.

Isn't it? For example, look at RFC1= 122 and compare it to this document. Compare the percentage of text used to= state requirements and the percentage of text used for rationale. If anyth= ing, an informational document should have fewer requirements and more rati= onale than a standard, not the other way around.
=A0

Nobody can control third party-applica= tions, not even the phone manufacturer (which is why REQ#33 doesn't mak= e sense).

[Med] There are API, there applications ship= ped by device vendors themselves, etc. Our teams already tested application= s provided by vendors devices which are broken when IPv6-only mode.<= /i>

Then change the requirement to say vend= or applications must not be IPv4-only. At least it's a reasonable reque= st (though one that's unlikely to happen before IPv6 is widely deployed= ). "All apps" is not a reasonable request.

The manufacturer can provide something like= 464xlat, which I agree is necessary for IPv6-only operation.

[Med] Are you sayin= g this=A0 is a MUST?

I don't think this document should = be a bunch of "MUST this", "SHOULD that", "MUST th= e other". As regards 464xlat, I think that shipping an IPv6-only phone= without 464xlat or something equivalent equals shipping a phone that's= not useful, and that doesn't happen in the real world. So if you want = to ship IPv6-only, you need something like 464xlat. Does it follow that a p= hone MUST implement 464xlat? No, it does not.
=A0

<= span style=3D"font-size:10pt;font-family:'Courier New';color:rgb(31= ,73,125)">[Med] How many device support IPv6 today? We can play that game e= ndlessly...


Not really, because upwa= rds of 30 million mobile devices are using IPv6 every day on Verizon Wirele= ss alone. See:


Those phon= es do not meet the requirements of this draft. They violate at least MUSTs = in #16, #20, #24, #27, #28, plus a large number of SHOULDs.

According to the text in -05, that means they cannot &q= uot;connect to an IPv6-only or dual-stack wireless network including 3GPP c= ellular network and IEEE 802.11 network)." I know that text won't = be there in the next version, but the point I'm trying to make is that = the document made it all the way to IETF last call while claiming that larg= est deployment of IPv6 in a mobile network was not possible. I don't wa= nt that to be the message coming out of this document.

=A0 =A0 =A0 NOTE WE= LL: This document is not a standard, and conformance with<= /u>

=A0=A0=A0=A0=A0 it is=
 not required in order to claim conformance with IETF<=
/pre>


=A0=A0=A0=A0=A0 standards f=
or IPv6.=A0 The support of the full set of features may
=A0=A0=A0=A0=A0 not be req=
uired in some contexts (e.g. dual-stack).=A0 The support
=A0=A0=A0=A0=A0 of a subset of th=
e features included in this profile may lead to
<= pre>=A0=A0=A0=A0=A0 degraded level of = service (e.g., IPv6-only mode).=A0=

This is not about IPv6-only mode.

[Med] What is wrong in that text? Can we focus on the exact text chang= e?

"The operators proposing this prof= ile believe that the support of a subset of the features included in this p= rotocol may lead to degraded level of service."

<= div style=3D"border-style:none none none solid;border-left-color:blue;borde= r-left-width:1.5pt;padding:0cm 0cm 0cm 4pt">

Consider an implementation that implements IPv6 = tethering without including a full RFC6204 IPv6 router with simple security= , ULA, DHCPv6 PD, stateful DHCPv6 and all the bells and whistles built in. = Or consider a 464xlat implementation without a local DNS64 implementation.<= br>

[Med] You still do that. These features are not M= UST in this document. It is your right to ignore them but you need to be aw= are this may have some negative impact. It seems you understand the list as= MUST ones=85while this is not true.

Per the document, if you implement IPv6= tethering you MUST implement a full RFC 6204 router in the device (req#28)= .

=A0I don= 't consider these to be degraded service, I consider them to be a lot b= etter than what we have today.

[Med] I=92m sorry to say that a customer with IPv6-only connectivit= y that cannot use some applications available for an IPv4 customer is a deg= raded service. This is seen by some operators as a barrier for that mode. = =A0

I stand by my opinion that IPv6 tether= ing without a full RFC6204 implementation and that 464xlat without a local = DNS64 implementation are not degraded.
--047d7bdc0934f01e6404e6062c3b-- From Ted.Lemon@nominum.com Tue Sep 10 06:25:05 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B721E8053 for ; Tue, 10 Sep 2013 06:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FvHeF9FyVIp for ; Tue, 10 Sep 2013 06:24:58 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D2C3A21F9B8C for ; Tue, 10 Sep 2013 06:24:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUi8dqQ5uNi9UcELi6o0asgEMyJQJt6PF@postini.com; Tue, 10 Sep 2013 06:24:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 56B671B8079 for ; Tue, 10 Sep 2013 06:24:57 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4F476190074; Tue, 10 Sep 2013 06:24:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Tue, 10 Sep 2013 06:24:57 -0700 From: Ted Lemon To: Owen DeLong Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHOrgnWw2OilCj73Eqxry/t5/qmPpm/a4wA Date: Tue, 10 Sep 2013 13:24:56 +0000 Message-ID: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4B1CE39DB22A4140A8A8AE6A5D6647E8@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 13:25:06 -0000 On Sep 10, 2013, at 5:35 AM, Owen DeLong wrote: > PDP contexts are a media adaptation problem unique to the (bizarre) choic= es of the cellular industry in order to support their arcane billing and li= censing schemes. Much sympathy. However, we do in fact do things specific to 3gpp environm= ents. There's a v6ops document in review in the IESG right now that's rel= ated: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ As you can see, this is a followon to previous work that was done in the IE= TF, so there's a long history of doing this _sort_ of work in the IETF. I= 'm not claiming any position on whether the current document you are discus= sing is a good idea or not, but I think the argument that the IETF doesn't = do this isn't supported by the facts, so IMHO you ought to be making argume= nts about this document as it relates to the v6ops charter rather than the = more general argument you are currently making. From ales.vizdal@t-mobile.cz Tue Sep 10 07:43:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F5611E81D3 for ; Tue, 10 Sep 2013 07:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8bkMzTky6Nq for ; Tue, 10 Sep 2013 07:43:33 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id E307A11E81A2 for ; Tue, 10 Sep 2013 07:43:32 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id E7A052E092F; Tue, 10 Sep 2013 16:43:30 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Tue, 10 Sep 2013 16:43:30 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Ted Lemon , Owen DeLong Date: Tue, 10 Sep 2013 16:43:29 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: AQHOrgnWw2OilCj73Eqxry/t5/qmPpm/a4wA//+fZ2A= Message-ID: <1808340F7EC362469DDFFB112B37E2FCD2BABB5F09@SRVHKE02.rdm.cz> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 14:43:51 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Ted > Lemon > Sent: Tuesday, September 10, 2013 3:25 PM > To: Owen DeLong > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] Last Call: > (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to I= nformational > RFC >=20 > On Sep 10, 2013, at 5:35 AM, Owen DeLong wrote: > > PDP contexts are a media adaptation problem unique to the (bizarre) cho= ices of the > cellular industry in order to support their arcane billing and licensing = schemes. >=20 > Much sympathy. However, we do in fact do things specific to 3gpp enviro= nments. > There's a v6ops document in review in the IESG right now that's related: >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ >=20 > As you can see, this is a followon to previous work that was done in the = IETF, so > there's a long history of doing this _sort_ of work in the IETF. I'm no= t claiming any > position on whether the current document you are discussing is a good ide= a or not, but > I think the argument that the IETF doesn't do this isn't supported by the= facts, so > IMHO you ought to be making arguments about this document as it relates t= o the > v6ops charter rather than the more general argument you are currently mak= ing. There is another one http://tools.ietf.org/html/rfc6459 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Sep 10 09:52:44 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23021F9FE5; Tue, 10 Sep 2013 09:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.455 X-Spam-Level: X-Spam-Status: No, score=-101.455 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91f5RCrlnKgB; Tue, 10 Sep 2013 09:52:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD321F9BAD; Tue, 10 Sep 2013 09:52:34 -0700 (PDT) Received: from mb-aye.corp.zynga.com (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r8AGqURU063106 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 10 Sep 2013 16:52:30 GMT (envelope-from joelja@bogus.com) Message-ID: <522F4E48.9020206@bogus.com> Date: Tue, 10 Sep 2013 09:52:24 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Owen DeLong , mohamed.boucadair@orange.com References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> In-Reply-To: <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 10 Sep 2013 16:52:31 +0000 (UTC) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 16:52:44 -0000 On 9/9/13 1:06 PM, Owen DeLong wrote: > I have to agree with Lorenzo here again. > > This document seems to me to be: > > 1.Out of scope for the IETF. AD here... let's put this one to bed. there are existance proof(s) of previous work in this area and others that covers similar ground. I don't believe that this is out of scope for the WG or the IETF, Neither did the previous AD. So... Focus on the contents. > 2.So watered down in its language as to use many words to say nearly > nothing. > 3.Claims to be informational, but with so many caveats about the nature > of that > information that it's hard to imagine what meaningful information an > independent > reader could glean from the document. > > Finally, given the spirited debate that has extended into this last call > (which I honestly wonder > how this ever saw last call over the sustained objections) definitely > does not appear to have > even rough consensus, nor does it appear to have running code. > > Why is there such a push to do this? > > Owen > > On Sep 9, 2013, at 05:16 , > wrote: > >> Re-, >> >> Please see inline. >> >> Cheers, >> Med >> >> *De :* Lorenzo Colitti [mailto:lorenzo@google.com ] >> *Envoyé :* lundi 9 septembre 2013 13:24 >> *À :* BOUCADAIR Mohamed IMT/OLN >> *Cc :* Dave Cridland; v6ops@ietf.org WG; BINET >> David IMT/OLN; IETF Discussion >> *Objet :* Re: [v6ops] Last Call: >> (Internet Protocol >> Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC >> >> On Mon, Sep 9, 2013 at 8:06 PM, > > wrote: >> >> The document explicitly says “This document is not a standard.” >> since version -00. >> >> >> >> What additional statement you would like to see added? >> >> >> I think the high-order points are: >> >> 1. The text "This document defines an IPv6 profile for 3GPP mobile >> devices. It lists the set of features a 3GPP mobile device is to be >> compliant with to connect to an IPv6-only or dual-stack wireless >> network" should be replaced with "This document defines an IPv6 >> profile for 3GPP mobile devices that a number of operators believe is >> necessary to deploy IPv6 on an IPv6-only or dual-stack wireless >> network (including 3GPP cellular network and IEEE 802.11 network)." >> >> In place of "a number of operators believe is necessary to deploy" you >> could have "intend to deploy" or "require". I'd guess that as long as >> it's clear that the requirements don't come from the IETF but from a >> number of operators (not all of them, or a majority of them), it >> doesn't matter exactly what you say. >> */[Med] I made this change:/* >> */ /* >> */OLD:/* >> */ /* >> This document defines an IPv6 profile for 3GPP mobile devices. It >> lists the set of features a 3GPP mobile device is to be compliant >> with to connect to an IPv6-only or dual-stack wireless network >> (including 3GPP cellular network and IEEE 802.11 network). >> */ /* >> */New:/* >> */ /* >> This document defines an IPv6 profile that a number of operators >> require in order to connect 3GPP mobile devices to an IPv6-only or >> dual-stack wireless network (including 3GPP cellular network and IEEE >> 802.11 network). >> */ >> >> /* >> 2. In the normative language section, I'd like to see a statement >> similar to what's in RFC 6092. Perhaps something like this? >> */[Med] I used the same wording as in RFC6092. The change is as follows:/* >> */ /* >> */OLD:/* >> */ /* >> This document is not a standard. It uses the normative keywords only >> for precision. >> */ /* >> */NEW:/* >> */ /* >> NOTE WELL: This document is not a standard, and conformance with >> it is not required in order to claim conformance with IETF >> standards for IPv6. It uses the normative keywords defined in the >> previous section only for precision. >> */ /* >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From owen@delong.com Tue Sep 10 10:25:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D808C21F9BFF for ; Tue, 10 Sep 2013 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quZEp9FL5cFw for ; Tue, 10 Sep 2013 10:25:39 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B132621F9BAD for ; Tue, 10 Sep 2013 10:25:38 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r8AHK99d026443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Sep 2013 10:20:10 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r8AHK99d026443 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378833610; bh=rC+RjIctaKU6reKgwHxUF7vxrV4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=pRfhQpAeiA2L8KISL1B9gwuc7yy2LfLGpWnqTYyspTZxMwkYXSh/M75RinIrfaR0u GTylnWdaCXxu15d6a1586/L0+5x5j2TW3lkFJuCFPJno03XgkeNI76apq7JnYpWZc4 yJnHQsQBnySwGLwIEzAsX2tgsFH9vYSVrpG0aKHM= Content-Type: multipart/alternative; boundary="Apple-Mail=_7E2B9014-22B6-4FE0-9DD1-252AF245577A" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7F11@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 10 Sep 2013 10:20:08 -0700 Message-Id: References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7F11@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 10 Sep 2013 10:20:10 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:25:41 -0000 --Apple-Mail=_7E2B9014-22B6-4FE0-9DD1-252AF245577A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 10, 2013, at 04:33 , mohamed.boucadair@orange.com wrote: > Hi Owen, > =20 > The main motivations for us to edit this draft is the lack of any = document that explicitly enumerate that IPv6 features for mobile = devices. Operators each in its own contact its device vendor partners = and discussion with them the list of features they would like to see = supported. For example, Orange is editing a 500 pages device requirement = document shared with our partners. IPv6 is only a small chapter in that = document=85 > =20 This doesn't change anything I said... The issues raised in this = document are by and large media adaptation issues. The fact that = cellular media is a quagmire of ill-formed and convoluted non-technical = requirements is best described in IETF terms as "damage and should be = routed around". Far better would be for these issues to be addressed in the appropriate = fora responsible for the media, such as 3GPP, et. al. > When discussing with other operators, we noticed that even if we were = requesting for the same features, some vendors told us we are the only = provider asking for that features. =46rom there, it was obvious for us = (a group of operators) there is a need to have a common document which = make abstraction of the frontiers between SDOs but provide a = comprehensive list of features we think are needed. We came naturally to = the IETF because there is where the IPv6 expertise is and better this is = an open forum. Then form an industry association or write the document in one of the = existing industry associations. IEEE did not abdicate their = responsibility for media adaptation specifications for ethernet, 802.16, = etc. to the IETF and I don't see a need for the cellular industry to do = that here. Worse, because this document is not a standard, it won't carry the = weight it would need in order to be useful and everything in it is best = described as "advice from a questionable source which will likely = conflict with multiple other sources more likely to have greater = credibility in the long run." (e.g. if 3GPP ever gets their act together on defining an IPv6 media = adaptation layer). > Because of the particularity of mobile networks, mobile deployments = require strong language for some features compared to what is recorded = in the IPv6 node requirement document. This document indicates such = cases and why. Strong language in a document that is not a standards document is like a = child throwing a temper tantrum. It is full of sound and fury signifying = nothing. > FWIW, this is not the first document edited by the IETF to cover IPv6 = in mobile networks; e.g., > =20 > * http://tools.ietf.org/html/rfc3316 > * http://tools.ietf.org/html/rfc6459 > * http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04 =20 I'm not opposed to mobile-specific things in the IETF where they make = sense. This goes well beyond that point. RFC3316 addresses specific IPv6 concerns for a specific media from the = layer 3 perspective. RFC6459 serves a similar purpose. The draft for 3316bis is essentially an updated version of 3316. None of these documents purports to be a standardized list of feature = requirements for devices. > =20 > There are also IETF documents specifying for instance: Transmission of = IPv6 Packets over BLUETOOTH Low Energy = (http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12) > =20 > So, we should not treat draft-ietf-v6ops-mobile-device-profile more = than what is intended to do: > =20 > 1. List in one single document a comprehensive list of IPv6 = features > for a mobile device, including both IPv6-only and dual-stack > mobile deployment contexts. These features cover various = network > types such as GPRS (General Packet Radio Service), EPC (Evolved > Packet Core) or IEEE 802.11 network. None of the documents you reference are feature-list documents. The = closest you could come would be RFC-1123 (requirements for internet = hosts) which is already applicable to cellular devices. Frankly, much of the problem with cellular is the continuous effort to = treat it as an exception instead of as just another media. > 2. Help Operators with the detailed device requirement list > preparation (to be exchanged with device suppliers). This is > also a contribution to harmonize Operators' requirements = towards > device vendors. Which belongs in a cellular operators industry forum and not in the = IETF, IMHO. > 3. Vendors to be aware of a set of features to allow for IPv6 > connectivity and IPv4 service continuity (over an IPv6-only > transport). See response to 2. > =20 > For more details on scope and goals, please refer to the introduction = text of the draft. I've read it. It doesn't differ from what you said above in any = meaningful way and neither what you have said above, nor what it says is = a convincing argument that the IETF should move from its technical = standards role into the realm of marriage counselor to intervene between = cellular providers and cellular device manufacturers. > I hope this clarify your concern. If anything, it confirms my opinion and increases my opposition to this = draft moving forward in the IETF. Owen > =20 > Cheers, > Med > =20 > =20 > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part = de Owen DeLong > Envoy=E9 : mardi 10 septembre 2013 11:35 > =C0 : v6ops@ietf.org WG > Objet : Re: [v6ops] Last Call: = (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > Perhaps I'm still confused or truly don't understand all of the = IP-specific implications of 3g/4g/other cellular protocols. > =20 > However, it seems to me that from an IETF perspective, the various = interfaces on a cell phone (802.11, 3gpp, LTE, etc.) are just various = layer 2 media. The phone itself is just another host and/or router. > =20 > Most of what is contained in this document strikes me as an effort to = shift the work in media adaptation out of the media standards bodies and = into the IETF solely because the cellular standards bodies, vendors, et. = al. don't seem to be able to come together and build reasonable working = documents. > =20 > Unfortunately, the result is an I-D/RFC that is slightly less = complicated than the Bluetooth specification and nearly as legible. > =20 > PDP contexts are a media adaptation problem unique to the (bizarre) = choices of the cellular industry in order to support their arcane = billing and licensing schemes. > =20 > Every other media, it has been left to the media standards group to = develop the necessary media adaptation layers for IP. This document = seems to be trying to shift that role into the IETF for this particular = implementation of a combination of media types, some of which already = have adaptation layers specified in their respective standards group, = some of which may not, and many of which are made unusually complex and = twisted by the unique nature of the accounting systems that are = involved. > =20 > I haven't seen an IETF profile document for Ethernet, Token Ring, PPP, = HDLC, FDDI, Firewire, USB, ATM, etc. > =20 > The requirements documents for hosts and routers are already in = reasonably good shape. Efforts are already underway to update them with = operational experience and more recent lessons learned. > =20 > It is my opinion that this document will, in the long run, merely = create additional confusion as it is likely to conflict with future = output from 3GPP and other standards bodies responsible for the media = that is unique to the cellular world and overlaps and may also conflict = with documents from IEEE and other standards bodies that control some of = the other network interfaces currently present on cellular devices = and/or likely to be present in the future (such as BLE and 802.16). > =20 > Yes, the 3GPP standards are currently rather lacking in their IP = adaptation guidance and the cellular industry is a quagmire of competing = interests and malformed overly-political standards processes. I do not = believe that bringing that into the IETF will do anything to reduce the = quagmire in the cellular industry, nor will it do anything to benefit = IPv6 or IPv6 deployment. > =20 > Owen > =20 > On Sep 10, 2013, at 01:18 , mohamed.boucadair@orange.com wrote: >=20 >=20 > Re-, > =20 > I really don=92t see how you can have a phone that =93make a phone = that works perfectly well on an IPv6-only=94 if you don=92t support = IPv6/IPv4v6 PDP context, you don=92t have a means to make work broken = applications when IPv6-only is enabled, if the phone does not follow the = procedure for requesting the PDP context, how you can be compatible with = DNSSEC, etc.=20 > =20 > If what you mean by =93perfect=94 is a degraded level of service, then = you are right.=20 > =20 > I update the text to reflect this: > =20 > NOTE WELL: This document is not a standard, and conformance with > it is not required in order to claim conformance with IETF > standards for IPv6. The support of the full set of features may > not be required in some contexts (e.g. dual-stack). The support > of a subset of the features included in this profile may lead to > degraded level of service (e.g., IPv6-only mode). > =20 > This document uses the normative keywords defined in the = previous > section only for precision. > =20 > Is this better? > =20 > Cheers, > Med > =20 > De : Lorenzo Colitti [mailto:lorenzo@google.com]=20 > Envoy=E9 : mardi 10 septembre 2013 09:21 > =C0 : BOUCADAIR Mohamed IMT/OLN > Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF = Discussion > Objet : Re: [v6ops] Last Call: = (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC > =20 > On Tue, Sep 10, 2013 at 3:57 PM, wrote: > I have considered that Lorenzo. =93is not required to deploy IPv6=94 = would be accurate if this document is dealing only with dual-stack, but = this is not true for the IPv6-only mode. The set of SHOULD = recommendations are targeting that deployment model. > =20 > I disagree. By my reading, you can make a phone that works perfectly = well on an IPv6-only carrier network without implementing #2, #3, #9, = #10, #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, = #33, and #36. Some of those are MUSTs in this document. > =20 > If you want to do IPv6-only on wifi you need either #9 and #10 (or = both plus #11 as well), and either #20 or #21 (or both plus #23). But = the other ones are not necessary to deploy an IPv6-only phone. One of = your co-authors will be able to confirm this: I'm told there are = multiple IPv6-only phones on T-Mobile USA today, and I'm sure none of = them implement all the requirements in this document (or even all the = MUSTs). > =20 > =20 > [*] How did #18 even make it in? What use is a MAY in a requirements = document? Of course implementors MAY do anything they want, unless they = SHOULD NOT or MUST NOT. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_7E2B9014-22B6-4FE0-9DD1-252AF245577A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 mohamed.boucadair@orange.com<= /a> wrote:
Hi = Owen,
 
The main motivations for us to edit this draft is the lack of = any document that explicitly enumerate that IPv6 features for mobile = devices. Operators each in its own contact its device vendor partners = and discussion with them the list of features they would like to see = supported. For example, Orange is editing a 500 pages device requirement = document shared with our partners. IPv6 is only a small chapter in that = document=85

Far better would be for these issues = to be addressed in the appropriate fora responsible for the media, such = as 3GPP, et. al.

When discussing with other = operators, we noticed that even if we were requesting for the same = features, some vendors told us we are the only provider asking for that = features. =46rom there, it was obvious for us (a group of operators) = there is a need to have a common document which make abstraction of the = frontiers between SDOs but provide a comprehensive list of features we = think are needed. We came naturally to the IETF because there is where = the IPv6 expertise is and better this is an open = forum.

Then form an = industry association or write the document in one of the existing = industry associations. IEEE did not abdicate their responsibility for = media adaptation specifications for ethernet, 802.16, etc. to the IETF = and I don't see a need for the cellular industry to do that = here.

Worse, because this document is not a = standard, it won't carry the weight it would need in order to be useful = and everything in it is best described as "advice from a questionable = source which will likely conflict with multiple other sources more = likely to have greater credibility in the long run."
(e.g. if = 3GPP ever gets their act together on defining an IPv6 media adaptation = layer).

Because of the = particularity of mobile networks, mobile deployments require strong = language for some features compared to what is recorded in the IPv6 node = requirement document. This document indicates such cases and = why.

Strong language = in a document that is not a standards document is like a child throwing = a temper tantrum. It is full of sound and fury signifying = nothing.

FWIW, this is not the = first document edited by the IETF to cover IPv6 in mobile networks; = e.g.,

I'm not opposed to mobile-specific things = in the IETF where they make sense. This goes well beyond that = point.





If = anything, it confirms my opinion and increases my opposition to this = draft moving forward in the = IETF.

Owen

 
Med
 
 
 v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] De la part = de Owen = DeLong
Envoy=E9 : mardi 10 septembre 2013 = 11:35
=C0 : v6ops@ietf.org = WG
Objet : Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational = RFC
Perhaps I'm = still confused or truly don't understand all of the IP-specific = implications of 3g/4g/other cellular = protocols.
However, it = seems to me that from an IETF perspective, the various interfaces on a = cell phone (802.11, 3gpp, LTE, etc.) are just various layer 2 media. The = phone itself is just another host and/or = router.
Most = of what is contained in this document strikes me as an effort to shift = the work in media adaptation out of the media standards bodies and into = the IETF solely because the cellular standards bodies, vendors, et. al. = don't seem to be able to come together and build reasonable working = documents.
PDP = contexts are a media adaptation problem unique to the (bizarre) choices = of the cellular industry in order to support their arcane billing and = licensing schemes.
I = haven't seen an IETF profile document for Ethernet, Token Ring, PPP, = HDLC, FDDI, Firewire, USB, ATM, etc.
 
The requirements documents for hosts and routers = are already in reasonably good shape. Efforts are already underway to = update them with operational experience and more recent lessons = learned.
It = is my opinion that this document will, in the long run, merely create = additional confusion as it is likely to conflict with future output from = 3GPP and other standards bodies responsible for the media that is unique = to the cellular world and overlaps and may also conflict with documents = from IEEE and other standards bodies that control some of the other = network interfaces currently present on cellular devices and/or likely = to be present in the future (such as BLE and = 802.16).
Yes, = the 3GPP standards are currently rather lacking in their IP adaptation = guidance and the cellular industry is a quagmire of competing interests = and malformed overly-political standards processes. I do not believe = that bringing that into the IETF will do anything to reduce the quagmire = in the cellular industry, nor will it do anything to benefit IPv6 or = IPv6 deployment.
On = Sep 10, 2013, at 01:18 , mohamed.boucadair@orange.com wrote:
=


 
I really =
don=92t see how you can have a phone that =93make a phone that =
works perfectly well on an IPv6-only=94 if you don=92t support IPv6/IPv4v6 PDP context, you don=92t have a =
means to make work broken applications when IPv6-only is enabled, if the =
phone does not follow the procedure for requesting the PDP context, how =
you can be compatible with DNSSEC, etc. 
If what you mean by =93perfect=94 is a degraded =
level of service, then you are right. 
I update the text to reflect =
this:
 
      NOTE =
WELL: This document is not a standard, and conformance =
with
      it is not required in =
order to claim conformance with IETF
      =
degraded level of service (e.g., IPv6-only =
mode).
 
      This =
document uses the normative keywords defined in the =
previous
      section only for =
precision.
 
Is this =
better?
 
Cheers,
 
De :  
Envoy=E9 : mardi 10 septembre 2013 = 09:21
=C0 : BOUCADAIR Mohamed = IMT/OLN
Cc : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; = IETF Discussion
Objet : Re: [v6ops] Last Call: = <draft-ietf-v6ops-mobile-device-profile-04.txt> (Internet Protocol = Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational = RFC
On = Tue, Sep 10, 2013 at 3:57 PM, <mohamed.boucadair@orange.com> = wrote:
I have considered that = Lorenzo. =93is not required to deploy IPv6=94 would = be accurate if this document is dealing only with dual-stack, but this = is not true for the IPv6-only mode. The set of SHOULD recommendations = are targeting that deployment = model.
 
I = disagree. By my reading, you can make a phone that works perfectly well = on an IPv6-only carrier network without implementing #2, #3, #9, #10, = #11, #12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, = and #36. Some of those are MUSTs in this = document.
If = you want to do IPv6-only on wifi you need either #9 and #10 (or both = plus #11 as well), and either #20 or #21 (or both plus #23). But the = other ones are not necessary to deploy an IPv6-only phone. One of your = co-authors will be able to confirm this: I'm told there are multiple = IPv6-only phones on T-Mobile USA today, and I'm sure none of them = implement all the requirements in this document (or even all the = MUSTs).
[*] = How did #18 even make it in? What use is a MAY in a requirements = document? Of course implementors MAY do anything they want, unless they = SHOULD NOT or MUST NOT.
v6ops@ietf.org
for v6ops@ietf.org; Tue, 10 Sep 2013 11:06:53 -0700 (PDT) X-AuditID: 11807143-b7fce6d000001c8e-24-522f5fbdea5a Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 9E.B6.07310.DBF5F225; Tue, 10 Sep 2013 11:06:53 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MSX00BLN8ZHKF00@fenugreek.apple.com> for v6ops@ietf.org; Tue, 10 Sep 2013 11:06:53 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 10 Sep 2013 11:06:57 -0700 Message-id: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1807) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FCcqLs3Xj/IYM8yeYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/nUJ+aCDf4VfXPvsDYwtjp3MXJySAiYSHy5eZwJwhaTuHBv PVsXIxeHkMBkJoklH2YwgiSEBNYxSfTPNAKxmQWSJK7+PwbWwCugJ/Gw+RQLiC0s4Cjx6tQu NhCbTUBF4tvlu2A1nALBEjd+TQazWQRUJb7en84GMUdD4vONXywQc2wkJp/dzASxuJlR4uHV Y2CLRYCKHqyDuU5W4njjIfYJjPyzkNwxC8kdEHFtiWULXzND2AYSTztfsWKK60u8eTeHaQEj 2ypGgaLUnMRKI73EgoKcVL3k/NxNjOBQLXTewXhsmdUhRgEORiUe3hty+kFCrIllxZW5hxgl OJiVRHinOgGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85YbA6UE0hNLUrNTUwtSi2CyTBycUg2M CmtXbQ60bvKWC61OjVep2LgokJ+tduGtb0IzBfdoH2bgyEz1kZr7VveQrAXXb4UvwRUdPSG+ 7DpK1/v19EoFPE5sF5tjWeA5UUzu+Avd6LVr/nez6HNlH7M183ybv6BX/nvAejYV53M7216v 31PBqb7GIqNSn7lrRWDtmXCXwsjJyl9vrlNiKc5INNRiLipOBADTdTwlUQIAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:07:12 -0000 --Boundary_(ID_fRkngX7TMOSMzfLXNzw1fw) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Sep 10, 2013, at 1:10, Lorenzo Colitti wrote: > On Tue, Sep 10, 2013 at 12:59 AM, james woodyatt = wrote: > I recommend dropping these recommendations and replacing them with = text that recognizes the present reality that cellular hosts are simply = not expected ever to receive unsolicited inbound connection flows from = arbitrary remote Internet addresses. It would simplify the document and = it would be a more honest appraisal of the situation. >=20 > To be fair, that doesn't happen on all devices. For example, my Nexus = 7 LTE on Docomo's business APN appears to have real Internet access. I = can ping it, and when I attempt to connect to it, I get a TCP reset = back. tcpdump running on the phone shows: >=20 > 17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length = 64 > 17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 > = 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, length = 64 > 17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win = 14400 > 17:06:26.366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > = 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win = 0 >=20 > Now, the battery life implications of such a setup are debatable, but = it does suggest that there is no stateful filtering going on in the = baseband. Or did I misunderstand what you wrote? I don=92t think you misunderstood, but I think I should clarify my = remarks in order to better convey my concern. It=92s nice that your phone, on that network, this month, can receive = unsolicited inbound flows=97 but the problem here is the same one I = complained bitterly about prior to and during the development of RFC = 6092: it isn=92t sufficient for only *some* or even most cellular hosts = to be reachable=97 in most places, most of the time=97 with unsolicited = flows by arbitrary remote hosts. We really need it to be practically = all the phones, practically all the time, practically everywhere. We = don=92t have that, and there is no reason to believe that we ever will = have that. If you=92re trying to develop an application that does any sort of = direct peer-to-peer communication between cellular hosts, then you need = to be able to rely on the expectation that network elements that block = unsolicited inbound flows are rare and deployed only where users are not = expecting direct peer-to-peer applications to function properly, so that = when your application is broken by the stateful firewall in the network, = users know whom to blame and where to petition for redress. We now have a situation where a sizable fraction of cellular = IPv6-capable user-endpoint hosts are unreachable by unsolicited inbound = flow because they are located behind one or more than one stateful = firewall, that is enabled by default, contains no exceptions for IPsec = or IKE, and implements no protocol like PCP for soliciting inbound flows = from arbitrary remote addresses. This is precisely the situation I was = warning against before I capitulated and agreed to serve as the editor = for RFC 6092 despite my reservations about the reasons the working group = decided to adopt it. This is also the situationI was warning against = when I was arguing for a recommendation in RFC 6092 that firewalls not = block unsolicited inbound flows in the DEFAULT configuration. Shorter james: it=92s time to admit defeat. We blew it=97 there will = never be direct peer-to-peer telecommunications with IPv6, particularly = with cellular hosts. All that traffic must be directed through relays in = the network where it can be subject to police wiretap and social network = analysis. Even shorter james: I told you all so. -- james woodyatt core os networking --Boundary_(ID_fRkngX7TMOSMzfLXNzw1fw) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable On Sep = 10, 2013, at 1:10, Lorenzo Colitti <lorenzo@google.com> = wrote:
On Tue, Sep = 10, 2013 at 12:59 AM, james woodyatt <jhw@apple.com> wrote:
I recommend dropping these = recommendations and replacing them with text that recognizes the present = reality that cellular hosts are simply not expected ever to receive = unsolicited inbound connection flows from arbitrary remote Internet = addresses. It would simplify the document and it would be a more honest = appraisal of the situation.

To be fair, that doesn't happen = on all devices. For example, my Nexus 7 LTE on Docomo's business APN = appears to have real Internet access. I can ping it, and when I attempt = to connect to it, I get a TCP reset back. tcpdump running on the phone = shows:

17:06:20.429555 IP6 = 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length = 64
17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 = > 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, = length 64
17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win = 14400 <mss 1394,sackOK,timestamp 9349082 0,nop,wscale = 7>
17:06:26.366201 IP6 = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > = 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win = 0

Now, the battery life implications of such a = setup are debatable, but it does suggest that there is no stateful = filtering going on in the baseband. Or did I misunderstand what you = wrote?

I don=92t think you misunderstood, but I = think I should clarify my remarks in order to better convey my = concern.

It=92s nice that your phone, on that = network, this month, can receive unsolicited inbound flows=97 but the = problem here is the same one I complained bitterly about prior to and = during the development of RFC 6092: it isn=92t sufficient for only = *some* or even most cellular hosts to be reachable=97 in most places, = most of the time=97 with unsolicited flows by arbitrary remote hosts. =  We really need it to be practically all the phones, practically = all the time, practically everywhere. We don=92t have that, and there is = no reason to believe that we ever will have = that.

If you=92re trying to develop an = application that does any sort of direct peer-to-peer communication = between cellular hosts, then you need to be able to rely on the = expectation that network elements that block unsolicited inbound flows = are rare and deployed only where users are not expecting direct = peer-to-peer applications to function properly, so that when your = application is broken by the stateful firewall in the network, users = know whom to blame and where to petition for = redress.

We now have a situation where a = sizable fraction of cellular IPv6-capable user-endpoint hosts are = unreachable by unsolicited inbound flow because they are located behind = one or more than one stateful firewall, that is enabled by default, = contains no exceptions for IPsec or IKE, and implements no protocol like = PCP for soliciting inbound flows from arbitrary remote addresses. This = is precisely the situation I was warning against before I capitulated = and agreed to serve as the editor for RFC 6092 despite my reservations = about the reasons the working group decided to adopt it. This is also = the situationI was warning against when I was arguing for a = recommendation in RFC 6092 that firewalls not block unsolicited inbound = flows in the DEFAULT configuration.

Shorter = james: it=92s time to admit defeat. We blew it=97 there will never be = direct peer-to-peer telecommunications with IPv6, particularly with = cellular hosts. All that traffic must be directed through relays in the = network where it can be subject to police wiretap and social network = analysis.

Even shorter james: I told you all = so.


--
james woodyatt <jhw@apple.com>
core os networking

= --Boundary_(ID_fRkngX7TMOSMzfLXNzw1fw)-- From owen@delong.com Tue Sep 10 12:49:21 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6B21E8199 for ; Tue, 10 Sep 2013 12:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95WsV5Abs1hC for ; Tue, 10 Sep 2013 12:49:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7821E818F for ; Tue, 10 Sep 2013 12:49:16 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id r8AJjd6p000971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Sep 2013 12:45:39 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r8AJjd6p000971 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378842340; bh=aa9hsyH3ZPBmqYrOsQZFw4Z+EAg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=vHMOuXAY31U+RkcUu0eteJN+1ySeil+y+1GC3azLm1IAOEjKCHtqa91dY8WHouwCA ASmkMeXol/bBcoaj+50I4K9wcPp8+NT2r1AJr9RZ3ezOZCuR28p7mwraEVHtjIjglx kyZaKz252db/3EERhmqYIhuHRWc9qGCUlPxLUlQA= Content-Type: multipart/alternative; boundary="Apple-Mail=_2CEE7A1A-6DDD-4E66-8412-FA51447C5707" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: Date: Tue, 10 Sep 2013 12:45:33 -0700 Message-Id: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 10 Sep 2013 12:45:40 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:49:21 -0000 --Apple-Mail=_2CEE7A1A-6DDD-4E66-8412-FA51447C5707 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 10, 2013, at 11:06 , james woodyatt wrote: > On Sep 10, 2013, at 1:10, Lorenzo Colitti wrote: >> On Tue, Sep 10, 2013 at 12:59 AM, james woodyatt = wrote: >> I recommend dropping these recommendations and replacing them with = text that recognizes the present reality that cellular hosts are simply = not expected ever to receive unsolicited inbound connection flows from = arbitrary remote Internet addresses. It would simplify the document and = it would be a more honest appraisal of the situation. >>=20 >> To be fair, that doesn't happen on all devices. For example, my Nexus = 7 LTE on Docomo's business APN appears to have real Internet access. I = can ping it, and when I attempt to connect to it, I get a TCP reset = back. tcpdump running on the phone shows: >>=20 >> 17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length = 64 >> 17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 > = 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, length = 64 >> 17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win = 14400 >> 17:06:26.366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > = 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win = 0 >>=20 >> Now, the battery life implications of such a setup are debatable, but = it does suggest that there is no stateful filtering going on in the = baseband. Or did I misunderstand what you wrote? >=20 > I don=92t think you misunderstood, but I think I should clarify my = remarks in order to better convey my concern. >=20 > It=92s nice that your phone, on that network, this month, can receive = unsolicited inbound flows=97 but the problem here is the same one I = complained bitterly about prior to and during the development of RFC = 6092: it isn=92t sufficient for only *some* or even most cellular hosts = to be reachable=97 in most places, most of the time=97 with unsolicited = flows by arbitrary remote hosts. We really need it to be practically = all the phones, practically all the time, practically everywhere. We = don=92t have that, and there is no reason to believe that we ever will = have that. We don't even have that for most computers at this point. I think it = would be a wonderful thing, but I don't think it is a problem that is = unique to cellular. > If you=92re trying to develop an application that does any sort of = direct peer-to-peer communication between cellular hosts, then you need = to be able to rely on the expectation that network elements that block = unsolicited inbound flows are rare and deployed only where users are not = expecting direct peer-to-peer applications to function properly, so that = when your application is broken by the stateful firewall in the network, = users know whom to blame and where to petition for redress. This is different from peer to peer software for non-cellular hosts how? > We now have a situation where a sizable fraction of cellular = IPv6-capable user-endpoint hosts are unreachable by unsolicited inbound = flow because they are located behind one or more than one stateful = firewall, that is enabled by default, contains no exceptions for IPsec = or IKE, and implements no protocol like PCP for soliciting inbound flows = from arbitrary remote addresses. This is precisely the situation I was = warning against before I capitulated and agreed to serve as the editor = for RFC 6092 despite my reservations about the reasons the working group = decided to adopt it. This is also the situationI was warning against = when I was arguing for a recommendation in RFC 6092 that firewalls not = block unsolicited inbound flows in the DEFAULT configuration. I don't think we should admit defeat, but we should fix this for more = than just cellular. Owen --Apple-Mail=_2CEE7A1A-6DDD-4E66-8412-FA51447C5707 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jhw@apple.com> wrote:

On Sep = 10, 2013, at 1:10, Lorenzo Colitti <lorenzo@google.com> = wrote:
On Tue, Sep = 10, 2013 at 12:59 AM, james woodyatt <jhw@apple.com> wrote:
I recommend dropping these = recommendations and replacing them with text that recognizes the present = reality that cellular hosts are simply not expected ever to receive = unsolicited inbound connection flows from arbitrary remote Internet = addresses. It would simplify the document and it would be a more honest = appraisal of the situation.

To be fair, that doesn't happen = on all devices. For example, my Nexus 7 LTE on Docomo's business APN = appears to have real Internet access. I can ping it, and when I attempt = to connect to it, I get a TCP reset back. tcpdump running on the phone = shows:

17:06:20.429555 IP6 = 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length = 64
17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 = > 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, = length 64
17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win = 14400 <mss 1394,sackOK,timestamp 9349082 0,nop,wscale = 7>
17:06:26.366201 IP6 = 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > = 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win = 0

Now, the battery life implications of such a = setup are debatable, but it does suggest that there is no stateful = filtering going on in the baseband. Or did I misunderstand what you = wrote?

I don=92t think you misunderstood, but I = think I should clarify my remarks in order to better convey my = concern.

It=92s nice that your phone, on that = network, this month, can receive unsolicited inbound flows=97 but the = problem here is the same one I complained bitterly about prior to and = during the development of RFC 6092: it isn=92t sufficient for only = *some* or even most cellular hosts to be reachable=97 in most places, = most of the time=97 with unsolicited flows by arbitrary remote hosts. =  We really need it to be practically all the phones, practically = all the time, practically everywhere. We don=92t have that, and there is = no reason to believe that we ever will have = that.

We don't even have that for = most computers at this point. I think it would be a wonderful thing, but = I don't think it is a problem that is unique to = cellular.

If you=92re trying to develop an application = that does any sort of direct peer-to-peer communication between cellular = hosts, then you need to be able to rely on the expectation that network = elements that block unsolicited inbound flows are rare and deployed only = where users are not expecting direct peer-to-peer applications to = function properly, so that when your application is broken by the = stateful firewall in the network, users know whom to blame and where to = petition for redress.

This is = different from peer to peer software for non-cellular hosts = how?

We now have a situation where a sizable = fraction of cellular IPv6-capable user-endpoint hosts are unreachable by = unsolicited inbound flow because they are located behind one or more = than one stateful firewall, that is enabled by default, contains no = exceptions for IPsec or IKE, and implements no protocol like PCP for = soliciting inbound flows from arbitrary remote addresses. This is = precisely the situation I was warning against before I capitulated and = agreed to serve as the editor for RFC 6092 despite my reservations about = the reasons the working group decided to adopt it. This is also the = situationI was warning against when I was arguing for a recommendation = in RFC 6092 that firewalls not block unsolicited inbound flows in the = DEFAULT configuration.

I don't = think we should admit defeat, but we should fix this for more than just = cellular.

Owen


= --Apple-Mail=_2CEE7A1A-6DDD-4E66-8412-FA51447C5707-- From cb.list6@gmail.com Tue Sep 10 12:58:37 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B649111E80AD for ; Tue, 10 Sep 2013 12:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19JNAw6ounNb for ; Tue, 10 Sep 2013 12:58:37 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D555621F991F for ; Tue, 10 Sep 2013 12:58:27 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q59so6989638wes.6 for ; Tue, 10 Sep 2013 12:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bOlFH8dMT+Prg1mj/KYuxCOHKpm/RAx3nuTBtpYCQoI=; b=gVy39rwgOxmWpHUCr/uQCEuAgP+v7DoHVDWpZLUS1No/UJKjpfiSco1ur0IisVRHZb D1dfKqW6nJ4WIqYAB43mndxd1sSPlXM6kpGOJdK2XuSN6g117Hbyr7xefJOoHfseAGM9 5ymzDLGY8wKyL3eHUj9x5zlS8twv69THFXqez438Mln6hBpzdOGID2z8vYnqMAUiClr0 jp0zHuBswuQf3DrDi4Ik+6z1K59nGlv5A45jqS5yU0bwZLlHXDXSA90nwb458kwa1G0J ocUC/glnel6ZZMV7gAG9P5iObMXqT+wyPTPJcjgzqJ+K52/lmRlq7Wf7G9s0fbFpt4z4 KM0A== MIME-Version: 1.0 X-Received: by 10.194.71.72 with SMTP id s8mr3168235wju.52.1378843106938; Tue, 10 Sep 2013 12:58:26 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Tue, 10 Sep 2013 12:58:26 -0700 (PDT) In-Reply-To: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> Date: Tue, 10 Sep 2013 12:58:26 -0700 Message-ID: From: "cb.list6" To: james woodyatt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:58:37 -0000 On Tue, Sep 10, 2013 at 11:06 AM, james woodyatt wrote: > On Sep 10, 2013, at 1:10, Lorenzo Colitti wrote: > > On Tue, Sep 10, 2013 at 12:59 AM, james woodyatt wrote: >> >> I recommend dropping these recommendations and replacing them with text >> that recognizes the present reality that cellular hosts are simply not >> expected ever to receive unsolicited inbound connection flows from arbit= rary >> remote Internet addresses. It would simplify the document and it would b= e a >> more honest appraisal of the situation. > > > To be fair, that doesn't happen on all devices. For example, my Nexus 7 L= TE > on Docomo's business APN appears to have real Internet access. I can ping > it, and when I attempt to connect to it, I get a TCP reset back. tcpdump > running on the phone shows: > > 17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length 6= 4 > 17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 > > 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, length 64 > 17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win 14= 400 > > 17:06:26.366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > > 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win 0 > > Now, the battery life implications of such a setup are debatable, but it > does suggest that there is no stateful filtering going on in the baseband= . > Or did I misunderstand what you wrote? > > > I don=92t think you misunderstood, but I think I should clarify my remark= s in > order to better convey my concern. > > It=92s nice that your phone, on that network, this month, can receive > unsolicited inbound flows=97 but the problem here is the same one I compl= ained > bitterly about prior to and during the development of RFC 6092: it isn=92= t > sufficient for only *some* or even most cellular hosts to be reachable=97= in > most places, most of the time=97 with unsolicited flows by arbitrary remo= te > hosts. We really need it to be practically all the phones, practically a= ll > the time, practically everywhere. We don=92t have that, and there is no r= eason > to believe that we ever will have that. > > If you=92re trying to develop an application that does any sort of direct > peer-to-peer communication between cellular hosts, then you need to be ab= le > to rely on the expectation that network elements that block unsolicited > inbound flows are rare and deployed only where users are not expecting > direct peer-to-peer applications to function properly, so that when your > application is broken by the stateful firewall in the network, users know > whom to blame and where to petition for redress. > > We now have a situation where a sizable fraction of cellular IPv6-capable > user-endpoint hosts are unreachable by unsolicited inbound flow because t= hey > are located behind one or more than one stateful firewall, that is enable= d > by default, contains no exceptions for IPsec or IKE, and implements no > protocol like PCP for soliciting inbound flows from arbitrary remote > addresses. This is precisely the situation I was warning against before I > capitulated and agreed to serve as the editor for RFC 6092 despite my > reservations about the reasons the working group decided to adopt it. Thi= s > is also the situationI was warning against when I was arguing for a > recommendation in RFC 6092 that firewalls not block unsolicited inbound > flows in the DEFAULT configuration. > > Shorter james: it=92s time to admit defeat. We blew it=97 there will neve= r be > direct peer-to-peer telecommunications with IPv6, particularly with cellu= lar > hosts. All that traffic must be directed through relays in the network wh= ere > it can be subject to police wiretap and social network analysis. > > Even shorter james: I told you all so. > I don't see it that way at all. I don't support PCP, and cannot see it being deployed any time soon. The idea of it gives me heartburn. But, in the general case of p2p, i certainly expect WebRTC to works with ICE / STUN / TURN. This is a use case i am very interested in supporting, especially with IPv6 end-to-end and IPv6 <->IPv4 via TURN. In the case of TMUS, users are able to use IPv6 to communicate freely with anyone on the internet without any *stateful* filters. And, according to Lorenzo's report, TMUS subscribers will have a nice e2e internet flow with anyone on Docomo. I am hopeful more network operators will see it our way. CB > > -- > james woodyatt > core os networking > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jhw@apple.com Tue Sep 10 13:35:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C313521F997B for ; Tue, 10 Sep 2013 13:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVunhvoH3gYL for ; Tue, 10 Sep 2013 13:35:43 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E25C211E811B for ; Tue, 10 Sep 2013 13:35:41 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9zpFqqA4fQMGFJmk/Jhayg)" Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSX00CQBFULFD01@mail-out.apple.com> for v6ops@ietf.org; Tue, 10 Sep 2013 13:35:12 -0700 (PDT) X-AuditID: 1180715a-b7f8e6d000006c98-b8-522f827f268d Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id CB.B0.27800.0828F225; Tue, 10 Sep 2013 13:35:12 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MSX00BDAFUNKF70@fenugreek.apple.com> for v6ops@ietf.org; Tue, 10 Sep 2013 13:35:11 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 10 Sep 2013 13:35:15 -0700 Message-id: <74CF222D-154A-4191-A401-057282A8909F@apple.com> References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> To: Owen DeLong X-Mailer: Apple Mail (2.1807) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FCcqNvQpB9ksKCfzeL0sb3MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLzmBEvBQ5uKp+tusTcwXjDuYuTgkBAwkei45dXFyAlkiklc uLeerYuRi0NIYDKTRHPTcSaQhJDAOiaJV6d9QGxmgSSJuSt3soDYvAJ6Eg+bT4HZwgKOEq9O 7WIDsdkEVCS+Xb7LBDKfU8BO4vZ3D5Awi4CqxPMTH9kgxmhIfL7xC2qMjcSTz3tZIPa+YpS4 9egV2F4RAUWJ868vsUEcJytxvPEQ+wRG/llIzpiF5AyIuLbEsoWvmSFsA4mnna9YMcX1Jd68 m8O0gJFtFaNAUWpOYqWZXmJBQU6qXnJ+7iZGcJgWRu1gbFhudYhRgINRiYfXQFE/SIg1say4 MvcQowQHs5II71QnoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeSmOglEB6YklqdmpqQWoRTJaJ g1OqgVHv7zwXoXmbZ1fFfuiI9V/kJv/i2Hepx2891Oy6nxw5KNfCpCfe/c1tYYRkW1nCypf5 rB4fV6demFei8PxYfYt25kkJRb6Fl7uYWpccu7hIQ/SL2+enyS31Goyx28NmdN5Mzmar8qz0 zZ4huT3YkpnZfyrT8R0PbwVuL9rH/l21OVl0zX31E0osxRmJhlrMRcWJAAVrWZtPAgAA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:35:57 -0000 --Boundary_(ID_9zpFqqA4fQMGFJmk/Jhayg) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Sep 10, 2013, at 12:45, Owen DeLong wrote: > On Sep 10, 2013, at 11:06 , james woodyatt wrote: > [=85] >> If you=92re trying to develop an application that does any sort of = direct peer-to-peer communication between cellular hosts, then you need = to be able to rely on the expectation that network elements that block = unsolicited inbound flows are rare and deployed only where users are not = expecting direct peer-to-peer applications to function properly, so that = when your application is broken by the stateful firewall in the network, = users know whom to blame and where to petition for redress. >=20 > This is different from peer to peer software for non-cellular hosts = how? At present, most of the wireline residential IPv6 service providers are = allowing unsolicited inbound flows. It=92s just some large wireless = mobile IPv6 service providers and host implementations that are blocking = it wholesale. I=92m currently thinking that = I-D.ietf-v6ops-mobile-device-profile could be a reasonable vehicle for = IETF to recognize that this is admissible only in the case of 3GPP = hosts, but not necessarily for all of the Internet. Trying to contain = the ongoing damage here, but the major damage is done and unrepairable = now. >> We now have a situation where a sizable fraction of cellular = IPv6-capable user-endpoint hosts are unreachable by unsolicited inbound = flow because they are located behind one or more than one stateful = firewall, that is enabled by default, contains no exceptions for IPsec = or IKE, and implements no protocol like PCP for soliciting inbound flows = from arbitrary remote addresses. This is precisely the situation I was = warning against before I capitulated and agreed to serve as the editor = for RFC 6092 despite my reservations about the reasons the working group = decided to adopt it. This is also the situationI was warning against = when I was arguing for a recommendation in RFC 6092 that firewalls not = block unsolicited inbound flows in the DEFAULT configuration. >=20 > I don't think we should admit defeat, but we should fix this for more = than just cellular. I think it=92s too late to fix this. The time to fix it was before RFC = 6092 went to publication, and arguably before RFC 4864 went to = publication. We failed utterly. It=92s done. Time to move on. -- james woodyatt core os networking --Boundary_(ID_9zpFqqA4fQMGFJmk/Jhayg) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable On Sep = 10, 2013, at 12:45, Owen DeLong <owen@delong.com> = wrote:
On Sep 10, 2013, at 11:06 , james = woodyatt <jhw@apple.com> = wrote:
[=85]
If you=92re trying to develop an application that = does any sort of direct peer-to-peer communication between cellular = hosts, then you need to be able to rely on the expectation that network = elements that block unsolicited inbound flows are rare and deployed only = where users are not expecting direct peer-to-peer applications to = function properly, so that when your application is broken by the = stateful firewall in the network, users know whom to blame and where to = petition for redress.

This is different = from peer to peer software for non-cellular hosts = how?

At present, most of the = wireline residential IPv6 service providers are allowing unsolicited = inbound flows. It=92s just some large wireless mobile IPv6 service = providers and host implementations that are blocking it wholesale. I=92m = currently thinking that I-D.ietf-v6ops-mobile-device-profile could be a = reasonable vehicle for IETF to recognize that this is admissible only in = the case of 3GPP hosts, but not necessarily for all of the Internet. = Trying to contain the ongoing damage here, but the major damage is done = and unrepairable now.

We now have a situation where a = sizable fraction of cellular IPv6-capable user-endpoint hosts are = unreachable by unsolicited inbound flow because they are located behind = one or more than one stateful firewall, that is enabled by default, = contains no exceptions for IPsec or IKE, and implements no protocol like = PCP for soliciting inbound flows from arbitrary remote addresses. This = is precisely the situation I was warning against before I capitulated = and agreed to serve as the editor for RFC 6092 despite my reservations = about the reasons the working group decided to adopt it. This is also = the situationI was warning against when I was arguing for a = recommendation in RFC 6092 that firewalls not block unsolicited inbound = flows in the DEFAULT configuration.

I = don't think we should admit defeat, but we should fix this for more than = just cellular.

I think it=92s too = late to fix this.  The time to fix it was before RFC 6092 went to = publication, and arguably before RFC 4864 went to publication.  We = failed utterly.  It=92s done.  Time to move = on.


--
james woodyatt <jhw@apple.com>
core os = networking

= --Boundary_(ID_9zpFqqA4fQMGFJmk/Jhayg)-- From jhw@apple.com Tue Sep 10 13:54:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49E611E8106 for ; Tue, 10 Sep 2013 13:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYekY5U2rXKJ for ; Tue, 10 Sep 2013 13:53:54 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4E21E8050 for ; Tue, 10 Sep 2013 13:53:52 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NN1Ze4yQL3cLi6llXNAYcw)" Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSX004Y6GPM6GH0@mail-out.apple.com> for v6ops@ietf.org; Tue, 10 Sep 2013 13:53:49 -0700 (PDT) X-AuditID: 11807166-b7fd66d000006a64-6e-522f86dc7b17 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id F5.B7.27236.CD68F225; Tue, 10 Sep 2013 13:53:48 -0700 (PDT) Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MSX0020MGPO6O00@fenugreek.apple.com> for v6ops@ietf.org; Tue, 10 Sep 2013 13:53:48 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 10 Sep 2013 13:53:52 -0700 Message-id: <84AC6F38-6CBE-468E-9699-154664617B47@apple.com> References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> To: "cb.list6" X-Mailer: Apple Mail (2.1807) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FCcqHunTT/I4PFyE4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9ZrwYLVihWTV8xlamBcINvFyMkhIWAi8f7GShYIW0ziwr31 bF2MXBxCApOZJP5/nM0E4axjknj2+TEbSBWzQJLEmqc7wTp4BfQkHjafArOFBRwlXp3aBVbD JqAi8e3yXSYQm1MgWOLrv/nsXYwcHCwCqhIvppZBjNGQ+HzjF9QYG4nlVyHGCAn8ZZQ4uF8E xBYRUJY4NKmfEeI4WYnjjYfYJzDyz0JyxSwkV0DEtSWWLXzNDGEbSDztfMWKKa4v8ebdHKYF jGyrGAWKUnMSKy30EgsKclL1kvNzNzGCw7QwbQdj03KrQ4wCHIxKPLw35PSDhFgTy4orcw8x SnAwK4nwTnUCCvGmJFZWpRblxxeV5qQWH2KU5mBREuetMgZKCaQnlqRmp6YWpBbBZJk4OKUa GA227+TcHZxZI2Gza8bBW8zfJxX/04mO/eLw2lVTufW0r3fEvUcz2Ky0lv2sYD9uJX65lWv3 oeQUs31Lojdxt7s1nP+Z/SgwaOb67Pd573pL7yz3X/Howb2ePBHeFXN/b5b8872j47BdieCq 31ryteFxMgF7Qp6xdHWvangSM/nLswkzLhcue6DEUpyRaKjFXFScCAAxuxtTTwIAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:54:03 -0000 --Boundary_(ID_NN1Ze4yQL3cLi6llXNAYcw) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Sep 10, 2013, at 12:58, cb.list6 wrote: > [=85] > I don't support PCP, and cannot see it being deployed any time soon. > The idea of it gives me heartburn. > [=85] > I am hopeful more network operators will see it our way. In shorter terms: you concur with me that = I-D.ietf-v6ops-mobile-device-profile should drop all its current = recommendations regarding the deployment of PCP clients in cellular = hosts. Is that so? -- james woodyatt core os networking --Boundary_(ID_NN1Ze4yQL3cLi6llXNAYcw) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable On Sep = 10, 2013, at 12:58, cb.list6 <cb.list6@gmail.com> = wrote:
[=85]
I don't support PCP, and cannot see = it being deployed any time soon.
The idea of it gives me = heartburn.
[=85]
I am hopeful more network operators = will see it our way.

In shorter = terms: you concur with me that I-D.ietf-v6ops-mobile-device-profile = should drop all its current recommendations regarding the deployment of = PCP clients in cellular hosts. Is that so?


--
james woodyatt <jhw@apple.com>
core os = networking

= --Boundary_(ID_NN1Ze4yQL3cLi6llXNAYcw)-- From cb.list6@gmail.com Tue Sep 10 14:01:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00F221F94FA for ; Tue, 10 Sep 2013 14:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X02McMpnHRC for ; Tue, 10 Sep 2013 14:01:56 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3AC21F9223 for ; Tue, 10 Sep 2013 14:01:54 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id a12so6995347wgh.6 for ; Tue, 10 Sep 2013 14:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PAEB/CrDwo4crRTudWA3mlZA0GyOTAr0PSt8+kppssU=; b=TBtiogr0SnM3r3WimH2XPdydQ8IIX+iklDssvdsANu6vUBpq1dag20mkL6P2al6qWH Ji+yPFKTEGXvpMBplEFOYK1QmO0oZZjLlulPAowoh2tPN6p3steQZsmdF3JB2nEYB7cr voUoMLfi9wQh8wu8eofYvMrW3IFVMeSPLoLBazA+GtQ7f+y8n+x7XvkXx2z4GP5sYPWS dEywA6x8ez7JoVMh7PUXPpYv4Aa/cX+kNhEf+uUTmVg8gK6IWx/VgcqbhV0hnQDAbyBo cEfB5rZQXM5JkGEuE/CdpgHNfqmi/+Ic36CU/PXUns+oJiSFcAIowt8ZkFEbloLRJPeS jmuA== MIME-Version: 1.0 X-Received: by 10.194.20.170 with SMTP id o10mr18887379wje.4.1378846911349; Tue, 10 Sep 2013 14:01:51 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Tue, 10 Sep 2013 14:01:51 -0700 (PDT) In-Reply-To: <84AC6F38-6CBE-468E-9699-154664617B47@apple.com> References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> <84AC6F38-6CBE-468E-9699-154664617B47@apple.com> Date: Tue, 10 Sep 2013 14:01:51 -0700 Message-ID: From: "cb.list6" To: james woodyatt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:01:59 -0000 On Tue, Sep 10, 2013 at 1:53 PM, james woodyatt wrote: > On Sep 10, 2013, at 12:58, cb.list6 wrote: > > [=85] > > I don't support PCP, and cannot see it being deployed any time soon. > The idea of it gives me heartburn. > [=85] > > I am hopeful more network operators will see it our way. > > > In shorter terms: you concur with me that > I-D.ietf-v6ops-mobile-device-profile should drop all its current > recommendations regarding the deployment of PCP clients in cellular hosts= . > Is that so? > I have made that case, but that idea was in the rough from the author team. CB > > -- > james woodyatt > core os networking > From owen@delong.com Tue Sep 10 14:48:58 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8B711E81CC for ; Tue, 10 Sep 2013 14:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikmOvHQ5YrFQ for ; Tue, 10 Sep 2013 14:48:57 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id EC6CA11E8142 for ; Tue, 10 Sep 2013 14:48:55 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id r8ALlIle003942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Sep 2013 14:47:18 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r8ALlIle003942 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378849638; bh=rAuKV5FVavYQ5P2+SMOby946q9s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ZbPu+mO3XxNF/asP2VXPefz56r3Zg9O2I2Reupmp53uGl9oMPz1YjhlwRUpyvBcrr cwPoYaS65ZagN+6KZVwmxEM/zp/BTyUiRbEOwmFtMyMXFxZFR1KMjks07YfmfRriKg l3pguo78l3G7uJqXCZxkyR8IrqOyAAFGsP+qZbpY= Content-Type: multipart/alternative; boundary="Apple-Mail=_2DFB567D-6736-4D1F-88D4-1AFC7080804A" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: <74CF222D-154A-4191-A401-057282A8909F@apple.com> Date: Tue, 10 Sep 2013 14:47:09 -0700 Message-Id: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> <74CF222D-154A-4191-A401-057282A8909F@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Tue, 10 Sep 2013 14:47:18 -0700 (PDT) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:48:58 -0000 --Apple-Mail=_2DFB567D-6736-4D1F-88D4-1AFC7080804A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 10, 2013, at 13:35 , james woodyatt wrote: > On Sep 10, 2013, at 12:45, Owen DeLong wrote: >> On Sep 10, 2013, at 11:06 , james woodyatt wrote: >> [=85] >>> If you=92re trying to develop an application that does any sort of = direct peer-to-peer communication between cellular hosts, then you need = to be able to rely on the expectation that network elements that block = unsolicited inbound flows are rare and deployed only where users are not = expecting direct peer-to-peer applications to function properly, so that = when your application is broken by the stateful firewall in the network, = users know whom to blame and where to petition for redress. >>=20 >> This is different from peer to peer software for non-cellular hosts = how? >=20 > At present, most of the wireline residential IPv6 service providers = are allowing unsolicited inbound flows. It=92s just some large wireless = mobile IPv6 service providers and host implementations that are blocking = it wholesale. I=92m currently thinking that = I-D.ietf-v6ops-mobile-device-profile could be a reasonable vehicle for = IETF to recognize that this is admissible only in the case of 3GPP = hosts, but not necessarily for all of the Internet. Trying to contain = the ongoing damage here, but the major damage is done and unrepairable = now. >=20 I don't think that the IETF is going to have much impact here no matter = what goes into a draft. Further, trying to overcome the (bad) administrative decisions of = service providers through IETF process seems a perilous precedent in the = long run. This is the kind of thing that more calls for regulation than for IETF = standards. The standards are already on the books for how to support the = proper movement of packets. Blocking them isn't a standards-related = decision, it's poor administrative practice. I don't see much of a difference between this and some of Comcast's = earlier misguided rate-shaping behaviors that got them a nice slap on = the wrist from the FCC. >>> We now have a situation where a sizable fraction of cellular = IPv6-capable user-endpoint hosts are unreachable by unsolicited inbound = flow because they are located behind one or more than one stateful = firewall, that is enabled by default, contains no exceptions for IPsec = or IKE, and implements no protocol like PCP for soliciting inbound flows = from arbitrary remote addresses. This is precisely the situation I was = warning against before I capitulated and agreed to serve as the editor = for RFC 6092 despite my reservations about the reasons the working group = decided to adopt it. This is also the situationI was warning against = when I was arguing for a recommendation in RFC 6092 that firewalls not = block unsolicited inbound flows in the DEFAULT configuration. >>=20 >> I don't think we should admit defeat, but we should fix this for more = than just cellular. >=20 > I think it=92s too late to fix this. The time to fix it was before = RFC 6092 went to publication, and arguably before RFC 4864 went to = publication. We failed utterly. It=92s done. Time to move on. No, RFCs are the wrong place to fix it. The place to fix it is either = through consumer demand (Cameron's latest post has me contemplating a = switch from VZW to T-Mo if VZW doesn't fix it for me soon) and/or = regulation. It's really not a standards issue. Owen --Apple-Mail=_2DFB567D-6736-4D1F-88D4-1AFC7080804A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jhw@apple.com> wrote:
On Sep = 10, 2013, at 12:45, Owen DeLong <owen@delong.com> = wrote:
On Sep 10, 2013, at 11:06 , james = woodyatt <jhw@apple.com> = wrote:
[=85]
If you=92re trying to develop an application that = does any sort of direct peer-to-peer communication between cellular = hosts, then you need to be able to rely on the expectation that network = elements that block unsolicited inbound flows are rare and deployed only = where users are not expecting direct peer-to-peer applications to = function properly, so that when your application is broken by the = stateful firewall in the network, users know whom to blame and where to = petition for redress.

This is different = from peer to peer software for non-cellular hosts = how?

At present, most of the = wireline residential IPv6 service providers are allowing unsolicited = inbound flows. It=92s just some large wireless mobile IPv6 service = providers and host implementations that are blocking it wholesale. I=92m = currently thinking that I-D.ietf-v6ops-mobile-device-profile could be a = reasonable vehicle for IETF to recognize that this is admissible only in = the case of 3GPP hosts, but not necessarily for all of the Internet. = Trying to contain the ongoing damage here, but the major damage is done = and unrepairable now.


I = don't think that the IETF is going to have much impact here no matter = what goes into a draft.

Further, trying to = overcome the (bad) administrative decisions of service providers through = IETF process seems a perilous precedent in the long = run.

This is the kind of thing that more calls = for regulation than for IETF standards. The standards are already on the = books for how to support the proper movement of packets. Blocking them = isn't a standards-related decision, it's poor administrative = practice.

I don't see much of a difference = between this and some of Comcast's earlier misguided rate-shaping = behaviors that got them a nice slap on the wrist from the = FCC.

We now have a situation where a = sizable fraction of cellular IPv6-capable user-endpoint hosts are = unreachable by unsolicited inbound flow because they are located behind = one or more than one stateful firewall, that is enabled by default, = contains no exceptions for IPsec or IKE, and implements no protocol like = PCP for soliciting inbound flows from arbitrary remote addresses. This = is precisely the situation I was warning against before I capitulated = and agreed to serve as the editor for RFC 6092 despite my reservations = about the reasons the working group decided to adopt it. This is also = the situationI was warning against when I was arguing for a = recommendation in RFC 6092 that firewalls not block unsolicited inbound = flows in the DEFAULT configuration.

I = don't think we should admit defeat, but we should fix this for more than = just cellular.

I think it=92s too = late to fix this.  The time to fix it was before RFC 6092 went to = publication, and arguably before RFC 4864 went to publication.  We = failed utterly.  It=92s done.  Time to move = on.

No, RFCs are the wrong = place to fix it. The place to fix it is either through consumer demand = (Cameron's latest post has me contemplating a switch from VZW to T-Mo if = VZW doesn't fix it for me soon) and/or regulation. It's really not a = standards = issue.

Owen

= --Apple-Mail=_2DFB567D-6736-4D1F-88D4-1AFC7080804A-- From mohamed.boucadair@orange.com Tue Sep 10 23:23:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DF811E8178 for ; Tue, 10 Sep 2013 23:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQOiL8l9dwFr for ; Tue, 10 Sep 2013 23:23:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id C68B611E812C for ; Tue, 10 Sep 2013 23:23:07 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 6AF69190686; Wed, 11 Sep 2013 08:23:05 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 51328384077; Wed, 11 Sep 2013 08:23:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 11 Sep 2013 08:23:05 +0200 From: To: cb.list6 , james woodyatt Date: Wed, 11 Sep 2013 08:23:03 +0200 Thread-Topic: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile Thread-Index: Ac6uaRdKvidUAMPTRTep1DghXdWkLAATOY7w Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE8128@PUEXCB1B.nanterre.francetelecom.fr> References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> <84AC6F38-6CBE-468E-9699-154664617B47@apple.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.11.53017 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 06:23:12 -0000 Hi all, Yes, that was discussed among authors and decided to go for a SHOULD.=20 One comment here: the ICE & cie path is not ideal ... and may require PCP t= o solve various issues: see http://tools.ietf.org/html/draft-penno-rtcweb-p= cp-00 for more details.=20 For the particular case of the voice over IP in managed networks (which wil= l be the case for mobile VoIP), some benefits of PCP are:=20 o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [I-D.ietf-mmusic-latching]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in the mid-box. o Not require symmetric RTP/RTCP to work. o Not require symmetric SIP to work (i.e., rport [RFC3581]). o Easily support unidirectional sessions. o No early media issues. o Because there is no need for connectivity checks, session establishment delay is not impacted (pairs of ports can be pre- reserved) Cheers, Med >-----Message d'origine----- >De=A0: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d= e >cb.list6 >Envoy=E9=A0: mardi 10 septembre 2013 23:02 >=C0=A0: james woodyatt >Cc=A0: v6ops@ietf.org WG >Objet=A0: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile > >On Tue, Sep 10, 2013 at 1:53 PM, james woodyatt wrote: >> On Sep 10, 2013, at 12:58, cb.list6 wrote: >> >> [.] >> >> I don't support PCP, and cannot see it being deployed any time soon. >> The idea of it gives me heartburn. >> [.] >> >> I am hopeful more network operators will see it our way. >> >> >> In shorter terms: you concur with me that >> I-D.ietf-v6ops-mobile-device-profile should drop all its current >> recommendations regarding the deployment of PCP clients in cellular >hosts. >> Is that so? >> > > >I have made that case, but that idea was in the rough from the author team= . > >CB > >> >> -- >> james woodyatt >> core os networking >> >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Tue Sep 10 23:41:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B378421F85BB; Tue, 10 Sep 2013 23:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgokvigifhee; Tue, 10 Sep 2013 23:41:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2696A21F8948; Tue, 10 Sep 2013 23:41:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130911064110.6772.80683.idtracker@ietfa.amsl.com> Date: Tue, 10 Sep 2013 23:41:10 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 06:41:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : An Internet Protocol Version 6 (IPv6) Profile for 3GPP M= obile Devices Author(s) : David Binet Mohamed Boucadair Ales Vizdal Cameron Byrne Gang Chen Filename : draft-ietf-v6ops-mobile-device-profile-06.txt Pages : 17 Date : 2013-09-10 Abstract: This document defines an IPv6 profile that a number of operators recommend in order to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-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 mohamed.boucadair@orange.com Tue Sep 10 23:46:43 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568BE21E805D for ; Tue, 10 Sep 2013 23:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEBNPUn4lNFu for ; Tue, 10 Sep 2013 23:46:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD421F9CC3 for ; Tue, 10 Sep 2013 23:46:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 58CD422C9AB for ; Wed, 11 Sep 2013 08:46:35 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 435BD4C024 for ; Wed, 11 Sep 2013 08:46:35 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 11 Sep 2013 08:46:35 +0200 From: To: "v6ops@ietf.org" Date: Wed, 11 Sep 2013 08:46:33 +0200 Thread-Topic: I-D Action: draft-ietf-v6ops-mobile-device-profile-06.txt Thread-Index: Ac6uugD8vy5RFOIPSgWFQBReOX2lVAAAIe1w Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE8140@PUEXCB1B.nanterre.francetelecom.fr> References: <20130911064110.6772.80683.idtracker@ietfa.amsl.com> In-Reply-To: <20130911064110.6772.80683.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.11.44515 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 06:46:43 -0000 Dear all, This new version integrates the changes suggested by Lorenzo.=20 You can check the diff for more details.=20 Cheers, Med >-----Message d'origine----- >De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] >De la part de internet-drafts@ietf.org >Envoy=E9=A0: mercredi 11 septembre 2013 08:41 >=C0=A0: i-d-announce@ietf.org >Cc=A0: v6ops@ietf.org >Objet=A0: I-D Action: draft-ietf-v6ops-mobile-device-profile-06.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the IPv6 Operations Working Group of the >IETF. > > Title : An Internet Protocol Version 6 (IPv6) Profile for >3GPP Mobile Devices > Author(s) : David Binet > Mohamed Boucadair > Ales Vizdal > Cameron Byrne > Gang Chen > Filename : draft-ietf-v6ops-mobile-device-profile-06.txt > Pages : 17 > Date : 2013-09-10 > >Abstract: > This document defines an IPv6 profile that a number of operators > recommend in order to connect 3GPP mobile devices to an IPv6-only or > dual-stack wireless network (including 3GPP cellular network and IEEE > 802.11 network). > > This document defines a different profile than the one for general > connection to IPv6 cellular networks defined in > [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies > also features to deliver IPv4 connectivity service over an IPv6-only > transport. > > Both hosts and devices with capability to share their WAN (Wide Area > Network) connectivity are in scope. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-mobile-device-profile-= 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/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From swmike@swm.pp.se Tue Sep 10 23:59:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814B011E8191 for ; Tue, 10 Sep 2013 23:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSPpDcd5NprW for ; Tue, 10 Sep 2013 23:59:24 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CCF0211E8183 for ; Tue, 10 Sep 2013 23:59:22 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 89BD69C; Wed, 11 Sep 2013 08:59:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 82FD49A; Wed, 11 Sep 2013 08:59:20 +0200 (CEST) Date: Wed, 11 Sep 2013 08:59:20 +0200 (CEST) From: Mikael Abrahamsson To: james woodyatt In-Reply-To: Message-ID: References: <7A28FE9A-EBA4-4C4C-8608-04B4A7820805@apple.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-147966182-1378882760=:10009" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 06:59:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-147966182-1378882760=:10009 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 10 Sep 2013, james woodyatt wrote: > Shorter james: it’s time to admit defeat. We blew it— there will never > be direct peer-to-peer telecommunications with IPv6, particularly with > cellular hosts. All that traffic must be directed through relays in the > network where it can be subject to police wiretap and social network > analysis. I don't agree. Looking at the design goals of 5G, the next generation networks will be engineered for massive device scale and very different traffic patterns. The small packets (backscatter or scanning) killing signaling (and battery life) in 3G is done a lot better in LTE, and most likely in 5G it'll be even less impacting. For mobile operators there is a huge incentive to block incoming connections to mobile today (3G) but less so going forward. Handset manufacturers also have a huge role in this in hardering their hosts so that they can actually handle being exposed to the Internet (they already are by large I'd say) and ask the baseband vendors to not implement filtering there (I don't understand why someone would do that, the "computer part" of the device can't be that bad at handling incoming connections, right?). I can understand wanting to save battery for customers by the ISP filtering unsolicited packets in 3G, but not going forward. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-147966182-1378882760=:10009-- From abdussalambaryun@gmail.com Wed Sep 11 02:40:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8A21E809F; Wed, 11 Sep 2013 02:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6s5jrkxqUFV; Wed, 11 Sep 2013 02:40:40 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1749421E809B; Wed, 11 Sep 2013 02:40:38 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so9056705pad.9 for ; Wed, 11 Sep 2013 02:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=70t2uOlDlEkK/GqqwqhUcHOKDUiOMoUV24K5jOn7REw=; b=QCnF3d1LH+YAMKWYzL7GAdgHUSR8eKowd9UrNtZcmZA0eq4lXvGbf5aw8CrW/up5ce V1t0WGmDvFobEVrp7BjRkJH9I4SjU0sfRrx6hWR88ZMrOftpZ2TarZkFRhhjmwarEyUK Uqk80O0EPyWYFq5cVA7BiyBimbWsoyhR5NGLhCpcKjFP5SRr83Yc5CQ1B2F6alLeTBY8 r1tkY+u7k+JePItYTIfgA9urIMOEWb60tXwCKzTWNmKFAFpEmNApunJbFOk7a6PYuPYO qj1kjVSqh6IodqL4BpUIIM2/dWVYkBpg6vOqdkPakn4Pk5K1W/U8k7K9A4fpjpKo/iiO znMQ== MIME-Version: 1.0 X-Received: by 10.67.3.103 with SMTP id bv7mr2527202pad.15.1378892438581; Wed, 11 Sep 2013 02:40:38 -0700 (PDT) Received: by 10.68.195.168 with HTTP; Wed, 11 Sep 2013 02:40:38 -0700 (PDT) In-Reply-To: <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> Date: Wed, 11 Sep 2013 11:40:38 +0200 Message-ID: From: Abdussalam Baryun To: Owen DeLong Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 11 Sep 2013 14:26:26 -0700 Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 09:40:40 -0000 On 9/9/13, Owen DeLong wrote: > I have to agree with Lorenzo here again. > > This document seems to me to be: > > 1. Out of scope for the IETF. Please define what is the IETF scope? IMHO, IETF is scoped to do with IPv6 devices requirements and implementations. Do you think there is a RFC that considers thoes requirements? > 2. So watered down in its language as to use many words to say nearly > nothing. No, the draft says things, I think if you read nothing that you did not read then. If you read, then what is your definition of saying nothing? > 3. Claims to be informational, but with so many caveats about the nature of > that > information that it's hard to imagine what meaningful information an > independent > reader could glean from the document. I think this was mentioned clearly in the draft, which readers can understand. > > Finally, given the spirited debate that has extended into this last call > (which I honestly wonder > how this ever saw last call over the sustained objections) definitely does > not appear to have > even rough consensus, nor does it appear to have running code. IMHO, the LC is not for consensus, but it is for us to send the IESG our comments, and then they decide what is the IETF decision. > > Why is there such a push to do this? Why is there a push to water-down it? I still was not convinced by your argument. However, Lorenzo comments should be considered by the draft as the authors are working on. AB From joelja@bogus.com Wed Sep 11 14:45:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2919D21E80A9; Wed, 11 Sep 2013 14:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.591 X-Spam-Level: X-Spam-Status: No, score=-101.591 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkqJYW4n0w7k; Wed, 11 Sep 2013 14:45:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 10E2C21E8050; Wed, 11 Sep 2013 14:45:32 -0700 (PDT) Received: from mb-aye.corp.zynga.com (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r8BLjNVU081861 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 11 Sep 2013 21:45:25 GMT (envelope-from joelja@bogus.com) Message-ID: <5230E46E.60106@bogus.com> Date: Wed, 11 Sep 2013 14:45:18 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Abdussalam Baryun , Owen DeLong References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 11 Sep 2013 21:45:25 +0000 (UTC) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 21:45:34 -0000 On 9/11/13 2:40 AM, Abdussalam Baryun wrote: > On 9/9/13, Owen DeLong wrote: >> I have to agree with Lorenzo here again. >> >> This document seems to me to be: >> >> 1. Out of scope for the IETF. > > Please define what is the IETF scope? IMHO, IETF is scoped to do with > IPv6 devices requirements and implementations. Do you think there is a > RFC that considers thoes requirements? The queue for dicussion of this point is closed. If there needs to be an appeal on this point now or in the future, then I'll be happy to help someone write it, but I consider that dicussion settled for the purposes of a draft that has already been tested for wg acceptance/wglc/ietf-lc > >> 2. So watered down in its language as to use many words to say nearly >> nothing. > > No, the draft says things, I think if you read nothing that you did > not read then. If you read, then what is your definition of saying > nothing? > >> 3. Claims to be informational, but with so many caveats about the nature of >> that >> information that it's hard to imagine what meaningful information an >> independent >> reader could glean from the document. > > I think this was mentioned clearly in the draft, which readers can understand. > >> >> Finally, given the spirited debate that has extended into this last call >> (which I honestly wonder >> how this ever saw last call over the sustained objections) definitely does >> not appear to have >> even rough consensus, nor does it appear to have running code. > > IMHO, the LC is not for consensus, but it is for us to send the IESG > our comments, and then they decide what is the IETF decision. >> >> Why is there such a push to do this? > > Why is there a push to water-down it? I still was not convinced by > your argument. However, Lorenzo comments should be considered by the > draft as the authors are working on. > > AB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Wed Sep 11 21:39:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECCA11E8142 for ; Wed, 11 Sep 2013 21:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxJfsC0d8lxY for ; Wed, 11 Sep 2013 21:39:45 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5490411E80FE for ; Wed, 11 Sep 2013 21:39:45 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so21080953ieb.14 for ; Wed, 11 Sep 2013 21:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=izpuQ8kHAAxxFJWwmHXNHRAnNs9MhYOxES6vXUcN9xw=; b=V6r/9e0llodkjARndweBwkCjKXUuhm+BXdcJGVFi1CP3kIjd6kEWlNbACPzkNsJPX7 ygYmSh38hsRCKOtb6mJ1CBAqxBXqKQFBD9q7pTA01MslUrpMc67POnBov7dCY+kcGaea BPEnjQwhyjoFX1iaruJdWc0Ppv75GA6wcd4qmnjgakqH+CCGRgz7iKL1urbmXGslzoTx 9uIyboVDmptTAP4+m1sG9dRfETW56AkOi2W+1M3jFoCFjqD0xMIeSZtD6ixQFPBdDNwa 424ih5Mf/mmbWC8U2eyZqPqZLjw+Ba1MgCbZ+zCvINmSVDu6MJL5QLLt6gZn4mMjyTCL 44wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=izpuQ8kHAAxxFJWwmHXNHRAnNs9MhYOxES6vXUcN9xw=; b=mcUcyAqaawXdSabHtLVJFHokSHFg3/S1TeYL2r26v6SBT23gzp24IV5BItxODto+39 smycvCrD+FruxSajD1Izy9i/vWLyG2g2C/XbEh0teI7ePq6taNzN8Bult9Bvhd13gg4g BUoVufk1IBO/LTlt8d4wvOUeHTGWdMr+8G8S3x22QWacYrFezA54Pp9BdmVJXrFR/SpA uaHgS39ZZx2IpS1fKDtmYuuU1sdaQTcSHt7uEMv229MKzNkOIE0lSFZ2BhdvrJw5AfjN XSWmgm2n/WNsz0bHaTrspYqwYSQOR2Y7aruGh2lCRqvGhc/J5Z0QpRDefeque+ZMsD0Z ACbw== X-Gm-Message-State: ALoCoQkHFg+Ki95w1LgwKqJOlimox0xGnz3UWsKi9OSmgve3jgna+8/uOTPljp1UqBUFyXEXmmn9PrSyuTYzAmWzlstBg0ZulTRWxJNUrEAvxAnpP3ysCPiKsPh+H9a7XdX4Ix4Wu9hG7CoKCQH+iG8B5HW1FUrem7eknNfH4twctRxdX590e4Tkg4iDrPKnqFcXFNruqnIs X-Received: by 10.50.78.162 with SMTP id c2mr13252999igx.20.1378960784789; Wed, 11 Sep 2013 21:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.138 with HTTP; Wed, 11 Sep 2013 21:39:23 -0700 (PDT) In-Reply-To: <5230E46E.60106@bogus.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> <5230E46E.60106@bogus.com> From: Lorenzo Colitti Date: Thu, 12 Sep 2013 13:39:23 +0900 Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=089e0111e074bcc1fe04e628535f Cc: "v6ops@ietf.org WG" , IETF Discussion , Abdussalam Baryun Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 04:39:46 -0000 --089e0111e074bcc1fe04e628535f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli wrote: > The queue for dicussion of this point is closed. If there needs to be an > appeal on this point now or in the future, then I'll be happy to help > someone write it, but I consider that dicussion settled for the purposes > of a draft that has already been tested for wg acceptance/wglc/ietf-lc To clarify - you're talking only about the discussion on whether this draft is in scope? Or are you saying that you consider all discussion of this document in this IETF last call settled? --089e0111e074bcc1fe04e628535f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli <joelja@bogu= s.com> wrote:
The queue for dicussion of this point is closed. If there needs t= o be an
appeal on this point now or in the future, then I'll be happy to help someone write it, but I consider that dicussion settled for the purposes of a draft that has already been tested for wg acceptance/wglc/ietf-lc

To clarify - you're talking only about the = discussion on whether this draft is in scope? Or are you saying that you co= nsider all discussion of this document in this IETF last call settled?
--089e0111e074bcc1fe04e628535f-- From joelja@bogus.com Wed Sep 11 23:08:36 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3621E21E8128; Wed, 11 Sep 2013 23:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNwmqhiwAfzz; Wed, 11 Sep 2013 23:08:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9871911E8119; Wed, 11 Sep 2013 23:08:35 -0700 (PDT) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r8C68Vso086923 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 12 Sep 2013 06:08:31 GMT (envelope-from joelja@bogus.com) Message-ID: <52315A59.2000301@bogus.com> Date: Wed, 11 Sep 2013 23:08:25 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <179F53B5-6217-49A0-B5FE-A88011533860@delong.com> <5230E46E.60106@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 12 Sep 2013 06:08:32 +0000 (UTC) Cc: "v6ops@ietf.org WG" , IETF Discussion , Abdussalam Baryun Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 06:08:36 -0000 On 9/11/13 9:39 PM, Lorenzo Colitti wrote: > On Thu, Sep 12, 2013 at 6:45 AM, joel jaeggli > wrote: > > The queue for dicussion of this point is closed. If there needs to be an > appeal on this point now or in the future, then I'll be happy to help > someone write it, but I consider that dicussion settled for the purposes > of a draft that has already been tested for wg acceptance/wglc/ietf-lc > > > To clarify - you're talking only about the discussion on whether this > draft is in scope? Or are you saying that you consider all discussion of > this document in this IETF last call settled? The discussion of whether the IETF, or this working group is a suitable location. It was my opinion that the working group should revist the document itself given what I saw in the last call. joel From owen@delong.com Wed Sep 11 23:24:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091011E8173; Wed, 11 Sep 2013 23:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=-2.274, BAYES_00=-2.599, GB_SUMOF=5, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAi2TCGDOpDw; Wed, 11 Sep 2013 23:24:00 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D9C0E11E8160; Wed, 11 Sep 2013 23:23:59 -0700 (PDT) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id r8C6LThR014146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Sep 2013 23:21:29 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r8C6LThR014146 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1378966889; bh=PB1CF5VolJ73VECOc1l1MIm9CfM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dOBtddwngK56MawnLZ2+SkvKMaeIJ2sY39sC7CbOK65wxwBXL/DYqyEHPscgvlEpH pXhdXVvw9c+P12oR6qAKgZwGSPikUg5AIe5O9+/HtTcCVCLh/4RJ43uZhQpFcBb8tE NvnGDFvbWKtrjJkvPRTLsT2PivuAtuxk7ZgB7qVI= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Owen DeLong In-Reply-To: Date: Wed, 11 Sep 2013 23:21:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C493382-615E-49BA-A93E-561A005F0657@delong.com> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <17! 9F53B5-6217-49A0-B5FE-A88011533860@delong.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 11 Sep 2013 23:21:29 -0700 (PDT) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 06:24:01 -0000 On Sep 11, 2013, at 02:40 , Abdussalam Baryun = wrote: > On 9/9/13, Owen DeLong wrote: >> I have to agree with Lorenzo here again. >>=20 >> This document seems to me to be: >>=20 >> 1. Out of scope for the IETF. >=20 > Please define what is the IETF scope? IMHO, IETF is scoped to do with > IPv6 devices requirements and implementations. Do you think there is a > RFC that considers thoes requirements? >=20 =46rom an RFC perspective, I think a cellular device is a host and/or = router and those cover it. The media-specific aspects of layering IPv6 onto he peculiarities and = vagaries of the underlying cellular specific technologies are, IMHO, best left to = the media adaptation efforts of the relevant media standards bodies (as was done = with ethernet, FDDI, Firewire, etc.). >> 2. So watered down in its language as to use many words to = say nearly >> nothing. >=20 > No, the draft says things, I think if you read nothing that you did > not read then. If you read, then what is your definition of saying > nothing? The draft says many things most or all of which conflict with things = said elsewhere and all of which are fronted by a strong "this is advisory only" caveat. In = fact, it says far too many things with far too little strength. The net result is that the = document will, in the long run, become a no-op at best and a quagmire of conflicting = and misleading advice at worst. >=20 >> 3. Claims to be informational, but with so many caveats = about the nature of >> that >> information that it's hard to imagine what meaningful = information an >> independent >> reader could glean from the document. >=20 > I think this was mentioned clearly in the draft, which readers can = understand. I don't doubt that readers can understand it. My point is that once you = understand the sum of the caveats and warnings and advisory nature of this = document, the sum of all those understandings is that you have to look for the true answer = to virtually everything contained here somewhere outside of the IETF anyway. >> Finally, given the spirited debate that has extended into this last = call >> (which I honestly wonder >> how this ever saw last call over the sustained objections) definitely = does >> not appear to have >> even rough consensus, nor does it appear to have running code. >=20 > IMHO, the LC is not for consensus, but it is for us to send the IESG > our comments, and then they decide what is the IETF decision. I suppose everyone is entitled to their opinion. >>=20 >> Why is there such a push to do this? >=20 > Why is there a push to water-down it? I still was not convinced by > your argument. However, Lorenzo comments should be considered by the > draft as the authors are working on. If you think I am pushing to water it down, you are mistaken. I'd like = to see it pared down to a useful document and then given the force of being a = standards track document so it can actually provide something useful. Owen From repenno@cisco.com Thu Sep 12 09:46:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2260A11E823E for ; Thu, 12 Sep 2013 09:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrfYJKCXI68s for ; Thu, 12 Sep 2013 09:45:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1121E11E81D4 for ; Thu, 12 Sep 2013 09:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25693; q=dns/txt; s=iport; t=1379004349; x=1380213949; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=slsG07yy3pcFJaQMVny4tLQVjm9Vc2wvr3n+8uyS2iw=; b=DasiiNflUwnUzaaCTwqyXjPif9dpML+w6dnGTH9OGceBzoWqFdijDvXz gBdK0kN5mrXRDU3hO8tbV1eZcrLPhmYaO9dOaYnFJHURAL8bBdAzvcG9y xtfItHr2+VIXjahGa4OPEFbHISvKmGFS8lRI+dCqES7OYEr2PWUdZU+F6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAGLvMVKtJXHB/2dsb2JhbABbgkNEOFK4GohHgRwWdIIlAQEBBC1eAQgRAQIBAgsWBzkUAwYIAQEEARIIh3oMu2qOHBYBgQcgFwGDHYEAA5kokESDIoFoBQQXIg X-IronPort-AV: E=Sophos;i="4.90,891,1371081600"; d="scan'208,217";a="258937307" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 12 Sep 2013 16:45:25 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8CGjPhV002322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 16:45:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 11:45:25 -0500 From: "Reinaldo Penno (repenno)" To: "mohamed.boucadair@orange.com" , "james woodyatt" , "v6ops@ietf.org WG" Thread-Topic: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile Thread-Index: Ac6td/8+oqaMCKkqR5qrc6AszGJyfQAeAPbAAHWssoA= Date: Thu, 12 Sep 2013 16:45:24 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B6D29BD@xmb-rcd-x04.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF0EE7DFA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.151.149] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D29BDxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:46:34 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D29BDxmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Inline with [RP] From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> Date: Tuesday, September 10, 2013 1:27 AM To: james woodyatt >, "v6ops@ietf.org WG" > Cc: Cisco Employee > Subject: RE: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile Hi James, I appreciate your effort for reading and raising a technical point. I reall= y don=92t care if you shared this comment during the WGLC or now once the I= ETF LC is over. Some general answers: * This document does not aim to provide a static picture of what current im= plementations are doing but we are listing also features to ease adoption o= f the IPv6-only model. For this reason, there is a list of feature that are= needed for that model: these recommendations are all SHOULD ones and not M= UST. FWIW, the document included some details on broken implementations and= tests but that text was removed as suggested by some reviewers. The docume= nt is not intended to ACK the current broken implementations but to list of= features to have more and more implementations that can be connected in IP= v6-only and DS modes without service degradation. * The feature of retrieving the PREFIX64 using PCP has been implemented and= tested (see for example http://tools.ietf.org/html/draft-boucadair-pcp-nat= 64-experiments-00) * Motivations for PCP from a provider perspective are mentioned in the docu= ment. No need to re-iterate that. From a customer standpoint, some users ar= e using their mobile connection as their main line. As such, they have the = same requirements as for fixed services. I have been told that there are cu= stomers running game consoles using their mobile connection (If I=92m not m= istaken, Reinaldo has mentioned this case in an e-mail. I will let him conf= irm/infirm). [RP] Right, FWIW in US there are wireless subscriber (LTE/4G) that do not h= ave wireline internet. They use (and expect) this high speed wireless to ca= rry traffic usually associated with wireline deployments. The case through = a Wireless provider was related to subscribers that want to use XBOX throug= h 4G/LTE. * The document includes the following: Some of the features listed in this profile document require to activate dedicated functions at the network side. It is out of scope of this document to list these network-side functions. * Some operators have included PCP as a requirement for their NAT64 in the = context of ongoing RFPs. For those operators, the client-side functionalit= y is needed. Cheers, Med De : v6ops-bounces@ietf.org [mailto:v6ops-bo= unces@ietf.org] De la part de james woodyatt Envoy=E9 : lundi 9 septembre 2013 17:59 =C0 : v6ops@ietf.org WG Objet : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile everyone=97 I haven=92t prepared an exhaustive criticism of this draft, but I do have o= ne concern in particular I would like to highlight. The recommendations (fo= r they are not requirements) REQ#12 and REQ#15 discussing matters related t= o the Port Control Protocol (PCP) and traversal of NAT and firewalls is tro= ubling to me. REQ#12: The cellular host SHOULD support a method to locally construct IPv4-embedded IPv6 addresses [RFC6052]. A method to learn PREFIX64 SHOULD be supported by the cellular host. This solves the issue when applications use IPv4 referrals on IPv6-only access networks. In PCP-based environments, cellular hosts SHOULD follow [I-D.ietf-pcp-nat64-prefix64] to lear= n the IPv6 Prefix used by an upstream PCP-controlled NAT64 device. If PCP is not enabled, the cellular host SHOULD implement the method specified in [I-D.ietf-behave-nat64-discovery-heuristic] to retrieve the PREFIX64. REQ#15: The cellular host SHOULD support PCP [RFC6887]. The support of PCP is seen as a driver to save battery consumption exacerbated by keepalive messages. PCP also gives the possibility of enabling incoming connections to the cellular device. Indeed, because several stateful devices may be deployed in wireless networks (e.g., NAT and/or Firewalls), PCP can be used by the cellular host to control network-based NAT and Firewall functions which will reduce per-application signaling and save battery consumption. It seems to me that these recommendations are only worth following if there= are to be PCP servers in *all* of the network elements in the paths betwee= n cellular hosts and the default free zone that implement stateful firewall= (and NAT) functions. Indeed, in at least one common cellular host archite= cture, there is a stateful filter in the baseband chipset firmware that blo= cks all inbound packets that it decides are unsolicited by applications on = the main system CPU. There is no PCP service in those chipset firmware impl= ementations, and no practical way to turn off the filtering, because it is = tied up with tricky power consumption issues, and without either of those t= hings, there is pretty much no good reason to implement a PCP client on the= main system CPU. It does not matter whether there are PCP servers in the f= irewalls further upstream, if there is a firewall in the baseband chipset t= hat you can=92t disable or control. I recommend dropping these recommendations and replacing them with text tha= t recognizes the present reality that cellular hosts are simply not expecte= d ever to receive unsolicited inbound connection flows from arbitrary remot= e Internet addresses. It would simplify the document and it would be a more= honest appraisal of the situation. -- james woodyatt > core os networking --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D29BDxmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Inline with [RP]

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com&g= t;
Date: Tuesday, September 10, 2013 1= :27 AM
To: james woodyatt <jhw@apple.com>, "v6ops@ietf.org WG" <= v6ops@ietf.org>
Cc: Cisco Employee <repenno@cisco.com>
Subject: RE: [v6ops] PCP and I-D.ie= tf-v6ops-mobile-device-profile

Hi James,

 

I appreciate your effort for reading and= raising a technical point. I really don=92t care if you shared this commen= t during the WGLC or now once the IETF LC is over.

 

Some general answers:

 

* This document does not aim to provide = a static picture of what current implementations are doing but we are listi= ng also features to ease adoption of the IPv6-only model. For this reason, there is a list of feature that are = needed for that model: these recommendations are all SHOULD ones and not MU= ST. FWIW, the document included some details on broken implementations and = tests but that text was removed as suggested by some reviewers. The document is not intended to ACK the cu= rrent broken implementations but to list of features to have more and more = implementations that can be connected in IPv6-only and DS modes without ser= vice degradation.

 

* The feature of retrieving the PREFIX64= using PCP has been implemented and tested (see for example http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00)

 

* Motivations for PCP from a provider pe= rspective are mentioned in the document. No need to re-iterate that. From a= customer standpoint, some users are using their mobile connection as their main line. As such, they have the s= ame requirements as for fixed services. I have been told that there are cus= tomers running game consoles using their mobile connection (If I=92m not mi= staken, Reinaldo has mentioned this case in an e-mail. I will let him confirm/infirm).

[RP] Right, FWIW in US there are wireless subscriber (LTE/4G) that do = not have wireline internet. They use (and expect) this high speed wireless = to carry traffic usually associated with wireline deployments. The case thr= ough a Wireless provider was related to subscribers that want to use XBOX through 4G/LTE. 

 

* The document includes the following:

 

   Some of the features listed in this profile document= require to

   activate dedicated functions at the network side.&nb= sp; It is out of scope

   of this document to list these network-side function= s.

 

* Some operators have included PCP as a = requirement for their NAT64 in the context of ongoing RFPs. For those  = ;operators, the client-side functionality is needed.

 

Cheers,

Med

 

 

De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de james woodyatt
Envoy=E9 : lundi 9 septembre 2013 17:59
=C0 : v6ops@ietf.org WG Objet : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

 

everyone=97

 

I haven=92t prepared an exhaustive criticism of this= draft, but I do have one concern in particular I would like to highlight. = The recommendations (for they are not requirements) REQ#12 and REQ#15 discu= ssing matters related to the Port Control Protocol (PCP) and traversal of NAT and firewalls is troubling to me.=

 

RE=
Q#12:  The cellular host SHOULD support a method to locally=

&n=
bsp;       construct IPv4-embedded IPv6 addre=
sses [RFC6052].  A method to
&n=
bsp;       learn PREFIX64 SHOULD be supported=
 by the cellular host.
 
&n=
bsp;          This solves the =
issue when applications use IPv4 referrals on
&n=
bsp;          IPv6-only access=
 networks.
 
&n=
bsp;          In PCP-based env=
ironments, cellular hosts SHOULD follow
&n=
bsp;          [I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 P=
refix used
&n=
bsp;          by an upstream P=
CP-controlled NAT64 device.  If PCP is not
&n=
bsp;          enabled, the cel=
lular host SHOULD implement the method
&n=
bsp;          specified in [I-D.ietf-behave-nat64-dis=
covery-heuristic] to
&n=
bsp;          retrieve the PRE=
FIX64.

 

RE=
Q#15:  The cellular host SHOULD support PCP [RFC=
6887].
 
&n=
bsp;          The support of P=
CP is seen as a driver to save battery
&n=
bsp;          consumption exac=
erbated by keepalive messages.  PCP also
&n=
bsp;          gives the possib=
ility of enabling incoming connections to the
&n=
bsp;          cellular device.=
  Indeed, because several stateful devices
&n=
bsp;          may be deployed =
in wireless networks (e.g., NAT and/or
&n=
bsp;          Firewalls), PCP =
can be used by the cellular host to control
&n=
bsp;          network-based NA=
T and Firewall functions which will reduce
&n=
bsp;          per-application =
signaling and save battery consumption.

 

It seems to me that these recommendations are only w= orth following if there are to be PCP servers in *all* of the network eleme= nts in the paths between cellular hosts and the default free zone that impl= ement stateful firewall (and NAT) functions.  Indeed, in at least one common cellular host architecture= , there is a stateful filter in the baseband chipset firmware that blocks a= ll inbound packets that it decides are unsolicited by applications on the m= ain system CPU. There is no PCP service in those chipset firmware implementations, and no practical way to turn of= f the filtering, because it is tied up with tricky power consumption issues= , and without either of those things, there is pretty much no good reason t= o implement a PCP client on the main system CPU. It does not matter whether there are PCP servers in the f= irewalls further upstream, if there is a firewall in the baseband chipset t= hat you can=92t disable or control.

 

I recommend dropping these recommendations and repla= cing them with text that recognizes the present reality that cellular hosts= are simply not expected ever to receive unsolicited inbound connection flo= ws from arbitrary remote Internet addresses. It would simplify the document and it would be a more honest ap= praisal of the situation.

 


--
james woodyatt <jhw@apple.com>
core os networking

 

--_000_45A697A8FFD7CF48BCF2BE7E106F06040B6D29BDxmbrcdx04ciscoc_-- From internet-drafts@ietf.org Sat Sep 14 09:54:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6021E81CC; Sat, 14 Sep 2013 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qddTRhgY2kEu; Sat, 14 Sep 2013 09:54:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2534521E81C9; Sat, 14 Sep 2013 09:54:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130914165400.30553.92313.idtracker@ietfa.amsl.com> Date: Sat, 14 Sep 2013 09:54:00 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 16:54:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-05.txt Pages : 19 Date : 2013-09-14 Abstract: As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Sep 15 01:59:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8D21E804B; Sun, 15 Sep 2013 01:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xREiQ9D1DCL4; Sun, 15 Sep 2013 01:59:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1866811E80FE; Sun, 15 Sep 2013 01:59:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130915085933.1563.56382.idtracker@ietfa.amsl.com> Date: Sun, 15 Sep 2013 01:59:33 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc3316bis-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 08:59:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 for 3GPP Cellular Hosts Author(s) : Jouni Korhonen Jari Arkko Teemu Savolainen Suresh Krishnan Filename : draft-ietf-v6ops-rfc3316bis-06.txt Pages : 19 Date : 2013-09-15 Abstract: As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-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 jouni.nospam@gmail.com Sun Sep 15 02:06:51 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66EB21E80B0 for ; Sun, 15 Sep 2013 02:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J30nItiDp0CY for ; Sun, 15 Sep 2013 02:06:50 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DDB9B21E804B for ; Sun, 15 Sep 2013 02:06:49 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so3255223lbh.5 for ; Sun, 15 Sep 2013 02:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to; bh=dNFBVhXrVN6yGtLapP0ZLOJWBy0hX2tVM1pCske5o/w=; b=NVV59KdgNtOVrNHkOXVGF0qW6k8s/AB0qldLbpn6O1sIuuS0OlYu1SqLIa28+x13H9 dT3jypBvq1vM8y9GUVPF8tNJtue05lGI1wuj3je+3coVq3ywYo8gUBxRJ6n1rur1dSVl HMJz4t0qu6sDqId2JEN1rEY7btjCs20016y1kecSd9HXRETyGSixP3ryxg3kVpn+1BRG p+K0Ljki0WIhqPDYU/7b8GZiLpgwPJQY3kF23jd6v9VeFQZCFcpGHj9f2nGkzHx0hRHI 3H7DKKRfhM/ODhKnZCg4JFv5XG+JVxsL/gk1SpHtETttPntwVEu21pbxFj2TSQG+4qqe aepw== X-Received: by 10.112.146.33 with SMTP id sz1mr19740754lbb.14.1379236007386; Sun, 15 Sep 2013 02:06:47 -0700 (PDT) Received: from [192.168.1.104] (81-197-26-216.elisa-mobile.fi. [81.197.26.216]) by mx.google.com with ESMTPSA id i3sm8572629laf.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 02:06:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen Date: Sun, 15 Sep 2013 12:06:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <540F232B-18AA-4222-A28E-B79EC3DA22B1@gmail.com> References: <20130915085934.1563.57043.idtracker@ietfa.amsl.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1508) Cc: "draft-ietf-v6ops-rfc3316bis@tools.ietf.org" Subject: [v6ops] Fwd: New Version Notification - draft-ietf-v6ops-rfc3316bis-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 09:06:51 -0000 Just to note that -05 includes IESG comments from Ted, Stephen and = Brian. And -06 removes old text from security considerations that was = accidentally left in when doing revision -05. - Jouni Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification - draft-ietf-v6ops-rfc3316bis-06.txt > Date: September 15, 2013 11:59:34 AM GMT+03:00 > Resent-To: jari.arkko@piuha.net, jouni.nospam@gmail.com, = suresh.krishnan@ericsson.com, teemu.savolainen@nokia.com > Resent-To: john_brzozowski@cable.comcast.com, fred.baker@cisco.com, > To: v6ops-chairs@tools.ietf.org, = draft-ietf-v6ops-rfc3316bis@tools.ietf.org, joelja@bogus.com >=20 >=20 > A new version (-06) has been submitted for = draft-ietf-v6ops-rfc3316bis: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc3316bis-06.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc3316bis-06 >=20 > 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. >=20 > IETF Secretariat. >=20 From fred@cisco.com Sun Sep 15 11:00:27 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804411E813B for ; Sun, 15 Sep 2013 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRMGcO3wSilt for ; Sun, 15 Sep 2013 11:00:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EB49E11E813A for ; Sun, 15 Sep 2013 11:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1379268018; x=1380477618; h=date:from:message-id:to:subject:cc; bh=LAnkH+UL44F1lPTYc34DtMmvZ3QfnhaC0LlzNGScmb0=; b=gXEuVPXrsYmLOOYACK8dKa2DaP1p2UTIMwtSLEaI3FCzLtJr2Amyaq1c eGv+zcr2KAtKWFV/9DjK/+i4Dwu3R7EPkHp2bKltzh6lOZFjvJKy4fN8m V98Lx6RdA0Gtcr6zELUZrn2uJzgocCsz84p6R5xutbo+8bydgRQ6O6xhY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoHADn1NVKrRDoJ/2dsb2JhbABbgwc4gzWraQGSHYEXFnSDJTw0iGMNuU6Pcx2DCIEAA4k4j3KQRYNE X-IronPort-AV: E=Sophos;i="4.90,910,1371081600"; d="scan'208";a="89395126" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 15 Sep 2013 18:00:11 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8FI0Af8028190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Sep 2013 18:00:10 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r8FI09qV026000; Sun, 15 Sep 2013 11:00:09 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r8FI09RB025998; Sun, 15 Sep 2013 11:00:09 -0700 (PDT) Date: Sun, 15 Sep 2013 11:00:09 -0700 (PDT) From: Fred Baker Message-Id: <201309151800.r8FI09RB025998@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 18:00:28 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From achatz@forthnetgroup.gr Sun Sep 15 13:20:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2236411E81C6 for ; Sun, 15 Sep 2013 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbukDHuMnZ4o for ; Sun, 15 Sep 2013 13:20:01 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4812611E81BE for ; Sun, 15 Sep 2013 13:20:01 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8FKJuvV007389 for ; Sun, 15 Sep 2013 23:19:56 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8FKJu7A008611 for ; Sun, 15 Sep 2013 23:19:56 +0300 Received: from [192.168.1.2] (194.219.240.252.dsl.dyn.forthnet.gr [194.219.240.252]) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8FKJos4022954; Sun, 15 Sep 2013 23:19:52 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; spf=pass Authentication-Results: MX-IN-05.forthnet.gr header.from=achatz@forthnetgroup.gr; sender-id=pass Message-ID: <52361667.2060201@forthnetgroup.gr> Date: Sun, 15 Sep 2013 23:19:51 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: v6ops@ietf.org References: <201309151800.r8FI09RB025998@irp-view13.cisco.com> In-Reply-To: <201309151800.r8FI09RB025998@irp-view13.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 20:20:07 -0000 Just a quick question... I don't see any reference of DNS servers under 3.1, only MTU & Prefix. Shouldn't there be a bullet showing that DNS info (UE address as DNS proxy, or original through-RA/DHCPv6 DNS servers) should also pass on the LAN link? -- Tassos Fred Baker wrote on 15/9/2013 21:00: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it now. If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tsavo.stds@gmail.com Sun Sep 15 23:14:25 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C9411E81C3 for ; Sun, 15 Sep 2013 23:14:25 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYSXRhVFx4bl for ; Sun, 15 Sep 2013 23:14:24 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9368811E8200 for ; Sun, 15 Sep 2013 23:14:23 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id z5so3948238lbh.28 for ; Sun, 15 Sep 2013 23:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:content-type; bh=z0cPDxqlgACrhavekduV07n/qbR1JevEnx53YCL8NZU=; b=T/1aXS1d7SPM/Tmspjg8sI4i9EuKo5M26xA0FpFqmNbBCo0wBysUQ0SHC0NyWPQRHg yLauekXT1Xv4zj8YVQjk4/N8X+2sJH1beoTgZ8Ht7Gp+2Z2Vu+cn/HhUIYihcQXHcXAV GNKolAO1jyyrY3xEurR+vssn+PibKXnOTMP4JQZN4/df0bPsRRrDqX6Woh4RGF42YxrZ H93OB/o8uYUXvUhbq+mUKQx7PgVjnT7iy1/yXS5kYKjsme/8tGEYaZ0ambgIziS6E77f sFwBMx7/p0HP9qcLTVxtgqgNB1Fc3ImnJa3lM0QhRcybfeGFSOdHmMiGiCisbfnIdCUE R7rw== X-Received: by 10.152.10.99 with SMTP id h3mr23851825lab.13.1379312061368; Sun, 15 Sep 2013 23:14:21 -0700 (PDT) Received: from [85.156.116.65] (85-156-116-65.elisa-mobile.fi. [85.156.116.65]) by mx.google.com with ESMTPSA id zw2sm12028818lbb.14.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 15 Sep 2013 23:14:20 -0700 (PDT) Message-ID: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> MIME-Version: 1.0 To: Tassos Chatzithomaoglou , "v6ops@ietf.org" From: Teemu Savolainen Date: Mon, 16 Sep 2013 09:12:35 +0300 Content-Type: multipart/alternative; boundary="_ACFF101A-23E8-4A61-826E-81356955DF4E_" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 06:14:25 -0000 --_ACFF101A-23E8-4A61-826E-81356955DF4E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" IMHO it is better to keep this draft focused solely on address sharing, and= not to go to other configuration topic or other possible problems. Btw most often, as of now, the "original" DNS server addresses are received= via link layer signaling (see http://www.ietf.org/id/draft-ietf-v6ops-rfc3= 316bis-06.txt section 2.10), and thus, for example, may need to be added to= "proxied" RA. Best regards, Teemu -----Original Message----- From: "Tassos Chatzithomaoglou" Sent: =E2=80=8E15.=E2=80=8E9.=E2=80=8E2013 23:20 To: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC Just a quick question... I don't see any reference of DNS servers under 3.1, only MTU & Prefix. Shouldn't there be a bullet showing that DNS info (UE address as DNS proxy,= or original through-RA/DHCPv6 DNS servers) should also pass on the LAN lin= k? -- Tassos Fred Baker wrote on 15/9/2013 21:00: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it now.= If you find nits > (spelling errors, minor suggested wording changes, etc), comment to the > authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_ACFF101A-23E8-4A61-826E-81356955DF4E_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
IMHO it is = better to keep this draft focused solely on address sharing, and not to go = to other configuration topic or other possible problems.

Btw most of= ten, as of now, the "original" DNS server addresses are received via link l= ayer signaling (see http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.t= xt section 2.10), and thus, for example, may need to be added to "proxied" = RA.

Best regards,

Teemu
From: Tassos Chatzithomaog= lou
Sent: =E2=80=8E15.=E2=80=8E9.=E2=80=8E2013 23:20
To: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
Just a quick question...

I don't see any reference of DNS se= rvers under 3.1, only MTU & Prefix.
Shouldn't there be a bullet show= ing that DNS info (UE address as DNS proxy, or original through-RA/DHCPv6 D= NS servers) should also pass on the LAN link?

--
Tassos

Fr= ed Baker wrote on 15/9/2013 21:00:
> This is to initiate a two week w= orking group last call of
> http://tools.ietf.org/html/draft-ietf-v6o= ps-64share.  Please read it now. If you find nits
> (spelling er= rors, minor suggested wording changes, etc), comment to the
> authors= ; if you find greater issues, such as disagreeing with a
> statement = or finding additional issues that need to be addressed,
> please post= your comments to the list.
>
> We are looking specifically for= comments on the importance of the
> document as well as its content.= If you have read the document and
> believe it to be of operational = utility, that is also an important
> comment to make.
> _______= ________________________________________
> v6ops mailing list
>= v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=

_______________________________________________
v6ops mailing li= st
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
= --_ACFF101A-23E8-4A61-826E-81356955DF4E_-- From achatz@forthnetgroup.gr Mon Sep 16 00:00:03 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3DA11E822A for ; Mon, 16 Sep 2013 00:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16Lm2jZjEE0T for ; Sun, 15 Sep 2013 23:59:57 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10811E821A for ; Sun, 15 Sep 2013 23:59:55 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8G6xrku018534; Mon, 16 Sep 2013 09:59:53 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8G6xraI001462; Mon, 16 Sep 2013 09:59:53 +0300 Received: from [192.168.1.2] (194.219.240.253.dsl.dyn.forthnet.gr [194.219.240.253]) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8G6xTC5021250; Mon, 16 Sep 2013 09:59:29 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; spf=pass Authentication-Results: MX-IN-04.forthnet.gr header.from=achatz@forthnetgroup.gr; sender-id=pass Message-ID: <5236AC4F.9040004@forthnetgroup.gr> Date: Mon, 16 Sep 2013 09:59:27 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Teemu Savolainen , "v6ops@ietf.org" References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> In-Reply-To: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 07:00:03 -0000 Teemu, MTU is already mentioned there. I mentioned DNS, becasue i consider Prefix and DNS the duo responsible fo= r basic internet connectivity, while MTU is something extra for even bett= er connectivity. If not explicitly defined, maybe the following statement needs to leave s= ome space for other data that are passed to the LAN link through the RAs.= > > The LAN link originated RA message carries a copy of the following > 3GPP radio link received RA message option fields: > > o MTU (if not provided by the 3GPP network, the UE will provide its= > 3GPP link MTU size) > o Prefix Information -- Tassos Teemu Savolainen wrote on 16/9/2013 09:12: > IMHO it is better to keep this draft focused solely on address sharing,= and not to go to other configuration topic or other possible problems. > > Btw most often, as of now, the "original" DNS server addresses are rece= ived via link layer signaling (see http://www.ietf.org/id/draft-ietf-v6op= s-rfc3316bis-06.txt section 2.10), and thus, for example, may need to be = added to "proxied" RA. > > Best regards, > > Teemu > -----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------- > From: Tassos Chatzithomaoglou > Sent: =E2=80=8E15.=E2=80=8E9.=E2=80=8E2013 23:20 > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC > > Just a quick question... > > I don't see any reference of DNS servers under 3.1, only MTU & Prefix. > Shouldn't there be a bullet showing that DNS info (UE address as DNS pr= oxy, or original through-RA/DHCPv6 DNS servers) should also pass on the L= AN link? > > -- > Tassos > > Fred Baker wrote on 15/9/2013 21:00: > > This is to initiate a two week working group last call of > > http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it = now. If you find nits > > (spelling errors, minor suggested wording changes, etc), comment to t= he > > authors; if you find greater issues, such as disagreeing with a > > statement or finding additional issues that need to be addressed, > > please post your comments to the list. > > > > We are looking specifically for comments on the importance of the > > document as well as its content. If you have read the document and > > believe it to be of operational utility, that is also an important > > comment to make. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ales.vizdal@t-mobile.cz Mon Sep 16 06:37:04 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3673111E824B for ; Mon, 16 Sep 2013 06:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BArcHqSlZ7-o for ; Mon, 16 Sep 2013 06:37:00 -0700 (PDT) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 250D811E823E for ; Mon, 16 Sep 2013 06:36:57 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by ctxmailhub.t-mobile.cz (Postfix) with ESMTP id BF9362E09B6 for ; Mon, 16 Sep 2013 15:36:56 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 16 Sep 2013 15:36:56 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Mon, 16 Sep 2013 15:36:50 +0200 Thread-Topic: [v6ops] draft-ietf-v6ops-64share WGLC Thread-Index: Ac6yPZXdYKJWLUpDQkSzf2jhbaTbdQAo30ag Message-ID: <1808340F7EC362469DDFFB112B37E2FCD2D007FC54@SRVHKE02.rdm.cz> References: <201309151800.r8FI09RB025998@irp-view13.cisco.com> In-Reply-To: <201309151800.r8FI09RB025998@irp-view13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 13:37:04 -0000 Hi Guys, I am planning on posting an update within a week addressing comments receiv= ed in Berlin such as rework the document a bit to make it more general and make scenario= s 1 & 2 as examples of how the sharing can be implemented. Fixing the security sect= ion as well as trying to address your comments raised in this wglc. Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Fred > Baker > Sent: Sunday, September 15, 2013 8:00 PM > To: v6ops@ietf.org > Subject: [v6ops] draft-ietf-v6ops-64share WGLC >=20 > This is to initiate a two week working group last call of http://tools.ie= tf.org/html/draft- > ietf-v6ops-64share. Please read it now. If you find nits (spelling error= s, minor > suggested wording changes, etc), comment to the authors; if you find grea= ter issues, > such as disagreeing with a statement or finding additional issues that ne= ed to be > addressed, please post your comments to the list. >=20 > We are looking specifically for comments on the importance of the documen= t as well as > its content. If you have read the document and believe it to be of operat= ional utility, > that is also an important comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From iesg-secretary@ietf.org Mon Sep 16 18:02:14 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D632111E8271; Mon, 16 Sep 2013 18:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9m-sNV7Ptsi8; Mon, 16 Sep 2013 18:02:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22111E828B; Mon, 16 Sep 2013 18:02:13 -0700 (PDT) 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: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917010213.6135.39914.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 18:02:13 -0700 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'IPv6 for 3GPP Cellular Hosts' to Informational RFC (draft-ietf-v6ops-rfc3316bis-06.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 01:02:15 -0000 The IESG has approved the following document: - 'IPv6 for 3GPP Cellular Hosts' (draft-ietf-v6ops-rfc3316bis-06.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3316bis/ Technical Summary As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (Hereafter collectively referred to as 3GPP networks). This document also lists out specific IPv6 functionalities that need to be implemented in addition what is already prescribed in the IPv6 Node Requirements document. It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. Working Group Summary IPv6 Operations contains a number of sub-communities, which include operators of various categories, vendors of various categories, academics, researchers, and others. This document, which is intended to replace RFC 3316, was primarily of interest to the vendors of mobile networking equipment, including handsets, cell equipment, and network back ends. It was also reviewed by the Mobile Network operators, including several of the authors of draft-ietf-v6ops-mobile-device-profile, which was developed at the same time. While there were comments and improvements made on the draft, it was not particularly controversial. Document Quality The document is a requirements document describing IPv6 capabilities required in mobile network devices. It is consistent with RFC 3316 an with the Node Requirements. Personnel The Document Shepherd is Fred Baker. The AD is Joel Jaeggli. From markzzzsmith@yahoo.com.au Wed Sep 18 14:59:16 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9937C11E8174 for ; Wed, 18 Sep 2013 14:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk4kTHBohHk6 for ; Wed, 18 Sep 2013 14:59:11 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id D907911E8263 for ; Wed, 18 Sep 2013 14:59:09 -0700 (PDT) Received: from [98.139.212.152] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2013 21:59:09 -0000 Received: from [98.139.212.241] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 18 Sep 2013 21:59:09 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 18 Sep 2013 21:59:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 269757.2130.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 63814 invoked by uid 60001); 18 Sep 2013 21:59:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1379541548; bh=wm8jEj+vpFb2w91rzwccCMtqOTBhHep4YNq1ByUT3Xw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B/hHa3vJf4BGIkJnCqGJ2wFgesiNv5e2Nzrtkau8dIE16aZ/cYKw+fzN+YLDs7Ckt9EQBLmiBgiWyToyNNpRQvJ/zTzIpXzlSCUJepMjYHZQxxJRIt0ZCE+rIaEEZsG4DO1VoxfwvZ8CH+OnFWlnqT1N6aChH/wR56C5xPwBS14= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MscS65Robq/80PTPmT0lHclhlHtl6uHsND8Ustl+hpfBJiNE0TdRZG0bjhHsL7QSwIBWCvh9NM9KW2NCaEUdPAPx4+bcE1k374t2rcvDvy/fHHnBQ3BBQuk9uWrCUlgYQyYS3IhcGA/hn3qR6Mj0k3MUg/eiZQBa1QRqu8UpLgY=; X-YMail-OSG: 0V.J6P4VM1l2Fb7Iifx8FkedOLqa77vt0.KVRn7K0jl26al mN40WyJi5Zn5jBrC2Ti30rN_k5Qjl_2bua5dhxs0s.R5oyLWkWOXK3tBcQ79 OhErmDwJin4X065QZzYUeh.3ms18bDjuBUuGoUILEnDEhrjlz5g1QTdLB8VR ZSf5ghepwtnPp2qr.zm5Ey9N6NqAEuWeGKmHRyp4gkOVjVU0GDnP_xAv9Gnf ijJEm34fNyb07hV7gKMtjegfXNXdo.sVO6HD41bBp9SuJqgGgog2aZiZybTh yQEjcMqccu2t1wjrJJZAVcWe0VxytWmgEXvFz1GSb1SB3pa2wkF0xyPO3hQd _dJKY3jdYHaRpOg0QMbCUj2ffy1A4G8dL1_q0vd9WKUrlUzFf3jBixgdAS3z cS_L32zn8zPgKtZQMga7NMzmGiVAGG1zygE5baMFP6xwMq4ssW5RiqZpeL9C DOvPqI7B1n8Py8JEYv8TcHAB4BIq9U6SlUilwVj0y0DoTsis02LoaoWdpkok Azw4FKMHjR5IdsrxMW1Rs2GmTo18vn50VurFltAYZ_P52EvjC_Zti7BU3zSS _NCGCFWaJnwH6ld2Pq0kkBCivJr3QWjjPk4a8IAAi_Xj9 Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Wed, 18 Sep 2013 14:59:08 PDT X-Rocket-MIMEInfo: 002.001, KzEKClRoaXMgcHVycG9zZSBoZXJlIGlzIHRvIGRlc2NyaWJlIGEgd29yayBhcm91bmQgdG8gYSBsaW1pdGF0aW9uLCBub3QgdG8gc3BlY2lmeSBob3cgUkFzL0RIQ1B2NiBhcmUgc3VwcG9zZWQgdG8gYmUgZ2VuZXJhbGx5IHVzZWQgYW5kIHdoYXQgb3B0aW9ucyBhcmUgcHJlc2VudCBpbiB0aGVtLiBJIGRvbid0IHRoaW5rIFJBIG9yIERIQ1B2NiBvcHRpb25zIHRoYXQgYXJlbid0IGVzc2VudGlhbCBvciB1c2VmdWwgdG8gdGhpcyAqc3BlY2lmaWMqIHNjZW5hcmlvIHNob3VsZCBiZSBtZW50aW9uZWQgYXQgYWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> Message-ID: <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Wed, 18 Sep 2013 14:59:08 -0700 (PDT) From: Mark ZZZ Smith To: Teemu Savolainen , Tassos Chatzithomaoglou , "v6ops@ietf.org" In-Reply-To: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:59:16 -0000 +1=0A=0AThis purpose here is to describe a work around to a limitation, not= to specify how RAs/DHCPv6 are supposed to be generally used and what optio= ns are present in them. I don't think RA or DHCPv6 options that aren't esse= ntial or useful to this *specific* scenario should be mentioned at all. DNS= in RAs is not special to or necessary to sharing a /64.=0A=0AGenerally rel= ated to DHCPv6 option passing across a CE device (of which this would be on= e), I posted the following draft a while ago. I'd be interested in comments= .=0A=0A"IPv6 CE Device DHCPv6 Option Transparency"=0A=0Ahttp://tools.ietf.o= rg/html/draft-smith-v6ops-ce-dhcpv6-transparency-00=0A=0A=0A=0A=0A=0A>_____= ___________________________=0A> From: Teemu Savolainen =0A>To: Tassos Chatzithomaoglou ; "v6ops@ietf.or= g" =0A>Sent: Monday, 16 September 2013 4:12 PM=0A>Subject:= Re: [v6ops] draft-ietf-v6ops-64share WGLC=0A> =0A>=0A>=0A>IMHO it is bette= r to keep this draft focused solely on address sharing, and not to go to ot= her configuration topic or other possible problems.=0A>=0A>Btw most often, = as of now, the "original" DNS server addresses are received via link layer = signaling (see http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.txt se= ction 2.10), and thus, for example, may need to be added to "proxied" RA.= =0A>=0A>Best regards,=0A>=0A>Teemu=0A>=0A>________________________________= =0A> From: Tassos Chatzithomaoglou=0A>Sent: =E2=80=8E15.=E2=80=8E9.=E2=80= =8E2013 23:20=0A>To: v6ops@ietf.org=0A>Subject: Re: [v6ops] draft-ietf-v6op= s-64share WGLC=0A>=0A>Just a quick question...=0A>=0A>I don't see any refer= ence of DNS servers under 3.1, only MTU & Prefix.=0A>Shouldn't there be a b= ullet showing that DNS info (UE address as DNS proxy, or original through-R= A/DHCPv6 DNS servers) should also pass on the LAN link?=0A>=0A>--=0A>Tassos= =0A>=0A>Fred Baker wrote on 15/9/2013 21:00:=0A>> This is to initiate a two= week working group last call of=0A>> http://tools.ietf.org/html/draft-ietf= -v6ops-64share.=C2=A0 Please read it now. If you find nits=0A>> (spelling e= rrors, minor suggested wording changes, etc), comment to the=0A>> authors; = if you find greater issues, such as disagreeing with a=0A>> statement or fi= nding additional issues that need to be addressed,=0A>> please post your co= mments to the list.=0A>>=0A>> We are looking specifically for comments on t= he importance of the=0A>> document as well as its content. If you have read= the document and=0A>> believe it to be of operational utility, that is als= o an important=0A>> comment to make.=0A>> _________________________________= ______________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www= .ietf.org/mailman/listinfo/v6ops=0A>>=0A>=0A>______________________________= _________________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ie= tf.org/mailman/listinfo/v6ops=0A>=0A>______________________________________= _________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/m= ailman/listinfo/v6ops=0A>=0A>=0A> From holger.metschulat@telekom.de Thu Sep 19 11:41:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCF621F9323 for ; Thu, 19 Sep 2013 11:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B58n2DKOGzff for ; Thu, 19 Sep 2013 11:41:03 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 927A221F92B9 for ; Thu, 19 Sep 2013 11:41:02 -0700 (PDT) From: Received: from he111511.emea1.cds.t-internal.com ([10.206.92.114]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 19 Sep 2013 20:40:58 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111511.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 19 Sep 2013 20:40:58 +0200 To: Date: Thu, 19 Sep 2013 20:40:57 +0200 Thread-Topic: [v6ops] draft-ietf-v6ops-64share WGLC Thread-Index: Ac60unOILwsoBAubTJKnKDGn4gssvwAofRhw Message-ID: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 18:41:07 -0000 Hello all, I believe this needs to be looked at. DNS server addresses are sent from th= e network to the mobile host ("CE" in this scenario) by outband 3GPP signal= ling and need to be queried by the CE OS driver from the radio chip. In order to convey the DNS information to the clients attached via the LAN,= the CE performing 64share needs to handle the DHCP solicits and answer on = the network's behalf because simply forwarding the DHCP solicits will not w= ork at all (the network won't answer them). Holger -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Mark ZZZ Smith Gesendet: Mittwoch, 18. September 2013 23:59 An: Teemu Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC +1 This purpose here is to describe a work around to a limitation, not to spec= ify how RAs/DHCPv6 are supposed to be generally used and what options are p= resent in them. I don't think RA or DHCPv6 options that aren't essential or= useful to this *specific* scenario should be mentioned at all. DNS in RAs = is not special to or necessary to sharing a /64. Generally related to DHCPv6 option passing across a CE device (of which thi= s would be one), I posted the following draft a while ago. I'd be intereste= d in comments. "IPv6 CE Device DHCPv6 Option Transparency" http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 >________________________________ > From: Teemu Savolainen >To: Tassos Chatzithomaoglou ; "v6ops@ietf.org"=20 > >Sent: Monday, 16 September 2013 4:12 PM >Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC >=20 > > >IMHO it is better to keep this draft focused solely on address sharing, an= d not to go to other configuration topic or other possible problems. > >Btw most often, as of now, the "original" DNS server addresses are receive= d via link layer signaling (see http://www.ietf.org/id/draft-ietf-v6ops-rfc= 3316bis-06.txt section 2.10), and thus, for example, may need to be added t= o "proxied" RA. > >Best regards, > >Teemu > >________________________________ > From: Tassos Chatzithomaoglou >Sent: =FD15.=FD9.=FD2013 23:20 >To: v6ops@ietf.org >Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC > >Just a quick question... > >I don't see any reference of DNS servers under 3.1, only MTU & Prefix. >Shouldn't there be a bullet showing that DNS info (UE address as DNS proxy= , or original through-RA/DHCPv6 DNS servers) should also pass on the LAN li= nk? > >-- >Tassos > >Fred Baker wrote on 15/9/2013 21:00: >> This is to initiate a two week working group last call of=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-64share.=A0 Please read it=20 >> now. If you find nits (spelling errors, minor suggested wording=20 >> changes, etc), comment to the authors; if you find greater issues,=20 >> such as disagreeing with a statement or finding additional issues=20 >> that need to be addressed, please post your comments to the list. >> >> We are looking specifically for comments on the importance of the=20 >> document as well as its content. If you have read the document and=20 >> believe it to be of operational utility, that is also an important=20 >> comment to make. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Thu Sep 19 12:18:00 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66721F9635 for ; Thu, 19 Sep 2013 12:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb5X5AjebocH for ; Thu, 19 Sep 2013 12:17:59 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BA94321F93BF for ; Thu, 19 Sep 2013 12:17:58 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id m15so7456517wgh.5 for ; Thu, 19 Sep 2013 12:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tUXdMi4ejFpXidpRDZ4VmROnN910C0hu/BK8b0vEhTw=; b=wUb0U6Jvs4V00k32njy3LGkb3TzDRegDeogKWMEMz6574BlrBBa3d87RWoIcGV6zlv zYwAn6YUF+GYzpbfO9OBgWbirr+k1/sdgVCSHSQdSYGTKxtYKoZMu5ilUl9R3H8EJzai OJYbDM0N4YCLohaVUD6aIYLkJnHJE0jrzTyzXgnczFlnQnBV9SXR1Go9p07T8aYHrtnI S4MvsuyWKy0qqmjzGN+pL5JepU2gFHkRJUyR87mlGhKzfZ3u/kNMU3v/jJ73j4I9xfBc XrTo7mSv1yHdDVF/aY0ta7WvdmLGwzkV6Vo7kz8DYevuJVBl2QgrKsdxeC5o3qPZ/Tdk 30rw== MIME-Version: 1.0 X-Received: by 10.180.20.163 with SMTP id o3mr275730wie.1.1379618277802; Thu, 19 Sep 2013 12:17:57 -0700 (PDT) Received: by 10.217.114.137 with HTTP; Thu, 19 Sep 2013 12:17:57 -0700 (PDT) In-Reply-To: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 19 Sep 2013 12:17:57 -0700 Message-ID: From: "cb.list6" To: Holger Metschulat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 19:18:00 -0000 On Thu, Sep 19, 2013 at 11:40 AM, wrote: > Hello all, > > I believe this needs to be looked at. DNS server addresses are sent from = the network to the mobile host ("CE" in this scenario) by outband 3GPP sign= alling and need to be queried by the CE OS driver from the radio chip. > > In order to convey the DNS information to the clients attached via the LA= N, the CE performing 64share needs to handle the DHCP solicits and answer o= n the network's behalf because simply forwarding the DHCP solicits will not= work at all (the network won't answer them). > I agree that is required for a functioning product, but this is not a product specification it is a connectivity sharing method only with a very narrow scope and hopefully narrow window of use if and when DHCP-PD comes to mobile. If you would like to specify that behavior, it would be best to reference this I-D as the connectivity model for WAN and RFC 6204 for a product LAN or just reference that the product MUST support this I-D as well as the relevant DHCPv6 and/or RDNSS CB > Holger > > -----Urspr=FCngliche Nachricht----- > Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag vo= n Mark ZZZ Smith > Gesendet: Mittwoch, 18. September 2013 23:59 > An: Teemu Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org > Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC > > +1 > > This purpose here is to describe a work around to a limitation, not to sp= ecify how RAs/DHCPv6 are supposed to be generally used and what options are= present in them. I don't think RA or DHCPv6 options that aren't essential = or useful to this *specific* scenario should be mentioned at all. DNS in RA= s is not special to or necessary to sharing a /64. > > Generally related to DHCPv6 option passing across a CE device (of which t= his would be one), I posted the following draft a while ago. I'd be interes= ted in comments. > > "IPv6 CE Device DHCPv6 Option Transparency" > > http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 > > > > > >>________________________________ >> From: Teemu Savolainen >>To: Tassos Chatzithomaoglou ; "v6ops@ietf.org" >> >>Sent: Monday, 16 September 2013 4:12 PM >>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC >> >> >> >>IMHO it is better to keep this draft focused solely on address sharing, a= nd not to go to other configuration topic or other possible problems. >> >>Btw most often, as of now, the "original" DNS server addresses are receiv= ed via link layer signaling (see http://www.ietf.org/id/draft-ietf-v6ops-rf= c3316bis-06.txt section 2.10), and thus, for example, may need to be added = to "proxied" RA. >> >>Best regards, >> >>Teemu >> >>________________________________ >> From: Tassos Chatzithomaoglou >>Sent: 15.9.2013 23:20 >>To: v6ops@ietf.org >>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC >> >>Just a quick question... >> >>I don't see any reference of DNS servers under 3.1, only MTU & Prefix. >>Shouldn't there be a bullet showing that DNS info (UE address as DNS prox= y, or original through-RA/DHCPv6 DNS servers) should also pass on the LAN l= ink? >> >>-- >>Tassos >> >>Fred Baker wrote on 15/9/2013 21:00: >>> This is to initiate a two week working group last call of >>> http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it >>> now. If you find nits (spelling errors, minor suggested wording >>> changes, etc), comment to the authors; if you find greater issues, >>> such as disagreeing with a statement or finding additional issues >>> that need to be addressed, please post your comments to the list. >>> >>> We are looking specifically for comments on the importance of the >>> document as well as its content. If you have read the document and >>> believe it to be of operational utility, that is also an important >>> comment to make. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From tsavo.stds@gmail.com Thu Sep 19 13:40:30 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F8C21F893E for ; Thu, 19 Sep 2013 13:40:30 -0700 (PDT) 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=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzmvMFeVZrq7 for ; Thu, 19 Sep 2013 13:40:29 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E839F21F88FB for ; Thu, 19 Sep 2013 13:40:28 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jy13so7159133veb.5 for ; Thu, 19 Sep 2013 13:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZCL95t0Za+0U7Sr+autaDPD79Tk2dKuE8q2iWCfSoKg=; b=MhB05lF1rvJj876XP4WhFZAwLo2+Ems/raX5gl7ozC0wgYSSy77kwY9kYsfHgLmT+0 XLZ1oDRpQmQ1wJd0VZ9L4kfzhk86cPgqb+yBKiOmVEU3Kg25Uw8IxQ+0gTC1lTf+WXjW Q6IUAeDKxpKKF2U7uGzJmLf5mZ4eGU6j9Npr9asVyrQqtEUUEAJDIHPEQ4W5Nbjz5XS1 aQG+7pePcRpUAi9Ftx4FFXByREBAg7jECdW5AxQpmOO6djIWgBWns/T1w5WoeEJ1plVY SXueQrGbeu/Z9WRlRGblxXHzEWOMq37MNJCw7259oVhc8y5+uV6pqne/qY81cKp4qEA+ WcyQ== MIME-Version: 1.0 X-Received: by 10.58.137.167 with SMTP id qj7mr2652903veb.1.1379623217749; Thu, 19 Sep 2013 13:40:17 -0700 (PDT) Received: by 10.52.166.72 with HTTP; Thu, 19 Sep 2013 13:40:17 -0700 (PDT) Received: by 10.52.166.72 with HTTP; Thu, 19 Sep 2013 13:40:17 -0700 (PDT) In-Reply-To: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Thu, 19 Sep 2013 23:40:17 +0300 Message-ID: From: Teemu Savolainen To: holger.metschulat@telekom.de Content-Type: multipart/alternative; boundary=047d7b677efad163bc04e6c28f39 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:40:30 -0000 --047d7b677efad163bc04e6c28f39 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The DNS handling might suite for draft-ietf-v6ops-mobile-device-profile Section 4, but in my opinion not to this document as it is not within the narrow scope. Secondly, I don't agree DHCP server support is required, as the CE can include the DNS addresses in RAs as specified in RFC6106. Best regards, Teemu On Sep 19, 2013 9:41 PM, wrote: > Hello all, > > I believe this needs to be looked at. DNS server addresses are sent from > the network to the mobile host ("CE" in this scenario) by outband 3GPP > signalling and need to be queried by the CE OS driver from the radio chip= . > > In order to convey the DNS information to the clients attached via the > LAN, the CE performing 64share needs to handle the DHCP solicits and answ= er > on the network's behalf because simply forwarding the DHCP solicits will > not work at all (the network won't answer them). > > Holger > > -----Urspr=FCngliche Nachricht----- > Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag > von Mark ZZZ Smith > Gesendet: Mittwoch, 18. September 2013 23:59 > An: Teemu Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org > Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC > > +1 > > This purpose here is to describe a work around to a limitation, not to > specify how RAs/DHCPv6 are supposed to be generally used and what options > are present in them. I don't think RA or DHCPv6 options that aren't > essential or useful to this *specific* scenario should be mentioned at al= l. > DNS in RAs is not special to or necessary to sharing a /64. > > Generally related to DHCPv6 option passing across a CE device (of which > this would be one), I posted the following draft a while ago. I'd be > interested in comments. > > "IPv6 CE Device DHCPv6 Option Transparency" > > http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 > > > > > > >________________________________ > > From: Teemu Savolainen > >To: Tassos Chatzithomaoglou ; "v6ops@ietf.org" > > > >Sent: Monday, 16 September 2013 4:12 PM > >Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC > > > > > > > >IMHO it is better to keep this draft focused solely on address sharing, > and not to go to other configuration topic or other possible problems. > > > >Btw most often, as of now, the "original" DNS server addresses are > received via link layer signaling (see > http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.txt section 2.10), > and thus, for example, may need to be added to "proxied" RA. > > > >Best regards, > > > >Teemu > > > >________________________________ > > From: Tassos Chatzithomaoglou > >Sent: 15.9.2013 23:20 > >To: v6ops@ietf.org > >Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC > > > >Just a quick question... > > > >I don't see any reference of DNS servers under 3.1, only MTU & Prefix. > >Shouldn't there be a bullet showing that DNS info (UE address as DNS > proxy, or original through-RA/DHCPv6 DNS servers) should also pass on the > LAN link? > > > >-- > >Tassos > > > >Fred Baker wrote on 15/9/2013 21:00: > >> This is to initiate a two week working group last call of > >> http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it > >> now. If you find nits (spelling errors, minor suggested wording > >> changes, etc), comment to the authors; if you find greater issues, > >> such as disagreeing with a statement or finding additional issues > >> that need to be addressed, please post your comments to the list. > >> > >> We are looking specifically for comments on the importance of the > >> document as well as its content. If you have read the document and > >> believe it to be of operational utility, that is also an important > >> comment to make. > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b677efad163bc04e6c28f39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The DNS handling might suite for draft-ietf-v6ops-mobile-dev= ice-profile Section 4, but in my opinion not to this document as it is not = within the narrow scope.

Secondly, I don't agree DHCP server support is required,= as the CE can include the DNS addresses in RAs as specified in RFC6106.

Best regards,

Teemu

On Sep 19, 2013 9:41 PM, <holger.metschulat@telekom.de> wrote:
Hello all,

I believe this needs to be looked at. DNS server addresses are sent from th= e network to the mobile host ("CE" in this scenario) by outband 3= GPP signalling and need to be queried by the CE OS driver from the radio ch= ip.

In order to convey the DNS information to the clients attached via the LAN,= the CE performing 64share needs to handle the DHCP solicits and answer on = the network's behalf because simply forwarding the DHCP solicits will n= ot work at all (the network won't answer them).

Holger

-----Urspr=FCngliche Nachricht-----
Von: v6ops-bounces@ietf.org [= mailto:v6ops-bounces@ietf.org= ] Im Auftrag von Mark ZZZ Smith
Gesendet: Mittwoch, 18. September 2013 23:59
An: Teemu Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org
Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC

+1

This purpose here is to describe a work around to a limitation, not to spec= ify how RAs/DHCPv6 are supposed to be generally used and what options are p= resent in them. I don't think RA or DHCPv6 options that aren't esse= ntial or useful to this *specific* scenario should be mentioned at all. DNS= in RAs is not special to or necessary to sharing a /64.

Generally related to DHCPv6 option passing across a CE device (of which thi= s would be one), I posted the following draft a while ago. I'd be inter= ested in comments.

"IPv6 CE Device DHCPv6 Option Transparency"

http://tools.ietf.org/html/draft-smith-v6ops-ce-d= hcpv6-transparency-00





>________________________________
> From: Teemu Savolainen <tsa= vo.stds@gmail.com>
>To: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>; "v6ops@ietf.org"
><v6ops@ietf.org>
>Sent: Monday, 16 September 2013 4:12 PM
>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>
>
>
>IMHO it is better to keep this draft focused solely on address sharing,= and not to go to other configuration topic or other possible problems.
>
>Btw most often, as of now, the "original" DNS server addresse= s are received via link layer signaling (see http://www.ietf.o= rg/id/draft-ietf-v6ops-rfc3316bis-06.txt section 2.10), and thus, for e= xample, may need to be added to "proxied" RA.
>
>Best regards,
>
>Teemu
>
>________________________________
> From: Tassos Chatzithomaoglou
>Sent: 15.9.2013 23:20
>To: v6ops@ietf.org
>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
>
>Just a quick question...
>
>I don't see any reference of DNS servers under 3.1, only MTU & = Prefix.
>Shouldn't there be a bullet showing that DNS info (UE address as DN= S proxy, or original through-RA/DHCPv6 DNS servers) should also pass on the= LAN link?
>
>--
>Tassos
>
>Fred Baker wrote on 15/9/2013 21:00:
>> This is to initiate a two week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-64share.=A0= Please read it
>> now. If you find nits (spelling errors, minor suggested wording >> changes, etc), comment to the authors; if you find greater issues,=
>> such as disagreeing with a statement or finding additional issues<= br> >> that need to be addressed, please post your comments to the list.<= br> >>
>> We are looking specifically for comments on the importance of the<= br> >> document as well as its content. If you have read the document and=
>> believe it to be of operational utility, that is also an important=
>> comment to make.
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--047d7b677efad163bc04e6c28f39-- From markzzzsmith@yahoo.com.au Thu Sep 19 13:51:38 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0A621F84E0 for ; Thu, 19 Sep 2013 13:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0C3Xu2Y4P4Q for ; Thu, 19 Sep 2013 13:51:33 -0700 (PDT) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0421F84D9 for ; Thu, 19 Sep 2013 13:51:33 -0700 (PDT) Received: from [66.196.81.173] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2013 20:51:32 -0000 Received: from [98.139.212.225] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2013 20:51:32 -0000 Received: from [127.0.0.1] by omp1034.mail.bf1.yahoo.com with NNFMP; 19 Sep 2013 20:51:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 748954.61477.bm@omp1034.mail.bf1.yahoo.com Received: (qmail 14697 invoked by uid 60001); 19 Sep 2013 20:51:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1379623892; bh=idV6rVpE+Gvdz0qPrvk41txDOpDxFfTY+r0HaodbD/k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SJ3rYdiLLGMRSFFwzcg0BkQe1AMK+pwekLI4nVlRHDs7twi3toRRrcJ7zKLXChkvo2ys1wc+8FlGDJwWlJsbFp3InANh/UZYWhLTiZ+kVubwrcONC1cYGkDczrWcNCPf8gS0XUnrW0Zf9Nm4Ll3WOyrimmENktXIk/W6yvkmyHg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=AFESpuQtMC1ORFKD7xR8U6mnUwjkaRJAWkvaWIdiW9zj3F3eXctVItIidUYlCQc1quBlEy+lT+C0lygqpTiCU4GXzcLGV5M2e7BL60x6xm5PuTYFdm/iyV7ph/6iqRpajylvev/vQM38ozDOVZ7mj6veqdECRC3e9iLGMPmXGCQ=; X-YMail-OSG: xu94YWgVM1mha_iqTKtZEHim2kZ9Qz0Li2p0yXEMcG7WVsq dk46FvVfwq7P4Gnp9cUjiF0jOII5c8fiHQERZEqYA2CY.K44R0rYDnRqxQ1d mKiKvTgHSpl_at8YIybTA0eQrGcKZHH64Zg32UQcenkuitA3bl1yjqpvzHqE IrGW1WMFDw3vt_7ERZvbD2QUmgEhlyknwlH9SCXzRlOeuL6E6.K9OU19iHqk 6cEHB3vkzGNU24j17IlEgjrMN7oEY_c3M2q9Wp3L7gMtQ3K0Dzn2hsjEsyMH xVPDSLQo9Ut77nOATSc59U90zud.X0ALtEE1MvX4GNWObM7D3qqox57YdV6X HC2HW4HhympucV.8KSOnBvRsJTz3WUN1qtiCSiTSnuBubX0lQ9WEZWlmQYI2 dUGVGxIXqCHU_2Gyhq3sZiDhPzk98KVQiKetBOJx7v09DXBfMMDBm7HzLT7Z PtArs2.KrOjPEy.8RyoZrgRtoVz.YZ1MRug2JK0ksrYZZAtpfB3PinIa8L6g FGY9hZvX6liblRiDJLXTm7RfS4aCC6DxoDqBouqIw.oJ_f9Y3n.Ycm4CWr3a 9xqtxPFnRU_wcpkCd1MwExySI1DjVp1tl32XcZrjbZfY- Received: from [150.101.221.237] by web142502.mail.bf1.yahoo.com via HTTP; Thu, 19 Sep 2013 13:51:32 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiAiaG9sZ2VyLm1ldHNjaHVsYXRAdGVsZWtvbS5kZSIgPGhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGU.Cj4gVG86IHY2b3BzQGlldGYub3JnCj4gQ2M6IAo.IFNlbnQ6IEZyaWRheSwgMjAgU2VwdGVtYmVyIDIwMTMgNDo0MCBBTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtNjRzaGFyZSBXR0xDCj4gCj4gSGVsbG8gYWxsLAo.IAo.IEkgYmVsaWV2ZSB0aGlzIG5lZWRzIHRvIGJlIGxvb2tlZCBhdC4gRE5TIHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1379623892.14059.YahooMailNeo@web142502.mail.bf1.yahoo.com> Date: Thu, 19 Sep 2013 13:51:32 -0700 (PDT) From: Mark ZZZ Smith To: "holger.metschulat@telekom.de" , "v6ops@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:51:38 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "holger.metschulat@telek= om.de" =0A> To: v6ops@ietf.org=0A> Cc: =0A> S= ent: Friday, 20 September 2013 4:40 AM=0A> Subject: Re: [v6ops] draft-ietf-= v6ops-64share WGLC=0A> =0A> Hello all,=0A> =0A> I believe this needs to be = looked at. DNS server addresses are sent from the =0A> network to the mobil= e host ("CE" in this scenario) by outband 3GPP =0A> signalling and need to = be queried by the CE OS driver from the radio chip.=0A> =0A> In order to co= nvey the DNS information to the clients attached via the LAN, the =0A> CE p= erforming 64share needs to handle the DHCP solicits and answer on the =0A> = network's behalf because simply forwarding the DHCP solicits will not work = =0A> at all (the network won't answer them).=0A>=C2=A0=0A=0Aoff-topic for 6= 4share, but perhaps briefly worth discussing as these devices are another e= xample of the issues I identified in the draft.=0A=0A=0AThat's pretty much = one of the fundamental problems of embedding application layer configuratio= n parameters in a layer 2 protocol. This was also the mistake made with IPv= 4 IPCP in PPP, and fixed in IPv6 by using DHCPv6 over PPP, than using IPV6C= P for parameters "in" PPP.=0A=0AWhile DNS is the most common application pa= rameter, I don't think it is a good idea to assume it is the only useful pa= rameter that could be conveyed to a host. Perhaps people don't think there = is anything useful outside of DNS because that's basically all IPv4 PPP cou= ld convey (other than Microsoft Netbios Name Server settings). In other wor= ds, a past constraint has limited people's perception of what is or could b= e useful.=0A=0AThe DHCPv6 options I think of as examples of useful paramete= rs that can't be conveyed to hosts in either the RFC6204 or it seems implem= entation models such as this are the geolocation DHCPv6 options. It might b= e useful for a client to be told by the network operator it's geolocation i= nformation, but that isn't possible with e.g., RFC6204, even though there a= re DHCPv6 options that can convey that information. The argument could be t= o add those options into the specs, but that is just leaving the constraint= in place, and creating extra work in the future when other useful options = may be defined.=0A=0AMy fundamental goal is to see the end of ISP settings = configuration pages, for customers to cut-and-paste settings from. I think = it is quite ridiculous that we've solved so many other problems, yet persis= t with customers (or their technical relatives) having to type in their ema= il server address or sip server address etc. into their devices. It's quite= un-user friendly, and a problem that should be easy to solve, considering = the much harder ones that have been.=0A=0ARegards,=0AMark.=0A=0A=0A=0A> Hol= ger=0A> =0A> -----Urspr=C3=BCngliche Nachricht-----=0A> Von: v6ops-bounces@= ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von Mark =0A> ZZZ Smith= =0A> Gesendet: Mittwoch, 18. September 2013 23:59=0A> An: Teemu Savolainen;= Tassos Chatzithomaoglou; v6ops@ietf.org=0A> Betreff: Re: [v6ops] draft-iet= f-v6ops-64share WGLC=0A> =0A> +1=0A> =0A> This purpose here is to describe = a work around to a limitation, not to specify =0A> how RAs/DHCPv6 are suppo= sed to be generally used and what options are present in =0A> them. I don't= think RA or DHCPv6 options that aren't essential or useful =0A> to this *s= pecific* scenario should be mentioned at all. DNS in RAs is not =0A> specia= l to or necessary to sharing a /64.=0A> =0A> Generally related to DHCPv6 op= tion passing across a CE device (of which this =0A> would be one), I posted= the following draft a while ago. I'd be interested =0A> in comments.=0A> = =0A> "IPv6 CE Device DHCPv6 Option Transparency"=0A> =0A> http://tools.ietf= .org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00=0A> =0A> =0A> =0A> = =0A> =0A>> ________________________________=0A>> From: Teemu Savolainen =0A>> To: Tassos Chatzithomaoglou ; =0A> "v6ops@ietf.org" =0A>> =0A>> Sent: Monday, 16 Se= ptember 2013 4:12 PM=0A>> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGL= C=0A>> =0A>> =0A>> =0A>> IMHO it is better to keep this draft focused solel= y on address sharing, and =0A> not to go to other configuration topic or ot= her possible problems.=0A>> =0A>> Btw most often, as of now, the "original"= DNS server addresses are =0A> received via link layer signaling (see =0A> = http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.txt section 2.10), an= d =0A> thus, for example, may need to be added to "proxied" RA.=0A>> =0A>> = Best regards,=0A>> =0A>> Teemu=0A>> =0A>> ________________________________= =0A>> From: Tassos Chatzithomaoglou=0A>> Sent: =E2=80=8E15.=E2=80=8E9.=E2= =80=8E2013 23:20=0A>> To: v6ops@ietf.org=0A>> Subject: Re: [v6ops] draft-ie= tf-v6ops-64share WGLC=0A>> =0A>> Just a quick question...=0A>> =0A>> I don'= t see any reference of DNS servers under 3.1, only MTU & =0A> Prefix.=0A>> = Shouldn't there be a bullet showing that DNS info (UE address as DNS =0A> p= roxy, or original through-RA/DHCPv6 DNS servers) should also pass on the LA= N =0A> link?=0A>> =0A>> --=0A>> Tassos=0A>> =0A>> Fred Baker wrote on 15/9/= 2013 21:00:=0A>>> This is to initiate a two week working group last call o= f =0A>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share.=C2=A0 Please= read it =0A>>> now. If you find nits (spelling errors, minor suggested wo= rding =0A>>> changes, etc), comment to the authors; if you find greater is= sues, =0A>>> such as disagreeing with a statement or finding additional is= sues =0A>>> that need to be addressed, please post your comments to the li= st.=0A>>> =0A>>> We are looking specifically for comments on the importanc= e of the =0A>>> document as well as its content. If you have read the docu= ment and =0A>>> believe it to be of operational utility, that is also an i= mportant =0A>>> comment to make.=0A>>> __________________________________= _____________=0A>>> v6ops mailing list=0A>>> v6ops@ietf.org=0A>>> https:= //www.ietf.org/mailman/listinfo/v6ops=0A>>> =0A>> =0A>> ___________________= ____________________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A>> _________________= ______________________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org= =0A>> https://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A>> =0A>> =0A> ___= ____________________________________________=0A> v6ops mailing list=0A> v6o= ps@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> ___________= ____________________________________=0A> v6ops mailing list=0A> v6ops@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/v6ops=0A> From markzzzsmith@yahoo.com.au Thu Sep 19 13:54:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA22A21F85E8 for ; Thu, 19 Sep 2013 13:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPB-W6644ze5 for ; Thu, 19 Sep 2013 13:54:55 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with ESMTP id A542A21F8640 for ; Thu, 19 Sep 2013 13:54:54 -0700 (PDT) Received: from [66.196.81.173] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2013 20:54:54 -0000 Received: from [98.139.212.212] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 19 Sep 2013 20:54:54 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 19 Sep 2013 20:54:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 44275.8751.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 66840 invoked by uid 60001); 19 Sep 2013 20:54:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1379624093; bh=a2EmmeUYWXoXnZwUkM9D0QKkfvPk0CUKae4ScRYeyiM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DSb3Vm6iD57NnDIka1ka/VbS+c6usj1vZXzMp0uNp+2XKftnKoV/tVbVZhMOBvMRZD/JO8PyTV+NF5f55INdP8qJGKtlhX8o8X0p7QaR0sMdsxzVG5o5g4hMCHLU2MSfwJ/uYnDM6m5HTH1DS9ZkrENjob6zsTmPvj1gkYIQTKs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1Rr/C2TMBzPvSj8uZ/pkmrxH2GDLj3VI9l2YjAG9DG6WmtpZtD4tD+opRfvipb9AmAABZv6X+4H8UMygbJkK8sSYUNjUJFIAVID5i7YpkPQJuXa7Sd247GEQs3NbAZWDPw57ZFxIs1NiCifU/dV+rL3yQGhGdSp2ORHKMawNUfQ=; X-YMail-OSG: FjI.5_EVM1kmAdjeIWmTguqYUSdwTNjYWf0acqNZEBOKzYC y0lnF_BQfgU60R0EU6JA4DavJK2ZkttJyMi1uS2CNIQgzN2cb7Wqgma3pnjg b.qDav0dkw2D_Sy8SRDDgRXlCSbQ0uUdVx9Cab5sLYJxVc08EZR.tf60FXl. Wp3mIDVijK_bEiftB137ZwzfYNrSSGO4WxxhQeCeo.icEid5aGzg6MxvgG8K 7BHRPn24wivCn5V1sGMt_zo5Ql.gf2vRzIj7T7tImUK8eopElQc9bQEbIxn8 hPAzYDFLoYxJHkNcWD6p91QM8PI1meCc2.RJMdDzc.2MWAIrulhpKSRdZZZ. CqqLtY_32FtNGWfgvZcn66zehGUaSf6KobGdN2m3RAW.PuUZTqUP_UXXSkM. L.kRt0Ubekvi7QNFQBhcfjswpdd7_iaJqNEa7ZRuXdWK4wjvU1Atcwj_0qx_ ForZAFR3L9xwNqsF5Hjji8cALU3tcxw9_A4GQD1BAy7L66iSu1BRJBE3vix1 OxmJzCgY7ads7LeQnUat3XEJiVxEHqDgyuxMWJx.f6YsQWOC3htgL1cYuekQ WW83Wjc7lc527fRGTeplkuwZpaJM0ocfUPJNOQNaEgB8- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Thu, 19 Sep 2013 13:54:53 PDT X-Rocket-MIMEInfo: 002.001, Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IFRlZW11IFNhdm9sYWluZW4gPHRzYXZvLnN0ZHNAZ21haWwuY29tPgo.VG86IGhvbGdlci5tZXRzY2h1bGF0QHRlbGVrb20uZGUgCj5DYzogdjZvcHNAaWV0Zi5vcmcgCj5TZW50OiBGcmlkYXksIDIwIFNlcHRlbWJlciAyMDEzIDY6NDAgQU0KPlN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtNjRzaGFyZSBXR0xDCj4gCj4KPgo.VGhlIEROUyBoYW5kbGluZyBtaWdodCBzdWl0ZSBmb3IgZHJhZnQtaWV0Zi12Nm9wcy0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Thu, 19 Sep 2013 13:54:53 -0700 (PDT) From: Mark ZZZ Smith To: Teemu Savolainen , "holger.metschulat@telekom.de" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:55:00 -0000 =0A>________________________________=0A> From: Teemu Savolainen =0A>To: holger.metschulat@telekom.de =0A>Cc: v6ops@ietf.org =0A>= Sent: Friday, 20 September 2013 6:40 AM=0A>Subject: Re: [v6ops] draft-ietf-= v6ops-64share WGLC=0A> =0A>=0A>=0A>The DNS handling might suite for draft-i= etf-v6ops-mobile-device-profile Section 4, but in my opinion not to this do= cument as it is not within the narrow scope.=0A=0AAgree it is out of scope = for this draft.=0A=0A>Secondly, I don't agree DHCP server support is requir= ed, as the CE can include the DNS addresses in RAs as specified in RFC6106.= =0A>=0A=0AHow could a CE convey NTP server settings to hosts using RAs? Acc= urate host time is pretty useful, if not essential.=0A=0A=0A=0A>=0A>Best re= gards,=0A>Teemu=0A>On Sep 19, 2013 9:41 PM,=A0=A0 wrote:=0A>=0A>Hello all,=0A>>=0A>>I believe this needs to be looked at= . DNS server addresses are sent from the network to the mobile host ("CE" i= n this scenario) by outband 3GPP signalling and need to be queried by the C= E OS driver from the radio chip.=0A>>=0A>>In order to convey the DNS inform= ation to the clients attached via the LAN, the CE performing 64share needs = to handle the DHCP solicits and answer on the network's behalf because simp= ly forwarding the DHCP solicits will not work at all (the network won't ans= wer them).=0A>>=0A>>Holger=0A>>=0A>>-----Urspr=FCngliche Nachricht-----=0A>= >Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von= Mark ZZZ Smith=0A>>Gesendet: Mittwoch, 18. September 2013 23:59=0A>>An: Te= emu Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org=0A>>Betreff: Re: [v= 6ops] draft-ietf-v6ops-64share WGLC=0A>>=0A>>+1=0A>>=0A>>This purpose here = is to describe a work around to a limitation, not to specify how RAs/DHCPv6= are supposed to be generally used and what options are present in them. I = don't think RA or DHCPv6 options that aren't essential or useful to this *s= pecific* scenario should be mentioned at all. DNS in RAs is not special to = or necessary to sharing a /64.=0A>>=0A>>Generally related to DHCPv6 option = passing across a CE device (of which this would be one), I posted the follo= wing draft a while ago. I'd be interested in comments.=0A>>=0A>>"IPv6 CE De= vice DHCPv6 Option Transparency"=0A>>=0A>>http://tools.ietf.org/html/draft-= smith-v6ops-ce-dhcpv6-transparency-00=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>>_______= _________________________=0A>>> From: Teemu Savolainen =0A>>>To: Tassos Chatzithomaoglou ; "v6ops@ietf.= org"=0A>>>=0A>>>Sent: Monday, 16 September 2013 4:12 PM=0A>= >>Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC=0A>>>=0A>>>=0A>>>=0A>>= >IMHO it is better to keep this draft focused solely on address sharing, an= d not to go to other configuration topic or other possible problems.=0A>>>= =0A>>>Btw most often, as of now, the "original" DNS server addresses are re= ceived via link layer signaling (see http://www.ietf.org/id/draft-ietf-v6op= s-rfc3316bis-06.txt section 2.10), and thus, for example, may need to be ad= ded to "proxied" RA.=0A>>>=0A>>>Best regards,=0A>>>=0A>>>Teemu=0A>>>=0A>>>_= _______________________________=0A>>> From: Tassos Chatzithomaoglou=0A>>>Se= nt: 15.9.2013 23:20=0A>>>To: v6ops@ietf.org=0A>>>Subject: Re: [v6ops] draft= -ietf-v6ops-64share WGLC=0A>>>=0A>>>Just a quick question...=0A>>>=0A>>>I d= on't see any reference of DNS servers under 3.1, only MTU & Prefix.=0A>>>Sh= ouldn't there be a bullet showing that DNS info (UE address as DNS proxy, o= r original through-RA/DHCPv6 DNS servers) should also pass on the LAN link?= =0A>>>=0A>>>--=0A>>>Tassos=0A>>>=0A>>>Fred Baker wrote on 15/9/2013 21:00:= =0A>>>> This is to initiate a two week working group last call of=0A>>>> ht= tp://tools.ietf.org/html/draft-ietf-v6ops-64share.=A0 Please read it=0A>>>>= now. If you find nits (spelling errors, minor suggested wording=0A>>>> cha= nges, etc), comment to the authors; if you find greater issues,=0A>>>> such= as disagreeing with a statement or finding additional issues=0A>>>> that n= eed to be addressed, please post your comments to the list.=0A>>>>=0A>>>> W= e are looking specifically for comments on the importance of the=0A>>>> doc= ument as well as its content. If you have read the document and=0A>>>> beli= eve it to be of operational utility, that is also an important=0A>>>> comme= nt to make.=0A>>>> _______________________________________________=0A>>>> v= 6ops mailing list=0A>>>> v6ops@ietf.org=0A>>>> https://www.ietf.org/mailman= /listinfo/v6ops=0A>>>>=0A>>>=0A>>>_________________________________________= ______=0A>>>v6ops mailing list=0A>>>v6ops@ietf.org=0A>>>https://www.ietf.or= g/mailman/listinfo/v6ops=0A>>>=0A>>>_______________________________________= ________=0A>>>v6ops mailing list=0A>>>v6ops@ietf.org=0A>>>https://www.ietf.= org/mailman/listinfo/v6ops=0A>>>=0A>>>=0A>>>=0A>>__________________________= _____________________=0A>>v6ops mailing list=0A>>v6ops@ietf.org=0A>>https:/= /www.ietf.org/mailman/listinfo/v6ops=0A>>__________________________________= _____________=0A>>v6ops mailing list=0A>>v6ops@ietf.org=0A>>https://www.iet= f.org/mailman/listinfo/v6ops=0A>>=0A>______________________________________= _________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/m= ailman/listinfo/v6ops=0A>=0A>=0A> From tsavo.stds@gmail.com Thu Sep 19 14:27:07 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE821F84CD for ; Thu, 19 Sep 2013 14:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i1uNOV7632d for ; Thu, 19 Sep 2013 14:27:07 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E3C0221F847C for ; Thu, 19 Sep 2013 14:27:00 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hf12so7200202vcb.27 for ; Thu, 19 Sep 2013 14:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BEc+jwcNqcUnqe8HQMQ5NX8v3+JiSRVt+n9bObhG5s0=; b=OzC+Bbfnsx7CkeUlp2rVRntnAURiW7s286kkdYjtUXzwllftuFuDPoLqOcMqssxBNg WJZKsgPEC2jmhFhghsnJUBmc/CR6BAy6VUeuoPDBrQrTiLSwQxaT+HHZTmJFTyzejdUW YE7OxB1ZRyc4TkEcl5R65nl0VkcT1ndwK6IxdfchfKuc+W7h6BsEhctm2F5DL86bScs6 X09hq6g1nqVd3Jyic5BgahryFjXRmj9v587jr6y+KRAUIourUYNLbfCUBvO0A+J7W+yY uQSYzbHWkEKCJKE6L3yTKNtXMOPVXHtOgoUXq0nlKbg6yOEFMEOOsQg+Zu35tjPHgLjZ VmMg== MIME-Version: 1.0 X-Received: by 10.220.186.202 with SMTP id ct10mr2917842vcb.14.1379626019364; Thu, 19 Sep 2013 14:26:59 -0700 (PDT) Received: by 10.52.166.72 with HTTP; Thu, 19 Sep 2013 14:26:59 -0700 (PDT) Received: by 10.52.166.72 with HTTP; Thu, 19 Sep 2013 14:26:59 -0700 (PDT) In-Reply-To: <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Fri, 20 Sep 2013 00:26:59 +0300 Message-ID: From: Teemu Savolainen To: Mark ZZZ Smith Content-Type: multipart/alternative; boundary=047d7b676fd0cea46404e6c336a2 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 21:27:07 -0000 --047d7b676fd0cea46404e6c336a2 Content-Type: text/plain; charset=ISO-8859-1 > >Secondly, I don't agree DHCP server support is required, as the CE can include the DNS addresses in RAs as specified in RFC6106. > > > > How could a CE convey NTP server settings to hosts using RAs? Accurate host time is pretty useful, if not essential. It cannot, but then again it probably would not help to have DHCP server implementation either, as, AFAIK, cellular networks commonly today do not provide DHCP service to terminals (to these "CEs" that would use 64share instead of DHCPv6 PD).... If CE has no NTP settings, it cannot share them either. CE often gets time from cellular network, though.. So maybe CE should implement NTP server and with DHCP share its own address as NTP address? ... And this is why it is best to focus 64share to just prefix sharing;-) Best regards, Teemu --047d7b676fd0cea46404e6c336a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> >Secondly, I don't agree DHCP server support is = required, as the CE can include the DNS addresses in RAs as specified in RF= C6106.
> >
>
> How could a CE convey NTP server settings to hosts using RAs? Accurate= host time is pretty useful, if not essential.

It cannot, but then again it probably would not help to have= DHCP server implementation either, as, AFAIK, cellular networks commonly t= oday do not provide DHCP service to terminals (to these "CEs" tha= t would use 64share instead of DHCPv6 PD).... If CE has no NTP settings, it= cannot share them either. CE often gets time from cellular network, though= .. So maybe CE should implement NTP server and with DHCP share its own addr= ess as NTP address?

... And this is why it is best to focus 64share to just pref= ix sharing;-)

Best regards,

Teemu

--047d7b676fd0cea46404e6c336a2-- From prvs=968e528b3=Dave.Michaud@rci.rogers.com Fri Sep 20 07:13:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69121F960D for ; Fri, 20 Sep 2013 07:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae9gAjj7fufn for ; Fri, 20 Sep 2013 07:13:46 -0700 (PDT) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 876E621F93D4 for ; Fri, 20 Sep 2013 07:13:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocAAM9WPFKOkg56l2dsb2JhbABaxUqBMA4BAQEBAQgWBzyCJwEEEh4jCwEVBRIBKgYYB1cBBAEaEweHY50FnXmOJoEOMYMlgQADjxKeICCBLA X-IronPort-AV: E=Sophos;i="4.90,944,1371096000"; d="scan'208";a="336437030" Received: from rssesnexigwb.rss.rogers.com (HELO rsoesnexigwb.rci.rogers.ca) ([142.146.14.122]) by mail.mail.rss.rogers.com with ESMTP; 20 Sep 2013 10:13:45 -0400 Received: from RSOESNGTABHC.rci.rogers.ca ([10.3.37.54]) by rsoesnexigwb.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Sep 2013 10:13:45 -0400 Received: from CL08MBE.rci.rogers.ca ([10.3.45.56]) by RSOESNGTABHC.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Sep 2013 10:13:45 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Sep 2013 10:13:20 -0400 Message-ID: <29AE8DB910E7704CA043795E00DCBE780A363F34@CL08MBE.rci.rogers.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac62C32cNXuCWp3LTsmN64khizODhA== From: "Dave Michaud" To: "GangChen" , "IPv6 Ops WG" X-OriginalArrivalTime: 20 Sep 2013 14:13:45.0092 (UTC) FILETIME=[9DEF3C40:01CEB60B] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Fri, 20 Sep 2013 07:46:48 -0700 Cc: Cameron Byrne Subject: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:13:52 -0000 SGkgR2FuZywKClRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQg YWxyZWFkeSBhbmQgYSBwcmVzZW50YXRpb24gYXQgSUVURjg3IGJ1dCBub3RoaW5nIGhhcyBiZWVu IGluY2x1ZGVkIGluIGEgcmV2aXNlZCB2ZXJzaW9uIHlldCBzbyBpdCdzIGRpZmZpY3VsdCB0byBo YXZlIGEgY2xlYXIgdmlldyBvZiB3aGVyZSB3ZSBzdGFuZCBhdCB0aGlzIHBvaW50IGFuZCBjb21t ZW50IGZ1cnRoZXIuCgpOb25ldGhlbGVzcywgSSdkIGxpa2UgdG8gc2hhcmUgb3VyIG93biBleHBl cmllbmNlIGluIGRlcGxveWluZyBJUHY2IGZvciBvdXIgaG9tZSBzdWJzY3JpYmVycyBhbmQgdGhl IGV4cGVjdGVkIHJvYW1pbmcgaW1wYWN0LiBJIGd1ZXNzIGl0IGNhbiBzZXJ2ZSBhcyBpbnB1dCBm b3IgdGhpcyBkcmFmdCBvciBmb3IgYSBmdXR1cmUgQkNQLiBPdXIgdGFyZ2V0IGlzIHRvIGVuYWJs ZSBJUHY2LW9ubHkgKGFuZCBub3QgZHVhbC1zdGFjaykgZm9yIGFzIG1hbnkgc3Vic2NyaWJlciBh cyB3ZSBjYW4sIHJvYW1pbmcgb3Igbm90IGJ1dCBvYnZpb3VzbHkgd2Ugd2FudCB0byBlbnN1cmUg dGhhdCB0aGUgc2VydmljZSBrZWVwcyB3b3JraW5nIGFzIGl0IGRvZXMgdG9kYXkuIFdlIGFyZSBh bHNvIG5vdCB1c2luZyB2UExNTiBsb2NhbCBicmVha291dCAod2hpY2ggaXMgdGhlIGNhc2UgZm9y IG1vc3Qgb3BlcmF0b3JzKSBidXQgbWF5IGNoYW5nZSBmb3IgSU1TIHNpdHVhdGlvbnMgaW4gdGhl IGZ1dHVyZS4KCi0tLS0gVUUgQ29uZmlndXJhdGlvbiAtLS0tClVFIGNhbiBiZSBzZXQgdG8gcmVx dWVzdCBhIFBEUC9QRE4gVHlwZSBJUHY0LCBJUHY0djYgb3IgSVB2Ni4gQ2VydGFpbiBVRSBoYXZl IHRoZSBhYmlsaXR5IGEgZGlmZmVyZW50IGNvbmZpZ3VyYXRpb24gZm9yIGhvbWUgbmV0d29yayAv IHZpc2l0ZWQgbmV0d29yay4gU2luY2UgdGhpcyBpcyByZWxhdGVkIHRvIHJvYW1pbmcgY2FzZSwg bXkgY29tbWVudHMgYXBwbHkgdG8gdGhlIHJvYW1pbmcgcHJvZmlsZSBvciB0aGUgaG9tZS9yb2Ft aW5nIHByb2ZpbGUgaWYgdGhlcmUgaXMgbm8gZGlzdGluY3Rpb24uIFRoaXMgaXMgd2hhdCB0aGUg VUUgcmVxdWVzdCwgbm90IG5lY2Vzc2FyaWx5IHRoZSBmaW5hbCBQRFAvUEROIFR5cGUuLi4KCi0g SVB2NDogaGFzIGJlZW4gd29ya2luZyBmb3IgeWVhcnMsIG5vIGlzc3VlCi0gSVB2NjogaWYgdGhl IFVFIHJlcXVlc3QgSVB2Ni1vbmx5IGFuZCBhIG5vZGUgaW4gdGhlIHBhdGggY2FuJ3Qgc3VwcG9y dCBpdCAoaWUuIHZpc2l0ZWQgU0dTTiksIHRoZXJlIGlzIG5vIHBvc3NpYmxlIGZhbGxiYWNrIGFu ZCBkYXRhIGlzIGJyb2tlbi4gVGhpcyBjb25maWd1cmF0aW9uIHNob3VsZCBiZSBhdm9pZGVkLgot IElQdjR2NjogdGhpcyBpcyBsZWFzdCBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbiAoYmFzZWQgb24g cmVxdWlyZWQgM0dQUCByZWxlYXNlIGluIFNHU04pIGJ1dCBhbHNvIHRoZSBjb25maWd1cmF0aW9u IHRoYXQgb2ZmZXJzIHRoZSBtb3N0IGZsZXhpYmlsaXR5LiBBcyBwZXIgM0dQUCAyNC4wMDgsIHRo aXMgUERQL1BETiBUeXBlIHNob3VsZCBiZSBpbnRlcnByZXRlZCBhcyBJUHY0IGJ5IHRoZSBTR1NO L01NRSBpZiBpdCBkb2Vzbid0IHVuZGVyc3RhbmQgaXQuIAoKV2UgaGF2ZSBoYWQgc29tZSBVRSBt b2RlbHMgY29uZmlndXJlZCB0byByZXF1ZXN0IHRoaXMgUERQL1BETiB0eXBlIGluIGNpcmN1bGF0 aW9uIGZvciBvdmVyIGEgeWVhciBub3cgYW5kIHdlIGhhdmUgb2JzZXJ2ZWQgY2FzZXMgd2hlcmUg dGhlIHZTR1NOIHdhcyBzaW1wbHkgcmVqZWN0aW5nIHRoZSBQRFAgQ29udGV4dCBDcmVhdGlvbiBt ZXNzYWdlIHdpdGggYSBjYXVzZSBjb2RlICMyNyAoVW5rbm93biBvciBtaXNzaW5nIEFQTikgYmVj YXVzZSBpdCBzdG9wcGVkIHByb2Nlc3NpbmcgdGhlIG1lc3NhZ2UgYXQgdGhlIFBEUCB0eXBlIChB UE4gbmFtZSBjb21lcyByaWdodCBhZnRlcikuIFRoaXMgaG93ZXZlciBoYXMgYmVlbiBhbiBleHRy ZW1lbHkgbGltaXRlZCBjb3JuZXIgY2FzZSB3aXRoIDIgY29uZmlybWVkIG9wZXJhdG9ycy4gVWx0 aW1hdGVseSwgd2UgYXJlIG5vdyBjb25maWd1cmluZyBtb3N0IFVFIHRvIHJlcXVlc3QgSVB2NHY2 IHdoaWxlIHJvYW1pbmcgKHdlIGtlcHQgc29tZSBmbGFnc2hpcCBkZXZpY2VzIGFzIElQdjQtb25s eSBmb3Igbm93IGFzIHdlIGJ1aWxkIGEgZGF0YWJhc2Ugb2Ygd29ya2luZyBQTE1OcykuCgotLS0t IFNHU04vTU1FIGZvciBNb2JpbGl0eSBNYW5hZ2VtZW50IFByb2NlZHVyZXMgKEF0dGFjaCkgLS0t LQpPbiBhdHRhY2gsIHRoZSBTR1NOL01NRSBtdXN0IGNvbnRhY3QgdGhlIGhvbWUgSExSL0hTUyBh bmQgb2J0YWluIHRoZSBzdWJzY3JpYmVyIHByb2ZpbGUuIEl0IGlzIHdlbGwga25vd24gbm93IGFu ZCBoYXMgYmVlbiBvYnNlcnZlZCBmaXJzdCBoYW5kIGJ5IHNvbWUgb2YgdXMgaGVyZSB0aGF0IG11 bHRpcGxlIFNHU04vTU1FIHdpbGwgYmUgdW5hYmxlIHRvIGNvcnJlY3RseSBwcm9jZXNzIGEgc3Vi c2NyaWJlciBwcm9maWxlIHJlY2VpdmVkIGluIHRoZSBJbnNlcnQgU3Vic2NyaWJlciBEYXRhIHBy b2NlZHVyZSBpZiBpdCBjb250YWlucyBhbiBFeHQtUERQLVR5cGUgKDNHUFAgVFMgMjkuMDAyIC8g M0dQUCBUUyAyOS4wNjApLiBJbiB0aGF0IGNhc2UsIGl0IGJyZWFrcyBkYXRhIHNvIHRoaXMgc2l0 dWF0aW9uIG11c3QgYmUgYXZvaWRlZC4KCkRldGFpbHMgb24gdGhlIHNvbHV0aW9uIGFyZSBpbiB0 aGUgSExSIHNlY3Rpb24gYmVsb3cgYnV0IHVsdGltYXRlbHksIHVubGVzcyB3ZSBrbm93IGZvciBz dXJlIHRoYXQgYW4gU0dTTiAoYW5kIHRoZSBvcGVyYXRvciBpbiBnZW5lcmFsIGFzIHBlciBJUi4y MSksIHRoZSBTR1NOIHdpbGwgcmVjZWl2ZSBhIHN1YnNjcmliZXIgcHJvZmlsZSB0aGF0IGNvbnRh aW5zIElQdjQtb25seSBhcyB0aGUgYXZhaWxhYmxlIFBEUCB0eXBlIChub3QgcHJlc2VuY2Ugb2Yg SVB2NiBhdCBhbGwpLgoKQXQgdGhpcyBzdGFnZSwgdGhlIFNHU04gc2hvdWxkIHRoZXJlZm9yZSBy ZWNlaXZlIGEgc3Vic2NyaWJlciBwcm9maWxlIGNvbnRhaW5pbmcgb25seSBmaWVsZHMgaXQgY2Fu IHVuZGVyc3RhbmQgYW5kIHRoaXMgYXR0YWNoIHdpbGwgY29tcGxldGUgc3VjY2Vzc2Z1bGx5LgoK LS0tLSBTR1NOL01NRSBmb3IgU2Vzc2lvbiBNYW5hZ2VtZW50IFByb2NlZHVyZXMgKFBEUCBDb250 ZXh0L0JlYXJlcikgLS0tLQpXaGVuIHRoZSBTR1NOL01NRSByZWNlaXZlcyBhIHNlc3Npb24gY3Jl YXRpb24gcmVxdWVzdCBmcm9tIHRoZSBVRSAoUERQL1BETiBUeXBlIElQdjR2NiksIHRoZSBmb2xs b3dpbmcgc2l0dWF0aW9ucyBhcmUgcG9zc2libGU6CgoxLiBTR1NOL01NRSBkb2VzIG5vdCB1bmRl cnN0YW5kIElQdjR2NiBzbyBpdCBmYWxscyBiYWNrIHRvIElQdjQgYXMgcGVyIHNwZWMKMi4gU0dT Ti9NTUUgdW5kZXJzdGFuZHMgSVB2NHY2IGJ1dCB0aGUgc3Vic2NyaWJlciBwcm9maWxlIGRpZCBu b3QgY29udGFpbiBFeHQtUERQLVR5cGUgc28gaXQgZmFsbHMgYmFjayB0byBJUHY0CjMuIFNHU04v TU1FIHVuZGVyc3RhbmRzIElQdjR2NiBidXQgYXMgcGVyIGEgbG9jYWwgcG9saWN5IGRvZXMgbm90 IGFsbG93IGl0IHNvIGl0IGZhbGxzIGJhY2sgdG8gSVB2NAogICBhLiBJUHY2IGJpbGxpbmcgbm90 IHN1cHBvcnRlZAogICBiLiBJUHY2IG5vdCBsaWNlbnNlZAogICBjLiBMb2NhbCBkZWNpc2lvbi4u Lgo0LiBTR1NOL01NRSBkb2VzIG5vdCB1bmRlcnN0YW5kIElQdjR2NiBhbmQgaXQgZG9lcyBub3Qg ZmFsbCBiYWNrIHRvIElQdjQuCgpQb2ludCA0IGlzIGZvciB1cyB0aGUgbW9zdCBjcml0aWNhbCBh c3BlY3QgYW5kIHRoZSBvbmUgd2UgYXJlIGZvbGxvd2luZyBjbG9zZWx5LgoKQmFzZWQgb24gdGhl IGFib3ZlIG9wdGlvbnMsIHRoZSBTR1NOL01NRSBmb3J3YXJkcyB0byB0aGUgR0dTTi9TLUdXIGEg c2Vzc2lvbiBjcmVhdGlvbiByZXF1ZXN0IHdpdGggZWl0aGVyIGEgUERQIFR5cGUgb2YgSVB2NCBv ciBJUHY0djYuCgotLS0tIEhMUi9IU1MgLS0tLQpXaGVuIHRoZSBITFIgcmVjZWl2ZXMgYW4gVXBk YXRlIEdQUlMgTG9jYXRpb24gbWVzc2FnZSwgaXQgaGFzIHRvIHByb3ZpZGUgdGhlIHN1YnNjcmli ZXIgcHJvZmlsZSB0byB0aGUgcmVxdWVzdGluZyBlbnRpdHkuIEFsbCBzdWJzY3JpYmVycyBoYXZl IHRoZWlyIEFQTnMgc2V0IGZvciBJUHY0LW9ubHkgd2l0aCBleHRlbmRlZCBQRFAgc3VwcG9ydCAo SVB2NHY2KS4KCldoZW4gcmVjZWl2aW5nIHRoaXMgbWVzc2FnZSwgdGhlIEhMUiBjb21wYXJlcyB0 aGUgU0dTTiBWTFIgYWRkcmVzcyB3aXRoIGEgd2hpdGVsaXN0IGRhdGFiYXNlIGFuZCBkZWNpZGUg aWYgdGhlIFNHU04gaXMgZGVlbWVkIElQdjYgY29tcGxpYW50LiBBdCBmaXJzdCwgdGhpcyBkYXRh YmFzZSB3aWxsIGJlIGVtcHR5IGJ1dCBhcyBJUHY2IHN1cHBvcnQgaXMgY29uZmlybWVkIHRocm91 Z2ggZWl0aGVyIHRlc3RpbmcsIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBvcGVyYXRvciBvciB0aGUg SVIuMjEsIHdlIHdpbGwgcG9wdWxhdGUgdGhpcyBkYXRhYmFzZS4KClVsdGltYXRlbHksIHRoZSBI TFIgc2VuZHMgb3V0IGEgcHJvZmlsZSB0aGF0IGVpdGhlciBjb250YWlucyBJUHY0IG9ubHkgb3Ig SVB2NCArIElQdjR2NiBiYXNlZCBvbiB0aGlzIHdoaXRlbGlzdCBkYXRhYmFzZS4KClVuZm9ydHVu YXRlbHksIHRoaXMgaXMgbm90IHlldCBhIHN0YW5kYXJkIGZlYXR1cmUgaW4gYW55IEhMUiBidXQg b3VyIEhMUiB2ZW5kb3IgaGFzIGJlZW4gY29vcGVyYXRpdmUgdG8gZGV2ZWxvcCB0aGlzIG1hcmtl dCBjdXN0b21pemF0aW9uIGZvciB1cy4KCi0tLS0gR0dTTi9TLUdXL1AtR1cgLS0tLQpXaGVuIHRo ZSBHR1NOL1AtR1cgcmVjZWl2ZXMgYSBzZXNzaW9uIGNyZWF0aW9uIHJlcXVlc3QsIGl0IGNhbWUg aW4gYXMgZWl0aGVyIElQdjQgb3IgSVB2NHY2IChzZWUgU0dTTi9NTUUgZm9yIFNlc3Npb24gTWFu YWdlbWVudCkuIFRoZSBBUE5zIG9uIHRoZSBHR1NOL1AtR1cgdGhhdCB0aGUgY3VzdG9tZXJzIGFy ZSByZXF1ZXN0aW5nIGFyZSBjb25maWd1cmVkIHRvIHN1cHBvcnQgSVB2NHY2IChhbmQgYnkgZXh0 ZW5zaW9uIElQdjQtb25seSBhbmQgSVB2Ni1vbmx5KS4gT24gc2Vzc2lvbiBjcmVhdGlvbiByZXF1 ZXN0LCB0aGUgR0dTTi9QLUdXIHNlbmRzIGFuIEFjY2Vzcy1SZXF1ZXN0IHRvIGEgQUFBIHNlcnZl ciwgc2VuZGluZyB0aGUgdlNHU04gTUNDK01OQywgdGhlIElNRUkgYW5kIHRoZSBQRFAgVHlwZSBy ZWNlaXZlZC4KClRoZSBBQUEgQWNjZXNzLUFjY2VwdCBjb250YWlucyBhIG5ldyBBUE4gbmFtZSB0 aGF0IHRoZSBHR1NOL1AtR1cgd2lsbCB1c2UgdG8gZWZmZWN0aXZlbHkgZXN0YWJsaXNoIHRoZSBz ZXNzaW9uLiBUaGUgcmVkaXJlY3Rpb24gQVBOIGlzIHVzZWQgbWFrZSBhIGZpbmFsIHNlbGVjdGlv biBvbiB0aGUgSVAgdHlwZSB1c2VkIChJUHY0IG9yIElQdjYgb3IgSVB2NHY2KQoKUmVxdWVzdGVk IEFQTjogaW50ZXJuZXQKUG9zc2libGUgQUFBIG91dHB1dDogdjQuaW50ZXJuZXQsIGRzLmludGVy bmV0IG9yIHY2LmludGVybmV0CgotLS0tIEFBQSBTZXJ2ZXIgLS0tLQpUaGUgQUFBIHJlY2VpdmVz IHRoZSBBY2Nlc3MtUmVxdWVzdCBmcm9tIHRoZSBHR1NOL1AtR1cuIEl0IGltcGxlbWVudHMgYSBs b2dpYyB0aGF0IHdpbGwgdWx0aW1hdGVseSBkZWNpZGUgd2hhdCB0eXBlIG9mIFBEUCB3ZSBzaG91 bGQgdXNlIGZvciB0aGlzIHNlc3Npb24uCgpUaGUgZm9sbG93aW5nIGNoZWNrcyBhcmUgcGVyZm9y bWVkOgotIFJlcXVlc3RlZCBQRFAgVHlwZTogaWYgSVB2NCBvciBJUHY2LCBhbnkgY2hhbmdlIHdp bGwgYnJlYWsgdGhlIGRhdGEgc2Vzc2lvbiBzbyBhbGxvdyBhcyBpcyAodjQgd291bGQgYmUgZm9y IG9sZGVyIGRldmljZXMgb3IgYSBmYWxsYmFjayBzY2VuYXJpbyBhbG9uZyB0aGUgcGF0aDsgdjYg d291bGQgYmUgYmVjYXVzZSB0aGUgdXNlciByZWNvbmZpZ3VyZWQgaGlzIFVFIHRvIGRpcmVjdGx5 IHJlcXVlc3QgSVB2NiBpbnN0ZWFkIG9mIHRoZSBkZWZhdWx0IElQdjR2NikKLSBTR1NOIE1DQy1N TkM6IHdpdGhvdXQgYSBjb25maXJtYXRpb24gdGhhdCB0aGlzIFBMTU4gSUQgc3VwcG9ydHMgSVB2 NiwgZmFsbGJhY2sgdG8gSVB2NAotIElNRUk6IGV4dHJhY3QgVEFDIGFuZCBTViBjb21wb25lbnRz IGFuZCB2ZXJpZnkgaWYgZGV2aWNlIGhhcyA0NjRYTEFUIHN1cHBvcnQuIElmIGl0IGRvZXMsIGFs bG93IElQdjYtb25seSwgb3RoZXJ3aXNlIGFsbG93IGR1YWwtc3RhY2sKCkJhc2VkIG9uIHRoZSBh Ym92ZSBjaGVja3MsIHRoZSBBQUEgd2lsbCBkZWNpZGUgd2hpY2ggQVBOIHRvIHNlbmQgdGhlIGN1 c3RvbWVyIHRvIGFuZCB0aGlzIGlzIHdoYXQgd2lsbCB1bHRpbWF0ZWx5IGRlY2lkZSBpZiB3ZSBh bGxvdyBJUHY2LW9ubHkgcm9hbWluZyBvciBub3QuCgoKRGF2ZSBNaWNoYXVkCgoKClRoaXMgZS1t YWlsIChhbmQgYXR0YWNobWVudChzKSkgaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgbWF5 IGJlIHN1YmplY3QgdG8gY29weXJpZ2h0IGFuZCBsZWdhbCBwcml2aWxlZ2UgYW5kIG5vIHJlbGF0 ZWQgcmlnaHRzIGFyZSB3YWl2ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQgb3IgaXRzIGFnZW50LCBhbnkgcmV2aWV3LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCBvciBhbnkgb2YgaXRzIGNvbnRlbnQgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBBbGwgbWVzc2FnZXMgbWF5IGJlIG1v bml0b3JlZCBhcyBwZXJtaXR0ZWQgYnkgYXBwbGljYWJsZSBsYXcgYW5kIHJlZ3VsYXRpb25zIGFu ZCBvdXIgcG9saWNpZXMgdG8gcHJvdGVjdCBvdXIgYnVzaW5lc3MuIEUtbWFpbHMgYXJlIG5vdCBz ZWN1cmUgYW5kIHlvdSBhcmUgZGVlbWVkIHRvIGhhdmUgYWNjZXB0ZWQgYW55IHJpc2sgaWYgeW91 IGNvbW11bmljYXRlIHdpdGggdXMgYnkgZS1tYWlsLiBJZiByZWNlaXZlZCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBlLW1haWwgKGFuZCBhbnkg YXR0YWNobWVudHMpIGZyb20gYW55IGNvbXB1dGVyIG9yIGFueSBzdG9yYWdlIG1lZGl1bSB3aXRo b3V0IHByaW50aW5nIGEgY29weS4KCkNlIGNvdXJyaWVsIChhaW5zaSBxdWUgc2VzIHBpw6hjZXMg am9pbnRlcykgZXN0IGNvbmZpZGVudGllbCwgZXhjbHVzaWYsIGV0IHBldXQgZmFpcmUgbOKAmW9i amV0IGRlIGRyb2l0IGTigJlhdXRldXIgZXQgZGUgcHJpdmlsw6hnZSBqdXJpZGlxdWU7IGF1Y3Vu IGRyb2l0IGNvbm5leGUgbuKAmWVzdCBleGNsdS4gU2kgdm91cyBu4oCZw6p0ZXMgcGFzIGxlIGRl c3RpbmF0YWlyZSB2aXPDqSBvdSBzb24gcmVwcsOpc2VudGFudCwgdG91dGUgw6l0dWRlLCBkaWZm dXNpb24sIHRyYW5zbWlzc2lvbiBvdSBjb3BpZSBkZSBjZSBjb3VycmllbCBlbiB0b3V0IG91IGVu IHBhcnRpZSwgZXN0IHN0cmljdGVtZW50IGludGVyZGl0ZSBldCBwZXV0IMOqdHJlIGlsbMOpZ2Fs ZS4gVG91cyBsZXMgbWVzc2FnZXMgcGV1dmVudCDDqnRyZSBzdXJ2ZWlsbMOpcywgc2Vsb24gbGVz IGxvaXMgZXQgcsOoZ2xlbWVudHMgYXBwbGljYWJsZXMgZXQgbGVzIHBvbGl0aXF1ZXMgZGUgcHJv dGVjdGlvbiBkZSBub3RyZSBlbnRyZXByaXNlLiBMZXMgY291cnJpZWxzIG5lIHNvbnQgcGFzIHPD qWN1cmlzw6lzIGV0IHZvdXMgw6p0ZXMgcsOpcHV0w6lzIGF2b2lyIGFjY2VwdMOpIHRvdXMgbGVz IHJpc3F1ZXMgcXVpIHkgc29udCBsacOpcyBzaSB2b3VzIGNob2lzaXNzZXogZGUgY29tbXVuaXF1 ZXIgYXZlYyBub3VzIHBhciBjZSBtb3llbi4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbm91cyBlbiBhdmlzZXIgaW1tw6lkaWF0ZW1lbnQgZXQgc3Vw cHJpbWVyIGNlIGNvdXJyaWVsIChhaW5zaSBxdWUgdG91dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMp IGRlIHRvdXQgb3JkaW5hdGV1ciBvdSBzdXBwb3J0IGRlIGRvbm7DqWVzIHNhbnMgZW4gaW1wcmlt ZXIgdW5lIGNvcGllLiAK From phdgang@gmail.com Sat Sep 21 01:33:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE911E812B for ; Sat, 21 Sep 2013 01:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-1.530, BAYES_20=-0.74, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bq4xKN8ujC0 for ; Sat, 21 Sep 2013 01:33:10 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2B76E11E8125 for ; Sat, 21 Sep 2013 01:33:04 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j7so303826qaq.5 for ; Sat, 21 Sep 2013 01:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PgS9cKIgLUvQu4xnU8ndY4ru3qx89OPHQpVQYiV7Z74=; b=0K+X5vHQLm6hoIx+dJYKjWLM2zjzUKmXQxtKwMuS0LE3vxgSDmL0Q+8mABeLEEMkoz 1bYAQTy81MgZ8z17XH8ege2wfee5f2KQUHDCloqgNZBmVV94TXxMqv4lNP1GBxIKPpGT QrIF4eeGxQck+6jiN/Ozzi7tup5y9Bbr7Z6tl7RJobp0qJoRJsQnQNeF4Nb81MEBFbeT dLjcRRAFqc0OQfKMbvKhTdrBX2jZRtae5Xk4Ke2JrtxhziSpH7U6+D9ugS8qxrIywXvo aMR52MXRtnds18/KeNxQpthODHC3xSA3l7jHjnCSi0P/XlNjKB4CVM18yQZ7ccmJ8FT1 4gyQ== MIME-Version: 1.0 X-Received: by 10.224.8.10 with SMTP id f10mr10562700qaf.29.1379752383608; Sat, 21 Sep 2013 01:33:03 -0700 (PDT) Received: by 10.49.81.171 with HTTP; Sat, 21 Sep 2013 01:33:03 -0700 (PDT) In-Reply-To: <29AE8DB910E7704CA043795E00DCBE780A363F32@CL08MBE.rci.rogers.ca> References: <29AE8DB910E7704CA043795E00DCBE780A363F32@CL08MBE.rci.rogers.ca> Date: Sat, 21 Sep 2013 16:33:03 +0800 Message-ID: From: GangChen To: Dave Michaud Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 21 Sep 2013 08:02:33 -0700 Cc: IPv6 Ops WG , Cameron Byrne , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, Victor Kuarsingh Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 08:33:11 -0000 Hi Dave, thank you for the comments. Please see my reply inline. 2013/9/20, Dave Michaud : > Hi Gang, > > There has been a lot of comments on this draft already and a presentation= at > IETF87 but nothing has been included in a revised version yet so it's > difficult to have a clear view of where we stand at this point and commen= t > further. As you may know, there is a design team to polish the draft. We intend to speed up the revision by gathering the comments from participants. You are welcome to join. > Nonetheless, I'd like to share our own experience in deploying IPv6 for o= ur > home subscribers and the expected roaming impact. I guess it can serve as > input for this draft or for a future BCP. Our target is to enable IPv6-on= ly > (and not dual-stack) for as many subscriber as we can, roaming or not but > obviously we want to ensure that the service keeps working as it does tod= ay. > We are also not using vPLMN local breakout (which is the case for most > operators) but may change for IMS situations in the future. Thank you for the inputs. Your comments will be incorporated into the next revision. Please see more detailed discussions as below. > ---- UE Configuration ---- > UE can be set to request a PDP/PDN Type IPv4, IPv4v6 or IPv6. Certain UE > have the ability a different configuration for home network / visited > network. Since this is related to roaming case, my comments apply to the > roaming profile or the home/roaming profile if there is no distinction. T= his > is what the UE request, not necessarily the final PDP/PDN Type... > > - IPv4: has been working for years, no issue > - IPv6: if the UE request IPv6-only and a node in the path can't support = it > (ie. visited SGSN), there is no possible fallback and data is broken. Thi= s > configuration should be avoided. > - IPv4v6: this is least supported configuration (based on required 3GPP > release in SGSN) but also the configuration that offers the most > flexibility. As per 3GPP 24.008, this PDP/PDN Type should be interpreted = as > IPv4 by the SGSN/MME if it doesn't understand it. > > We have had some UE models configured to request this PDP/PDN type in > circulation for over a year now and we have observed cases where the vSGS= N > was simply rejecting the PDP Context Creation message with a cause code #= 27 > (Unknown or missing APN) because it stopped processing the message at the > PDP type (APN name comes right after). This however has been an extremely > limited corner case with 2 confirmed operators. That is the case we are also observing for the time being. I guess we have to justify whether that is a corner case, because I heard the issue from at least 2 operators. >Ultimately, we are now > configuring most UE to request IPv4v6 while roaming (we kept some flagshi= p > devices as IPv4-only for now as we build a database of working PLMNs). If the behavior complies with 24.008, IPv4v6 roaming is a workable solution. But, how could this recommendation related to your goal(i.e. Our target is to enable IPv6-only (and not dual-stack)? > ---- SGSN/MME for Mobility Management Procedures (Attach) ---- > On attach, the SGSN/MME must contact the home HLR/HSS and obtain the > subscriber profile. It is well known now and has been observed first hand= by > some of us here that multiple SGSN/MME will be unable to correctly proces= s a > subscriber profile received in the Insert Subscriber Data procedure if it > contains an Ext-PDP-Type (3GPP TS 29.002 / 3GPP TS 29.060). In that case,= it > breaks data so this situation must be avoided. > > Details on the solution are in the HLR section below but ultimately, unle= ss > we know for sure that an SGSN (and the operator in general as per IR.21), > the SGSN will receive a subscriber profile that contains IPv4-only as the > available PDP type (not presence of IPv6 at all). > > At this stage, the SGSN should therefore receive a subscriber profile > containing only fields it can understand and this attach will complete > successfully. Yes. That is the issue identified in the current draft. We didn't provide the solution, because the draft not intends to make a suggestion to modify 3GPP node. That is the conclusion from last meeting discussion. The solution you described below may be an approach to solve the issue. If that is formally published or planned to be a 3GPP CR, the draft may include to convey this information. > ---- SGSN/MME for Session Management Procedures (PDP Context/Bearer) ---- > When the SGSN/MME receives a session creation request from the UE (PDP/PD= N > Type IPv4v6), the following situations are possible: > > 1. SGSN/MME does not understand IPv4v6 so it falls back to IPv4 as per sp= ec > 2. SGSN/MME understands IPv4v6 but the subscriber profile did not contain > Ext-PDP-Type so it falls back to IPv4 > 3. SGSN/MME understands IPv4v6 but as per a local policy does not allow i= t > so it falls back to IPv4 > a. IPv6 billing not supported > b. IPv6 not licensed > c. Local decision... > 4. SGSN/MME does not understand IPv4v6 and it does not fall back to IPv4. > > Point 4 is for us the most critical aspect and the one we are following > closely. > > Based on the above options, the SGSN/MME forwards to the GGSN/S-GW a sess= ion > creation request with either a PDP Type of IPv4 or IPv4v6. To be clear, SGSN/MME would forward a PDP Type of IPv4 in the case of #1,2,= 3 Would SGSN/MME in #4 directly reject the request? > ---- HLR/HSS ---- > When the HLR receives an Update GPRS Location message, it has to provide = the > subscriber profile to the requesting entity. All subscribers have their A= PNs > set for IPv4-only with extended PDP support (IPv4v6). > > When receiving this message, the HLR compares the SGSN VLR address with a > whitelist database and decide if the SGSN is deemed IPv6 compliant. At > first, this database will be empty but as IPv6 support is confirmed throu= gh > either testing, confirmation from the operator or the IR.21, we will > populate this database. > > Ultimately, the HLR sends out a profile that either contains IPv4 only or > IPv4 + IPv4v6 based on this whitelist database. > > Unfortunately, this is not yet a standard feature in any HLR but our HLR > vendor has been cooperative to develop this market customization for us. > > ---- GGSN/S-GW/P-GW ---- > When the GGSN/P-GW receives a session creation request, it came in as eit= her > IPv4 or IPv4v6 (see SGSN/MME for Session Management). The APNs on the > GGSN/P-GW that the customers are requesting are configured to support IPv= 4v6 > (and by extension IPv4-only and IPv6-only). On session creation request, = the > GGSN/P-GW sends an Access-Request to a AAA server, sending the vSGSN > MCC+MNC, the IMEI and the PDP Type received. > > The AAA Access-Accept contains a new APN name that the GGSN/P-GW will use= to > effectively establish the session. The redirection APN is used make a fin= al > selection on the IP type used (IPv4 or IPv6 or IPv4v6) > > Requested APN: internet > Possible AAA output: v4.internet, ds.internet or v6.internet > > ---- AAA Server ---- > The AAA receives the Access-Request from the GGSN/P-GW. It implements a > logic that will ultimately decide what type of PDP we should use for this > session. > > The following checks are performed: > - Requested PDP Type: if IPv4 or IPv6, any change will break the data > session so allow as is (v4 would be for older devices or a fallback scena= rio > along the path; v6 would be because the user reconfigured his UE to direc= tly > request IPv6 instead of the default IPv4v6) > - SGSN MCC-MNC: without a confirmation that this PLMN ID supports IPv6, > fallback to IPv4 > - IMEI: extract TAC and SV components and verify if device has 464XLAT > support. If it does, allow IPv6-only, otherwise allow dual-stack > > Based on the above checks, the AAA will decide which APN to send the > customer to and this is what will ultimately decide if we allow IPv6-only > roaming or not. AAA is located in the Gi/SGi interface. If the signal comes to AAA server, that means there is no issues with the interworking between vSGSN/SGW and HSS/HLR. If I understand correctly, you may recommend using AAA server to guide the user's request to IPv6-only+464xlat or dual-stack or IPv4 fallback As per 23.401 and 29.061, AAA server is one of deployment options. Did you evaluate if the recommendation is applicable widely? Best Regards Gang > > Dave Michaud > > > > > This e-mail (and attachment(s)) is confidential, proprietary, may be subj= ect > to copyright and legal privilege and no related rights are waived. If you > are not the intended recipient or its agent, any review, dissemination, > distribution or copying of this e-mail or any of its content is strictly > prohibited and may be unlawful. All messages may be monitored as permitte= d > by applicable law and regulations and our policies to protect our busines= s. > E-mails are not secure and you are deemed to have accepted any risk if yo= u > communicate with us by e-mail. If received in error, please notify us > immediately and delete the e-mail (and any attachments) from any computer= or > any storage medium without printing a copy. > > Ce courriel (ainsi que ses pi=E8ces jointes) est confidentiel, exclusif, = et > peut faire l=92objet de droit d=92auteur et de privil=E8ge juridique; auc= un droit > connexe n=92est exclu. Si vous n=92=EAtes pas le destinataire vis=E9 ou s= on > repr=E9sentant, toute =E9tude, diffusion, transmission ou copie de ce cou= rriel > en tout ou en partie, est strictement interdite et peut =EAtre ill=E9gale= . Tous > les messages peuvent =EAtre surveill=E9s, selon les lois et r=E8glements > applicables et les politiques de protection de notre entreprise. Les > courriels ne sont pas s=E9curis=E9s et vous =EAtes r=E9put=E9s avoir acce= pt=E9 tous les > risques qui y sont li=E9s si vous choisissez de communiquer avec nous par= ce > moyen. Si vous avez re=E7u ce message par erreur, veuillez nous en aviser > imm=E9diatement et supprimer ce courriel (ainsi que toutes ses pi=E8ces j= ointes) > de tout ordinateur ou support de donn=E9es sans en imprimer une copie. > From fred@cisco.com Sun Sep 22 11:00:22 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AE221F9C3A for ; Sun, 22 Sep 2013 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf7waei2mytn for ; Sun, 22 Sep 2013 11:00:13 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0521F93B9 for ; Sun, 22 Sep 2013 11:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1379872813; x=1381082413; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=hWlIbshZs7f2Jn6vmDMW+MOeHMwhDhkYRTvR337eWEo6Au3IDEdtLlX7 T3pd1k1Jtp0cH0/axcX5ArWcT5T91gfR3dZl5qlnIm6s4jdTFyphA3fMr 253D1ng+eP4i1p3lbynTkZwKhnacePqL3s5ayGTpqzwe9AFZv1Rq/9gm+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMIAHQvP1KrRDoJ/2dsb2JhbABZgwewCgGSLoESFnSCSVw8NIhluimPZR2ECAOJOKA7g0Q X-IronPort-AV: E=Sophos;i="4.90,957,1371081600"; d="scan'208";a="89307896" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 22 Sep 2013 18:00:13 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8MI0CVB012169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Sep 2013 18:00:12 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r8MI0BWC029604; Sun, 22 Sep 2013 11:00:11 -0700 (PDT) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r8MI0B2g029598; Sun, 22 Sep 2013 11:00:11 -0700 (PDT) Date: Sun, 22 Sep 2013 11:00:11 -0700 (PDT) From: Fred Baker Message-Id: <201309221800.r8MI0B2g029598@irp-view13.cisco.com> To: v6ops@ietf.org Subject: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 18:00:23 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From swmike@swm.pp.se Sun Sep 22 11:36:59 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907B921F9E46 for ; Sun, 22 Sep 2013 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOaqdURJm+RL for ; Sun, 22 Sep 2013 11:36:59 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3366621F9D4C for ; Sun, 22 Sep 2013 11:36:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 42893A1; Sun, 22 Sep 2013 20:36:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3ED829A; Sun, 22 Sep 2013 20:36:54 +0200 (CEST) Date: Sun, 22 Sep 2013 20:36:54 +0200 (CEST) From: Mikael Abrahamsson To: Teemu Savolainen In-Reply-To: Message-ID: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 18:36:59 -0000 On Thu, 19 Sep 2013, Teemu Savolainen wrote: > Secondly, I don't agree DHCP server support is required, as the CE can > include the DNS addresses in RAs as specified in RFC6106. There are very few products out there that supports this way of conveying DNS resolver information. I am not opposed to say that providing basic 64share might skip supplying DNS resolver over IPv6, but then I agree with a few mail back where it was said we should have another document recommending how to get DNS resolver working for IPv6 only clients. -- Mikael Abrahamsson email: swmike@swm.pp.se From jouni.nospam@gmail.com Sun Sep 22 12:54:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615D111E814B for ; Sun, 22 Sep 2013 12:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn2DhE8-I1ry for ; Sun, 22 Sep 2013 12:54:13 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AB6E411E8147 for ; Sun, 22 Sep 2013 12:54:12 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id z15so1295629ead.5 for ; Sun, 22 Sep 2013 12:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iMS2emxKPIufez6CQxo1DQjqY4G6T0QyTHSt+iF3Hiw=; b=lARumz+YY38I7oChBkqGzH0/sBLlOT/ja2FJ/23rzIaAVRDzy1N5pQ4uIuCCI73RZf Xd5IhVl/nyraNvvKgfiRbXF5yX79ApYnIgIUa0AjwdquCpmz61rUA5H8LZ0pdi4B6u9+ S8XmJ6Q5bo7HJWVcGU4zuBSdeI3qe07cYk5DX3kw/My/rvMlVTyt+SYNLlLTEUz6wegD kf4uBvBnRxCcVmJnGJpXQaelueF4ktcveLsFTFVMlFZezzhoJ+YArGz5ew8GFxpdBKKi pVOQE4EOhYrRY4vVkFsiNQCc+AnuYIT8r+hG41gh/SNPNX5WtdcOPHGCeprV6qBGL9ZM Qd8g== X-Received: by 10.15.22.67 with SMTP id e43mr6322430eeu.47.1379879651836; Sun, 22 Sep 2013 12:54:11 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id d8sm36465181eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 12:54:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Sun, 22 Sep 2013 22:54:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 19:54:13 -0000 On Sep 22, 2013, at 9:36 PM, Mikael Abrahamsson = wrote: > On Thu, 19 Sep 2013, Teemu Savolainen wrote: >=20 >> Secondly, I don't agree DHCP server support is required, as the CE = can include the DNS addresses in RAs as specified in RFC6106. >=20 > There are very few products out there that supports this way of = conveying DNS resolver information. >=20 > I am not opposed to say that providing basic 64share might skip = supplying DNS resolver over IPv6, but then I agree with a few mail back = where it was said we should have another document recommending how to = get DNS resolver working for IPv6 only clients. Why wouldn't we add this (rather obvious) requirement to = draft-ietf-v6ops-mobile-device-profile? That would basically be just a = clarification to Req#10. - Jouni >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Sun Sep 22 19:55:17 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5873611E817B for ; Sun, 22 Sep 2013 19:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4GRH1bZSFop for ; Sun, 22 Sep 2013 19:55:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 43FB111E816E for ; Sun, 22 Sep 2013 19:55:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9CEC49C; Mon, 23 Sep 2013 04:55:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 90F559A; Mon, 23 Sep 2013 04:55:13 +0200 (CEST) Date: Mon, 23 Sep 2013 04:55:13 +0200 (CEST) From: Mikael Abrahamsson To: Jouni Korhonen In-Reply-To: Message-ID: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 02:55:17 -0000 On Sun, 22 Sep 2013, Jouni Korhonen wrote: > > On Sep 22, 2013, at 9:36 PM, Mikael Abrahamsson wrote: > >> On Thu, 19 Sep 2013, Teemu Savolainen wrote: >> >>> Secondly, I don't agree DHCP server support is required, as the CE can include the DNS addresses in RAs as specified in RFC6106. >> >> There are very few products out there that supports this way of conveying DNS resolver information. >> >> I am not opposed to say that providing basic 64share might skip supplying DNS resolver over IPv6, but then I agree with a few mail back where it was said we should have another document recommending how to get DNS resolver working for IPv6 only clients. > > Why wouldn't we add this (rather obvious) requirement to draft-ietf-v6ops-mobile-device-profile? That would basically be just a clarification to Req#10. Absolutely fine, draft-ietf-v6ops-mobile-device-profile could be this "other document". -- Mikael Abrahamsson email: swmike@swm.pp.se From nick.heatley@ee.co.uk Mon Sep 23 06:02:34 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF6A21F9AD5 for ; Mon, 23 Sep 2013 06:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUfri742oc2y for ; Mon, 23 Sep 2013 06:02:29 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9076621F8514 for ; Mon, 23 Sep 2013 06:02:28 -0700 (PDT) Received: from [85.158.139.3:39998] by server-8.bemta-5.messagelabs.com id 32/B5-17437-3EB30425; Mon, 23 Sep 2013 13:02:27 +0000 X-Env-Sender: nick.heatley@ee.co.uk X-Msg-Ref: server-15.tower-90.messagelabs.com!1379941346!626748!1 X-Originating-IP: [193.36.79.210] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27580 invoked from network); 23 Sep 2013 13:02:26 -0000 Received: from unknown (HELO aphex) (193.36.79.210) by server-15.tower-90.messagelabs.com with SMTP; 23 Sep 2013 13:02:26 -0000 Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id ; Mon, 23 Sep 2013 14:06:28 +0100 Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([fe80::5093:62a6:6ee3:7198%11]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 14:02:25 +0100 From: "Heatley, Nick" To: Dave Michaud , GangChen , IPv6 Ops WG Thread-Topic: draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac62C32cNXuCWp3LTsmN64khizODhACTaS9w Date: Mon, 23 Sep 2013 13:02:25 +0000 Message-ID: <6536E263028723489CCD5B6821D4B213039E5E17@UK30S005EXS06.EEAD.EEINT.CO.UK> References: <29AE8DB910E7704CA043795E00DCBE780A363F34@CL08MBE.rci.rogers.ca> In-Reply-To: <29AE8DB910E7704CA043795E00DCBE780A363F34@CL08MBE.rci.rogers.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.246.208.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Cameron Byrne Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:02:34 -0000 SGkgRGF2ZSwNCldlIGFyZSBhbHNvIGludGVyZXN0ZWQgaW4gdGhlIHVzZSBvZiBob21lIEFBQSAo b2ZmbGluZSByYWRpdXMgZnJvbSBQR1csIG5vdCBvbiBHaSBTR2kgaW50ZXJmYWNlKSB0byBjb250 cm9sIGhvdyBhIFBEUCB0eXBlIElQdjR2NiByZXF1ZXN0IGNhbiByZXR1cm4gYW4gUERQIHR5cGUg SVB2NiByZXNwb25zZSwgYmFzZWQgb24gSU1FSSBUQUMuDQoNClJlZ2FyZGluZyBJTUVJIFRBQywg d2UgYXNzdW1lIHRoYXQgd2UgY2FuIGZpbmQgZGV2aWNlIGhhcmR3YXJlIGJ1aWxkcyB0aGF0IHVu ZXF1aXZvY2FsbHkgc3VwcG9ydCA0NjR4bGF0OyBvdXIgZGV2aWNlcyB0ZWFtIGFyZSBzdXNwaWNp b3VzIG9mIGZvcmtpbmcgb2Ygc29mdHdhcmUgYW5kIGhhcmR3YXJlIGJ1aWxkcywgZXNwZWNpYWxs eSB3aXRoIGEgYmlnIGdyZXkgbWFya2V0LiBXZSBhbHNvIGFzc3VtZSB0aGF0IG9uIGFsbCBkZXZp Y2VzIHRoZSA0NjR4bGF0IGlzIGludm9rZWQgcGVyIEFQTiBiYXNlZCBvbiB0aGUgUERQIHR5cGUg cmV0dXJuZWQsIG5vdCB0aGUgUERQIHR5cGUgcmVxdWVzdGVkIChsb2dpY2FsLCBidXQgSSBkb24n dCB0aGluayBJIGhhdmUgc2VlbiB0aGlzIHdyaXR0ZW4gZG93bikuDQoNCk1heSBJIGFzayBhIHF1 ZXN0aW9uIG9uOg0KPlNHU04gTUNDLU1OQzogd2l0aG91dCBhIGNvbmZpcm1hdGlvbiB0aGF0IHRo aXMgUExNTiBJRCBzdXBwb3J0cyBJUHY2LCBmYWxsYmFjayB0byBJUHY0DQoNCkdpdmVuIHRoYXQg MSkgdGhlIEhTUy9ITFIgd2hpdGVsaXN0IGhhcyBhbHJlYWR5IGJlZW4gcGFzc2VkLCAyKSB0aGUg cmVxdWVzdCBoYXMgdG8gYmUgSVB2NHY2LCBhbmQgMykgdGhlIHZpc2l0ZWQgU0dTTiBoYXMgYWxs b3dlZCB0aGUgSVB2NHY2IHJlcXVlc3QgdG8gcmVhY2ggdGhlIGhvbWUgbmV0d29yaywgY2FuIHlv dSBhc3N1bWUgdGhlIHZpc2l0ZWQgbmV0d29yayBjYW4gc3VwcG9ydCBJUHY2IG9yIG5vdD8gSSBh bSB3b25kZXJpbmcgd2hhdCBwcm9ibGVtIHNjZW5hcmlvcyBkb2VzIHRoZSBQTE1OIGlkIHdoaXRl bGlzdCBvbiBBQUEgc29sdmU/DQoNCkdyZWF0IGluZm9ybWF0aW9uLCB0aGFua3MgZm9yIHNoYXJp bmcgeW91ciBleHBlcmllbmNlIGhlcmUuDQpOaWNrDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2ZSBNaWNoYXVkDQpTZW50OiAyMCBTZXB0ZW1iZXIg MjAxMyAxNToxMw0KVG86IEdhbmdDaGVuOyBJUHY2IE9wcyBXRw0KQ2M6IENhbWVyb24gQnlybmUN ClN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtY2hlbi12Nm9wcy1pcHY2LXJvYW1pbmctYW5hbHlzaXMN Cg0KSGkgR2FuZywNCg0KVGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgY29tbWVudHMgb24gdGhpcyBk cmFmdCBhbHJlYWR5IGFuZCBhIHByZXNlbnRhdGlvbiBhdCBJRVRGODcgYnV0IG5vdGhpbmcgaGFz IGJlZW4gaW5jbHVkZWQgaW4gYSByZXZpc2VkIHZlcnNpb24geWV0IHNvIGl0J3MgZGlmZmljdWx0 IHRvIGhhdmUgYSBjbGVhciB2aWV3IG9mIHdoZXJlIHdlIHN0YW5kIGF0IHRoaXMgcG9pbnQgYW5k IGNvbW1lbnQgZnVydGhlci4NCg0KTm9uZXRoZWxlc3MsIEknZCBsaWtlIHRvIHNoYXJlIG91ciBv d24gZXhwZXJpZW5jZSBpbiBkZXBsb3lpbmcgSVB2NiBmb3Igb3VyIGhvbWUgc3Vic2NyaWJlcnMg YW5kIHRoZSBleHBlY3RlZCByb2FtaW5nIGltcGFjdC4gSSBndWVzcyBpdCBjYW4gc2VydmUgYXMg aW5wdXQgZm9yIHRoaXMgZHJhZnQgb3IgZm9yIGEgZnV0dXJlIEJDUC4gT3VyIHRhcmdldCBpcyB0 byBlbmFibGUgSVB2Ni1vbmx5IChhbmQgbm90IGR1YWwtc3RhY2spIGZvciBhcyBtYW55IHN1YnNj cmliZXIgYXMgd2UgY2FuLCByb2FtaW5nIG9yIG5vdCBidXQgb2J2aW91c2x5IHdlIHdhbnQgdG8g ZW5zdXJlIHRoYXQgdGhlIHNlcnZpY2Uga2VlcHMgd29ya2luZyBhcyBpdCBkb2VzIHRvZGF5LiBX ZSBhcmUgYWxzbyBub3QgdXNpbmcgdlBMTU4gbG9jYWwgYnJlYWtvdXQgKHdoaWNoIGlzIHRoZSBj YXNlIGZvciBtb3N0IG9wZXJhdG9ycykgYnV0IG1heSBjaGFuZ2UgZm9yIElNUyBzaXR1YXRpb25z IGluIHRoZSBmdXR1cmUuDQoNCi0tLS0gVUUgQ29uZmlndXJhdGlvbiAtLS0tDQpVRSBjYW4gYmUg c2V0IHRvIHJlcXVlc3QgYSBQRFAvUEROIFR5cGUgSVB2NCwgSVB2NHY2IG9yIElQdjYuIENlcnRh aW4gVUUgaGF2ZSB0aGUgYWJpbGl0eSBhIGRpZmZlcmVudCBjb25maWd1cmF0aW9uIGZvciBob21l IG5ldHdvcmsgLyB2aXNpdGVkIG5ldHdvcmsuIFNpbmNlIHRoaXMgaXMgcmVsYXRlZCB0byByb2Ft aW5nIGNhc2UsIG15IGNvbW1lbnRzIGFwcGx5IHRvIHRoZSByb2FtaW5nIHByb2ZpbGUgb3IgdGhl IGhvbWUvcm9hbWluZyBwcm9maWxlIGlmIHRoZXJlIGlzIG5vIGRpc3RpbmN0aW9uLiBUaGlzIGlz IHdoYXQgdGhlIFVFIHJlcXVlc3QsIG5vdCBuZWNlc3NhcmlseSB0aGUgZmluYWwgUERQL1BETiBU eXBlLi4uDQoNCi0gSVB2NDogaGFzIGJlZW4gd29ya2luZyBmb3IgeWVhcnMsIG5vIGlzc3VlDQot IElQdjY6IGlmIHRoZSBVRSByZXF1ZXN0IElQdjYtb25seSBhbmQgYSBub2RlIGluIHRoZSBwYXRo IGNhbid0IHN1cHBvcnQgaXQgKGllLiB2aXNpdGVkIFNHU04pLCB0aGVyZSBpcyBubyBwb3NzaWJs ZSBmYWxsYmFjayBhbmQgZGF0YSBpcyBicm9rZW4uIFRoaXMgY29uZmlndXJhdGlvbiBzaG91bGQg YmUgYXZvaWRlZC4NCi0gSVB2NHY2OiB0aGlzIGlzIGxlYXN0IHN1cHBvcnRlZCBjb25maWd1cmF0 aW9uIChiYXNlZCBvbiByZXF1aXJlZCAzR1BQIHJlbGVhc2UgaW4gU0dTTikgYnV0IGFsc28gdGhl IGNvbmZpZ3VyYXRpb24gdGhhdCBvZmZlcnMgdGhlIG1vc3QgZmxleGliaWxpdHkuIEFzIHBlciAz R1BQIDI0LjAwOCwgdGhpcyBQRFAvUEROIFR5cGUgc2hvdWxkIGJlIGludGVycHJldGVkIGFzIElQ djQgYnkgdGhlIFNHU04vTU1FIGlmIGl0IGRvZXNuJ3QgdW5kZXJzdGFuZCBpdC4gDQoNCldlIGhh dmUgaGFkIHNvbWUgVUUgbW9kZWxzIGNvbmZpZ3VyZWQgdG8gcmVxdWVzdCB0aGlzIFBEUC9QRE4g dHlwZSBpbiBjaXJjdWxhdGlvbiBmb3Igb3ZlciBhIHllYXIgbm93IGFuZCB3ZSBoYXZlIG9ic2Vy dmVkIGNhc2VzIHdoZXJlIHRoZSB2U0dTTiB3YXMgc2ltcGx5IHJlamVjdGluZyB0aGUgUERQIENv bnRleHQgQ3JlYXRpb24gbWVzc2FnZSB3aXRoIGEgY2F1c2UgY29kZSAjMjcgKFVua25vd24gb3Ig bWlzc2luZyBBUE4pIGJlY2F1c2UgaXQgc3RvcHBlZCBwcm9jZXNzaW5nIHRoZSBtZXNzYWdlIGF0 IHRoZSBQRFAgdHlwZSAoQVBOIG5hbWUgY29tZXMgcmlnaHQgYWZ0ZXIpLiBUaGlzIGhvd2V2ZXIg aGFzIGJlZW4gYW4gZXh0cmVtZWx5IGxpbWl0ZWQgY29ybmVyIGNhc2Ugd2l0aCAyIGNvbmZpcm1l ZCBvcGVyYXRvcnMuIFVsdGltYXRlbHksIHdlIGFyZSBub3cgY29uZmlndXJpbmcgbW9zdCBVRSB0 byByZXF1ZXN0IElQdjR2NiB3aGlsZSByb2FtaW5nICh3ZSBrZXB0IHNvbWUgZmxhZ3NoaXAgZGV2 aWNlcyBhcyBJUHY0LW9ubHkgZm9yIG5vdyBhcyB3ZSBidWlsZCBhIGRhdGFiYXNlIG9mIHdvcmtp bmcgUExNTnMpLg0KDQotLS0tIFNHU04vTU1FIGZvciBNb2JpbGl0eSBNYW5hZ2VtZW50IFByb2Nl ZHVyZXMgKEF0dGFjaCkgLS0tLSBPbiBhdHRhY2gsIHRoZSBTR1NOL01NRSBtdXN0IGNvbnRhY3Qg dGhlIGhvbWUgSExSL0hTUyBhbmQgb2J0YWluIHRoZSBzdWJzY3JpYmVyIHByb2ZpbGUuIEl0IGlz IHdlbGwga25vd24gbm93IGFuZCBoYXMgYmVlbiBvYnNlcnZlZCBmaXJzdCBoYW5kIGJ5IHNvbWUg b2YgdXMgaGVyZSB0aGF0IG11bHRpcGxlIFNHU04vTU1FIHdpbGwgYmUgdW5hYmxlIHRvIGNvcnJl Y3RseSBwcm9jZXNzIGEgc3Vic2NyaWJlciBwcm9maWxlIHJlY2VpdmVkIGluIHRoZSBJbnNlcnQg U3Vic2NyaWJlciBEYXRhIHByb2NlZHVyZSBpZiBpdCBjb250YWlucyBhbiBFeHQtUERQLVR5cGUg KDNHUFAgVFMgMjkuMDAyIC8gM0dQUCBUUyAyOS4wNjApLiBJbiB0aGF0IGNhc2UsIGl0IGJyZWFr cyBkYXRhIHNvIHRoaXMgc2l0dWF0aW9uIG11c3QgYmUgYXZvaWRlZC4NCg0KRGV0YWlscyBvbiB0 aGUgc29sdXRpb24gYXJlIGluIHRoZSBITFIgc2VjdGlvbiBiZWxvdyBidXQgdWx0aW1hdGVseSwg dW5sZXNzIHdlIGtub3cgZm9yIHN1cmUgdGhhdCBhbiBTR1NOIChhbmQgdGhlIG9wZXJhdG9yIGlu IGdlbmVyYWwgYXMgcGVyIElSLjIxKSwgdGhlIFNHU04gd2lsbCByZWNlaXZlIGEgc3Vic2NyaWJl ciBwcm9maWxlIHRoYXQgY29udGFpbnMgSVB2NC1vbmx5IGFzIHRoZSBhdmFpbGFibGUgUERQIHR5 cGUgKG5vdCBwcmVzZW5jZSBvZiBJUHY2IGF0IGFsbCkuDQoNCkF0IHRoaXMgc3RhZ2UsIHRoZSBT R1NOIHNob3VsZCB0aGVyZWZvcmUgcmVjZWl2ZSBhIHN1YnNjcmliZXIgcHJvZmlsZSBjb250YWlu aW5nIG9ubHkgZmllbGRzIGl0IGNhbiB1bmRlcnN0YW5kIGFuZCB0aGlzIGF0dGFjaCB3aWxsIGNv bXBsZXRlIHN1Y2Nlc3NmdWxseS4NCg0KLS0tLSBTR1NOL01NRSBmb3IgU2Vzc2lvbiBNYW5hZ2Vt ZW50IFByb2NlZHVyZXMgKFBEUCBDb250ZXh0L0JlYXJlcikgLS0tLSBXaGVuIHRoZSBTR1NOL01N RSByZWNlaXZlcyBhIHNlc3Npb24gY3JlYXRpb24gcmVxdWVzdCBmcm9tIHRoZSBVRSAoUERQL1BE TiBUeXBlIElQdjR2NiksIHRoZSBmb2xsb3dpbmcgc2l0dWF0aW9ucyBhcmUgcG9zc2libGU6DQoN CjEuIFNHU04vTU1FIGRvZXMgbm90IHVuZGVyc3RhbmQgSVB2NHY2IHNvIGl0IGZhbGxzIGJhY2sg dG8gSVB2NCBhcyBwZXIgc3BlYyAyLiBTR1NOL01NRSB1bmRlcnN0YW5kcyBJUHY0djYgYnV0IHRo ZSBzdWJzY3JpYmVyIHByb2ZpbGUgZGlkIG5vdCBjb250YWluIEV4dC1QRFAtVHlwZSBzbyBpdCBm YWxscyBiYWNrIHRvIElQdjQgMy4gU0dTTi9NTUUgdW5kZXJzdGFuZHMgSVB2NHY2IGJ1dCBhcyBw ZXIgYSBsb2NhbCBwb2xpY3kgZG9lcyBub3QgYWxsb3cgaXQgc28gaXQgZmFsbHMgYmFjayB0byBJ UHY0DQogICBhLiBJUHY2IGJpbGxpbmcgbm90IHN1cHBvcnRlZA0KICAgYi4gSVB2NiBub3QgbGlj ZW5zZWQNCiAgIGMuIExvY2FsIGRlY2lzaW9uLi4uDQo0LiBTR1NOL01NRSBkb2VzIG5vdCB1bmRl cnN0YW5kIElQdjR2NiBhbmQgaXQgZG9lcyBub3QgZmFsbCBiYWNrIHRvIElQdjQuDQoNClBvaW50 IDQgaXMgZm9yIHVzIHRoZSBtb3N0IGNyaXRpY2FsIGFzcGVjdCBhbmQgdGhlIG9uZSB3ZSBhcmUg Zm9sbG93aW5nIGNsb3NlbHkuDQoNCkJhc2VkIG9uIHRoZSBhYm92ZSBvcHRpb25zLCB0aGUgU0dT Ti9NTUUgZm9yd2FyZHMgdG8gdGhlIEdHU04vUy1HVyBhIHNlc3Npb24gY3JlYXRpb24gcmVxdWVz dCB3aXRoIGVpdGhlciBhIFBEUCBUeXBlIG9mIElQdjQgb3IgSVB2NHY2Lg0KDQotLS0tIEhMUi9I U1MgLS0tLQ0KV2hlbiB0aGUgSExSIHJlY2VpdmVzIGFuIFVwZGF0ZSBHUFJTIExvY2F0aW9uIG1l c3NhZ2UsIGl0IGhhcyB0byBwcm92aWRlIHRoZSBzdWJzY3JpYmVyIHByb2ZpbGUgdG8gdGhlIHJl cXVlc3RpbmcgZW50aXR5LiBBbGwgc3Vic2NyaWJlcnMgaGF2ZSB0aGVpciBBUE5zIHNldCBmb3Ig SVB2NC1vbmx5IHdpdGggZXh0ZW5kZWQgUERQIHN1cHBvcnQgKElQdjR2NikuDQoNCldoZW4gcmVj ZWl2aW5nIHRoaXMgbWVzc2FnZSwgdGhlIEhMUiBjb21wYXJlcyB0aGUgU0dTTiBWTFIgYWRkcmVz cyB3aXRoIGEgd2hpdGVsaXN0IGRhdGFiYXNlIGFuZCBkZWNpZGUgaWYgdGhlIFNHU04gaXMgZGVl bWVkIElQdjYgY29tcGxpYW50LiBBdCBmaXJzdCwgdGhpcyBkYXRhYmFzZSB3aWxsIGJlIGVtcHR5 IGJ1dCBhcyBJUHY2IHN1cHBvcnQgaXMgY29uZmlybWVkIHRocm91Z2ggZWl0aGVyIHRlc3Rpbmcs IGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBvcGVyYXRvciBvciB0aGUgSVIuMjEsIHdlIHdpbGwgcG9w dWxhdGUgdGhpcyBkYXRhYmFzZS4NCg0KVWx0aW1hdGVseSwgdGhlIEhMUiBzZW5kcyBvdXQgYSBw cm9maWxlIHRoYXQgZWl0aGVyIGNvbnRhaW5zIElQdjQgb25seSBvciBJUHY0ICsgSVB2NHY2IGJh c2VkIG9uIHRoaXMgd2hpdGVsaXN0IGRhdGFiYXNlLg0KDQpVbmZvcnR1bmF0ZWx5LCB0aGlzIGlz IG5vdCB5ZXQgYSBzdGFuZGFyZCBmZWF0dXJlIGluIGFueSBITFIgYnV0IG91ciBITFIgdmVuZG9y IGhhcyBiZWVuIGNvb3BlcmF0aXZlIHRvIGRldmVsb3AgdGhpcyBtYXJrZXQgY3VzdG9taXphdGlv biBmb3IgdXMuDQoNCi0tLS0gR0dTTi9TLUdXL1AtR1cgLS0tLQ0KV2hlbiB0aGUgR0dTTi9QLUdX IHJlY2VpdmVzIGEgc2Vzc2lvbiBjcmVhdGlvbiByZXF1ZXN0LCBpdCBjYW1lIGluIGFzIGVpdGhl ciBJUHY0IG9yIElQdjR2NiAoc2VlIFNHU04vTU1FIGZvciBTZXNzaW9uIE1hbmFnZW1lbnQpLiBU aGUgQVBOcyBvbiB0aGUgR0dTTi9QLUdXIHRoYXQgdGhlIGN1c3RvbWVycyBhcmUgcmVxdWVzdGlu ZyBhcmUgY29uZmlndXJlZCB0byBzdXBwb3J0IElQdjR2NiAoYW5kIGJ5IGV4dGVuc2lvbiBJUHY0 LW9ubHkgYW5kIElQdjYtb25seSkuIE9uIHNlc3Npb24gY3JlYXRpb24gcmVxdWVzdCwgdGhlIEdH U04vUC1HVyBzZW5kcyBhbiBBY2Nlc3MtUmVxdWVzdCB0byBhIEFBQSBzZXJ2ZXIsIHNlbmRpbmcg dGhlIHZTR1NOIE1DQytNTkMsIHRoZSBJTUVJIGFuZCB0aGUgUERQIFR5cGUgcmVjZWl2ZWQuDQoN ClRoZSBBQUEgQWNjZXNzLUFjY2VwdCBjb250YWlucyBhIG5ldyBBUE4gbmFtZSB0aGF0IHRoZSBH R1NOL1AtR1cgd2lsbCB1c2UgdG8gZWZmZWN0aXZlbHkgZXN0YWJsaXNoIHRoZSBzZXNzaW9uLiBU aGUgcmVkaXJlY3Rpb24gQVBOIGlzIHVzZWQgbWFrZSBhIGZpbmFsIHNlbGVjdGlvbiBvbiB0aGUg SVAgdHlwZSB1c2VkIChJUHY0IG9yIElQdjYgb3IgSVB2NHY2KQ0KDQpSZXF1ZXN0ZWQgQVBOOiBp bnRlcm5ldA0KUG9zc2libGUgQUFBIG91dHB1dDogdjQuaW50ZXJuZXQsIGRzLmludGVybmV0IG9y IHY2LmludGVybmV0DQoNCi0tLS0gQUFBIFNlcnZlciAtLS0tDQpUaGUgQUFBIHJlY2VpdmVzIHRo ZSBBY2Nlc3MtUmVxdWVzdCBmcm9tIHRoZSBHR1NOL1AtR1cuIEl0IGltcGxlbWVudHMgYSBsb2dp YyB0aGF0IHdpbGwgdWx0aW1hdGVseSBkZWNpZGUgd2hhdCB0eXBlIG9mIFBEUCB3ZSBzaG91bGQg dXNlIGZvciB0aGlzIHNlc3Npb24uDQoNClRoZSBmb2xsb3dpbmcgY2hlY2tzIGFyZSBwZXJmb3Jt ZWQ6DQotIFJlcXVlc3RlZCBQRFAgVHlwZTogaWYgSVB2NCBvciBJUHY2LCBhbnkgY2hhbmdlIHdp bGwgYnJlYWsgdGhlIGRhdGEgc2Vzc2lvbiBzbyBhbGxvdyBhcyBpcyAodjQgd291bGQgYmUgZm9y IG9sZGVyIGRldmljZXMgb3IgYSBmYWxsYmFjayBzY2VuYXJpbyBhbG9uZyB0aGUgcGF0aDsgdjYg d291bGQgYmUgYmVjYXVzZSB0aGUgdXNlciByZWNvbmZpZ3VyZWQgaGlzIFVFIHRvIGRpcmVjdGx5 IHJlcXVlc3QgSVB2NiBpbnN0ZWFkIG9mIHRoZSBkZWZhdWx0IElQdjR2NikNCi0gU0dTTiBNQ0Mt TU5DOiB3aXRob3V0IGEgY29uZmlybWF0aW9uIHRoYXQgdGhpcyBQTE1OIElEIHN1cHBvcnRzIElQ djYsIGZhbGxiYWNrIHRvIElQdjQNCi0gSU1FSTogZXh0cmFjdCBUQUMgYW5kIFNWIGNvbXBvbmVu dHMgYW5kIHZlcmlmeSBpZiBkZXZpY2UgaGFzIDQ2NFhMQVQgc3VwcG9ydC4gSWYgaXQgZG9lcywg YWxsb3cgSVB2Ni1vbmx5LCBvdGhlcndpc2UgYWxsb3cgZHVhbC1zdGFjaw0KDQpCYXNlZCBvbiB0 aGUgYWJvdmUgY2hlY2tzLCB0aGUgQUFBIHdpbGwgZGVjaWRlIHdoaWNoIEFQTiB0byBzZW5kIHRo ZSBjdXN0b21lciB0byBhbmQgdGhpcyBpcyB3aGF0IHdpbGwgdWx0aW1hdGVseSBkZWNpZGUgaWYg d2UgYWxsb3cgSVB2Ni1vbmx5IHJvYW1pbmcgb3Igbm90Lg0KDQoNCkRhdmUgTWljaGF1ZA0KDQoN Cg0KVGhpcyBlLW1haWwgKGFuZCBhdHRhY2htZW50KHMpKSBpcyBjb25maWRlbnRpYWwsIHByb3By aWV0YXJ5LCBtYXkgYmUgc3ViamVjdCB0byBjb3B5cmlnaHQgYW5kIGxlZ2FsIHByaXZpbGVnZSBh bmQgbm8gcmVsYXRlZCByaWdodHMgYXJlIHdhaXZlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBvciBpdHMgYWdlbnQsIGFueSByZXZpZXcsIGRpc3NlbWluYXRpb24sIGRp c3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgZS1tYWlsIG9yIGFueSBvZiBpdHMgY29udGVu dCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIEFsbCBtZXNzYWdl cyBtYXkgYmUgbW9uaXRvcmVkIGFzIHBlcm1pdHRlZCBieSBhcHBsaWNhYmxlIGxhdyBhbmQgcmVn dWxhdGlvbnMgYW5kIG91ciBwb2xpY2llcyB0byBwcm90ZWN0IG91ciBidXNpbmVzcy4gRS1tYWls cyBhcmUgbm90IHNlY3VyZSBhbmQgeW91IGFyZSBkZWVtZWQgdG8gaGF2ZSBhY2NlcHRlZCBhbnkg cmlzayBpZiB5b3UgY29tbXVuaWNhdGUgd2l0aCB1cyBieSBlLW1haWwuIElmIHJlY2VpdmVkIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIGUtbWFp bCAoYW5kIGFueSBhdHRhY2htZW50cykgZnJvbSBhbnkgY29tcHV0ZXIgb3IgYW55IHN0b3JhZ2Ug bWVkaXVtIHdpdGhvdXQgcHJpbnRpbmcgYSBjb3B5Lg0KDQpDZSBjb3VycmllbCAoYWluc2kgcXVl IHNlcyBwacOoY2VzIGpvaW50ZXMpIGVzdCBjb25maWRlbnRpZWwsIGV4Y2x1c2lmLCBldCBwZXV0 IGZhaXJlIGzigJlvYmpldCBkZSBkcm9pdCBk4oCZYXV0ZXVyIGV0IGRlIHByaXZpbMOoZ2UganVy aWRpcXVlOyBhdWN1biBkcm9pdCBjb25uZXhlIG7igJllc3QgZXhjbHUuIFNpIHZvdXMgbuKAmcOq dGVzIHBhcyBsZSBkZXN0aW5hdGFpcmUgdmlzw6kgb3Ugc29uIHJlcHLDqXNlbnRhbnQsIHRvdXRl IMOpdHVkZSwgZGlmZnVzaW9uLCB0cmFuc21pc3Npb24gb3UgY29waWUgZGUgY2UgY291cnJpZWwg ZW4gdG91dCBvdSBlbiBwYXJ0aWUsIGVzdCBzdHJpY3RlbWVudCBpbnRlcmRpdGUgZXQgcGV1dCDD qnRyZSBpbGzDqWdhbGUuIFRvdXMgbGVzIG1lc3NhZ2VzIHBldXZlbnQgw6p0cmUgc3VydmVpbGzD qXMsIHNlbG9uIGxlcyBsb2lzIGV0IHLDqGdsZW1lbnRzIGFwcGxpY2FibGVzIGV0IGxlcyBwb2xp dGlxdWVzIGRlIHByb3RlY3Rpb24gZGUgbm90cmUgZW50cmVwcmlzZS4gTGVzIGNvdXJyaWVscyBu ZSBzb250IHBhcyBzw6ljdXJpc8OpcyBldCB2b3VzIMOqdGVzIHLDqXB1dMOpcyBhdm9pciBhY2Nl cHTDqSB0b3VzIGxlcyByaXNxdWVzIHF1aSB5IHNvbnQgbGnDqXMgc2kgdm91cyBjaG9pc2lzc2V6 IGRlIGNvbW11bmlxdWVyIGF2ZWMgbm91cyBwYXIgY2UgbW95ZW4uIFNpIHZvdXMgYXZleiByZcOn dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IG5vdXMgZW4gYXZpc2VyIGltbcOpZGlh dGVtZW50IGV0IHN1cHByaW1lciBjZSBjb3VycmllbCAoYWluc2kgcXVlIHRvdXRlcyBzZXMgcGnD qGNlcyBqb2ludGVzKSBkZSB0b3V0IG9yZGluYXRldXIgb3Ugc3VwcG9ydCBkZSBkb25uw6llcyBz YW5zIGVuIGltcHJpbWVyIHVuZSBjb3BpZS4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQpOT1RJQ0UgQU5E IERJU0NMQUlNRVINClRoaXMgZS1tYWlsIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBpcyBp bnRlbmRlZCBmb3IgdGhlIGFib3ZlLW5hbWVkIHBlcnNvbihzKS4gIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LCBkZWxl dGUgdGhpcyBlbWFpbCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBkbyBub3QgZGlzY2xvc2Ugb3IgdXNl IGZvciBhbnkgcHVycG9zZS4gIA0KIA0KV2UgbWF5IG1vbml0b3IgYWxsIGluY29taW5nIGFuZCBv dXRnb2luZyBlbWFpbHMgaW4gbGluZSB3aXRoIGN1cnJlbnQgbGVnaXNsYXRpb24uIFdlIGhhdmUg dGFrZW4gc3RlcHMgdG8gZW5zdXJlIHRoYXQgdGhpcyBlbWFpbCBhbmQgYXR0YWNobWVudHMgYXJl IGZyZWUgZnJvbSBhbnkgdmlydXMsIGJ1dCBpdCByZW1haW5zIHlvdXIgcmVzcG9uc2liaWxpdHkg dG8gZW5zdXJlIHRoYXQgdmlydXNlcyBkbyBub3QgYWR2ZXJzZWx5IGFmZmVjdCB5b3UuIA0KDQpF RSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzDQpDb21wYW55IFJlZ2lz dGVyZWQgTnVtYmVyOiAwMjM4MjE2MQ0KUmVnaXN0ZXJlZCBPZmZpY2UgQWRkcmVzczogVHJpZGVu dCBQbGFjZSwgTW9zcXVpdG8gV2F5LCBIYXRmaWVsZCwgSGVydGZvcmRzaGlyZSwgQUwxMCA5QlcN Cg== From alexandru.petrescu@gmail.com Mon Sep 23 07:03:12 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1120121F9EAE for ; Mon, 23 Sep 2013 07:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.862 X-Spam-Level: X-Spam-Status: No, score=-8.862 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+FAkqV2WBn5 for ; Mon, 23 Sep 2013 07:03:07 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9E76C21F9B18 for ; Mon, 23 Sep 2013 07:03:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r8NE35fi006929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Sep 2013 16:03:05 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r8NE35Nb023229 for ; Mon, 23 Sep 2013 16:03:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r8NE30l4030916 for ; Mon, 23 Sep 2013 16:03:04 +0200 Message-ID: <52404A14.1080302@gmail.com> Date: Mon, 23 Sep 2013 16:03:00 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:03:12 -0000 Le 19/09/2013 22:54, Mark ZZZ Smith a écrit : > >> ________________________________ From: Teemu Savolainen >> To: holger.metschulat@telekom.de Cc: >> v6ops@ietf.org Sent: Friday, 20 September 2013 6:40 AM Subject: Re: >> [v6ops] draft-ietf-v6ops-64share WGLC >> >> >> >> The DNS handling might suite for >> draft-ietf-v6ops-mobile-device-profile Section 4, but in my opinion >> not to this document as it is not within the narrow scope. > > Agree it is out of scope for this draft. > >> Secondly, I don't agree DHCP server support is required, as the CE >> can include the DNS addresses in RAs as specified in RFC6106. >> > > How could a CE convey NTP server settings to hosts using RAs? > Accurate host time is pretty useful, if not essential. In addition to NTP time, DHCP would be needed to deliver a prefix as well (in the sense of prefix delegation), because RA couldnt. (yes accurate time is often essential in safety and mission-critical applications). Still, the 64share method is useful and it works. Alex > > > >> >> Best regards, Teemu On Sep 19, 2013 9:41 PM, >> wrote: >> >> Hello all, >>> >>> I believe this needs to be looked at. DNS server addresses are >>> sent from the network to the mobile host ("CE" in this scenario) >>> by outband 3GPP signalling and need to be queried by the CE OS >>> driver from the radio chip. >>> >>> In order to convey the DNS information to the clients attached >>> via the LAN, the CE performing 64share needs to handle the DHCP >>> solicits and answer on the network's behalf because simply >>> forwarding the DHCP solicits will not work at all (the network >>> won't answer them). >>> >>> Holger >>> >>> -----Ursprüngliche Nachricht----- Von: v6ops-bounces@ietf.org >>> [mailto:v6ops-bounces@ietf.org] Im Auftrag von Mark ZZZ Smith >>> Gesendet: Mittwoch, 18. September 2013 23:59 An: Teemu >>> Savolainen; Tassos Chatzithomaoglou; v6ops@ietf.org Betreff: Re: >>> [v6ops] draft-ietf-v6ops-64share WGLC >>> >>> +1 >>> >>> This purpose here is to describe a work around to a limitation, >>> not to specify how RAs/DHCPv6 are supposed to be generally used >>> and what options are present in them. I don't think RA or DHCPv6 >>> options that aren't essential or useful to this *specific* >>> scenario should be mentioned at all. DNS in RAs is not special to >>> or necessary to sharing a /64. >>> >>> Generally related to DHCPv6 option passing across a CE device (of >>> which this would be one), I posted the following draft a while >>> ago. I'd be interested in comments. >>> >>> "IPv6 CE Device DHCPv6 Option Transparency" >>> >>> http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00 >>> >>> >>> >>> >>> >>>> >>> ________________________________ >>>> From: Teemu Savolainen To: Tassos >>>> Chatzithomaoglou ; "v6ops@ietf.org" >>>> Sent: Monday, 16 September 2013 4:12 PM >>>> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC >>>> >>>> >>>> >>>> IMHO it is better to keep this draft focused solely on address >>>> sharing, and not to go to other configuration topic or other >>>> possible problems. >>>> >>>> Btw most often, as of now, the "original" DNS server addresses >>>> are received via link layer signaling (see >>>> http://www.ietf.org/id/draft-ietf-v6ops-rfc3316bis-06.txt >>>> section 2.10), and thus, for example, may need to be added to >>>> "proxied" RA. >>>> >>>> Best regards, >>>> >>>> Teemu >>>> >>>> ________________________________ From: Tassos Chatzithomaoglou >>>> Sent: 15.9.2013 23:20 To: v6ops@ietf.org Subject: Re: [v6ops] >>>> draft-ietf-v6ops-64share WGLC >>>> >>>> Just a quick question... >>>> >>>> I don't see any reference of DNS servers under 3.1, only MTU & >>>> Prefix. Shouldn't there be a bullet showing that DNS info (UE >>>> address as DNS proxy, or original through-RA/DHCPv6 DNS >>>> servers) should also pass on the LAN link? >>>> >>>> -- Tassos >>>> >>>> Fred Baker wrote on 15/9/2013 21:00: >>>>> This is to initiate a two week working group last call of >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please >>>>> read it now. If you find nits (spelling errors, minor >>>>> suggested wording changes, etc), comment to the authors; if >>>>> you find greater issues, such as disagreeing with a statement >>>>> or finding additional issues that need to be addressed, >>>>> please post your comments to the list. >>>>> >>>>> We are looking specifically for comments on the importance of >>>>> the document as well as its content. If you have read the >>>>> document and believe it to be of operational utility, that is >>>>> also an important comment to make. >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From alexandru.petrescu@gmail.com Mon Sep 23 07:09:28 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9661621F9F8E for ; Mon, 23 Sep 2013 07:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.94 X-Spam-Level: X-Spam-Status: No, score=-8.94 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ-7RJnFId6J for ; Mon, 23 Sep 2013 07:09:23 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id C070521F9F88 for ; Mon, 23 Sep 2013 07:09:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r8NE9LJ0010301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Sep 2013 16:09:22 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r8NE9LgJ026827 for ; Mon, 23 Sep 2013 16:09:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r8NE9IOt012812 for ; Mon, 23 Sep 2013 16:09:21 +0200 Message-ID: <52404B8E.9020003@gmail.com> Date: Mon, 23 Sep 2013 16:09:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:09:29 -0000 Le 19/09/2013 23:26, Teemu Savolainen a écrit : > > >Secondly, I don't agree DHCP server support is required, as the CE > can include the DNS addresses in RAs as specified in RFC6106. > > > > > > > How could a CE convey NTP server settings to hosts using RAs? > Accurate host time is pretty useful, if not essential. > > It cannot, but then again it probably would not help to have DHCP server > implementation either, as, AFAIK, cellular networks commonly today do > not provide DHCP service to terminals (to these "CEs" that would use > 64share instead of DHCPv6 PD).... In addition to considering whether or not the cellular network delivers DHCP, one should consider whether or not the local USB dongle delivers DHCP to the Host. This or someone other unknown entity in the middle, between the network and the host, delivers DHCP and make that link look like ARP-capable link. The QMI drivers and clients in linux see new evolutions in that sense. But that is more like future work; 64share has place here where QMI is not yet widely deployed. > If CE has no NTP settings, it cannot > share them either. CE often gets time from cellular network, though.. So > maybe CE should implement NTP server and with DHCP share its own address > as NTP address? CE to run a DHCPv6 Server? > ... And this is why it is best to focus 64share to just prefix sharing;-) In a sense I agree to let 64share just do the prefix sharing. But obviously the client on the LAN side needs a way to get a DNS server address otherwise its connectivity is only partial. Alex > > Best regards, > > Teemu > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From michelg@upperside.fr Mon Sep 23 10:16:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0FD21F9D89 for ; Mon, 23 Sep 2013 10:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_60=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmoHYnldtrbV for ; Mon, 23 Sep 2013 10:16:06 -0700 (PDT) Received: from smtp01.msg.oleane.net (smtp01.msg.oleane.net [62.161.4.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6521F9E88 for ; Mon, 23 Sep 2013 10:16:05 -0700 (PDT) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp01.msg.oleane.net (MSA) with ESMTP id r8NHG0VO025818 for ; Mon, 23 Sep 2013 19:16:01 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Mon, 23 Sep 2013 19:15:53 +0200 Message-ID: <000c01ceb880$93b0df50$bb129df0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CEB891.573F54A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac64gCs6kxl6O1GgQkWpRGfh222d7g== Content-Language: fr X-Backend: sophos52 X-PMX-Spam: Probability=8% X-PFSI-Info: PMX 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.23.170314 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [v6ops] V6 World Paris 2014: IP on Everything X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 17:16:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CEB891.573F54A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fourth edition of V6 World Congress will take place in Paris from 18 to 21 March, 2014. The 2014 edition will place particular emphasis on Internet of Things, SDN issues and Enterprises deployments. The call for proposals dead line has been extended to October 10, 2013. More info.: http://www.uppersideconferences.com/v6world2014/v6world2014cfp.html ------=_NextPart_000_000D_01CEB891.573F54A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Th= e fourth edition of V6 World Congress will take place in Paris = from 18 to 21 = March, 2014.&= nbsp;

The 2014 = edition will place particular emphasis on Internet of Things, = SDN issues and Enterprises = deployments.

The call for = proposals dead line has been extended to October 10, = 2013.

More info.: = http://www.uppersideconferences.com/v6world2014/v6world2014c= fp.html

 =

------=_NextPart_000_000D_01CEB891.573F54A0-- From markzzzsmith@yahoo.com.au Mon Sep 23 13:07:29 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BF921F9FB3 for ; Mon, 23 Sep 2013 13:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U85JSU4GYaeQ for ; Mon, 23 Sep 2013 13:07:24 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0121F9FAE for ; Mon, 23 Sep 2013 13:07:18 -0700 (PDT) Received: from [98.139.214.32] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 20:07:16 -0000 Received: from [98.139.212.230] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 20:07:16 -0000 Received: from [127.0.0.1] by omp1039.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 20:07:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 574136.65842.bm@omp1039.mail.bf1.yahoo.com Received: (qmail 18759 invoked by uid 60001); 23 Sep 2013 20:07:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1379966836; bh=s/FkH2rvp5PeY6ixgBXAONSDS8GdepDGSnrxs/vnLU0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ktkYJUvyYGdW3MWolj44ZVIdJqZ2xYtKwSYwqqJl7E/cTzjhx4qffvdinqUXJ+EbMflLuhtRLQK4HRr8n5t3kx33uyPQF8EXS1HDYHtHvS0DNx7SbD5KbYqDDbvK4DwMdFL5SrEwbqLTVr8bl2lK/PYqGGrLdtjvBkMDTbRqATQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L8anN93XVFeAVBS0ySyBKyTMjP1HLl6tdHT0FfeSB43aGm5//Y+HENn9yTP4j7NUBU699FwCMzdAQCIbLrIq7HJu98SkRqmKJXp8EiJXGbox4jS28SKKObi7mE6BM6duD2zAsfm+j+woP8j8n7z4uDW63C7Ptx+W4uip5xhlRqo=; X-YMail-OSG: 3ShXQEoVM1mhoqUiaX5ZtFKO_85rIXM3hMctN7AyO7DHkdn _nTxC9K2t7Yqxj.kiDln2cqsfcKaJ7F_66ST13xZLKd5kgIgokPgmXvXpJEu HSMiZi1mYOyrJqiaEeJPc3YQqUfD5HNwLbnmjZBz6VWeeOqiMgKfzs3zrK7B y.49TwMdZYlPLQM0Qa7G.oqAUtMve.O4.byTySbH3bjfPMou0B88FIcPdnUW mk58GLU4iohrWRVMOB.ejJSofxl9rqUErz9yvtQwxpoqNGcfcI5mBBT5fQda gaxY0vGe6A7HmraaFgM9cEzTc.ozYv46l5mbTQMmRlluIiOfa7_0fiF35pIE CLWBhrY1G.N7eMp7vFlxqwHd3Gb0g.d3gXhHxcw3hNZNQME4tgl1ukJaYCd8 6nS3MplNnmzyk4qXvV8fgLmGLko8U8kZgWQOLKv0h8C8HSi31n2YY3V5OMGQ L_eK3y0f1FGa9I98uFjfmW32AAKm2.zpXuWT4WpohwRiqCGFg9afSd8pujNI Aaf8Hig48lapkJWgzwBAQmYaplhoCG3wV.7836NJNPmH1Z5ELDo5LXbdNRia vzUJmU0R.AymFosdY.mqnOe9NVTcOr4WAycBNrtNb6A8M Received: from [150.101.221.237] by web142504.mail.bf1.yahoo.com via HTTP; Mon, 23 Sep 2013 13:07:16 PDT X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj5UbzogdjZvcHNAaWV0Zi5vcmcgCj5TZW50OiBUdWVzZGF5LCAyNCBTZXB0ZW1iZXIgMjAxMyAxMjowOSBBTQo.U3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy02NHNoYXJlIFdHTEMKPiAKPgo.TGUgMTkvMDkvMjAxMyAyMzoyNiwgVGVlbXUgU2F2b2xhaW5lbiBhIMOpY3JpdCA6Cj4.wqAgPiA.U2Vjb25kbHksIEkgZG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> <52404B8E.9020003@gmail.com> Message-ID: <1379966836.15205.YahooMailNeo@web142504.mail.bf1.yahoo.com> Date: Mon, 23 Sep 2013 13:07:16 -0700 (PDT) From: Mark ZZZ Smith To: Alexandru Petrescu , "v6ops@ietf.org" In-Reply-To: <52404B8E.9020003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:07:29 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Alexandru Petres= cu =0A>To: v6ops@ietf.org =0A>Sent: Tuesday, = 24 September 2013 12:09 AM=0A>Subject: Re: [v6ops] draft-ietf-v6ops-64share= WGLC=0A> =0A>=0A>Le 19/09/2013 23:26, Teemu Savolainen a =E9crit :=0A>>=A0= > >Secondly, I don't agree DHCP server support is required, as the CE=0A>>= can include the DNS addresses in RAs as specified in RFC6106.=0A>>=A0 > >= =0A>>=A0 >=0A>>=A0 > How could a CE convey NTP server settings to hosts usi= ng RAs?=0A>> Accurate host time is pretty useful, if not essential.=0A>>=0A= >> It cannot, but then again it probably would not help to have DHCP server= =0A>> implementation either, as, AFAIK, cellular networks commonly today do= =0A>> not provide DHCP service to terminals (to these "CEs" that would use= =0A>> 64share instead of DHCPv6 PD)....=0A>=0A>In addition to considering w= hether or not the cellular network delivers =0A>DHCP, one should consider w= hether or not the local USB dongle delivers =0A>DHCP to the Host.=0A>=0A>Th= is or someone other unknown entity in the middle, between the network =0A>a= nd the host, delivers DHCP and make that link look like ARP-capable =0A>lin= k.=A0 The QMI drivers and clients in linux see new evolutions in that =0A>s= ense.=0A>=0A>But that is more like future work; 64share has place here wher= e QMI is =0A>not yet widely deployed.=0A>=0A>> If CE has no NTP settings, i= t cannot=0A>> share them either. CE often gets time from cellular network, = though.. So=0A>> maybe CE should implement NTP server and with DHCP share i= ts own address=0A>> as NTP address?=0A>=0A>CE to run a DHCPv6 Server?=0A>= =0A=0AI think the CE should run a DHCPv6 relay, not a DHCPv6 server. Otherw= ise, the parameters the upstream "network" and the downstream hosts can rec= eive are constrained by the DHCPv6 option support of the DHCPv6 client/serv= er in the CE device. This is what I've discussed, including how I think sta= teful DHCPv6 addressing could be handled on the downstream interface, in=0A= =0A"IPv6 CE Device DHCPv6 Option Transparency"=0A=0Ahttp://tools.ietf.org/h= tml/draft-smith-v6ops-ce-dhcpv6-transparency-00=0A=0A=0A=0A=0A=0A=0A>> ... = And this is why it is best to focus 64share to just prefix sharing;-)=0A>= =0A>In a sense I agree to let 64share just do the prefix sharing.=0A>=0A>Bu= t obviously the client on the LAN side needs a way to get a DNS server =0A>= address otherwise its connectivity is only partial.=0A>=0A>Alex=0A>=0A>>=0A= >> Best regards,=0A>>=0A>> Teemu=0A>>=0A>>=0A>>=0A>> ______________________= _________________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> = https://www.ietf.org/mailman/listinfo/v6ops=0A>>=0A>=0A>=0A>_______________= ________________________________=0A>v6ops mailing list=0A>v6ops@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/v6ops=0A>=0A> From markzzzsmith@yahoo.com.au Mon Sep 23 13:15:57 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFFD21F9E28 for ; Mon, 23 Sep 2013 13:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9BjMTD8cI7g for ; Mon, 23 Sep 2013 13:15:52 -0700 (PDT) Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) by ietfa.amsl.com (Postfix) with ESMTP id 891AC21F8EB2 for ; Mon, 23 Sep 2013 13:15:52 -0700 (PDT) Received: from [98.139.212.147] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 20:15:50 -0000 Received: from [98.139.212.241] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 20:15:50 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 23 Sep 2013 20:15:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 743978.68555.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 16002 invoked by uid 60001); 23 Sep 2013 20:15:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1379967350; bh=kZPjJEIbPFJgWHHGSPlUhyMJHVDGkjRhM+5BFmQocHw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MkmV79AGkaiJOA9ZGiCG6VjUojPbEROcIFLbHGO7mWcDWiOMicTK/3pRVASv45tVFr3phaSGaAxWhC0nPP0mQaO1PRITBiojpjfGi2eBGqsHijb5OA4WAtDGfZIUyifswY8jrsTaAW1fj14VziDA0+BQ+ZNL7l06MrRtlti1ZHE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z5NTf6eJPf6W8/oksUFwa2JgGgln0KB2fzQmNt5+0lMmRw/+K8TkCf5p6hjAR6CffevOIR40RUKQITDO0yDw5FrVJCirZ/rKlnDBnfs1NN33tc2Cvo78YpB9rbFn5Un+gmmCPR7ycqIzQD9KGx3fUfDf5nfCeAv8b+UdYt80hBM=; X-YMail-OSG: osv5UIEVM1kyP99slwjqDwd3y7yvK7MeZdoZRGsF9.gymVM Actwe9i3nN_ipcm4cht9R9z6GaL3Qk4dKNnnq_zxMbMNcyQSuwxEHfwmcAg3 KjEDSAfeF26QZnR.2Ia.6W7U9zfNasWvqvzMPw_dneng0zeCe8oFyaxQmrgM eF_9lMh0aBPLr6p8gmH_1iodBiRA9_SYeRt6L4acph4NOsy5C58hVx8NRX6_ AjfUFVCgvdgh8f7_0eFyHwItLkyoaZ90L1URN7DFIvSbJHh6.RU8Cg1IDWjX eEdsdYVc7I4YE8A9LqgIQIvDhgWHp1Ari8J0jNtZGFQoi26xnUUey.LD6OTl KhF0WzfKea8kTW2ZWFnfgJV_GuXvIzoBwes0GL2PjQSwv5_8oXc_Gs.g6Pwj pfeVBIB23bgRdgRNKOb4nSdkuUlFYKpjzsrB0UWNx3.g3g02E2HJ85IWHqPO zMKgzERw8VnknlXSli8h_1j1jtu8VYbUvSKNAtCoFT1DA4vCl_.diRhUvL.3 H441MIsJSdNDkvkeio0r8TwL2qAuEusa8RI2Prs1znaw20p7UbH._ZfvoDoR z2hCn.uj6TVDO_fyrPvi_w48CHJQJ_yDJACEQpMDh0Ck- Received: from [150.101.221.237] by web142501.mail.bf1.yahoo.com via HTTP; Mon, 23 Sep 2013 13:15:50 PDT X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBUbzogQWxleGFuZHJ1IFBldHJlc2N1IDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPjsgInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IFR1ZXNkYXksIDI0IFNlcHRlbWJlciAyMDEzIDY6MDcgQU0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLTY0c2hhcmUgV0dMQwo.IAo.IAo.IAo.IAoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> <1379624093.60428.YahooMailNeo@web142501.mail.bf1.yahoo.com> <52404B8E.9020003@gmail.com> <1379966836.15205.YahooMailNeo@web142504.mail.bf1.yahoo.com> Message-ID: <1379967350.10545.YahooMailNeo@web142501.mail.bf1.yahoo.com> Date: Mon, 23 Sep 2013 13:15:50 -0700 (PDT) From: Mark ZZZ Smith To: Alexandru Petrescu , "v6ops@ietf.org" In-Reply-To: <1379966836.15205.YahooMailNeo@web142504.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:15:57 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Mark ZZZ Smith =0A> To: Alexandru Petrescu ; "v6ops@ietf.org" =0A> Cc: =0A> Sent: Tuesday, 24 Septemb= er 2013 6:07 AM=0A> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC=0A> = =0A> =0A> =0A> =0A>=A0=0A=0A=0A=0A>> =0A>>> If CE has no NTP setting= s, it cannot=0A>>> share them either. CE often gets time from cellular net= work, though.. =0A> So=0A>>> maybe CE should implement NTP server and with= DHCP share its own =0A> address=0A>>> as NTP address?=0A>> =0A>> CE to ru= n a DHCPv6 Server?=0A>> =0A> =0A> I think the CE should run a DHCPv6 relay,= not a DHCPv6 server. Otherwise, the =0A> parameters the upstream "network"= and the downstream hosts can receive =0A> are constrained by the DHCPv6 op= tion support of the DHCPv6 client/server in the =0A> CE device. This is wha= t I've discussed, including how I think stateful =0A> DHCPv6 addressing cou= ld be handled on the downstream interface, in=0A> =0A> "IPv6 CE Device DHCP= v6 Option Transparency"=0A> =0A> http://tools.ietf.org/html/draft-smith-v6o= ps-ce-dhcpv6-transparency-00=0A> =0A> =0A=0A=0AI've realised in the last we= ek or so that I need to generalise the draft, so that what it proposes appl= ies to all IPv6 routers, including 3G smartphones/tablets etc., not just RF= C6204 ones. I'll work on updating it over the next week or so. Here's the c= urrent abstract:=0A=0A=0A"[RFC6204] defines basic requirements for IPv6 Cus= tomer Edge Routers,=0Ato suit residential or small office IPv6 deployments.= It describes a WAN interface DHCPv6 client and LAN interface DHCPv6 serve= r implementation model. This model constrains the set of DHCPv6 options th= at can be conveyed between the upstream service provider and the hosts down= stream of the CE device, to those supported by both the CE device's DHCPv6 = client and server. To support further current and future DHCPv6 options, t= his memo instead proposes a DHCPv6 option "transparent" implementation mode= l for CE devices, primarily using DHCPv6 message relaying."=0A=0AThanks,=0A= Mark. From prvs=9712ab07a=Dave.Michaud@rci.rogers.com Mon Sep 23 07:33:45 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166DE11E80DF for ; Mon, 23 Sep 2013 07:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtOTLWZWUsym for ; Mon, 23 Sep 2013 07:33:39 -0700 (PDT) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A69611E8186 for ; Mon, 23 Sep 2013 07:33:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUAAMNPQFKOkg57l2dsb2JhbABZhzq+CBeBChYOAQEBAQEIFgc8giUBAQEDARIRDQQfCwEVBQUHBAIBCA0EBAEBAwIGBhcBAgICAQEfJQkIAQEEEwgTB4dRAwkGnUaLQogmDYlqgSmLToEvgQ4GKwcCAgKCYzWBAAOPEocAAYhChWuIcyCBLA X-IronPort-AV: E=Sophos;i="4.90,963,1371096000"; d="scan'208";a="266534682" Received: from unknown (HELO RSOESNEXIGWC.rci.rogers.ca) ([142.146.14.123]) by mail.mail.rss.rogers.com with ESMTP; 23 Sep 2013 10:33:14 -0400 Received: from RSOESNGTABHB.rci.rogers.ca ([10.3.37.23]) by RSOESNEXIGWC.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 10:33:15 -0400 Received: from CL08MBE.rci.rogers.ca ([10.3.45.56]) by RSOESNGTABHB.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 10:33:14 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Sep 2013 10:32:52 -0400 Message-ID: <29AE8DB910E7704CA043795E00DCBE780A363F9A@CL08MBE.rci.rogers.ca> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac62pTHKSX8N+CMLTrqiK90iLjitpgBvwpjA References: <29AE8DB910E7704CA043795E00DCBE780A363F32@CL08MBE.rci.rogers.ca> From: "Dave Michaud" To: "GangChen" X-OriginalArrivalTime: 23 Sep 2013 14:33:14.0130 (UTC) FILETIME=[D5F98720:01CEB869] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Wed, 25 Sep 2013 08:31:10 -0700 Cc: IPv6 Ops WG , Cameron Byrne , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, Victor Kuarsingh Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:33:45 -0000 Q2xhcmlmaWNhdGlvbnMvY29tbWVudHMgYXJlIGlubGluZQ0KDQpEYXZlIE1pY2hhdWQNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHYW5nQ2hlbiBbbWFpbHRvOnBoZGdh bmdAZ21haWwuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDIxLCAyMDEzIDQ6MzMg QU0NCj4gVG86IERhdmUgTWljaGF1ZA0KPiBDYzogSVB2NiBPcHMgV0c7IGRyYWZ0LWNoZW4tdjZv cHMtaXB2Ni1yb2FtaW5nLWFuYWx5c2lzQHRvb2xzLmlldGYub3JnOyBKb3VuaTsNCj4gQ2FtZXJv biBCeXJuZTsgVmljdG9yIEt1YXJzaW5naDsgVsOtemRhbCBBbGXFoTsgSHVpIERlbmc7IGZyZWRA Y2lzY28uY29tOyBKb2huDQo+IEphc29uIEJyem96b3dza2k7IEJJTkVUIERhdmlkIElNVC9PTE47 IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJh ZnQtY2hlbi12Nm9wcy1pcHY2LXJvYW1pbmctYW5hbHlzaXMNCj4gDQo+IEhpIERhdmUsDQo+IA0K PiB0aGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4gUGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUu DQo+IA0KPiAyMDEzLzkvMjAsIERhdmUgTWljaGF1ZCA8RGF2ZS5NaWNoYXVkQHJjaS5yb2dlcnMu Y29tPjoNCj4gPiBIaSBHYW5nLA0KPiA+DQo+ID4gVGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgY29t bWVudHMgb24gdGhpcyBkcmFmdCBhbHJlYWR5IGFuZCBhIHByZXNlbnRhdGlvbiBhdA0KPiA+IElF VEY4NyBidXQgbm90aGluZyBoYXMgYmVlbiBpbmNsdWRlZCBpbiBhIHJldmlzZWQgdmVyc2lvbiB5 ZXQgc28gaXQncw0KPiA+IGRpZmZpY3VsdCB0byBoYXZlIGEgY2xlYXIgdmlldyBvZiB3aGVyZSB3 ZSBzdGFuZCBhdCB0aGlzIHBvaW50IGFuZCBjb21tZW50DQo+ID4gZnVydGhlci4NCj4gQXMgeW91 IG1heSBrbm93LCB0aGVyZSBpcyBhIGRlc2lnbiB0ZWFtIHRvIHBvbGlzaCB0aGUgZHJhZnQuIFdl IGludGVuZA0KPiB0byBzcGVlZCB1cCB0aGUgcmV2aXNpb24gYnkgZ2F0aGVyaW5nIHRoZSBjb21t ZW50cyBmcm9tIHBhcnRpY2lwYW50cy4NCj4gWW91IGFyZSB3ZWxjb21lIHRvIGpvaW4uDQoNCkkn ZCBiZSBtb3JlIHRoYW4gd2lsbGluZyB0byBwYXJ0aWNpcGF0ZS4NCg0KPiANCj4gPiBOb25ldGhl bGVzcywgSSdkIGxpa2UgdG8gc2hhcmUgb3VyIG93biBleHBlcmllbmNlIGluIGRlcGxveWluZyBJ UHY2IGZvciBvdXINCj4gPiBob21lIHN1YnNjcmliZXJzIGFuZCB0aGUgZXhwZWN0ZWQgcm9hbWlu ZyBpbXBhY3QuIEkgZ3Vlc3MgaXQgY2FuIHNlcnZlIGFzDQo+ID4gaW5wdXQgZm9yIHRoaXMgZHJh ZnQgb3IgZm9yIGEgZnV0dXJlIEJDUC4gT3VyIHRhcmdldCBpcyB0byBlbmFibGUgSVB2Ni1vbmx5 DQo+ID4gKGFuZCBub3QgZHVhbC1zdGFjaykgZm9yIGFzIG1hbnkgc3Vic2NyaWJlciBhcyB3ZSBj YW4sIHJvYW1pbmcgb3Igbm90IGJ1dA0KPiA+IG9idmlvdXNseSB3ZSB3YW50IHRvIGVuc3VyZSB0 aGF0IHRoZSBzZXJ2aWNlIGtlZXBzIHdvcmtpbmcgYXMgaXQgZG9lcyB0b2RheS4NCj4gPiBXZSBh cmUgYWxzbyBub3QgdXNpbmcgdlBMTU4gbG9jYWwgYnJlYWtvdXQgKHdoaWNoIGlzIHRoZSBjYXNl IGZvciBtb3N0DQo+ID4gb3BlcmF0b3JzKSBidXQgbWF5IGNoYW5nZSBmb3IgSU1TIHNpdHVhdGlv bnMgaW4gdGhlIGZ1dHVyZS4NCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhlIGlucHV0cy4gWW91ciBj b21tZW50cyB3aWxsIGJlIGluY29ycG9yYXRlZCBpbnRvIHRoZQ0KPiBuZXh0IHJldmlzaW9uLiBQ bGVhc2Ugc2VlIG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbnMgYXMgYmVsb3cuDQo+IA0KPiANCj4g PiAtLS0tIFVFIENvbmZpZ3VyYXRpb24gLS0tLQ0KPiA+IFVFIGNhbiBiZSBzZXQgdG8gcmVxdWVz dCBhIFBEUC9QRE4gVHlwZSBJUHY0LCBJUHY0djYgb3IgSVB2Ni4gQ2VydGFpbiBVRQ0KPiA+IGhh dmUgdGhlIGFiaWxpdHkgYSBkaWZmZXJlbnQgY29uZmlndXJhdGlvbiBmb3IgaG9tZSBuZXR3b3Jr IC8gdmlzaXRlZA0KPiA+IG5ldHdvcmsuIFNpbmNlIHRoaXMgaXMgcmVsYXRlZCB0byByb2FtaW5n IGNhc2UsIG15IGNvbW1lbnRzIGFwcGx5IHRvIHRoZQ0KPiA+IHJvYW1pbmcgcHJvZmlsZSBvciB0 aGUgaG9tZS9yb2FtaW5nIHByb2ZpbGUgaWYgdGhlcmUgaXMgbm8gZGlzdGluY3Rpb24uIFRoaXMN Cj4gPiBpcyB3aGF0IHRoZSBVRSByZXF1ZXN0LCBub3QgbmVjZXNzYXJpbHkgdGhlIGZpbmFsIFBE UC9QRE4gVHlwZS4uLg0KPiA+DQo+ID4gLSBJUHY0OiBoYXMgYmVlbiB3b3JraW5nIGZvciB5ZWFy cywgbm8gaXNzdWUNCj4gPiAtIElQdjY6IGlmIHRoZSBVRSByZXF1ZXN0IElQdjYtb25seSBhbmQg YSBub2RlIGluIHRoZSBwYXRoIGNhbid0IHN1cHBvcnQgaXQNCj4gPiAoaWUuIHZpc2l0ZWQgU0dT TiksIHRoZXJlIGlzIG5vIHBvc3NpYmxlIGZhbGxiYWNrIGFuZCBkYXRhIGlzIGJyb2tlbi4gVGhp cw0KPiA+IGNvbmZpZ3VyYXRpb24gc2hvdWxkIGJlIGF2b2lkZWQuDQo+ID4gLSBJUHY0djY6IHRo aXMgaXMgbGVhc3Qgc3VwcG9ydGVkIGNvbmZpZ3VyYXRpb24gKGJhc2VkIG9uIHJlcXVpcmVkIDNH UFANCj4gPiByZWxlYXNlIGluIFNHU04pIGJ1dCBhbHNvIHRoZSBjb25maWd1cmF0aW9uIHRoYXQg b2ZmZXJzIHRoZSBtb3N0DQo+ID4gZmxleGliaWxpdHkuIEFzIHBlciAzR1BQIDI0LjAwOCwgdGhp cyBQRFAvUEROIFR5cGUgc2hvdWxkIGJlIGludGVycHJldGVkIGFzDQo+ID4gSVB2NCBieSB0aGUg U0dTTi9NTUUgaWYgaXQgZG9lc24ndCB1bmRlcnN0YW5kIGl0Lg0KPiA+DQo+ID4gV2UgaGF2ZSBo YWQgc29tZSBVRSBtb2RlbHMgY29uZmlndXJlZCB0byByZXF1ZXN0IHRoaXMgUERQL1BETiB0eXBl IGluDQo+ID4gY2lyY3VsYXRpb24gZm9yIG92ZXIgYSB5ZWFyIG5vdyBhbmQgd2UgaGF2ZSBvYnNl cnZlZCBjYXNlcyB3aGVyZSB0aGUgdlNHU04NCj4gPiB3YXMgc2ltcGx5IHJlamVjdGluZyB0aGUg UERQIENvbnRleHQgQ3JlYXRpb24gbWVzc2FnZSB3aXRoIGEgY2F1c2UgY29kZQ0KPiAjMjcNCj4g PiAoVW5rbm93biBvciBtaXNzaW5nIEFQTikgYmVjYXVzZSBpdCBzdG9wcGVkIHByb2Nlc3Npbmcg dGhlIG1lc3NhZ2UgYXQgdGhlDQo+ID4gUERQIHR5cGUgKEFQTiBuYW1lIGNvbWVzIHJpZ2h0IGFm dGVyKS4gVGhpcyBob3dldmVyIGhhcyBiZWVuIGFuIGV4dHJlbWVseQ0KPiA+IGxpbWl0ZWQgY29y bmVyIGNhc2Ugd2l0aCAyIGNvbmZpcm1lZCBvcGVyYXRvcnMuDQo+IA0KPiBUaGF0IGlzIHRoZSBj YXNlIHdlIGFyZSBhbHNvIG9ic2VydmluZyBmb3IgdGhlIHRpbWUgYmVpbmcuIEkgZ3Vlc3Mgd2UN Cj4gaGF2ZSB0byBqdXN0aWZ5IHdoZXRoZXIgdGhhdCBpcyBhIGNvcm5lciBjYXNlLCBiZWNhdXNl IEkgaGVhcmQgdGhlDQo+IGlzc3VlIGZyb20gYXQgbGVhc3QgMiBvcGVyYXRvcnMuDQo+IA0KDQpB bGwgdGhlIGZhaWx1cmVzIHdlIGhhdmUgb2JzZXJ2ZWQgYXJlIGluIEtvcmVhLiBJIGFtIHRyeWlu ZyB0byBvYnRhaW4gYW4gZXhhY3QgbGlzdCBvZiBkZXZpY2VzIGN1cnJlbnRseSBzZXQgdG8gcmVx dWVzdCBJUHY0djYgd2hpbGUgcm9hbWluZyBhbmQgd2lsbCBydW4gYW4gYW5hbHlzaXMgb24gb3Vy IENEUnMgdG8gYnVpbGQgYSBsaXN0IG9mIG9wZXJhdG9ycyB3aGVyZSB0aGlzIGNvbmZpZ3VyYXRp b24gaGFzIHdvcmtlZCBjb3JyZWN0bHkuDQoNCj4gDQo+ID5VbHRpbWF0ZWx5LCB3ZSBhcmUgbm93 DQo+ID4gY29uZmlndXJpbmcgbW9zdCBVRSB0byByZXF1ZXN0IElQdjR2NiB3aGlsZSByb2FtaW5n ICh3ZSBrZXB0IHNvbWUgZmxhZ3NoaXANCj4gPiBkZXZpY2VzIGFzIElQdjQtb25seSBmb3Igbm93 IGFzIHdlIGJ1aWxkIGEgZGF0YWJhc2Ugb2Ygd29ya2luZyBQTE1OcykuDQo+IA0KPiBJZiB0aGUg YmVoYXZpb3IgY29tcGxpZXMgd2l0aCAyNC4wMDgsIElQdjR2NiByb2FtaW5nIGlzIGEgd29ya2Fi bGUNCj4gc29sdXRpb24uIEJ1dCwgaG93IGNvdWxkIHRoaXMgcmVjb21tZW5kYXRpb24gcmVsYXRl ZCB0byB5b3VyIGdvYWwoaS5lLg0KPiBPdXIgdGFyZ2V0IGlzIHRvIGVuYWJsZSBJUHY2LW9ubHkg KGFuZCBub3QgZHVhbC1zdGFjayk/DQoNCkFzIGRldGFpbGVkIGJlbG93LCB3ZSBoYXZlIHRoZSBV RSByZXF1ZXN0IElQdjR2NiBzbyB0aGF0IHdlIGtlZXAgZnVsbCBmbGV4aWJpbGl0eSBpbiBmdXJ0 aGVyIGNvbnRyb2xsaW5nIHRoZSB0eXBlIG9mIFBEUCBmcm9tIHRoZSBuZXR3b3JrLiBJZiB0aGUg VUUgcmVxdWVzdHMgSVB2NCBvciBJUHY2LCB3ZSBjYW5ub3Qgb3ZlcnJpZGUgaXQgZnJvbSB0aGUg bmV0d29yay4NCg0KPiANCj4gPiAtLS0tIFNHU04vTU1FIGZvciBNb2JpbGl0eSBNYW5hZ2VtZW50 IFByb2NlZHVyZXMgKEF0dGFjaCkgLS0tLQ0KPiA+IE9uIGF0dGFjaCwgdGhlIFNHU04vTU1FIG11 c3QgY29udGFjdCB0aGUgaG9tZSBITFIvSFNTIGFuZCBvYnRhaW4gdGhlDQo+ID4gc3Vic2NyaWJl ciBwcm9maWxlLiBJdCBpcyB3ZWxsIGtub3duIG5vdyBhbmQgaGFzIGJlZW4gb2JzZXJ2ZWQgZmly c3QgaGFuZCBieQ0KPiA+IHNvbWUgb2YgdXMgaGVyZSB0aGF0IG11bHRpcGxlIFNHU04vTU1FIHdp bGwgYmUgdW5hYmxlIHRvIGNvcnJlY3RseSBwcm9jZXNzDQo+IGENCj4gPiBzdWJzY3JpYmVyIHBy b2ZpbGUgcmVjZWl2ZWQgaW4gdGhlIEluc2VydCBTdWJzY3JpYmVyIERhdGEgcHJvY2VkdXJlIGlm IGl0DQo+ID4gY29udGFpbnMgYW4gRXh0LVBEUC1UeXBlICgzR1BQIFRTIDI5LjAwMiAvIDNHUFAg VFMgMjkuMDYwKS4gSW4gdGhhdCBjYXNlLCBpdA0KPiA+IGJyZWFrcyBkYXRhIHNvIHRoaXMgc2l0 dWF0aW9uIG11c3QgYmUgYXZvaWRlZC4NCj4gPg0KPiA+IERldGFpbHMgb24gdGhlIHNvbHV0aW9u IGFyZSBpbiB0aGUgSExSIHNlY3Rpb24gYmVsb3cgYnV0IHVsdGltYXRlbHksIHVubGVzcw0KPiA+ IHdlIGtub3cgZm9yIHN1cmUgdGhhdCBhbiBTR1NOIChhbmQgdGhlIG9wZXJhdG9yIGluIGdlbmVy YWwgYXMgcGVyIElSLjIxKSwNCj4gPiB0aGUgU0dTTiB3aWxsIHJlY2VpdmUgYSBzdWJzY3JpYmVy IHByb2ZpbGUgdGhhdCBjb250YWlucyBJUHY0LW9ubHkgYXMgdGhlDQo+ID4gYXZhaWxhYmxlIFBE UCB0eXBlIChub3QgcHJlc2VuY2Ugb2YgSVB2NiBhdCBhbGwpLg0KPiA+DQo+ID4gQXQgdGhpcyBz dGFnZSwgdGhlIFNHU04gc2hvdWxkIHRoZXJlZm9yZSByZWNlaXZlIGEgc3Vic2NyaWJlciBwcm9m aWxlDQo+ID4gY29udGFpbmluZyBvbmx5IGZpZWxkcyBpdCBjYW4gdW5kZXJzdGFuZCBhbmQgdGhp cyBhdHRhY2ggd2lsbCBjb21wbGV0ZQ0KPiA+IHN1Y2Nlc3NmdWxseS4NCj4gDQo+IFllcy4gVGhh dCBpcyB0aGUgaXNzdWUgaWRlbnRpZmllZCBpbiB0aGUgY3VycmVudCBkcmFmdC4gV2UgZGlkbid0 DQo+IHByb3ZpZGUgdGhlIHNvbHV0aW9uLCBiZWNhdXNlIHRoZSBkcmFmdCBub3QgaW50ZW5kcyB0 byBtYWtlIGENCj4gc3VnZ2VzdGlvbiB0byBtb2RpZnkgM0dQUCBub2RlLiBUaGF0IGlzIHRoZSBj b25jbHVzaW9uIGZyb20gbGFzdA0KPiBtZWV0aW5nIGRpc2N1c3Npb24uIFRoZSBzb2x1dGlvbiB5 b3UgZGVzY3JpYmVkIGJlbG93IG1heSBiZSBhbg0KPiBhcHByb2FjaCB0byBzb2x2ZSB0aGUgaXNz dWUuIElmIHRoYXQgaXMgZm9ybWFsbHkgcHVibGlzaGVkIG9yIHBsYW5uZWQNCj4gdG8gYmUgYSAz R1BQIENSLCB0aGUgZHJhZnQgbWF5IGluY2x1ZGUgdG8gY29udmV5IHRoaXMgaW5mb3JtYXRpb24u DQo+IA0KPiANCj4gPiAtLS0tIFNHU04vTU1FIGZvciBTZXNzaW9uIE1hbmFnZW1lbnQgUHJvY2Vk dXJlcyAoUERQIENvbnRleHQvQmVhcmVyKSAtLS0NCj4gLQ0KPiA+IFdoZW4gdGhlIFNHU04vTU1F IHJlY2VpdmVzIGEgc2Vzc2lvbiBjcmVhdGlvbiByZXF1ZXN0IGZyb20gdGhlIFVFDQo+IChQRFAv UERODQo+ID4gVHlwZSBJUHY0djYpLCB0aGUgZm9sbG93aW5nIHNpdHVhdGlvbnMgYXJlIHBvc3Np YmxlOg0KPiA+DQo+ID4gMS4gU0dTTi9NTUUgZG9lcyBub3QgdW5kZXJzdGFuZCBJUHY0djYgc28g aXQgZmFsbHMgYmFjayB0byBJUHY0IGFzIHBlciBzcGVjDQo+ID4gMi4gU0dTTi9NTUUgdW5kZXJz dGFuZHMgSVB2NHY2IGJ1dCB0aGUgc3Vic2NyaWJlciBwcm9maWxlIGRpZCBub3QgY29udGFpbg0K PiA+IEV4dC1QRFAtVHlwZSBzbyBpdCBmYWxscyBiYWNrIHRvIElQdjQNCj4gPiAzLiBTR1NOL01N RSB1bmRlcnN0YW5kcyBJUHY0djYgYnV0IGFzIHBlciBhIGxvY2FsIHBvbGljeSBkb2VzIG5vdCBh bGxvdyBpdA0KPiA+IHNvIGl0IGZhbGxzIGJhY2sgdG8gSVB2NA0KPiA+ICAgIGEuIElQdjYgYmls bGluZyBub3Qgc3VwcG9ydGVkDQo+ID4gICAgYi4gSVB2NiBub3QgbGljZW5zZWQNCj4gPiAgICBj LiBMb2NhbCBkZWNpc2lvbi4uLg0KPiA+IDQuIFNHU04vTU1FIGRvZXMgbm90IHVuZGVyc3RhbmQg SVB2NHY2IGFuZCBpdCBkb2VzIG5vdCBmYWxsIGJhY2sgdG8gSVB2NC4NCj4gPg0KPiA+IFBvaW50 IDQgaXMgZm9yIHVzIHRoZSBtb3N0IGNyaXRpY2FsIGFzcGVjdCBhbmQgdGhlIG9uZSB3ZSBhcmUg Zm9sbG93aW5nDQo+ID4gY2xvc2VseS4NCj4gPg0KPiA+IEJhc2VkIG9uIHRoZSBhYm92ZSBvcHRp b25zLCB0aGUgU0dTTi9NTUUgZm9yd2FyZHMgdG8gdGhlIEdHU04vUy1HVyBhDQo+IHNlc3Npb24N Cj4gPiBjcmVhdGlvbiByZXF1ZXN0IHdpdGggZWl0aGVyIGEgUERQIFR5cGUgb2YgSVB2NCBvciBJ UHY0djYuDQo+IA0KPiBUbyBiZSBjbGVhciwgU0dTTi9NTUUgd291bGQgZm9yd2FyZCBhIFBEUCBU eXBlIG9mIElQdjQgaW4gdGhlIGNhc2Ugb2YgIzEsMiwzDQo+IFdvdWxkIFNHU04vTU1FIGluICM0 IGRpcmVjdGx5IHJlamVjdCB0aGUgcmVxdWVzdD8NCj4gDQoNClRoaXMgaXMgdGhlIGNvcm5lciBj YXNlIHdlIG9ic2VydmVkIGluIEtvcmVhIGFuZCB0aGUgU0dTTi9NTUUgcmVqZWN0cyB0aGUgcmVx dWVzdCBidXQgaXQgZG9lc24ndCB1c2UgYW4gYXBwcm9wcmlhdGUgZXJyb3IgY29kZS4NCkluIGJv dGggY2FzZXMgb2JzZXJ2ZWQsIHRoZSByZWplY3Rpb24gY2FtZSB3aXRoIGNhdXNlIGNvZGUgIzI3 IChNaXNzaW5nIG9yIHVua25vd24gQVBOKS4NCg0KPiANCj4gPiAtLS0tIEhMUi9IU1MgLS0tLQ0K PiA+IFdoZW4gdGhlIEhMUiByZWNlaXZlcyBhbiBVcGRhdGUgR1BSUyBMb2NhdGlvbiBtZXNzYWdl LCBpdCBoYXMgdG8gcHJvdmlkZQ0KPiB0aGUNCj4gPiBzdWJzY3JpYmVyIHByb2ZpbGUgdG8gdGhl IHJlcXVlc3RpbmcgZW50aXR5LiBBbGwgc3Vic2NyaWJlcnMgaGF2ZSB0aGVpciBBUE5zDQo+ID4g c2V0IGZvciBJUHY0LW9ubHkgd2l0aCBleHRlbmRlZCBQRFAgc3VwcG9ydCAoSVB2NHY2KS4NCj4g Pg0KPiA+IFdoZW4gcmVjZWl2aW5nIHRoaXMgbWVzc2FnZSwgdGhlIEhMUiBjb21wYXJlcyB0aGUg U0dTTiBWTFIgYWRkcmVzcyB3aXRoIGENCj4gPiB3aGl0ZWxpc3QgZGF0YWJhc2UgYW5kIGRlY2lk ZSBpZiB0aGUgU0dTTiBpcyBkZWVtZWQgSVB2NiBjb21wbGlhbnQuIEF0DQo+ID4gZmlyc3QsIHRo aXMgZGF0YWJhc2Ugd2lsbCBiZSBlbXB0eSBidXQgYXMgSVB2NiBzdXBwb3J0IGlzIGNvbmZpcm1l ZCB0aHJvdWdoDQo+ID4gZWl0aGVyIHRlc3RpbmcsIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSBvcGVy YXRvciBvciB0aGUgSVIuMjEsIHdlIHdpbGwNCj4gPiBwb3B1bGF0ZSB0aGlzIGRhdGFiYXNlLg0K PiA+DQo+ID4gVWx0aW1hdGVseSwgdGhlIEhMUiBzZW5kcyBvdXQgYSBwcm9maWxlIHRoYXQgZWl0 aGVyIGNvbnRhaW5zIElQdjQgb25seSBvcg0KPiA+IElQdjQgKyBJUHY0djYgYmFzZWQgb24gdGhp cyB3aGl0ZWxpc3QgZGF0YWJhc2UuDQo+ID4NCj4gPiBVbmZvcnR1bmF0ZWx5LCB0aGlzIGlzIG5v dCB5ZXQgYSBzdGFuZGFyZCBmZWF0dXJlIGluIGFueSBITFIgYnV0IG91ciBITFINCj4gPiB2ZW5k b3IgaGFzIGJlZW4gY29vcGVyYXRpdmUgdG8gZGV2ZWxvcCB0aGlzIG1hcmtldCBjdXN0b21pemF0 aW9uIGZvciB1cy4NCj4gPg0KPiA+IC0tLS0gR0dTTi9TLUdXL1AtR1cgLS0tLQ0KPiA+IFdoZW4g dGhlIEdHU04vUC1HVyByZWNlaXZlcyBhIHNlc3Npb24gY3JlYXRpb24gcmVxdWVzdCwgaXQgY2Ft ZSBpbiBhcw0KPiBlaXRoZXINCj4gPiBJUHY0IG9yIElQdjR2NiAoc2VlIFNHU04vTU1FIGZvciBT ZXNzaW9uIE1hbmFnZW1lbnQpLiBUaGUgQVBOcyBvbiB0aGUNCj4gPiBHR1NOL1AtR1cgdGhhdCB0 aGUgY3VzdG9tZXJzIGFyZSByZXF1ZXN0aW5nIGFyZSBjb25maWd1cmVkIHRvIHN1cHBvcnQNCj4g SVB2NHY2DQo+ID4gKGFuZCBieSBleHRlbnNpb24gSVB2NC1vbmx5IGFuZCBJUHY2LW9ubHkpLiBP biBzZXNzaW9uIGNyZWF0aW9uIHJlcXVlc3QsIHRoZQ0KPiA+IEdHU04vUC1HVyBzZW5kcyBhbiBB Y2Nlc3MtUmVxdWVzdCB0byBhIEFBQSBzZXJ2ZXIsIHNlbmRpbmcgdGhlIHZTR1NODQo+ID4gTUND K01OQywgdGhlIElNRUkgYW5kIHRoZSBQRFAgVHlwZSByZWNlaXZlZC4NCj4gPg0KPiA+IFRoZSBB QUEgQWNjZXNzLUFjY2VwdCBjb250YWlucyBhIG5ldyBBUE4gbmFtZSB0aGF0IHRoZSBHR1NOL1At R1cgd2lsbA0KPiB1c2UgdG8NCj4gPiBlZmZlY3RpdmVseSBlc3RhYmxpc2ggdGhlIHNlc3Npb24u IFRoZSByZWRpcmVjdGlvbiBBUE4gaXMgdXNlZCBtYWtlIGEgZmluYWwNCj4gPiBzZWxlY3Rpb24g b24gdGhlIElQIHR5cGUgdXNlZCAoSVB2NCBvciBJUHY2IG9yIElQdjR2NikNCj4gPg0KPiA+IFJl cXVlc3RlZCBBUE46IGludGVybmV0DQo+ID4gUG9zc2libGUgQUFBIG91dHB1dDogdjQuaW50ZXJu ZXQsIGRzLmludGVybmV0IG9yIHY2LmludGVybmV0DQo+ID4NCj4gPiAtLS0tIEFBQSBTZXJ2ZXIg LS0tLQ0KPiA+IFRoZSBBQUEgcmVjZWl2ZXMgdGhlIEFjY2Vzcy1SZXF1ZXN0IGZyb20gdGhlIEdH U04vUC1HVy4gSXQgaW1wbGVtZW50cyBhDQo+ID4gbG9naWMgdGhhdCB3aWxsIHVsdGltYXRlbHkg ZGVjaWRlIHdoYXQgdHlwZSBvZiBQRFAgd2Ugc2hvdWxkIHVzZSBmb3IgdGhpcw0KPiA+IHNlc3Np b24uDQo+ID4NCj4gPiBUaGUgZm9sbG93aW5nIGNoZWNrcyBhcmUgcGVyZm9ybWVkOg0KPiA+IC0g UmVxdWVzdGVkIFBEUCBUeXBlOiBpZiBJUHY0IG9yIElQdjYsIGFueSBjaGFuZ2Ugd2lsbCBicmVh ayB0aGUgZGF0YQ0KPiA+IHNlc3Npb24gc28gYWxsb3cgYXMgaXMgKHY0IHdvdWxkIGJlIGZvciBv bGRlciBkZXZpY2VzIG9yIGEgZmFsbGJhY2sgc2NlbmFyaW8NCj4gPiBhbG9uZyB0aGUgcGF0aDsg djYgd291bGQgYmUgYmVjYXVzZSB0aGUgdXNlciByZWNvbmZpZ3VyZWQgaGlzIFVFIHRvIGRpcmVj dGx5DQo+ID4gcmVxdWVzdCBJUHY2IGluc3RlYWQgb2YgdGhlIGRlZmF1bHQgSVB2NHY2KQ0KPiA+ IC0gU0dTTiBNQ0MtTU5DOiB3aXRob3V0IGEgY29uZmlybWF0aW9uIHRoYXQgdGhpcyBQTE1OIElE IHN1cHBvcnRzIElQdjYsDQo+ID4gZmFsbGJhY2sgdG8gSVB2NA0KPiA+IC0gSU1FSTogZXh0cmFj dCBUQUMgYW5kIFNWIGNvbXBvbmVudHMgYW5kIHZlcmlmeSBpZiBkZXZpY2UgaGFzIDQ2NFhMQVQN Cj4gPiBzdXBwb3J0LiBJZiBpdCBkb2VzLCBhbGxvdyBJUHY2LW9ubHksIG90aGVyd2lzZSBhbGxv dyBkdWFsLXN0YWNrDQo+ID4NCj4gPiBCYXNlZCBvbiB0aGUgYWJvdmUgY2hlY2tzLCB0aGUgQUFB IHdpbGwgZGVjaWRlIHdoaWNoIEFQTiB0byBzZW5kIHRoZQ0KPiA+IGN1c3RvbWVyIHRvIGFuZCB0 aGlzIGlzIHdoYXQgd2lsbCB1bHRpbWF0ZWx5IGRlY2lkZSBpZiB3ZSBhbGxvdyBJUHY2LW9ubHkN Cj4gPiByb2FtaW5nIG9yIG5vdC4NCj4gDQo+IEFBQSBpcyBsb2NhdGVkIGluIHRoZSBHaS9TR2kg aW50ZXJmYWNlLiBJZiB0aGUgc2lnbmFsIGNvbWVzIHRvIEFBQQ0KPiBzZXJ2ZXIsIHRoYXQgbWVh bnMgdGhlcmUgaXMgbm8gaXNzdWVzIHdpdGggdGhlIGludGVyd29ya2luZyBiZXR3ZWVuDQo+IHZT R1NOL1NHVyBhbmQgSFNTL0hMUi4NCg0KVGhlcmUgaXMgbm8gaW50ZXJ3b3JraW5nIGlzc3VlIGJ1 dCBpdCBpcyBzdGlsbCBwb3NzaWJsZSB0aGF0IHRoZSB2aXNpdGVkIG5ldHdvcmsgY2hhbmdlZCB0 aGUgUERQIHR5cGUgZnJvbSBJUHY0djYgdG8gSVB2NC4NCg0KPiBJZiBJIHVuZGVyc3RhbmQgY29y cmVjdGx5LCB5b3UgbWF5IHJlY29tbWVuZCB1c2luZyBBQUEgc2VydmVyIHRvIGd1aWRlDQo+IHRo ZSB1c2VyJ3MgcmVxdWVzdCB0byBJUHY2LW9ubHkrNDY0eGxhdCBvciBkdWFsLXN0YWNrIG9yIElQ djQgZmFsbGJhY2sNCj4gQXMgcGVyIDIzLjQwMSBhbmQgMjkuMDYxLCBBQUEgc2VydmVyIGlzIG9u ZSBvZiBkZXBsb3ltZW50IG9wdGlvbnMuIERpZA0KPiB5b3UgZXZhbHVhdGUgaWYgdGhlIHJlY29t bWVuZGF0aW9uIGlzIGFwcGxpY2FibGUgd2lkZWx5Pw0KDQpUaGUgc3RhbmRhcmQgZGVwbG95bWVu dCBvcHRpb24gYXMgcGVyIHRoZSBzcGVjIHdvdWxkIGJlIHRvIHBlcmZvcm0gSVAgYWRkcmVzcyBh bGxvY2F0aW9uIHRocm91Z2ggdGhlIEFBQSBzZXJ2ZXIgYW5kIHRodXMgZGVjaWRlIHRoZSB0eXBl IG9mIHJlc291cmNlIHRvIGFsbG9jYXRlLiBGcm9tIG15IHVuZGVyc3RhbmRpbmcsIGl0IGlzIGEg dmFsaWQgYW5kIHdpZGVseSBkZXBsb3lhYmxlIG9wdGlvbi4NCg0KSW4gb3VyIGNhc2UgaG93ZXZl ciwgd2UgYXJlIG5vdCB1c2luZyBBQUEgZm9yIElQIGFsbG9jYXRpb24gc28gdGhpcyB3YXMgbm90 IHRoZSBiZXN0IG9wdGlvbi4gV2UgYXJlIGN1cnJlbnRseSB1c2luZyBhIGxvY2FsIHBvb2wgKG9u IHRoZSBHR1NOL1AtR1cpIGFuZCBtb3ZpbmcgdG93YXJkcyBhIERIQ1AuDQoNCldoYXQgaXMgaG93 ZXZlciBhdmFpbGFibGUgZnJvbSBvdXIgZXF1aXBtZW50IHZlbmRvciBpcyB0aGUgYWJpbGl0eSB0 byBtb2RpZnkgdGhlIFVFIHJlcXVlc3RlZCBBUE4gYnkgcmV0dXJuaW5nIEFWUCBDYWxsZWQtU3Rh dGlvbi1JZCB3aXRoIGEgbmV3IEFQTiBuYW1lIGluIHRoZSBBY2Nlc3MtQWNjZXB0IG1lc3NhZ2Uu IFRoaXMgInNlbGVjdGVkIiBBUE4gaXMgY29uZmlndXJlZCBvbiB0aGUgR0dTTi9QLUdXIHRvIGJl IGVpdGhlciBJUHY0LU9ubHksIElQdjYtT25seSBvciBkdWFsLXN0YWNrIHdpdGggbm8gZnVydGhl ciBBQUEgQXV0aGVudGljYXRpb24gcHJvY2VkdXJlcy4NCg0KVUUgcmVxdWVzdGVkIEFQTjogZGF0 YQ0KQUFBIHNlbGVjdGVkIEFQTjogdjQuZGF0YSBvciB2Ni5kYXRhIG9yIGRzLmRhdGENCg0KPiAN Cj4gQmVzdCBSZWdhcmRzDQo+IA0KPiBHYW5nDQo+IA0KPiA+DQo+ID4gRGF2ZSBNaWNoYXVkDQoN CkRhdmUgTWljaGF1ZA0KClRoaXMgZS1tYWlsIChhbmQgYXR0YWNobWVudChzKSkgaXMgY29uZmlk ZW50aWFsLCBwcm9wcmlldGFyeSwgbWF5IGJlIHN1YmplY3QgdG8gY29weXJpZ2h0IGFuZCBsZWdh bCBwcml2aWxlZ2UgYW5kIG5vIHJlbGF0ZWQgcmlnaHRzIGFyZSB3YWl2ZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3IgaXRzIGFnZW50LCBhbnkgcmV2aWV3LCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCBvciBhbnkg b2YgaXRzIGNvbnRlbnQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBBbGwgbWVzc2FnZXMgbWF5IGJlIG1vbml0b3JlZCBhcyBwZXJtaXR0ZWQgYnkgYXBwbGljYWJs ZSBsYXcgYW5kIHJlZ3VsYXRpb25zIGFuZCBvdXIgcG9saWNpZXMgdG8gcHJvdGVjdCBvdXIgYnVz aW5lc3MuIEUtbWFpbHMgYXJlIG5vdCBzZWN1cmUgYW5kIHlvdSBhcmUgZGVlbWVkIHRvIGhhdmUg YWNjZXB0ZWQgYW55IHJpc2sgaWYgeW91IGNvbW11bmljYXRlIHdpdGggdXMgYnkgZS1tYWlsLiBJ ZiByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBhbmQgZGVs ZXRlIHRoZSBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGZyb20gYW55IGNvbXB1dGVyIG9y IGFueSBzdG9yYWdlIG1lZGl1bSB3aXRob3V0IHByaW50aW5nIGEgY29weS4KCkNlIGNvdXJyaWVs IChhaW5zaSBxdWUgc2VzIHBpw6hjZXMgam9pbnRlcykgZXN0IGNvbmZpZGVudGllbCwgZXhjbHVz aWYsIGV0IHBldXQgZmFpcmUgbOKAmW9iamV0IGRlIGRyb2l0IGTigJlhdXRldXIgZXQgZGUgcHJp dmlsw6hnZSBqdXJpZGlxdWU7IGF1Y3VuIGRyb2l0IGNvbm5leGUgbuKAmWVzdCBleGNsdS4gU2kg dm91cyBu4oCZw6p0ZXMgcGFzIGxlIGRlc3RpbmF0YWlyZSB2aXPDqSBvdSBzb24gcmVwcsOpc2Vu dGFudCwgdG91dGUgw6l0dWRlLCBkaWZmdXNpb24sIHRyYW5zbWlzc2lvbiBvdSBjb3BpZSBkZSBj ZSBjb3VycmllbCBlbiB0b3V0IG91IGVuIHBhcnRpZSwgZXN0IHN0cmljdGVtZW50IGludGVyZGl0 ZSBldCBwZXV0IMOqdHJlIGlsbMOpZ2FsZS4gVG91cyBsZXMgbWVzc2FnZXMgcGV1dmVudCDDqnRy ZSBzdXJ2ZWlsbMOpcywgc2Vsb24gbGVzIGxvaXMgZXQgcsOoZ2xlbWVudHMgYXBwbGljYWJsZXMg ZXQgbGVzIHBvbGl0aXF1ZXMgZGUgcHJvdGVjdGlvbiBkZSBub3RyZSBlbnRyZXByaXNlLiBMZXMg Y291cnJpZWxzIG5lIHNvbnQgcGFzIHPDqWN1cmlzw6lzIGV0IHZvdXMgw6p0ZXMgcsOpcHV0w6lz IGF2b2lyIGFjY2VwdMOpIHRvdXMgbGVzIHJpc3F1ZXMgcXVpIHkgc29udCBsacOpcyBzaSB2b3Vz IGNob2lzaXNzZXogZGUgY29tbXVuaXF1ZXIgYXZlYyBub3VzIHBhciBjZSBtb3llbi4gU2kgdm91 cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbm91cyBlbiBhdmlz ZXIgaW1tw6lkaWF0ZW1lbnQgZXQgc3VwcHJpbWVyIGNlIGNvdXJyaWVsIChhaW5zaSBxdWUgdG91 dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMpIGRlIHRvdXQgb3JkaW5hdGV1ciBvdSBzdXBwb3J0IGRl IGRvbm7DqWVzIHNhbnMgZW4gaW1wcmltZXIgdW5lIGNvcGllLiAK From prvs=9712ab07a=Dave.Michaud@rci.rogers.com Mon Sep 23 13:56:52 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAB421F8F2A for ; Mon, 23 Sep 2013 13:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l51Kfn9ZDq7o for ; Mon, 23 Sep 2013 13:56:46 -0700 (PDT) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8723E21F8F24 for ; Mon, 23 Sep 2013 13:56:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssAAHyqQFKOkg56l2dsb2JhbABZhzq+ABeBIg4BAQEBAQgWBzyCJQEBAQQSEQ0EHwsBEQQFDAQCAQYCEQQBAQECAgYGFwECAgIBAR8lCQgBAQQTCBMHh1EDD44KkBGLQohIDYlqgSmLToEvBgaBAgYrBwQCgmM1gQADjxKHAY4tiHMggSwBCBc X-IronPort-AV: E=Sophos;i="4.90,965,1371096000"; d="scan'208";a="337934685" Received: from rssesnexigwb.rss.rogers.com (HELO rsoesnexigwb.rci.rogers.ca) ([142.146.14.122]) by mail.mail.rss.rogers.com with ESMTP; 23 Sep 2013 16:56:43 -0400 Received: from RSOESNGTABHB.rci.rogers.ca ([10.3.37.23]) by rsoesnexigwb.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 16:56:43 -0400 Received: from CL08MBE.rci.rogers.ca ([10.3.45.56]) by RSOESNGTABHB.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 16:56:42 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Sep 2013 16:55:43 -0400 Message-ID: <29AE8DB910E7704CA043795E00DCBE780A363FED@CL08MBE.rci.rogers.ca> In-Reply-To: <5A5E3B5B-480B-4C3E-9032-E76EA6129408@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac64ltIBkrooMnDAQjm4aS/N3qQc9QAB725g References: <29AE8DB910E7704CA043795E00DCBE780A363F32@CL08MBE.rci.rogers.ca> <5A5E3B5B-480B-4C3E-9032-E76EA6129408@gmail.com> From: "Dave Michaud" To: "Jouni Korhonen" X-OriginalArrivalTime: 23 Sep 2013 20:56:42.0559 (UTC) FILETIME=[68112CF0:01CEB89F] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Wed, 25 Sep 2013 08:31:10 -0700 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, Cameron Byrne , Victor Kuarsingh Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:56:52 -0000 VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbnMgb24gZGlmZmVyZW5jZXMgYmV0d2VlbiBTR1NO IGFuZCBNTUUuIFdlIHN0aWxsIGhhdmUgbGltaXRlZCBMVEUgcm9hbWluZyBzbyB3ZSBhcmUgbm90 IHJ1bm5pbmcgaW50byB0aGVzZSBpc3N1ZXMgeWV0Li4uDQoNClJlZ2FyZGluZyB5b3VyIHF1ZXN0 aW9uIGFib3V0IG91ciBHUFJTU3Vic2NyaXB0aW9uRGF0YSBpbiB0aGUgSExSLCBJIGNhbid0IHRl bGwgZm9yIHN1cmUgYWJvdXQgdGhpcyBvbmUuIEdpdmVuIENhbWVyb24ncyBleHBlcmllbmNlLCB3 ZSBzdG9wcGVkIHRoZSBkZXBsb3ltZW50IGFuZCByZXF1ZXN0ZWQgYSBwYXRjaCBmcm9tIG91ciBI TFIgdmVuZG9yIGJlZm9yZSBpdCB3ZW50IGxpdmUuDQoNCkRhdmUgTWljaGF1ZA0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm91bmkgS29yaG9uZW4gW21haWx0bzpq b3VuaS5ub3NwYW1AZ21haWwuY29tXQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMywgMjAx MyAzOjU1IFBNDQo+IFRvOiBEYXZlIE1pY2hhdWQNCj4gQ2M6IEdhbmdDaGVuOyBJUHY2IE9wcyBX RzsgZHJhZnQtY2hlbi12Nm9wcy1pcHY2LXJvYW1pbmctDQo+IGFuYWx5c2lzQHRvb2xzLmlldGYu b3JnOyBDYW1lcm9uIEJ5cm5lOyBWaWN0b3IgS3VhcnNpbmdoOyBWw616ZGFsIEFsZcWhOyBIdWkN Cj4gRGVuZzsgZnJlZEBjaXNjby5jb207IEpvaG4gSmFzb24gQnJ6b3pvd3NraTsgQklORVQgRGF2 aWQgSU1UL09MTjsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBkcmFmdC1jaGVuLXY2b3BzLWlwdjYtcm9hbWluZy1hbmFseXNpcw0KPiANCj4g DQo+IEp1c3Qgc29tZSBuaXRwaWNraW5nIGlubGluZS4gR3JlYXQgc3R1ZmYgYnR3IGFuZCB0aGFu a3MgZm9yIHNoYXJpbmcgaXQuDQo+IA0KPiBPbiBTZXAgMjAsIDIwMTMsIGF0IDU6MTAgUE0sIERh dmUgTWljaGF1ZCA8RGF2ZS5NaWNoYXVkQHJjaS5yb2dlcnMuY29tPg0KPiB3cm90ZToNCj4gDQo+ ID4gSGkgR2FuZywNCj4gPg0KPiA+IFRoZXJlIGhhcyBiZWVuIGEgbG90IG9mIGNvbW1lbnRzIG9u IHRoaXMgZHJhZnQgYWxyZWFkeSBhbmQgYSBwcmVzZW50YXRpb24gYXQNCj4gSUVURjg3IGJ1dCBu b3RoaW5nIGhhcyBiZWVuIGluY2x1ZGVkIGluIGEgcmV2aXNlZCB2ZXJzaW9uIHlldCBzbyBpdCdz IGRpZmZpY3VsdCB0bw0KPiBoYXZlIGEgY2xlYXIgdmlldyBvZiB3aGVyZSB3ZSBzdGFuZCBhdCB0 aGlzIHBvaW50IGFuZCBjb21tZW50IGZ1cnRoZXIuDQo+ID4NCj4gPiBOb25ldGhlbGVzcywgSSdk IGxpa2UgdG8gc2hhcmUgb3VyIG93biBleHBlcmllbmNlIGluIGRlcGxveWluZyBJUHY2IGZvciBv dXINCj4gaG9tZSBzdWJzY3JpYmVycyBhbmQgdGhlIGV4cGVjdGVkIHJvYW1pbmcgaW1wYWN0LiBJ IGd1ZXNzIGl0IGNhbiBzZXJ2ZSBhcw0KPiBpbnB1dCBmb3IgdGhpcyBkcmFmdCBvciBmb3IgYSBm dXR1cmUgQkNQLiBPdXIgdGFyZ2V0IGlzIHRvIGVuYWJsZSBJUHY2LW9ubHkgKGFuZA0KPiBub3Qg ZHVhbC1zdGFjaykgZm9yIGFzIG1hbnkgc3Vic2NyaWJlciBhcyB3ZSBjYW4sIHJvYW1pbmcgb3Ig bm90IGJ1dCBvYnZpb3VzbHkNCj4gd2Ugd2FudCB0byBlbnN1cmUgdGhhdCB0aGUgc2VydmljZSBr ZWVwcyB3b3JraW5nIGFzIGl0IGRvZXMgdG9kYXkuIFdlIGFyZSBhbHNvDQo+IG5vdCB1c2luZyB2 UExNTiBsb2NhbCBicmVha291dCAod2hpY2ggaXMgdGhlIGNhc2UgZm9yIG1vc3Qgb3BlcmF0b3Jz KSBidXQgbWF5DQo+IGNoYW5nZSBmb3IgSU1TIHNpdHVhdGlvbnMgaW4gdGhlIGZ1dHVyZS4NCj4g Pg0KPiA+IC0tLS0gVUUgQ29uZmlndXJhdGlvbiAtLS0tDQo+ID4gVUUgY2FuIGJlIHNldCB0byBy ZXF1ZXN0IGEgUERQL1BETiBUeXBlIElQdjQsIElQdjR2NiBvciBJUHY2LiBDZXJ0YWluIFVFDQo+ IGhhdmUgdGhlIGFiaWxpdHkgYSBkaWZmZXJlbnQgY29uZmlndXJhdGlvbiBmb3IgaG9tZSBuZXR3 b3JrIC8gdmlzaXRlZCBuZXR3b3JrLg0KPiBTaW5jZSB0aGlzIGlzIHJlbGF0ZWQgdG8gcm9hbWlu ZyBjYXNlLCBteSBjb21tZW50cyBhcHBseSB0byB0aGUgcm9hbWluZw0KPiBwcm9maWxlIG9yIHRo ZSBob21lL3JvYW1pbmcgcHJvZmlsZSBpZiB0aGVyZSBpcyBubyBkaXN0aW5jdGlvbi4gVGhpcyBp cyB3aGF0IHRoZQ0KPiBVRSByZXF1ZXN0LCBub3QgbmVjZXNzYXJpbHkgdGhlIGZpbmFsIFBEUC9Q RE4gVHlwZS4uLg0KPiA+DQo+ID4gLSBJUHY0OiBoYXMgYmVlbiB3b3JraW5nIGZvciB5ZWFycywg bm8gaXNzdWUNCj4gPiAtIElQdjY6IGlmIHRoZSBVRSByZXF1ZXN0IElQdjYtb25seSBhbmQgYSBu b2RlIGluIHRoZSBwYXRoIGNhbid0IHN1cHBvcnQgaXQgKGllLg0KPiB2aXNpdGVkIFNHU04pLCB0 aGVyZSBpcyBubyBwb3NzaWJsZSBmYWxsYmFjayBhbmQgZGF0YSBpcyBicm9rZW4uIFRoaXMNCj4g Y29uZmlndXJhdGlvbiBzaG91bGQgYmUgYXZvaWRlZC4NCj4gPiAtIElQdjR2NjogdGhpcyBpcyBs ZWFzdCBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbiAoYmFzZWQgb24gcmVxdWlyZWQgM0dQUA0KPiBy ZWxlYXNlIGluIFNHU04pIGJ1dCBhbHNvIHRoZSBjb25maWd1cmF0aW9uIHRoYXQgb2ZmZXJzIHRo ZSBtb3N0IGZsZXhpYmlsaXR5LiBBcw0KPiBwZXIgM0dQUCAyNC4wMDgsIHRoaXMgUERQL1BETiBU eXBlIHNob3VsZCBiZSBpbnRlcnByZXRlZCBhcyBJUHY0IGJ5IHRoZQ0KPiBTR1NOL01NRSBpZiBp dCBkb2Vzbid0IHVuZGVyc3RhbmQgaXQuDQo+IA0KPiBSZWdhcmRpbmcgdGhlIE1NRSBwYXJ0IHNl ZSBiZWxvdy4NCj4gDQo+ID4gV2UgaGF2ZSBoYWQgc29tZSBVRSBtb2RlbHMgY29uZmlndXJlZCB0 byByZXF1ZXN0IHRoaXMgUERQL1BETiB0eXBlIGluDQo+IGNpcmN1bGF0aW9uIGZvciBvdmVyIGEg eWVhciBub3cgYW5kIHdlIGhhdmUgb2JzZXJ2ZWQgY2FzZXMgd2hlcmUgdGhlIHZTR1NODQo+IHdh cyBzaW1wbHkgcmVqZWN0aW5nIHRoZSBQRFAgQ29udGV4dCBDcmVhdGlvbiBtZXNzYWdlIHdpdGgg YSBjYXVzZSBjb2RlICMyNw0KPiAoVW5rbm93biBvciBtaXNzaW5nIEFQTikgYmVjYXVzZSBpdCBz dG9wcGVkIHByb2Nlc3NpbmcgdGhlIG1lc3NhZ2UgYXQgdGhlDQo+IFBEUCB0eXBlIChBUE4gbmFt ZSBjb21lcyByaWdodCBhZnRlcikuIFRoaXMgaG93ZXZlciBoYXMgYmVlbiBhbiBleHRyZW1lbHkN Cj4gbGltaXRlZCBjb3JuZXIgY2FzZSB3aXRoIDIgY29uZmlybWVkIG9wZXJhdG9ycy4gVWx0aW1h dGVseSwgd2UgYXJlIG5vdw0KPiBjb25maWd1cmluZyBtb3N0IFVFIHRvIHJlcXVlc3QgSVB2NHY2 IHdoaWxlIHJvYW1pbmcgKHdlIGtlcHQgc29tZSBmbGFnc2hpcA0KPiBkZXZpY2VzIGFzIElQdjQt b25seSBmb3Igbm93IGFzIHdlIGJ1aWxkIGEgZGF0YWJhc2Ugb2Ygd29ya2luZyBQTE1OcykuDQo+ ID4NCj4gPiAtLS0tIFNHU04vTU1FIGZvciBNb2JpbGl0eSBNYW5hZ2VtZW50IFByb2NlZHVyZXMg KEF0dGFjaCkgLS0tLQ0KPiA+IE9uIGF0dGFjaCwgdGhlIFNHU04vTU1FIG11c3QgY29udGFjdCB0 aGUgaG9tZSBITFIvSFNTIGFuZCBvYnRhaW4gdGhlDQo+IHN1YnNjcmliZXIgcHJvZmlsZS4gSXQg aXMgd2VsbCBrbm93biBub3cgYW5kIGhhcyBiZWVuIG9ic2VydmVkIGZpcnN0IGhhbmQgYnkNCj4g c29tZSBvZiB1cyBoZXJlIHRoYXQgbXVsdGlwbGUgU0dTTi9NTUUgd2lsbCBiZSB1bmFibGUgdG8g Y29ycmVjdGx5IHByb2Nlc3MgYQ0KPiBzdWJzY3JpYmVyIHByb2ZpbGUgcmVjZWl2ZWQgaW4gdGhl IEluc2VydCBTdWJzY3JpYmVyIERhdGEgcHJvY2VkdXJlIGlmIGl0IGNvbnRhaW5zDQo+IGFuIEV4 dC1QRFAtVHlwZSAoM0dQUCBUUyAyOS4wMDIgLyAzR1BQIFRTIDI5LjA2MCkuIEluIHRoYXQgY2Fz ZSwgaXQgYnJlYWtzIGRhdGENCj4gc28gdGhpcyBzaXR1YXRpb24gbXVzdCBiZSBhdm9pZGVkLg0K PiANCj4gWWVwLiBTR1NOcyBwcmlvciByZWxlYXNlLTkgKG9yIGluIHNvbWUgY2FzZXMgcHJlLXJl bC04KSBhcmUgbm90IHN1cHBvc2VkIHRvDQo+IHVuZGVyc3RhbmQgRXh0LVBEUC1UeXBlLi4gYW5k IHNhZGx5IHJlamVjdCB0aGUgY29udGV4dCByZXF1ZXN0IGVudGlyZWx5IG9uDQo+IGNhc2VzIEkg Y2FtZSBhY3Jvc3MuIFBvc3RlbCdzIGxhdyBkb2VzIG5vdCBzZWVtIHRvIGFwcGx5IGhlcmUgOykN Cj4gDQo+IEJ0dywganVzdCBhc2tpbmcgZm9yIGNsYXJpZmljYXRpb24uIERpZCB5b3VyIEdQUlNT dWJzY3JpcHRpb25EYXRhIGNvbnRhaW4NCj4gbXVsdGlwbGUgUERQLUNvbnRleHRzIG9yIG9ubHkg b25lICh0aGUgb25lIHdpdGggRXh0LVBEUC1UeXBlKT8NCj4gDQo+IA0KPiA+IERldGFpbHMgb24g dGhlIHNvbHV0aW9uIGFyZSBpbiB0aGUgSExSIHNlY3Rpb24gYmVsb3cgYnV0IHVsdGltYXRlbHks IHVubGVzcyB3ZQ0KPiBrbm93IGZvciBzdXJlIHRoYXQgYW4gU0dTTiAoYW5kIHRoZSBvcGVyYXRv ciBpbiBnZW5lcmFsIGFzIHBlciBJUi4yMSksIHRoZSBTR1NODQo+IHdpbGwgcmVjZWl2ZSBhIHN1 YnNjcmliZXIgcHJvZmlsZSB0aGF0IGNvbnRhaW5zIElQdjQtb25seSBhcyB0aGUgYXZhaWxhYmxl IFBEUA0KPiB0eXBlIChub3QgcHJlc2VuY2Ugb2YgSVB2NiBhdCBhbGwpLg0KPiA+DQo+ID4gQXQg dGhpcyBzdGFnZSwgdGhlIFNHU04gc2hvdWxkIHRoZXJlZm9yZSByZWNlaXZlIGEgc3Vic2NyaWJl ciBwcm9maWxlDQo+IGNvbnRhaW5pbmcgb25seSBmaWVsZHMgaXQgY2FuIHVuZGVyc3RhbmQgYW5k IHRoaXMgYXR0YWNoIHdpbGwgY29tcGxldGUNCj4gc3VjY2Vzc2Z1bGx5Lg0KPiA+DQo+ID4gLS0t LSBTR1NOL01NRSBmb3IgU2Vzc2lvbiBNYW5hZ2VtZW50IFByb2NlZHVyZXMgKFBEUCBDb250ZXh0 L0JlYXJlcikgLS0tDQo+IC0NCj4gPiBXaGVuIHRoZSBTR1NOL01NRSByZWNlaXZlcyBhIHNlc3Np b24gY3JlYXRpb24gcmVxdWVzdCBmcm9tIHRoZSBVRQ0KPiAoUERQL1BETiBUeXBlIElQdjR2Niks IHRoZSBmb2xsb3dpbmcgc2l0dWF0aW9ucyBhcmUgcG9zc2libGU6DQo+ID4NCj4gPiAxLiBTR1NO L01NRSBkb2VzIG5vdCB1bmRlcnN0YW5kIElQdjR2NiBzbyBpdCBmYWxscyBiYWNrIHRvIElQdjQg YXMgcGVyIHNwZWMNCj4gDQo+IE1NRSBzaG91bGQgbm90IGZhbGwgYmFjayB0byBJUHY0Li4gZm9y IEVQQyBub2RlcyB1bmtub3duIFBETiBUeXBlIGlzDQo+IHN1cHBvc2VkIHRvIGJlIHRyZWF0ZWQg YXMgSVB2Ni4NCj4gDQo+ID4gMi4gU0dTTi9NTUUgdW5kZXJzdGFuZHMgSVB2NHY2IGJ1dCB0aGUg c3Vic2NyaWJlciBwcm9maWxlIGRpZCBub3QgY29udGFpbg0KPiBFeHQtUERQLVR5cGUgc28gaXQg ZmFsbHMgYmFjayB0byBJUHY0DQo+IA0KPiBNTUUgc2hvdWxkIG5vdCBiZSBhZmZlY3RlZCBieSBH ciBpbnRlcmZhY2UgKHVubGVzcyB0aGVyZSBpcyBzb21lIElXRiBzZXR1cCBpbg0KPiBwbGFjZSku Lg0KPiANCj4gPiAzLiBTR1NOL01NRSB1bmRlcnN0YW5kcyBJUHY0djYgYnV0IGFzIHBlciBhIGxv Y2FsIHBvbGljeSBkb2VzIG5vdCBhbGxvdyBpdA0KPiBzbyBpdCBmYWxscyBiYWNrIHRvIElQdjQN Cj4gPiAgIGEuIElQdjYgYmlsbGluZyBub3Qgc3VwcG9ydGVkDQo+ID4gICBiLiBJUHY2IG5vdCBs aWNlbnNlZA0KPiA+ICAgYy4gTG9jYWwgZGVjaXNpb24uLi4NCj4gPiA0LiBTR1NOL01NRSBkb2Vz IG5vdCB1bmRlcnN0YW5kIElQdjR2NiBhbmQgaXQgZG9lcyBub3QgZmFsbCBiYWNrIHRvIElQdjQu DQo+IA0KPiBTYW1lIGFzIDEuDQo+IA0KPiANCj4gLSBKb3VuaQ0KPiANCj4gPg0KPiA+IFBvaW50 IDQgaXMgZm9yIHVzIHRoZSBtb3N0IGNyaXRpY2FsIGFzcGVjdCBhbmQgdGhlIG9uZSB3ZSBhcmUg Zm9sbG93aW5nIGNsb3NlbHkuDQo+ID4NCj4gPiBCYXNlZCBvbiB0aGUgYWJvdmUgb3B0aW9ucywg dGhlIFNHU04vTU1FIGZvcndhcmRzIHRvIHRoZSBHR1NOL1MtR1cgYQ0KPiBzZXNzaW9uIGNyZWF0 aW9uIHJlcXVlc3Qgd2l0aCBlaXRoZXIgYSBQRFAgVHlwZSBvZiBJUHY0IG9yIElQdjR2Ni4NCj4g Pg0KPiA+IC0tLS0gSExSL0hTUyAtLS0tDQo+ID4gV2hlbiB0aGUgSExSIHJlY2VpdmVzIGFuIFVw ZGF0ZSBHUFJTIExvY2F0aW9uIG1lc3NhZ2UsIGl0IGhhcyB0byBwcm92aWRlDQo+IHRoZSBzdWJz Y3JpYmVyIHByb2ZpbGUgdG8gdGhlIHJlcXVlc3RpbmcgZW50aXR5LiBBbGwgc3Vic2NyaWJlcnMg aGF2ZSB0aGVpciBBUE5zDQo+IHNldCBmb3IgSVB2NC1vbmx5IHdpdGggZXh0ZW5kZWQgUERQIHN1 cHBvcnQgKElQdjR2NikuDQo+ID4NCj4gPiBXaGVuIHJlY2VpdmluZyB0aGlzIG1lc3NhZ2UsIHRo ZSBITFIgY29tcGFyZXMgdGhlIFNHU04gVkxSIGFkZHJlc3Mgd2l0aCBhDQo+IHdoaXRlbGlzdCBk YXRhYmFzZSBhbmQgZGVjaWRlIGlmIHRoZSBTR1NOIGlzIGRlZW1lZCBJUHY2IGNvbXBsaWFudC4g QXQgZmlyc3QsDQo+IHRoaXMgZGF0YWJhc2Ugd2lsbCBiZSBlbXB0eSBidXQgYXMgSVB2NiBzdXBw b3J0IGlzIGNvbmZpcm1lZCB0aHJvdWdoIGVpdGhlcg0KPiB0ZXN0aW5nLCBjb25maXJtYXRpb24g ZnJvbSB0aGUgb3BlcmF0b3Igb3IgdGhlIElSLjIxLCB3ZSB3aWxsIHBvcHVsYXRlIHRoaXMNCj4g ZGF0YWJhc2UuDQo+ID4NCj4gPiBVbHRpbWF0ZWx5LCB0aGUgSExSIHNlbmRzIG91dCBhIHByb2Zp bGUgdGhhdCBlaXRoZXIgY29udGFpbnMgSVB2NCBvbmx5IG9yIElQdjQgKw0KPiBJUHY0djYgYmFz ZWQgb24gdGhpcyB3aGl0ZWxpc3QgZGF0YWJhc2UuDQo+ID4NCj4gPiBVbmZvcnR1bmF0ZWx5LCB0 aGlzIGlzIG5vdCB5ZXQgYSBzdGFuZGFyZCBmZWF0dXJlIGluIGFueSBITFIgYnV0IG91ciBITFIN Cj4gdmVuZG9yIGhhcyBiZWVuIGNvb3BlcmF0aXZlIHRvIGRldmVsb3AgdGhpcyBtYXJrZXQgY3Vz dG9taXphdGlvbiBmb3IgdXMuDQo+ID4NCj4gPiAtLS0tIEdHU04vUy1HVy9QLUdXIC0tLS0NCj4g PiBXaGVuIHRoZSBHR1NOL1AtR1cgcmVjZWl2ZXMgYSBzZXNzaW9uIGNyZWF0aW9uIHJlcXVlc3Qs IGl0IGNhbWUgaW4gYXMNCj4gZWl0aGVyIElQdjQgb3IgSVB2NHY2IChzZWUgU0dTTi9NTUUgZm9y IFNlc3Npb24gTWFuYWdlbWVudCkuIFRoZSBBUE5zIG9uDQo+IHRoZSBHR1NOL1AtR1cgdGhhdCB0 aGUgY3VzdG9tZXJzIGFyZSByZXF1ZXN0aW5nIGFyZSBjb25maWd1cmVkIHRvIHN1cHBvcnQNCj4g SVB2NHY2IChhbmQgYnkgZXh0ZW5zaW9uIElQdjQtb25seSBhbmQgSVB2Ni1vbmx5KS4gT24gc2Vz c2lvbiBjcmVhdGlvbiByZXF1ZXN0LA0KPiB0aGUgR0dTTi9QLUdXIHNlbmRzIGFuIEFjY2Vzcy1S ZXF1ZXN0IHRvIGEgQUFBIHNlcnZlciwgc2VuZGluZyB0aGUgdlNHU04NCj4gTUNDK01OQywgdGhl IElNRUkgYW5kIHRoZSBQRFAgVHlwZSByZWNlaXZlZC4NCj4gPg0KPiA+IFRoZSBBQUEgQWNjZXNz LUFjY2VwdCBjb250YWlucyBhIG5ldyBBUE4gbmFtZSB0aGF0IHRoZSBHR1NOL1AtR1cgd2lsbA0K PiB1c2UgdG8gZWZmZWN0aXZlbHkgZXN0YWJsaXNoIHRoZSBzZXNzaW9uLiBUaGUgcmVkaXJlY3Rp b24gQVBOIGlzIHVzZWQgbWFrZSBhIGZpbmFsDQo+IHNlbGVjdGlvbiBvbiB0aGUgSVAgdHlwZSB1 c2VkIChJUHY0IG9yIElQdjYgb3IgSVB2NHY2KQ0KPiA+DQo+ID4gUmVxdWVzdGVkIEFQTjogaW50 ZXJuZXQNCj4gPiBQb3NzaWJsZSBBQUEgb3V0cHV0OiB2NC5pbnRlcm5ldCwgZHMuaW50ZXJuZXQg b3IgdjYuaW50ZXJuZXQNCj4gPg0KPiA+IC0tLS0gQUFBIFNlcnZlciAtLS0tDQo+ID4gVGhlIEFB QSByZWNlaXZlcyB0aGUgQWNjZXNzLVJlcXVlc3QgZnJvbSB0aGUgR0dTTi9QLUdXLiBJdCBpbXBs ZW1lbnRzIGENCj4gbG9naWMgdGhhdCB3aWxsIHVsdGltYXRlbHkgZGVjaWRlIHdoYXQgdHlwZSBv ZiBQRFAgd2Ugc2hvdWxkIHVzZSBmb3IgdGhpcyBzZXNzaW9uLg0KPiA+DQo+ID4gVGhlIGZvbGxv d2luZyBjaGVja3MgYXJlIHBlcmZvcm1lZDoNCj4gPiAtIFJlcXVlc3RlZCBQRFAgVHlwZTogaWYg SVB2NCBvciBJUHY2LCBhbnkgY2hhbmdlIHdpbGwgYnJlYWsgdGhlIGRhdGEgc2Vzc2lvbg0KPiBz byBhbGxvdyBhcyBpcyAodjQgd291bGQgYmUgZm9yIG9sZGVyIGRldmljZXMgb3IgYSBmYWxsYmFj ayBzY2VuYXJpbyBhbG9uZyB0aGUNCj4gcGF0aDsgdjYgd291bGQgYmUgYmVjYXVzZSB0aGUgdXNl ciByZWNvbmZpZ3VyZWQgaGlzIFVFIHRvIGRpcmVjdGx5IHJlcXVlc3QgSVB2Ng0KPiBpbnN0ZWFk IG9mIHRoZSBkZWZhdWx0IElQdjR2NikNCj4gPiAtIFNHU04gTUNDLU1OQzogd2l0aG91dCBhIGNv bmZpcm1hdGlvbiB0aGF0IHRoaXMgUExNTiBJRCBzdXBwb3J0cyBJUHY2LA0KPiBmYWxsYmFjayB0 byBJUHY0DQo+ID4gLSBJTUVJOiBleHRyYWN0IFRBQyBhbmQgU1YgY29tcG9uZW50cyBhbmQgdmVy aWZ5IGlmIGRldmljZSBoYXMgNDY0WExBVA0KPiBzdXBwb3J0LiBJZiBpdCBkb2VzLCBhbGxvdyBJ UHY2LW9ubHksIG90aGVyd2lzZSBhbGxvdyBkdWFsLXN0YWNrDQo+ID4NCj4gPiBCYXNlZCBvbiB0 aGUgYWJvdmUgY2hlY2tzLCB0aGUgQUFBIHdpbGwgZGVjaWRlIHdoaWNoIEFQTiB0byBzZW5kIHRo ZQ0KPiBjdXN0b21lciB0byBhbmQgdGhpcyBpcyB3aGF0IHdpbGwgdWx0aW1hdGVseSBkZWNpZGUg aWYgd2UgYWxsb3cgSVB2Ni1vbmx5DQo+IHJvYW1pbmcgb3Igbm90Lg0KPiA+DQo+ID4NCj4gPiBE YXZlIE1pY2hhdWQNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoaXMgZS1tYWlsIChhbmQgYXR0 YWNobWVudChzKSkgaXMgY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgbWF5IGJlIHN1YmplY3Qg dG8NCj4gY29weXJpZ2h0IGFuZCBsZWdhbCBwcml2aWxlZ2UgYW5kIG5vIHJlbGF0ZWQgcmlnaHRz IGFyZSB3YWl2ZWQuIElmIHlvdSBhcmUgbm90DQo+IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3Ig aXRzIGFnZW50LCBhbnkgcmV2aWV3LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3INCj4g Y29weWluZyBvZiB0aGlzIGUtbWFpbCBvciBhbnkgb2YgaXRzIGNvbnRlbnQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5IGJlDQo+IHVubGF3ZnVsLiBBbGwgbWVzc2FnZXMgbWF5IGJlIG1v bml0b3JlZCBhcyBwZXJtaXR0ZWQgYnkgYXBwbGljYWJsZSBsYXcgYW5kDQo+IHJlZ3VsYXRpb25z IGFuZCBvdXIgcG9saWNpZXMgdG8gcHJvdGVjdCBvdXIgYnVzaW5lc3MuIEUtbWFpbHMgYXJlIG5v dCBzZWN1cmUgYW5kDQo+IHlvdSBhcmUgZGVlbWVkIHRvIGhhdmUgYWNjZXB0ZWQgYW55IHJpc2sg aWYgeW91IGNvbW11bmljYXRlIHdpdGggdXMgYnkgZS0NCj4gbWFpbC4gSWYgcmVjZWl2ZWQgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgZS1tYWls DQo+IChhbmQgYW55IGF0dGFjaG1lbnRzKSBmcm9tIGFueSBjb21wdXRlciBvciBhbnkgc3RvcmFn ZSBtZWRpdW0gd2l0aG91dA0KPiBwcmludGluZyBhIGNvcHkuDQo+ID4NCj4gPiBDZSBjb3Vycmll bCAoYWluc2kgcXVlIHNlcyBwacOoY2VzIGpvaW50ZXMpIGVzdCBjb25maWRlbnRpZWwsIGV4Y2x1 c2lmLCBldCBwZXV0DQo+IGZhaXJlIGzigJlvYmpldCBkZSBkcm9pdCBk4oCZYXV0ZXVyIGV0IGRl IHByaXZpbMOoZ2UganVyaWRpcXVlOyBhdWN1biBkcm9pdCBjb25uZXhlDQo+IG7igJllc3QgZXhj bHUuIFNpIHZvdXMgbuKAmcOqdGVzIHBhcyBsZSBkZXN0aW5hdGFpcmUgdmlzw6kgb3Ugc29uIHJl cHLDqXNlbnRhbnQsIHRvdXRlDQo+IMOpdHVkZSwgZGlmZnVzaW9uLCB0cmFuc21pc3Npb24gb3Ug Y29waWUgZGUgY2UgY291cnJpZWwgZW4gdG91dCBvdSBlbiBwYXJ0aWUsIGVzdA0KPiBzdHJpY3Rl bWVudCBpbnRlcmRpdGUgZXQgcGV1dCDDqnRyZSBpbGzDqWdhbGUuIFRvdXMgbGVzIG1lc3NhZ2Vz IHBldXZlbnQgw6p0cmUNCj4gc3VydmVpbGzDqXMsIHNlbG9uIGxlcyBsb2lzIGV0IHLDqGdsZW1l bnRzIGFwcGxpY2FibGVzIGV0IGxlcyBwb2xpdGlxdWVzIGRlDQo+IHByb3RlY3Rpb24gZGUgbm90 cmUgZW50cmVwcmlzZS4gTGVzIGNvdXJyaWVscyBuZSBzb250IHBhcyBzw6ljdXJpc8OpcyBldCB2 b3VzIMOqdGVzDQo+IHLDqXB1dMOpcyBhdm9pciBhY2NlcHTDqSB0b3VzIGxlcyByaXNxdWVzIHF1 aSB5IHNvbnQgbGnDqXMgc2kgdm91cyBjaG9pc2lzc2V6IGRlDQo+IGNvbW11bmlxdWVyIGF2ZWMg bm91cyBwYXIgY2UgbW95ZW4uIFNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhcg0KPiBl cnJldXIsIHZldWlsbGV6IG5vdXMgZW4gYXZpc2VyIGltbcOpZGlhdGVtZW50IGV0IHN1cHByaW1l ciBjZSBjb3VycmllbCAoYWluc2kNCj4gcXVlIHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzKSBk ZSB0b3V0IG9yZGluYXRldXIgb3Ugc3VwcG9ydCBkZSBkb25uw6llcyBzYW5zIGVuDQo+IGltcHJp bWVyIHVuZSBjb3BpZS4NCg0KClRoaXMgZS1tYWlsIChhbmQgYXR0YWNobWVudChzKSkgaXMgY29u ZmlkZW50aWFsLCBwcm9wcmlldGFyeSwgbWF5IGJlIHN1YmplY3QgdG8gY29weXJpZ2h0IGFuZCBs ZWdhbCBwcml2aWxlZ2UgYW5kIG5vIHJlbGF0ZWQgcmlnaHRzIGFyZSB3YWl2ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3IgaXRzIGFnZW50LCBhbnkgcmV2aWV3LCBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCBvciBh bnkgb2YgaXRzIGNvbnRlbnQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBBbGwgbWVzc2FnZXMgbWF5IGJlIG1vbml0b3JlZCBhcyBwZXJtaXR0ZWQgYnkgYXBwbGlj YWJsZSBsYXcgYW5kIHJlZ3VsYXRpb25zIGFuZCBvdXIgcG9saWNpZXMgdG8gcHJvdGVjdCBvdXIg YnVzaW5lc3MuIEUtbWFpbHMgYXJlIG5vdCBzZWN1cmUgYW5kIHlvdSBhcmUgZGVlbWVkIHRvIGhh dmUgYWNjZXB0ZWQgYW55IHJpc2sgaWYgeW91IGNvbW11bmljYXRlIHdpdGggdXMgYnkgZS1tYWls LiBJZiByZWNlaXZlZCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBhbmQg ZGVsZXRlIHRoZSBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGZyb20gYW55IGNvbXB1dGVy IG9yIGFueSBzdG9yYWdlIG1lZGl1bSB3aXRob3V0IHByaW50aW5nIGEgY29weS4KCkNlIGNvdXJy aWVsIChhaW5zaSBxdWUgc2VzIHBpw6hjZXMgam9pbnRlcykgZXN0IGNvbmZpZGVudGllbCwgZXhj bHVzaWYsIGV0IHBldXQgZmFpcmUgbOKAmW9iamV0IGRlIGRyb2l0IGTigJlhdXRldXIgZXQgZGUg cHJpdmlsw6hnZSBqdXJpZGlxdWU7IGF1Y3VuIGRyb2l0IGNvbm5leGUgbuKAmWVzdCBleGNsdS4g U2kgdm91cyBu4oCZw6p0ZXMgcGFzIGxlIGRlc3RpbmF0YWlyZSB2aXPDqSBvdSBzb24gcmVwcsOp c2VudGFudCwgdG91dGUgw6l0dWRlLCBkaWZmdXNpb24sIHRyYW5zbWlzc2lvbiBvdSBjb3BpZSBk ZSBjZSBjb3VycmllbCBlbiB0b3V0IG91IGVuIHBhcnRpZSwgZXN0IHN0cmljdGVtZW50IGludGVy ZGl0ZSBldCBwZXV0IMOqdHJlIGlsbMOpZ2FsZS4gVG91cyBsZXMgbWVzc2FnZXMgcGV1dmVudCDD qnRyZSBzdXJ2ZWlsbMOpcywgc2Vsb24gbGVzIGxvaXMgZXQgcsOoZ2xlbWVudHMgYXBwbGljYWJs ZXMgZXQgbGVzIHBvbGl0aXF1ZXMgZGUgcHJvdGVjdGlvbiBkZSBub3RyZSBlbnRyZXByaXNlLiBM ZXMgY291cnJpZWxzIG5lIHNvbnQgcGFzIHPDqWN1cmlzw6lzIGV0IHZvdXMgw6p0ZXMgcsOpcHV0 w6lzIGF2b2lyIGFjY2VwdMOpIHRvdXMgbGVzIHJpc3F1ZXMgcXVpIHkgc29udCBsacOpcyBzaSB2 b3VzIGNob2lzaXNzZXogZGUgY29tbXVuaXF1ZXIgYXZlYyBub3VzIHBhciBjZSBtb3llbi4gU2kg dm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbm91cyBlbiBh dmlzZXIgaW1tw6lkaWF0ZW1lbnQgZXQgc3VwcHJpbWVyIGNlIGNvdXJyaWVsIChhaW5zaSBxdWUg dG91dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMpIGRlIHRvdXQgb3JkaW5hdGV1ciBvdSBzdXBwb3J0 IGRlIGRvbm7DqWVzIHNhbnMgZW4gaW1wcmltZXIgdW5lIGNvcGllLiAK From jouni.nospam@gmail.com Mon Sep 23 22:30:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66B21F9E4D for ; Mon, 23 Sep 2013 22:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZaAmGodmraN for ; Mon, 23 Sep 2013 22:30:10 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 88D0321F9DE9 for ; Mon, 23 Sep 2013 22:30:09 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id q8so3460956lbi.11 for ; Mon, 23 Sep 2013 22:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qw4w149MNzZcJ0L35pX3pP62hJa76lfWHG+vW+dOxmA=; b=V2haY0Dx7dPz24jpHrbxx4qFzhdPVxdNu27SMf5OrXjrvA7BcyFuSbrtluGVwcEcRe Nl6bJAKeOFyDFpmALlX088Ems4bf76HUFN+8Xq+UrIzDr+8+Q54MTqueDM+W0uwi0jnM hE0tDATEMVe5qSkz/gzJ7zx2DVcFX2EJESUep/gEki9sydfm3gis7Lin1ZqOAoT3QZ1M FnvYFCj6wp9t+0Wlv/54ZCZwlS9G7p0VK02tM17r6w/NqUQlK7aFhkr/8+3DvxzMRUj7 ii4hFh9DAda8CrAY3HmJaiirWorZ9JI+T3CoWSWXZw2TXJEJW2ALOaSzeYA+1eA/Vmjr ahDg== X-Received: by 10.152.7.100 with SMTP id i4mr84088laa.35.1380000607673; Mon, 23 Sep 2013 22:30:07 -0700 (PDT) Received: from [192.168.250.30] ([194.100.71.98]) by mx.google.com with ESMTPSA id vo1sm14098098lbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 22:30:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <29AE8DB910E7704CA043795E00DCBE780A363FED@CL08MBE.rci.rogers.ca> Date: Tue, 24 Sep 2013 08:30:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <994FED44-27D4-45F4-87E1-FC1E319EA79D@gmail.com> References: <29AE8DB910E7704CA043795E00DCBE780A363F32@CL08MBE.rci.rogers.ca> <5A5E3B5B-480B-4C3E-9032-E76EA6129408@gmail.com> <29AE8DB910E7704CA043795E00DCBE780A363FED@CL08MBE.rci.rogers.ca> To: Dave Michaud X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Wed, 25 Sep 2013 08:31:03 -0700 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, Cameron Byrne , Victor Kuarsingh Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 05:30:11 -0000 On Sep 23, 2013, at 11:55 PM, Dave Michaud = wrote: > Thanks for the clarifications on differences between SGSN and MME. We = still have limited LTE roaming so we are not running into these issues = yet... >=20 > Regarding your question about our GPRSSubscriptionData in the HLR, I = can't tell for sure about this one. Given Cameron's experience, we = stopped the deployment and requested a patch from our HLR vendor before = it went live. I am just interested on the GPRSSubscriptionData because if the SGSN = would not drop whole GPRSSubscriptionData based on one PDP-Context it = does not understand, then it could be possible to include another = PDP-Type IPv4 PDP-Context for the same APN in the GPRSSubscriptionData.. = and the SGSN could supposedly use that. I am sure I tried this is one = setup but cannot remember the outcome anymore :( (anyway, such setup = involves quite many assumptions in an SGSN and a GGSN regarding e.g. the = fallback behaviour..) - JOuni >=20 > Dave Michaud >=20 >=20 >> -----Original Message----- >> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, September 23, 2013 3:55 PM >> To: Dave Michaud >> Cc: GangChen; IPv6 Ops WG; draft-chen-v6ops-ipv6-roaming- >> analysis@tools.ietf.org; Cameron Byrne; Victor Kuarsingh; V=EDzdal = Ale=9A; Hui >> Deng; fred@cisco.com; John Jason Brzozowski; BINET David IMT/OLN; >> mohamed.boucadair@orange.com >> Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis >>=20 >>=20 >> Just some nitpicking inline. Great stuff btw and thanks for sharing = it. >>=20 >> On Sep 20, 2013, at 5:10 PM, Dave Michaud = >> wrote: >>=20 >>> Hi Gang, >>>=20 >>> There has been a lot of comments on this draft already and a = presentation at >> IETF87 but nothing has been included in a revised version yet so it's = difficult to >> have a clear view of where we stand at this point and comment = further. >>>=20 >>> Nonetheless, I'd like to share our own experience in deploying IPv6 = for our >> home subscribers and the expected roaming impact. I guess it can = serve as >> input for this draft or for a future BCP. Our target is to enable = IPv6-only (and >> not dual-stack) for as many subscriber as we can, roaming or not but = obviously >> we want to ensure that the service keeps working as it does today. We = are also >> not using vPLMN local breakout (which is the case for most operators) = but may >> change for IMS situations in the future. >>>=20 >>> ---- UE Configuration ---- >>> UE can be set to request a PDP/PDN Type IPv4, IPv4v6 or IPv6. = Certain UE >> have the ability a different configuration for home network / visited = network. >> Since this is related to roaming case, my comments apply to the = roaming >> profile or the home/roaming profile if there is no distinction. This = is what the >> UE request, not necessarily the final PDP/PDN Type... >>>=20 >>> - IPv4: has been working for years, no issue >>> - IPv6: if the UE request IPv6-only and a node in the path can't = support it (ie. >> visited SGSN), there is no possible fallback and data is broken. This >> configuration should be avoided. >>> - IPv4v6: this is least supported configuration (based on required = 3GPP >> release in SGSN) but also the configuration that offers the most = flexibility. As >> per 3GPP 24.008, this PDP/PDN Type should be interpreted as IPv4 by = the >> SGSN/MME if it doesn't understand it. >>=20 >> Regarding the MME part see below. >>=20 >>> We have had some UE models configured to request this PDP/PDN type = in >> circulation for over a year now and we have observed cases where the = vSGSN >> was simply rejecting the PDP Context Creation message with a cause = code #27 >> (Unknown or missing APN) because it stopped processing the message at = the >> PDP type (APN name comes right after). This however has been an = extremely >> limited corner case with 2 confirmed operators. Ultimately, we are = now >> configuring most UE to request IPv4v6 while roaming (we kept some = flagship >> devices as IPv4-only for now as we build a database of working = PLMNs). >>>=20 >>> ---- SGSN/MME for Mobility Management Procedures (Attach) ---- >>> On attach, the SGSN/MME must contact the home HLR/HSS and obtain the >> subscriber profile. It is well known now and has been observed first = hand by >> some of us here that multiple SGSN/MME will be unable to correctly = process a >> subscriber profile received in the Insert Subscriber Data procedure = if it contains >> an Ext-PDP-Type (3GPP TS 29.002 / 3GPP TS 29.060). In that case, it = breaks data >> so this situation must be avoided. >>=20 >> Yep. SGSNs prior release-9 (or in some cases pre-rel-8) are not = supposed to >> understand Ext-PDP-Type.. and sadly reject the context request = entirely on >> cases I came across. Postel's law does not seem to apply here ;) >>=20 >> Btw, just asking for clarification. Did your GPRSSubscriptionData = contain >> multiple PDP-Contexts or only one (the one with Ext-PDP-Type)? >>=20 >>=20 >>> Details on the solution are in the HLR section below but ultimately, = unless we >> know for sure that an SGSN (and the operator in general as per = IR.21), the SGSN >> will receive a subscriber profile that contains IPv4-only as the = available PDP >> type (not presence of IPv6 at all). >>>=20 >>> At this stage, the SGSN should therefore receive a subscriber = profile >> containing only fields it can understand and this attach will = complete >> successfully. >>>=20 >>> ---- SGSN/MME for Session Management Procedures (PDP Context/Bearer) = --- >> - >>> When the SGSN/MME receives a session creation request from the UE >> (PDP/PDN Type IPv4v6), the following situations are possible: >>>=20 >>> 1. SGSN/MME does not understand IPv4v6 so it falls back to IPv4 as = per spec >>=20 >> MME should not fall back to IPv4.. for EPC nodes unknown PDN Type is >> supposed to be treated as IPv6. >>=20 >>> 2. SGSN/MME understands IPv4v6 but the subscriber profile did not = contain >> Ext-PDP-Type so it falls back to IPv4 >>=20 >> MME should not be affected by Gr interface (unless there is some IWF = setup in >> place).. >>=20 >>> 3. SGSN/MME understands IPv4v6 but as per a local policy does not = allow it >> so it falls back to IPv4 >>> a. IPv6 billing not supported >>> b. IPv6 not licensed >>> c. Local decision... >>> 4. SGSN/MME does not understand IPv4v6 and it does not fall back to = IPv4. >>=20 >> Same as 1. >>=20 >>=20 >> - Jouni >>=20 >>>=20 >>> Point 4 is for us the most critical aspect and the one we are = following closely. >>>=20 >>> Based on the above options, the SGSN/MME forwards to the GGSN/S-GW a >> session creation request with either a PDP Type of IPv4 or IPv4v6. >>>=20 >>> ---- HLR/HSS ---- >>> When the HLR receives an Update GPRS Location message, it has to = provide >> the subscriber profile to the requesting entity. All subscribers have = their APNs >> set for IPv4-only with extended PDP support (IPv4v6). >>>=20 >>> When receiving this message, the HLR compares the SGSN VLR address = with a >> whitelist database and decide if the SGSN is deemed IPv6 compliant. = At first, >> this database will be empty but as IPv6 support is confirmed through = either >> testing, confirmation from the operator or the IR.21, we will = populate this >> database. >>>=20 >>> Ultimately, the HLR sends out a profile that either contains IPv4 = only or IPv4 + >> IPv4v6 based on this whitelist database. >>>=20 >>> Unfortunately, this is not yet a standard feature in any HLR but our = HLR >> vendor has been cooperative to develop this market customization for = us. >>>=20 >>> ---- GGSN/S-GW/P-GW ---- >>> When the GGSN/P-GW receives a session creation request, it came in = as >> either IPv4 or IPv4v6 (see SGSN/MME for Session Management). The APNs = on >> the GGSN/P-GW that the customers are requesting are configured to = support >> IPv4v6 (and by extension IPv4-only and IPv6-only). On session = creation request, >> the GGSN/P-GW sends an Access-Request to a AAA server, sending the = vSGSN >> MCC+MNC, the IMEI and the PDP Type received. >>>=20 >>> The AAA Access-Accept contains a new APN name that the GGSN/P-GW = will >> use to effectively establish the session. The redirection APN is used = make a final >> selection on the IP type used (IPv4 or IPv6 or IPv4v6) >>>=20 >>> Requested APN: internet >>> Possible AAA output: v4.internet, ds.internet or v6.internet >>>=20 >>> ---- AAA Server ---- >>> The AAA receives the Access-Request from the GGSN/P-GW. It = implements a >> logic that will ultimately decide what type of PDP we should use for = this session. >>>=20 >>> The following checks are performed: >>> - Requested PDP Type: if IPv4 or IPv6, any change will break the = data session >> so allow as is (v4 would be for older devices or a fallback scenario = along the >> path; v6 would be because the user reconfigured his UE to directly = request IPv6 >> instead of the default IPv4v6) >>> - SGSN MCC-MNC: without a confirmation that this PLMN ID supports = IPv6, >> fallback to IPv4 >>> - IMEI: extract TAC and SV components and verify if device has = 464XLAT >> support. If it does, allow IPv6-only, otherwise allow dual-stack >>>=20 >>> Based on the above checks, the AAA will decide which APN to send the >> customer to and this is what will ultimately decide if we allow = IPv6-only >> roaming or not. >>>=20 >>>=20 >>> Dave Michaud >>>=20 >>>=20 >>>=20 >>>=20 >>> This e-mail (and attachment(s)) is confidential, proprietary, may be = subject to >> copyright and legal privilege and no related rights are waived. If = you are not >> the intended recipient or its agent, any review, dissemination, = distribution or >> copying of this e-mail or any of its content is strictly prohibited = and may be >> unlawful. All messages may be monitored as permitted by applicable = law and >> regulations and our policies to protect our business. E-mails are not = secure and >> you are deemed to have accepted any risk if you communicate with us = by e- >> mail. If received in error, please notify us immediately and delete = the e-mail >> (and any attachments) from any computer or any storage medium without >> printing a copy. >>>=20 >>> Ce courriel (ainsi que ses pi=E8ces jointes) est confidentiel, = exclusif, et peut >> faire l=92objet de droit d=92auteur et de privil=E8ge juridique; = aucun droit connexe >> n=92est exclu. Si vous n=92=EAtes pas le destinataire vis=E9 ou son = repr=E9sentant, toute >> =E9tude, diffusion, transmission ou copie de ce courriel en tout ou = en partie, est >> strictement interdite et peut =EAtre ill=E9gale. Tous les messages = peuvent =EAtre >> surveill=E9s, selon les lois et r=E8glements applicables et les = politiques de >> protection de notre entreprise. Les courriels ne sont pas s=E9curis=E9s= et vous =EAtes >> r=E9put=E9s avoir accept=E9 tous les risques qui y sont li=E9s si = vous choisissez de >> communiquer avec nous par ce moyen. Si vous avez re=E7u ce message = par >> erreur, veuillez nous en aviser imm=E9diatement et supprimer ce = courriel (ainsi >> que toutes ses pi=E8ces jointes) de tout ordinateur ou support de = donn=E9es sans en >> imprimer une copie. >=20 >=20 > This e-mail (and attachment(s)) is confidential, proprietary, may be = subject to copyright and legal privilege and no related rights are = waived. If you are not the intended recipient or its agent, any review, = dissemination, distribution or copying of this e-mail or any of its = content is strictly prohibited and may be unlawful. All messages may be = monitored as permitted by applicable law and regulations and our = policies to protect our business. E-mails are not secure and you are = deemed to have accepted any risk if you communicate with us by e-mail. = If received in error, please notify us immediately and delete the e-mail = (and any attachments) from any computer or any storage medium without = printing a copy. >=20 > Ce courriel (ainsi que ses pi=E8ces jointes) est confidentiel, = exclusif, et peut faire l=92objet de droit d=92auteur et de privil=E8ge = juridique; aucun droit connexe n=92est exclu. Si vous n=92=EAtes pas le = destinataire vis=E9 ou son repr=E9sentant, toute =E9tude, diffusion, = transmission ou copie de ce courriel en tout ou en partie, est = strictement interdite et peut =EAtre ill=E9gale. Tous les messages = peuvent =EAtre surveill=E9s, selon les lois et r=E8glements applicables = et les politiques de protection de notre entreprise. Les courriels ne = sont pas s=E9curis=E9s et vous =EAtes r=E9put=E9s avoir accept=E9 tous = les risques qui y sont li=E9s si vous choisissez de communiquer avec = nous par ce moyen. Si vous avez re=E7u ce message par erreur, veuillez = nous en aviser imm=E9diatement et supprimer ce courriel (ainsi que = toutes ses pi=E8ces jointes) de tout ordinateur ou support de donn=E9es = sans en imprimer une copie.=20 From prvs=9729d969c=Dave.Michaud@rci.rogers.com Tue Sep 24 06:23:11 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCF121E8083 for ; Tue, 24 Sep 2013 06:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs5TftV4j4CD for ; Tue, 24 Sep 2013 06:23:06 -0700 (PDT) Received: from mail.mail.rss.rogers.com (mail.mail.rss.rogers.com [142.146.31.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC821F9A98 for ; Tue, 24 Sep 2013 06:22:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoAANWQQVKOkg56l2dsb2JhbABaxGGBNA4BAQEBAQgWBzyCJQEBAQQSHiMLARoMBAIBCBEEAQEBCgYXAQYBICUJCAEBBBMIGodRAw+fDpQPDYlqjGaBLIEOBisHBoMXgQADjxKHAY4tiHMggSw X-IronPort-AV: E=Sophos;i="4.90,970,1371096000"; d="scan'208";a="266696626" Received: from rssesnexigwb.rss.rogers.com (HELO rsoesnexigwb.rci.rogers.ca) ([142.146.14.122]) by mail.mail.rss.rogers.com with ESMTP; 24 Sep 2013 09:22:33 -0400 Received: from RSOESNGTABHA.rci.rogers.ca ([10.3.37.22]) by rsoesnexigwb.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Sep 2013 09:22:26 -0400 Received: from CL08MBE.rci.rogers.ca ([10.3.45.56]) by RSOESNGTABHA.rci.rogers.ca with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Sep 2013 09:22:25 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Sep 2013 09:20:15 -0400 Message-ID: <29AE8DB910E7704CA043795E00DCBE780A364000@CL08MBE.rci.rogers.ca> In-Reply-To: <994FED44-27D4-45F4-87E1-FC1E319EA79D@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis Thread-Index: Ac645yTbkRca2oJXShSxS9iIe2cMkAAQW1tg References: <29AE8DB910E7704CA043795E00DCBE780A363F32@CL08MBE.rci.rogers.ca> <5A5E3B5B-480B-4C3E-9032-E76EA6129408@gmail.com> <29AE8DB910E7704CA043795E00DCBE780A363FED@CL08MBE.rci.rogers.ca> <994FED44-27D4-45F4-87E1-FC1E319EA79D@gmail.com> From: "Dave Michaud" To: "Jouni Korhonen" X-OriginalArrivalTime: 24 Sep 2013 13:22:25.0899 (UTC) FILETIME=[1C3EABB0:01CEB929] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Wed, 25 Sep 2013 08:31:10 -0700 Cc: IPv6 Ops WG , draft-chen-v6ops-ipv6-roaming-analysis@tools.ietf.org, Cameron Byrne , Victor Kuarsingh Subject: Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 13:23:12 -0000 Cgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogSm91bmkgS29yaG9uZW4gW21h aWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tXQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAy NCwgMjAxMyAxOjMwIEFNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtY2hlbi12Nm9wcy1p cHY2LXJvYW1pbmctYW5hbHlzaXMKPiAKPiAKPiBPbiBTZXAgMjMsIDIwMTMsIGF0IDExOjU1IFBN LCBEYXZlIE1pY2hhdWQgPERhdmUuTWljaGF1ZEByY2kucm9nZXJzLmNvbT4KPiB3cm90ZToKPiAK PiA+IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb25zIG9uIGRpZmZlcmVuY2VzIGJldHdlZW4g U0dTTiBhbmQgTU1FLiBXZSBzdGlsbAo+IGhhdmUgbGltaXRlZCBMVEUgcm9hbWluZyBzbyB3ZSBh cmUgbm90IHJ1bm5pbmcgaW50byB0aGVzZSBpc3N1ZXMgeWV0Li4uCj4gPgo+ID4gUmVnYXJkaW5n IHlvdXIgcXVlc3Rpb24gYWJvdXQgb3VyIEdQUlNTdWJzY3JpcHRpb25EYXRhIGluIHRoZSBITFIs IEkgY2FuJ3QKPiB0ZWxsIGZvciBzdXJlIGFib3V0IHRoaXMgb25lLiBHaXZlbiBDYW1lcm9uJ3Mg ZXhwZXJpZW5jZSwgd2Ugc3RvcHBlZCB0aGUKPiBkZXBsb3ltZW50IGFuZCByZXF1ZXN0ZWQgYSBw YXRjaCBmcm9tIG91ciBITFIgdmVuZG9yIGJlZm9yZSBpdCB3ZW50IGxpdmUuCj4gCj4gSSBhbSBq dXN0IGludGVyZXN0ZWQgb24gdGhlIEdQUlNTdWJzY3JpcHRpb25EYXRhIGJlY2F1c2UgaWYgdGhl IFNHU04gd291bGQKPiBub3QgZHJvcCB3aG9sZSBHUFJTU3Vic2NyaXB0aW9uRGF0YSBiYXNlZCBv biBvbmUgUERQLUNvbnRleHQgaXQgZG9lcyBub3QKPiB1bmRlcnN0YW5kLCB0aGVuIGl0IGNvdWxk IGJlIHBvc3NpYmxlIHRvIGluY2x1ZGUgYW5vdGhlciBQRFAtVHlwZSBJUHY0IFBEUC0KPiBDb250 ZXh0IGZvciB0aGUgc2FtZSBBUE4gaW4gdGhlIEdQUlNTdWJzY3JpcHRpb25EYXRhLi4gYW5kIHRo ZSBTR1NOIGNvdWxkCj4gc3VwcG9zZWRseSB1c2UgdGhhdC4gSSBhbSBzdXJlIEkgdHJpZWQgdGhp cyBpcyBvbmUgc2V0dXAgYnV0IGNhbm5vdCByZW1lbWJlciB0aGUKPiBvdXRjb21lIGFueW1vcmUg OiggIChhbnl3YXksIHN1Y2ggc2V0dXAgaW52b2x2ZXMgcXVpdGUgbWFueSBhc3N1bXB0aW9ucyBp bgo+IGFuIFNHU04gYW5kIGEgR0dTTiByZWdhcmRpbmcgZS5nLiB0aGUgZmFsbGJhY2sgIGJlaGF2 aW91ci4uKQo+IAo+IC0gSk91bmkKCkluIGFueSBjYXNlLCB0aGUgYmVoYXZpb3IgY291bGQgYmUg ZGlmZmVyZW50IGRlcGVuZGluZyBvbiB0aGUgZXF1aXBtZW50IG1hbnVmYWN0dXJlciBhbmQgcmVs ZWFzZS4gSXQgaXMgbGlrZWx5IG5vdCBzb21ldGhpbmcgd2UgY2FuIGNvdW50IG9uIGZvciBhIHBy b2R1Y3Rpb24gZGVwbG95bWVudCwgbm90IGF0IHRoaXMgcG9pbnQgYXQgbGVhc3QuCgpEYXZlIE1p Y2hhdWQKClRoaXMgZS1tYWlsIChhbmQgYXR0YWNobWVudChzKSkgaXMgY29uZmlkZW50aWFsLCBw cm9wcmlldGFyeSwgbWF5IGJlIHN1YmplY3QgdG8gY29weXJpZ2h0IGFuZCBsZWdhbCBwcml2aWxl Z2UgYW5kIG5vIHJlbGF0ZWQgcmlnaHRzIGFyZSB3YWl2ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb3IgaXRzIGFnZW50LCBhbnkgcmV2aWV3LCBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCBvciBhbnkgb2YgaXRzIGNv bnRlbnQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBBbGwgbWVz c2FnZXMgbWF5IGJlIG1vbml0b3JlZCBhcyBwZXJtaXR0ZWQgYnkgYXBwbGljYWJsZSBsYXcgYW5k IHJlZ3VsYXRpb25zIGFuZCBvdXIgcG9saWNpZXMgdG8gcHJvdGVjdCBvdXIgYnVzaW5lc3MuIEUt bWFpbHMgYXJlIG5vdCBzZWN1cmUgYW5kIHlvdSBhcmUgZGVlbWVkIHRvIGhhdmUgYWNjZXB0ZWQg YW55IHJpc2sgaWYgeW91IGNvbW11bmljYXRlIHdpdGggdXMgYnkgZS1tYWlsLiBJZiByZWNlaXZl ZCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBl LW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGZyb20gYW55IGNvbXB1dGVyIG9yIGFueSBzdG9y YWdlIG1lZGl1bSB3aXRob3V0IHByaW50aW5nIGEgY29weS4KCkNlIGNvdXJyaWVsIChhaW5zaSBx dWUgc2VzIHBpw6hjZXMgam9pbnRlcykgZXN0IGNvbmZpZGVudGllbCwgZXhjbHVzaWYsIGV0IHBl dXQgZmFpcmUgbOKAmW9iamV0IGRlIGRyb2l0IGTigJlhdXRldXIgZXQgZGUgcHJpdmlsw6hnZSBq dXJpZGlxdWU7IGF1Y3VuIGRyb2l0IGNvbm5leGUgbuKAmWVzdCBleGNsdS4gU2kgdm91cyBu4oCZ w6p0ZXMgcGFzIGxlIGRlc3RpbmF0YWlyZSB2aXPDqSBvdSBzb24gcmVwcsOpc2VudGFudCwgdG91 dGUgw6l0dWRlLCBkaWZmdXNpb24sIHRyYW5zbWlzc2lvbiBvdSBjb3BpZSBkZSBjZSBjb3Vycmll bCBlbiB0b3V0IG91IGVuIHBhcnRpZSwgZXN0IHN0cmljdGVtZW50IGludGVyZGl0ZSBldCBwZXV0 IMOqdHJlIGlsbMOpZ2FsZS4gVG91cyBsZXMgbWVzc2FnZXMgcGV1dmVudCDDqnRyZSBzdXJ2ZWls bMOpcywgc2Vsb24gbGVzIGxvaXMgZXQgcsOoZ2xlbWVudHMgYXBwbGljYWJsZXMgZXQgbGVzIHBv bGl0aXF1ZXMgZGUgcHJvdGVjdGlvbiBkZSBub3RyZSBlbnRyZXByaXNlLiBMZXMgY291cnJpZWxz IG5lIHNvbnQgcGFzIHPDqWN1cmlzw6lzIGV0IHZvdXMgw6p0ZXMgcsOpcHV0w6lzIGF2b2lyIGFj Y2VwdMOpIHRvdXMgbGVzIHJpc3F1ZXMgcXVpIHkgc29udCBsacOpcyBzaSB2b3VzIGNob2lzaXNz ZXogZGUgY29tbXVuaXF1ZXIgYXZlYyBub3VzIHBhciBjZSBtb3llbi4gU2kgdm91cyBhdmV6IHJl w6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbm91cyBlbiBhdmlzZXIgaW1tw6lk aWF0ZW1lbnQgZXQgc3VwcHJpbWVyIGNlIGNvdXJyaWVsIChhaW5zaSBxdWUgdG91dGVzIHNlcyBw acOoY2VzIGpvaW50ZXMpIGRlIHRvdXQgb3JkaW5hdGV1ciBvdSBzdXBwb3J0IGRlIGRvbm7DqWVz IHNhbnMgZW4gaW1wcmltZXIgdW5lIGNvcGllLiAK From holger.metschulat@telekom.de Thu Sep 26 01:02:41 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325E421F8D0B for ; Thu, 26 Sep 2013 01:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUlXjf-W-rmA for ; Thu, 26 Sep 2013 01:02:37 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id B429021F9951 for ; Thu, 26 Sep 2013 01:02:31 -0700 (PDT) From: Received: from he113495.emea1.cds.t-internal.com ([10.206.92.152]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 26 Sep 2013 10:01:06 +0200 Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE113495.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 26 Sep 2013 10:01:06 +0200 To: Date: Thu, 26 Sep 2013 10:01:05 +0200 Thread-Topic: [v6ops] draft-ietf-v6ops-64share WGLC Thread-Index: Ac64CG//QiV+Qe/6QoWz4LTV+SLSRgChaSoA Message-ID: References: <5236a1bc.82a8700a.3a3f.ffffc0d8@mx.google.com> <1379541548.63737.YahooMailNeo@web142504.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 08:02:41 -0000 Hi all, fine with me as well. However, Req#10 is not the correct place since that's= only about the DHCPv6 client mode of the mobile. Around Req#27 would be a = better place, however, the link to RFC6204 and Req L-10 there more or less = indicates what must be done without explicitly stating the detailed procedu= re. Holger -----Urspr=FCngliche Nachricht----- Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Mikael Abrahamsson Gesendet: Montag, 23. September 2013 04:55 An: Jouni Korhonen Cc: v6ops@ietf.org Betreff: Re: [v6ops] draft-ietf-v6ops-64share WGLC On Sun, 22 Sep 2013, Jouni Korhonen wrote: > > On Sep 22, 2013, at 9:36 PM, Mikael Abrahamsson wrote: > >> On Thu, 19 Sep 2013, Teemu Savolainen wrote: >> >>> Secondly, I don't agree DHCP server support is required, as the CE can = include the DNS addresses in RAs as specified in RFC6106. >> >> There are very few products out there that supports this way of conveyin= g DNS resolver information. >> >> I am not opposed to say that providing basic 64share might skip supplyin= g DNS resolver over IPv6, but then I agree with a few mail back where it wa= s said we should have another document recommending how to get DNS resolver= working for IPv6 only clients. > > Why wouldn't we add this (rather obvious) requirement to draft-ietf-v6ops= -mobile-device-profile? That would basically be just a clarification to Req= #10. Absolutely fine, draft-ietf-v6ops-mobile-device-profile could be this "othe= r document". --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From sajjad_akr@yahoo.com Fri Sep 27 02:09:20 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92EF21F9D7E for ; Fri, 27 Sep 2013 02:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu+L48ZX39JR for ; Fri, 27 Sep 2013 02:09:06 -0700 (PDT) Received: from nm46-vm6.bullet.mail.gq1.yahoo.com (nm46-vm6.bullet.mail.gq1.yahoo.com [67.195.87.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4207321F937E for ; Fri, 27 Sep 2013 02:08:59 -0700 (PDT) Received: from [98.137.12.189] by nm46.bullet.mail.gq1.yahoo.com with NNFMP; 27 Sep 2013 09:08:58 -0000 Received: from [98.137.12.254] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 27 Sep 2013 09:08:58 -0000 Received: from [127.0.0.1] by omp1062.mail.gq1.yahoo.com with NNFMP; 27 Sep 2013 09:08:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 742149.99641.bm@omp1062.mail.gq1.yahoo.com Received: (qmail 39496 invoked by uid 60001); 27 Sep 2013 09:08:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380272938; bh=PXuCPIkh7WzO3KHPSycD2SjkFKbHeMqL8cg7nR+lMOo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=Lzw0/KLFTkgWbTRkINyCdE+QSGww31LqqT80L+ksMahwo3xTYgpPgiD2LsDK2GJ34/lTcf2tcHoeCXdFSuV4jQCse4Uu5s4EPnwtgcv5v26sMhLuwGczdrfisAi+ligOKHGzrlbyr1Cy23MnR2H/qyG5Yy4iBv4EZBrI+ifZVNA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=mdZKeO/oesWOeFQAqaq0tTD8F7uPP1OZeusE4Xw8ERvS1XA6dasON/8nEZbMBpnpRgy8jIWEFZh+nJav+MJVcQS40VmOxLdNVIsWTwHoXYHcwMQ8PtGgmtYznyQPc2vkacMGBtBAvLUeSE/SpLRCPIV6NFoylvp/lSUN66u/0Y0=; X-YMail-OSG: 6l21Ow4VM1kI4Rxn3N2WsbUlIjzNqooncNJXWEsROFjuOkQ 0SGI7aPUiNcY70Pf6yaiWCpXIRfHr3voKjZg1pJB8Mx7hVVnw.I6vZ4juq9v HZlkMpSpNIJNQUcLiSijUzKATLIxozzkauEkbQINN8LpC7tQ3I.lMhp.4cvs h5JY9HwqTC3vaMGYOBzGxU9zODVjrkbidR2GfHQLEv.kQlkfT4FiR7uq5Ize hyABXp_MXu3eEgeXoK6BFpG0qf8inNXHMVOXrMCkEst015ylSq8YPCYYIxaF tbwvzobSDFSfmGG9yDKzZ58Zujrq8mS9Z3gA4sLi_C.UpPt.hlP_8ABQOB8Y FOQZUdcH0.faF4n17HQhzHx7JOyTzWO01CBjQK_WGCk8RA61Tf2EoZRnTV0b BTh551No9kw6Ox3ye61m5sa1cQvkAd.6jjkMTJfjMVZMDyIPVs3R5aU5frNL xnTb14ijuzv_Z5mw3ZtQuyQvRGJ8v8Cbfgm1h6pt8LeX1ZYQicmyZoCXTvpc JQavFp7RfClEHyTP5h_hFlIxNdcHLfMhXViUsGk.wniGR7.fSB224XHzOXAi TKel3OekED53gE7Nu452NZFw- Received: from [39.47.142.80] by web121502.mail.ne1.yahoo.com via HTTP; Fri, 27 Sep 2013 02:08:58 PDT X-Rocket-MIMEInfo: 002.001, aGkuLi4KClRoZXJlIGlzIGEgZm9sbG93aW5nIMKgaXNzdWUgcmVnYXJkaW5nIGR1YWwgc3RhY2sgaW4gY29udGV4dCBvZiBETlMgZm9yIElQdjYuCgpJZiBhIGR1YWwgc3RhY2sgZW5hYmxlIG5vZGUgdHJ5IHRvIGNvbm5lY3QgYSBzZXJ2ZXIgd2hpY2ggaXMgYWxzbyBkdWFsIHN0YWNrIGJ1dCBoYXZpbmcgaXNzdWUgaW4gaGlzIElQdjYgc3RhY2sgdGVtcG9yYXJ5LiBJbiB0aGlzIGNhc2UsIEROUyByZXR1cm5lZCB0aGUgQUFBQSBhZGRyZXNzIHRvIHRoZSByZXF1ZXN0aW5nIG5vZGUuIFdoYXQgYXJlIHRoZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 Message-ID: <1380272938.39375.YahooMailNeo@web121502.mail.ne1.yahoo.com> Date: Fri, 27 Sep 2013 02:08:58 -0700 (PDT) From: sajjad akbar To: "v6ops-bounces@ietf.org" Cc: "v6ops@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1319493512-1209163493-1380272938=:39375" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 09:09:21 -0000 --1319493512-1209163493-1380272938=:39375 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable hi...=0A=0AThere is a following =A0issue regarding dual stack in context of= DNS for IPv6.=0A=0AIf a dual stack enable node try to connect a server whi= ch is also dual stack but having issue in his IPv6 stack temporary. In this= case, DNS returned the AAAA address to the requesting node. What are the p= ossibilities to identify this issues or how we can solve it?=0A=0ARegards= =0ASajjad --1319493512-1209163493-1380272938=:39375 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
hi...

There is a following  issue regarding dual sta= ck in context of DNS for IPv6.

If a dual stack enable node try to connect a server w= hich is also dual stack but having issue in his IPv6 stack temporary. In th= is case, DNS returned the AAAA address to the requesting node. What are the= possibilities to identify this issues or how we can solve it?

Regards
To: sajjad akbar Content-Type: multipart/alternative; boundary=047d7b450a427a611504e75db00b Cc: v6ops@ietf.org, v6ops-bounces@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:44:47 -0000 --047d7b450a427a611504e75db00b Content-Type: text/plain; charset=ISO-8859-1 Inline On Sep 27, 2013 2:09 AM, "sajjad akbar" wrote: > > hi... > > There is a following issue regarding dual stack in context of DNS for IPv6. > > If a dual stack enable node try to connect a server which is also dual stack but having issue in his IPv6 stack temporary. In this case, DNS returned the AAAA address to the requesting node. What are the possibilities to identify this issues or how we can solve it? > Please see http://tools.ietf.org/html/rfc6555 > Regards > Sajjad > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b450a427a611504e75db00b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Inline

On Sep 27, 2013 2:09 AM, "sajjad akbar" <sajjad_akr@yahoo.com> wrote:
>
> hi...
>
> There is a following =A0issue regarding dual stack in context of DNS f= or IPv6.
>
> If a dual stack enable node try to connect a server which is also dual= stack but having issue in his IPv6 stack temporary. In this case, DNS retu= rned the AAAA address to the requesting node. What are the possibilities to= identify this issues or how we can solve it?
>

Please see ht= tp://tools.ietf.org/html/rfc6555
> Regards
> Sajjad
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--047d7b450a427a611504e75db00b-- From sajjad_akr@yahoo.com Fri Sep 27 07:32:13 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3632621E80F8 for ; Fri, 27 Sep 2013 07:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.065 X-Spam-Level: X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdvKoHFvi4kd for ; Fri, 27 Sep 2013 07:32:08 -0700 (PDT) Received: from nm3.bullet.mail.gq1.yahoo.com (nm3.bullet.mail.gq1.yahoo.com [98.136.218.68]) by ietfa.amsl.com (Postfix) with ESMTP id C2AEB11E814E for ; Fri, 27 Sep 2013 07:32:03 -0700 (PDT) Received: from [216.39.60.181] by nm3.bullet.mail.gq1.yahoo.com with NNFMP; 27 Sep 2013 14:32:03 -0000 Received: from [98.137.12.206] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 27 Sep 2013 14:32:03 -0000 Received: from [127.0.0.1] by omp1014.mail.gq1.yahoo.com with NNFMP; 27 Sep 2013 14:32:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 305737.87725.bm@omp1014.mail.gq1.yahoo.com Received: (qmail 7336 invoked by uid 60001); 27 Sep 2013 14:32:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380292322; bh=/UYdSqqcUpvlt95JyvHyGZ19eIj7Go2AuMQFO8o+oA0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=srJHQKkxuTt9GOtI6PwsAQl+EPiLJWtiYT2/fMjZb83j1H3yppJ3edV4jigduZJA7iMscjaq0pAsLmfO7DD+CGuUq3XBrpSlRHBaBVEaIId7cPy0Vf1YvR+v2grdgwTvA25BSvNOwFJqeI1/I6qYQ18K1g/NuRGeVzyo63dEj1c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vac/2yqkEivxsRsY4VncFrIn3yQM9eCyZ6pQEWU6EqEd7WQ78hX3gUHGPblD7G8GnxxIVUvYwb1M3BaF83pDJ6KDOE7lSRBavkZJw8/i1CpUQ7P2CKPHk7TUpPGptmomy+H4j6DuKSO/z7z0rrhQPEH/toAtyKbqQhSrIL5ImF4=; X-YMail-OSG: R4Wh9IAVM1mrUgWBusuGhSibuz2urSDy2XDuCZAkRaYcMZ0 96zjyi1OPzbcYLrPbiYOzbk4R7fQCpmkCLNri0mZvMRVXUekVm1PaegTWchd wwwseYGtkk22irkfNHEovKS6kSRLzK91HD2K_rnwCOjjPhOHmn5mFKKY2glS AK2B1tWpAeL8KAigGG1Ft3KHY6lpAKbBQyMgx1o8p56.I0DhADfnrUy.CCLN PfGNaTWKSp1ZhCC0s2D7Iuro2COlSMuRKCJ7qa4NYqja1ulkZoc2.6JKSelQ lvSvk8xfZFuwtqXbTyJLq1Ev5jvnlqLiffSZVc4M6LniUgt0vtKMRV2AyubS 372u_s9UuGlRYp7XUjXUwPNL_m8Ih2rLqShyDFZRv_aOBA5TVZtbgqnvWf8R vxTrkmad5AEkNkqDL7No2e_EkxoFNFnoaCXGPVyLcn69s1FMY05oDPtwxidm xUAgNCk18ViiU4lDxzWiiPI2rkW7tDYueqIxfiUYkjJLbbJ1xWSbW286lyPd uIZ31I0lDieXxacPcw_VJppOMWoRmajfGp6Y.crTb7Qxc1Df7vflZVzKKIDo btHqIHw0j46BBaX5tQmPcADCKyVbc4NGuNt8eVi_4HvAEbyEyE.6.Hcb8iiy pN02cnOBSXda8qslRiYI815ba3fvWpodCS_9JRezCwM3zZrmoFS_5dvuCRte j Received: from [39.47.65.61] by web121504.mail.ne1.yahoo.com via HTTP; Fri, 27 Sep 2013 07:32:02 PDT X-Rocket-MIMEInfo: 002.001, RGVhciBmZWxsb3dzCgpUaGFua3MgZm9yIHJlZmVycmluZyBSRkMgNjU1NS4gwqAgQWN0dWFsbHkgd2UgYXJlIGRvaW5nIGEgcHJvamVjdCB0aXR0bGVkIMKgCgpEZXNpZ24gYW5kIERldmVsb3BtZW50IG9mIEh5YnJpZCBJUHY0IGFuZCBJUHY2IE5ldHdvcmsgZm9yIFFvUyBFbmFibGVkIFZpZGVvIFN0cmVhbWluZyBNdWx0aWNhc3QgQXBwbGljYXRpb24KCiAgCsKgaW4gUGFraXN0YW4gKGh0dHA6Ly93d3cuY29yZW5ldC5vcmcucGsvcHJvamVjdHMucGhwKS4gSXQgaXMgZnVuZGVkIGJ5IGEgVGVsZWNvbSBzZWMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1380272938.39375.YahooMailNeo@web121502.mail.ne1.yahoo.com> Message-ID: <1380292322.5784.YahooMailNeo@web121504.mail.ne1.yahoo.com> Date: Fri, 27 Sep 2013 07:32:02 -0700 (PDT) From: sajjad akbar To: "v6ops@ietf.org" Cc: "v6ops-bounces@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1050781934-1077143588-1380292322=:5784" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 14:32:13 -0000 --1050781934-1077143588-1380292322=:5784 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear fellows=0A=0AThanks for referring RFC 6555. =A0 Actually we are doing = a project tittled =A0=0A=0ADesign and Development of Hybrid IPv4 and IPv6 N= etwork for QoS Enabled Video Streaming Multicast Application=0A=0A =0A=A0i= n Pakistan (http://www.corenet.org.pk/projects.php). It is funded by a Tele= com sector. The purpose is to build confidence of ISP's on IPv6. There is v= ery limited implementation of V6 in Pakistan. =A0=0A=0AWe are implementing = multicast pim-sm for v6 on this hybrid v4 and v6 network. To handle transit= ion we have decided to use dual stack and tunneling mechanisms.=0AMulticast= for hybrid v4 and v6 network is only working with dual stack. No tunneling= technique (6to4, 6RD) is supporting multicast.=A0=0A=0ACan you people sugg= est a way to test multicast for these tunneling mechanisms?=A0=0A=0ARegards= =0ASajjad=0AIPv4 project team lead=0A=A0=0A=0A=0A=0A=0A____________________= ____________=0A From: cb.list6 =0ATo: sajjad akbar =0ACc: v6ops@ietf.org; v6ops-bounces@ietf.org =0ASent: F= riday, September 27, 2013 6:44 PM=0ASubject: Re: [v6ops] draft-ietf-v6ops-6= 4share WGLC... query=0A =0A=0A=0AInline=0AOn Sep 27, 2013 2:09 AM, "sajjad = akbar" wrote:=0A>=0A> hi...=0A>=0A> There is a follo= wing =A0issue regarding dual stack in context of DNS for IPv6.=0A>=0A> If a= dual stack enable node try to connect a server which is also dual stack bu= t having issue in his IPv6 stack temporary. In this case, DNS returned the = AAAA address to the requesting node. What are the possibilities to identify= this issues or how we can solve it?=0A>=0APlease see http://tools.ietf.org= /html/rfc6555=0A> Regards=0A> Sajjad=0A>=0A> ______________________________= _________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://www= .ietf.org/mailman/listinfo/v6ops=0A> --1050781934-1077143588-1380292322=:5784 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear fellows

Thanks for refer= ring RFC 6555.   Actually we are doing a project tittled  =


We are imple= menting multicast pim-sm for v6 on this hybrid v4 and v6 network. To handle= transition we have decided to use dual stack and tunneling mechanisms.
Multicast for hybrid v4 and v6 network is only workin= g with dual stack. No tunneling technique (6to4, 6RD) is supporting multica= st. 

Can you people sugges= t a way to test multicast for these tunneling mechanisms? 

Regards
Sajjad
IPv4 project team lead
 



From: cb.list6 <cb.list6@gmail.com>
To: sajjad akbar <sajjad_akr@yahoo.com>
<= span style=3D"font-weight: bold;">Cc: v6ops@ietf.org; v6ops-bounces@= ietf.org
Sent: Friday= , September 27, 2013 6:44 PM
Subj= ect: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query

Inline
=0A
On Sep 27, 2013 2:09 AM, "saj= jad akbar" <sajjad_akr@yahoo.com= > wrote:
=0A>
=0A> hi...
=0A>
=0A> There is = a following  issue regarding dual stack in context of DNS for IPv6.=0A>
=0A> If a dual stack enable node try to connect a server whi= ch is also dual stack but having issue in his IPv6 stack temporary. In this= case, DNS returned the AAAA address to the requesting node. What are the p= ossibilities to identify this issues or how we can solve it?
=0A=0A><= /div>=0A
Please see http://tools.ietf.org/html/rfc65= 55
=0A> Regards
=0A> Sajjad
=0A>
=0A> _________= ______________________________________
=0A> v6ops mailing list
=0A= > v6ops@ietf.org
=0A> https://www.ietf.org/mailman/listinfo/v6ops
=0A>
=0A
=


--1050781934-1077143588-1380292322=:5784-- From tom.taylor.stds@gmail.com Fri Sep 27 10:18:32 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F8821E80FA for ; Fri, 27 Sep 2013 10:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc5SO6aSAjWx for ; Fri, 27 Sep 2013 10:18:32 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 051B321F9FED for ; Fri, 27 Sep 2013 10:18:29 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so1894976qcr.20 for ; Fri, 27 Sep 2013 10:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PHpZMq9lz9PTztyT0CNAQgyaeRI0R4oYSib0fT5QWLc=; b=Uo+yUzQj6OrtU0F2sYtsTX3HeEw09FrrYT40laZIvjIZ4ETkqugGweuyy9tD/Vj4Ca VUXqCIpg4Sxx7Gq8c39huE2qprRJ3z2VhIbam4nd/Bc8YPW8R2f/tqVMOCyGBoesrwER NIVe8V+PisV1TW2AfdOni1+i/cFskX69LjsiBKw8wnw8PalTviWZdM/WZckpXr2aKah1 1BeJRvOI7cDelWZnJ9rymCKRGR/61t1vSKEE3cOzWj7yp879awGfXvd/ek6CCz1Sgf2e uFzc07yn4EYTIBgMZbLwPq/ACpzTOH/q+hIhIJKLVVzaBMAartQObJ3CU3U/JceLyuHO 9hGQ== X-Received: by 10.49.127.116 with SMTP id nf20mr10374901qeb.90.1380302309375; Fri, 27 Sep 2013 10:18:29 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id 5sm20851769qao.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 10:18:28 -0700 (PDT) Message-ID: <5245BDE1.4080307@gmail.com> Date: Fri, 27 Sep 2013 13:18:25 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sajjad akbar References: <1380272938.39375.YahooMailNeo@web121502.mail.ne1.yahoo.com> <1380292322.5784.YahooMailNeo@web121504.mail.ne1.yahoo.com> In-Reply-To: <1380292322.5784.YahooMailNeo@web121504.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 17:18:33 -0000 You might look at http://datatracker.ietf.org/doc/draft-sarikaya-softwire-6rdmulticast/, taking note that it has not drawn any interest in the Softwires Working Group. On 27/09/2013 10:32 AM, sajjad akbar wrote: > Dear fellows > > Thanks for referring RFC 6555. Actually we are doing a project tittled > > Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Application > > > in Pakistan (http://www.corenet.org.pk/projects.php). It is funded by a Telecom sector. The purpose is to build confidence of ISP's on IPv6. There is very limited implementation of V6 in Pakistan. > > We are implementing multicast pim-sm for v6 on this hybrid v4 and v6 network. To handle transition we have decided to use dual stack and tunneling mechanisms. > Multicast for hybrid v4 and v6 network is only working with dual stack. No tunneling technique (6to4, 6RD) is supporting multicast. > > Can you people suggest a way to test multicast for these tunneling mechanisms? > > Regards > Sajjad > IPv4 project team lead > > > > > > ________________________________ > From: cb.list6 > To: sajjad akbar > Cc: v6ops@ietf.org; v6ops-bounces@ietf.org > Sent: Friday, September 27, 2013 6:44 PM > Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query > > > > Inline > On Sep 27, 2013 2:09 AM, "sajjad akbar" wrote: >> >> hi... >> >> There is a following issue regarding dual stack in context of DNS for IPv6. >> >> If a dual stack enable node try to connect a server which is also dual stack but having issue in his IPv6 stack temporary. In this case, DNS returned the AAAA address to the requesting node. What are the possibilities to identify this issues or how we can solve it? >> > Please see http://tools.ietf.org/html/rfc6555 >> Regards >> Sajjad >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From sajjad_akr@yahoo.com Sat Sep 28 01:51:01 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220D321E80BF for ; Sat, 28 Sep 2013 01:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.314 X-Spam-Level: X-Spam-Status: No, score=0.314 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+y1pL2Kv7hu for ; Sat, 28 Sep 2013 01:50:56 -0700 (PDT) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with ESMTP id C9D2821F9B86 for ; Sat, 28 Sep 2013 01:50:55 -0700 (PDT) Received: from [98.139.212.148] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 08:50:54 -0000 Received: from [98.139.212.244] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 08:50:54 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 08:50:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 382049.84217.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 3476 invoked by uid 60001); 28 Sep 2013 08:50:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380358253; bh=R0KGNib7sbQZ0xEQTnzyxSIztby3vRjG0D8s9esBIuo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lN0y6otgeJVS75lFisH8x7tU0DfszfKw0M02W4qkOp2JXr5/eg1Ac4B0ReVsLfx/WyEEfpW/lBXvFYVg7OEx99ZbiHCyKeKaf/DxsbpW7q+TzYzTV3Nxq1/HuIe+xFoa/TACiSzTnAEzX3quYoAgNwtb0LQ1Pih8DtZzMarfZWw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G2s9zZH/GjdRHvNd7N85ezXrWKtDnOaaVtQPy4SAU1elq0ehdHhbnBhTL2eTNM9PEDGcbW8IXtR3VZmWCRNeqCEYhr1Ri76AftsQOk50oVRYxoYSnbGQKtikwc57f++Nvpg/6ogGnXgDmkEwLubszmyC2GVlpXiuRBIVn8UaIl0=; X-YMail-OSG: p7aoE0YVM1lBluhtWKYKHBBHxHpsOms4lUTdoP0eTWsefsV odibmPBcJw1TQwi94aQSaEeowhJuBQZ7WX8CqAipkF5DfjfJPoBlVOGntp0t 55NLe8wsQXyUSzV6Gb9MS6abEnz8j_Ap112MeJQHB7WuA.WrU7lhWImGXxQq MTD642yUVjw2eEYaKKQMssb0nvhmRTH9xWv2f7yoO5yDt8Bg785KMVrgXTL0 SRmKK0MxNqrSOl_JjZCe72CW.tk4YdOGZedOB7iGcD_4DNYfGB54wpZeX15o 5jMFM.K3OGTZZLboPErfFmwbpsa60R4Vxg1JQXoxvluVO5Rz8K3WepJCXSWY 22XpeBGEZiTfbvIVHXG_SEswbEOlkyXtnImEf0nkCwYRaghlhXonit7_s.to h2febjFPP1Pl7bU9.Yme56WoHZZuckss7qgHSi3iZg8sL6ZmzdrxsNHmouJq KVIc9zXUZmZxCun4TeQax8qMA.U62YbyvI_.JCXEbqkg3sRgLo6aB5Z2sCQw 06I9MYyZZNi40R5f1_vRbuxdLNDLeOo5GuaKqiFzpHbLyOgEPbkInXR56_U_ 85fiEP3RdCimVXpUqvdJlfnrMds8qLQBTE1eWkLuAFraE0FwDuJTAXaiCtUV 18plSvOHk7mIj5IX1DTZW3WlH_8ftldudRGd0V7n40z9l6.JtE1f4Xwfa_TU JYwk- Received: from [39.47.177.112] by web121503.mail.ne1.yahoo.com via HTTP; Sat, 28 Sep 2013 01:50:53 PDT X-Rocket-MIMEInfo: 002.001, CgoKVGhhbmtzIGZvciB0aGUgc3VnZ2VzdGVkIGxpbmsuIHdlIGhhdmUgc3R1ZGllZCB0aGlzIGRyYWZ0IGVhcmxpZXIuIEl0LHMgbm90IHZlcnkgc2ltcGxlIHRvIGRlcGxveSB0aGlzIG1lY2hhbmlzbSBvbiBldmVyeSByb3V0ZXIuIFR1bm5lbGluZyBpcyBhbHJlYWR5IGNvc3RseSBhbmQgYnkgYXBwbHlpbmcgc3VjaCBtZWNoYW5pc21zIHdlIHdpbGwgbWFrZSBpdCBtb3JlIGNvbXBsZXguIFNvLCBjYW4gd2UgY29uY2x1ZGUgdGhhdCBJUHY2IHR1bm5lbGluZyBtZWNoYW5pc21zIGFyZSBub3Qgc3VwcG9ydGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1380272938.39375.YahooMailNeo@web121502.mail.ne1.yahoo.com> <1380292322.5784.YahooMailNeo@web121504.mail.ne1.yahoo.com> <5245BDE1.4080307@gmail.com> Message-ID: <1380358253.2685.YahooMailNeo@web121503.mail.ne1.yahoo.com> Date: Sat, 28 Sep 2013 01:50:53 -0700 (PDT) From: sajjad akbar To: Tom Taylor In-Reply-To: <5245BDE1.4080307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="828875537-1808610021-1380358253=:2685" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 08:51:01 -0000 --828875537-1808610021-1380358253=:2685 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0AThanks for the suggested link. we have studied this draft earlier.= It,s not very simple to deploy this mechanism on every router. Tunneling i= s already costly and by applying such mechanisms we will make it more compl= ex. So, can we conclude that IPv6 tunneling mechanisms are not supporting m= ulticast? I think its alarming for the transition phase as in coming days t= echnologies like IPTV etc will be very common.=0AMay be we can also state t= hat only dual stack is a complete solution for transition phase. As per my = knowledge translation techniques are also not supporting multicast.=0A=0A= =0ARegards=0ASajjad=0A=0A=0A________________________________=0A From: Tom T= aylor =0ATo: sajjad akbar = =0ACc: "v6ops@ietf.org" =0ASent: Friday, September 27, 20= 13 10:18 PM=0ASubject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query= =0A =0A=0AYou might look at=0Ahttp://datatracker.ietf.org/doc/draft-sarikay= a-softwire-6rdmulticast/, =0Ataking note that it has not drawn any interest= in the Softwires Working =0AGroup.=0A=0AOn 27/09/2013 10:32 AM, sajjad akb= ar wrote:=0A> Dear fellows=0A>=0A> Thanks for referring RFC 6555.=A0 Actua= lly we are doing a project tittled=0A>=0A> Design and Development of Hybrid= IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Applicatio= n=0A>=0A>=0A>=A0 in Pakistan (http://www.corenet.org.pk/projects.php). It = is funded by a Telecom sector. The purpose is to build confidence of ISP's = on IPv6. There is very limited implementation of V6 in Pakistan.=0A>=0A> We= are implementing multicast pim-sm for v6 on this hybrid v4 and v6 network.= To handle transition we have decided to use dual stack and tunneling mecha= nisms.=0A> Multicast for hybrid v4 and v6 network is only working with dual= stack. No tunneling technique (6to4, 6RD) is supporting multicast.=0A>=0A>= Can you people suggest a way to test multicast for these tunneling mechani= sms?=0A>=0A> Regards=0A> Sajjad=0A> IPv4 project team lead=0A>=0A>=0A>=0A>= =0A>=0A> ________________________________=0A>=A0 From: cb.list6 =0A> To: sajjad akbar =0A> Cc: v6ops@ietf.o= rg; v6ops-bounces@ietf.org=0A> Sent: Friday, September 27, 2013 6:44 PM=0A>= Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query=0A>=0A>=0A>=0A= > Inline=0A> On Sep 27, 2013 2:09 AM, "sajjad akbar" = wrote:=0A>>=0A>> hi...=0A>>=0A>> There is a following=A0 issue regarding d= ual stack in context of DNS for IPv6.=0A>>=0A>> If a dual stack enable node= try to connect a server which is also dual stack but having issue in his I= Pv6 stack temporary. In this case, DNS returned the AAAA address to the req= uesting node. What are the possibilities to identify this issues or how we = can solve it?=0A>>=0A> Please see http://tools.ietf.org/html/rfc6555=0A>> R= egards=0A>> Sajjad=0A>>=0A>> ______________________________________________= _=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mai= lman/listinfo/v6ops=0A>>=0A>>=0A>>=0A>> ___________________________________= ____________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https://www.i= etf.org/mailman/listinfo/v6ops --828875537-1808610021-1380358253=:2685 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


Thanks for the suggested= link. we have studied this draft earlier. It,s not very simple to deploy t= his mechanism on every router. Tunneling is already costly and by applying = such mechanisms we will make it more complex. So, can we conclude that IPv6= tunneling mechanisms are not supporting multicast? I think its alarming fo= r the transition phase as in coming days technologies like IPTV etc will be= very common.
May be we can also state t= hat only dual stack is a complete solution for transition phase. As per my = knowledge translation techniques are also not supporting multicast.<= /div>


Regards
Sajjad

From: Tom Taylor <tom.taylor.stds@gmail.com>
To: sajjad akbar <sajjad_akr@yahoo.com&g= t;
Cc: "v6ops@ietf.org= " <v6ops@ietf.org>
Sent: Friday, September 27, 2013 10:18 PM
Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC.= .. query

You might lo= ok at
http://datatracker.ietf.org/doc/draft-sarikaya-softwire-= 6rdmulticast/,
taking note that it has not drawn any interest in th= e Softwires Working
Group.

On 27/09/2013 10:32 AM, sajjad akbar = wrote:
> Dear fellows
>
> Thanks for referring RFC 6555.&= nbsp; Actually we are doing a project tittled
>
> Design and D= evelopment of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming = Multicast Application
>
>
>  in Pakistan (http://www.co= renet.org.pk/projects.php). It is funded by a Telecom sector. The purpo= se is to build confidence of ISP's on IPv6. There is very limited implement= ation of V6 in Pakistan.
>
> We are implementing multicast pim-= sm for v6 on this hybrid v4 and v6 network. To handle transition we have de= cided to use dual stack and tunneling mechanisms.
> Multicast for hybrid v4 and v6 network is only working with dual stack. No tunneling tec= hnique (6to4, 6RD) is supporting multicast.
>
> Can you people = suggest a way to test multicast for these tunneling mechanisms?
>
= > Regards
> Sajjad
> IPv4 project team lead
>
><= br>>
>
>
> ________________________________
>&nb= sp; From: cb.list6 <cb.list6@gmail.com>
> To: sajjad akba= r <sajjad_akr@yahoo.com>
> Cc: v6ops@ietf.org; v= 6ops-bounces@ietf.org
> Sent: Friday, September 27, 2013 6:44 PM<= br>> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query
>
>
>
> Inline
> On Sep 27, 2013 2:09 = AM, "sajjad akbar" <sajjad_akr@yahoo.com> wrote:
>>=
>> hi...
>>
>> There is a following  issue= regarding dual stack in context of DNS for IPv6.
>>
>> I= f a dual stack enable node try to connect a server which is also dual stack= but having issue in his IPv6 stack temporary. In this case, DNS returned t= he AAAA address to the requesting node. What are the possibilities to ident= ify this issues or how we can solve it?
>>
> Please see http://tools.i= etf.org/html/rfc6555
>> Regards
>> Sajjad
>>=
>> _______________________________________________
>> v6= ops mailing list
>> v6ops@ietf.org
>> https://www.i= etf.org/mailman/listinfo/v6ops
>>
>>
>>
&= gt;> _______________________________________________
>> v6ops m= ailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman= /listinfo/v6ops


--828875537-1808610021-1380358253=:2685-- From sajjad_akr@yahoo.com Sat Sep 28 06:34:18 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12F121F9BCE for ; Sat, 28 Sep 2013 06:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USRKmN1w2NIt for ; Sat, 28 Sep 2013 06:34:13 -0700 (PDT) Received: from nm40-vm1.bullet.mail.gq1.yahoo.com (nm40-vm1.bullet.mail.gq1.yahoo.com [98.136.217.124]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7921F9B86 for ; Sat, 28 Sep 2013 06:34:10 -0700 (PDT) Received: from [98.137.12.191] by nm40.bullet.mail.gq1.yahoo.com with NNFMP; 28 Sep 2013 13:34:09 -0000 Received: from [216.39.60.209] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 28 Sep 2013 13:34:09 -0000 Received: from [127.0.0.1] by omp1096.mail.gq1.yahoo.com with NNFMP; 28 Sep 2013 13:34:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509963.61852.bm@omp1096.mail.gq1.yahoo.com Received: (qmail 2845 invoked by uid 60001); 28 Sep 2013 13:34:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380375248; bh=Of/DlNUFnuNtJvf324aX/lHJamUITOSUnlQNyXBTGd0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DiVzQUV1iYocgVlzOibeHSk13T9mzjuVaJR1xREYvqy1Wdgatlv+foOJDSeC7WrIp4Mh1+XsSHHbgUGEjJDKabFET69q1NwDSmmUhYe7dZ6x3HyyBS+aAoQpZuPtdY4Yj17MDKacRD5Wyd7b4f6Bh476pjLue1h1RdPaos5qZGY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vTboaCLuIna+gowi9Gt69Q6W4Y+JnQNc8pzmuxh8FiMxU74km+K4YStPtbzpBmodaMD7A2KBsvUP+aasymefnyKSnYFSWbak4wFyHyFXBJt2yFTnzENFaito0o706vr8QteiQB582GJjXH1OyU/pvv//Q6nNIpHUZ7no9a+C0qU=; X-YMail-OSG: c6HZMsEVM1mLtEE15Uz75Cr7zK1gkW4qh1uKJrT1mKZbZTw mhhDB4fmht6PcDDOo8nyuzoh0.KRip4yetrEFk83slbc.5rmYAeXd6t6XN5J dNrkJ3CxOV3Aa6YlKvmAPq8Q0q4jOVq5Jm_5_jwH8tC0g_VlzRbb_nOrsDOe JsVvdH9j2MaOu44EBuKNNp4dXka9Yf5D2jbRfPwA9KCq4319u_nCGcPfXqlr YAx90ZJVd1Nf_i6EreHt8bMionM1lB.0axNKJKwu_WN6RVP5s0uKI9dGqHRR 5YEYx1KRYRHfZfWpboJ59LU4kytCvOCsElkbmP26ipRkUSh5aYv1H29KN0bG JqjJTdCye8LNUi5mWCoKKNuRyjMfXvEuiWgH0428jta7t7Xyj_vnrnDbVY0J 6hWhITbwZHI9Eb2bBRPZz46KHrrLQ2NLCl49VXSSLfeZJpIZWif51DGvN3uc zcTA3lG9TI49qYAQm0QaCw87O5RhUsDadC.fXK1C7TJgh4QOc82vwKlW1UxE 7nKrn4dm6EUJ3bJLD8DOvesibCO52HBUmZA0VHdynbgPM0Tns22Yj9Y15FNZ Gs3lqGpFU19xJeaGUe6It8TI4aIV3_WIoQxbbD0bNL1TCorKiPr7KjySOtQY IBPjiezZlA5oQrvgNjX_4_2i0bVPh.TSyoTqdBo4qwPPEPgRS3z7ikqx01Ul 3..ef.sZmnzXFA8RShb6yBj0Cdt0q4_upIvxWZKOuk0wV7qJ5yX58Ohvqdw- - Received: from [39.47.71.54] by web121503.mail.ne1.yahoo.com via HTTP; Sat, 28 Sep 2013 06:34:08 PDT X-Rocket-MIMEInfo: 002.001, CgpZZXMsaSBndWVzcyB0aGlzIGlzIHRoZSByaWdodCBzdGF0ZW1lbnQuCkkgaGF2ZSB2aXNpdGVkIHRoZSBsaW5rCgpodHRwOi8vd3d3LmNzYy5maS9lbmdsaXNoL2luc3RpdHV0aW9ucy9mdW5ldC9uZXR3b3Jrc2VydmljZXMvaXB2Ni9tY2FzdDQ2CgoKQ2FuIHdlIGZpZ3VyZSBvdXQgdGhlIGJhc2ljIHJlYXNvbiB0aGF0IHdoeSB0dW5uZWxpbmcgYW5kIHRyYW5zbGF0aW9uIGFyZSBsYWNraW5nIG11bHRpY2FzdD8KCklzIGl0IGR1ZSB0byBoZWFkZXIgcmVjb25zdHJ1Y3Rpb24gaXNzdWVzPwpvcgppcyBpdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <1380272938.39375.YahooMailNeo@web121502.mail.ne1.yahoo.com> <1380292322.5784.YahooMailNeo@web121504.mail.ne1.yahoo.com> <5245BDE1.4080307@gmail.com> <1380358253.2685.YahooMailNeo@web121503.mail.ne1.yahoo.com> Message-ID: <1380375248.2785.YahooMailNeo@web121503.mail.ne1.yahoo.com> Date: Sat, 28 Sep 2013 06:34:08 -0700 (PDT) From: sajjad akbar To: Jouni In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="828875537-833470770-1380375248=:2785" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 13:34:19 -0000 --828875537-833470770-1380375248=:2785 Content-Type: text/plain; charset=us-ascii Yes,i guess this is the right statement. I have visited the link http://www.csc.fi/english/institutions/funet/networkservices/ipv6/mcast46 Can we figure out the basic reason that why tunneling and translation are lacking multicast? Is it due to header reconstruction issues? or is it due to limitation of one to one tunnel basic mechanism? Regards ________________________________ From: Jouni To: sajjad akbar Sent: Saturday, September 28, 2013 3:34 PM Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query On Sep 28, 2013, at 11:50 AM, sajjad akbar wrote: > May be we can also state that only dual stack is a complete solution for transition phase. As per my knowledge translation techniques are also not supporting multicast. http://www.csc.fi/english/institutions/funet/networkservices/ipv6/mcast46 - Jouni --828875537-833470770-1380375248=:2785 Content-Type: text/html; charset=us-ascii
Yes,i guess this is the right statement.
I have visited the link

Can we figure out the basic reason that why tunneling and translation are lacking multicast?

Is it due to header reconstruction issues?
or
is it due to limitation of one to one tunnel basic mechanism?


Regards
From: Jouni <jouni.nospam@gmail.com>
To: sajjad akbar <sajjad_akr@yahoo.com>
Sent: Saturday, September 28, 2013 3:34 PM
Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC... query




On Sep 28, 2013, at 11:50 AM, sajjad akbar wrote:

> May be we can also state that only dual stack is a complete solution for transition phase. As per my knowledge translation techniques are also not supporting multicast.

http://www.csc.fi/english/institutions/funet/networkservices/ipv6/mcast46


- Jouni


--828875537-833470770-1380375248=:2785--

Re-,

 

P= lease see inline.

 =

Cheers,

Med

 

=

De : Loren= zo Colitti [mailto:lorenzo@google.com]
Envoy=E9 : mardi 10 = septembre 2013 11:27
=C0 : BOUCADAIR Mohamed IMT/OLN
C= c : Dave Cridland; v6ops@ietf.org WG; BINET David IMT/OLN; IETF Di= scussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops= -mobile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profi= le for 3GPP Mobile Devices) to Informational RFC

 

= On Tue, Sep 10, 2013 at 5:18 PM, <mohamed.boucadair@orange.com> wrote:

I really don’t see how you ca= n have a phone that “make a phone that works perfectly well on= an IPv6-only” if you don’t suppo= rt IPv6/IPv4v6 PDP context=

You don't need to su= pport IPV4V6 if all you need to do is work on an IPv6-only network.

[Med]= UEs that will provided with IPv6-only or DS is up to the provider. Note al= so that the requirement is worded to let the decision to each provider. The= document explicitly says:

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 This allows each operator to select their own strategy

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 regarding IPv6 introduction.=A0 Bo= th IPv6 and IPv4v6 PDP-

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Contexts MUST be supported.=A0 IPv4, IPv6 or IPv4v6 PDP-Context=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 request acceptance dep= ends on the cellular network

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 configuration.

<= o:p> 

That might seem lik= e a stupid answer, but the point I'm trying to make is that while you and I= know that supporting only IPV6 will result in the phone being incompatible= with some networks *the document doesn't say that*. The document says you = MUST support all this stuff=

[Med] No. no, no the document indicates the la= nguage for each feature: there are MUST, SHOULD, etc. This is not the first= time a document makes such classification of the features.

 

=

, without saying why, and without giving any informati= on to operators, implementers, or anyone else on why this particular laundr= y list of features was selected. <= /span>

[Med] There is already motivations text = for most of features, rationale and scope of the overall effort in the draf= t. You are continuing ignore it. That’s not fair. <= /i>

 

That's not a good way to specify things. Look at RFC1122,= for example: every requirement is carefully articulated, with rationale an= d everything else.

[Med] This docume= nt is not a standard. This document does not ambition to have the same leve= l as RFC1122.

y= ou don’t have a means to make work broken applications when IPv6-only= is enabled

Nobody can control third party-applications, not even the phone manufact= urer (which is why REQ#33 doesn't make sense).

[Med] There are API, there = applications shipped by device vendors themselves, etc. Our teams already t= ested applications provided by vendors devices which are broken when IPv6-o= nly mode.

 = ;

The manufacturer can provid= e something like 464xlat, which I agree is necessary for IPv6-only operatio= n.

[Med] Are you saying this=A0 is a= MUST?

if the ph= one does not follow the procedure for requesting the PDP context,

You don't need to = do that if you have an APN database that's configured with what the operato= r supports, or if you don't support IPV4V6. (Straying back into technical d= iscussion for a bit - from a technical point of view, having seen the wide = variety of behaviours and result codes that basebands typically exhibit whe= n you ask them to do something that they or the network doesn't support, I = think relying on this fallback is a terrible idea.)

how you can be compatible with DNSSEC, etc. 

How many phones to= day support DNSSEC?

[Med] How many d= evice support IPv6 today? We can play that game endlessly...=

 

      NOTE WELL: This document is not= a standard, and conformance with

      it is not required in or=
der to claim conformance with IETF
      standards for IPv6.&=
nbsp; The support of the full set of features may
      not be requ= ired in some contexts (e.g. dual-stack).  The support
      of=
 a subset of the features included in this profile may lead to<=
/o:p>
     =
; degraded level of service (e.g., IPv6-only mode).
=

 

This is not about IPv6-only mode.

[Med] What is wro= ng in that text? Can we focus on the exact text change? <= /i>

 

That's a useful feature, and as I'm sure you know, it's = been implemented by a number of manufacturers.

 

Cons= ider an implementation that implements IPv6 tethering without including a f= ull RFC6204 IPv6 router with simple security, ULA, DHCPv6 PD, stateful DHCP= v6 and all the bells and whistles built in. Or consider a 464xlat implement= ation without a local DNS64 implementation.

[Med] You still do that. These features are not MUST in this docume= nt. It is your right to ignore them but you need to be aware this may have = some negative impact. It seems you understand the list as MUST ones…w= hile this is not true.

 

I don't= consider these to be degraded service, I consider them to be a lot better = than what we have today.

[Med] I’m sorry to say that a customer wit= h IPv6-only connectivity that cannot use some applications available for an= IPv4 customer is a degraded service. This is seen by some operators as a b= arrier for that mode. =A0

= --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7EFEPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Tue Sep 10 04:33:40 2013 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8E911E819D for ; Tue, 10 Sep 2013 04:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbJGW23WZKdk for ; Tue, 10 Sep 2013 04:33:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 06DBE21F9B9F for ; Tue, 10 Sep 2013 04:33:34 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A1FB722C42B; Tue, 10 Sep 2013 13:33:32 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 897CD238048; Tue, 10 Sep 2013 13:33:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 10 Sep 2013 13:33:32 +0200 From: To: Owen DeLong , "v6ops@ietf.org WG" Date: Tue, 10 Sep 2013 13:33:30 +0200 Thread-Topic: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC Thread-Index: Ac6uCdhUWStCapyCR2m3WZvGJSrFDQADYoLA Message-ID: <94C682931C08B048B7A8645303FDC9F36EF0EE7F11@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819135219.8236.40060.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EF033638D@PUEXCB1B.nanterre.francetelecom.fr> <10526_1378283356_5226EF5C_10526_843_1_1B2E7539FECD9048B261B791B1B24A7C511C52CE60@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF033645A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0A6F@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF06D0AF5@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7D57@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EF0EE7DEF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EF0EE7F11PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.10.101514 Subject: Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:33:40 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7F11PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Owen, The main motivations for us to edit this draft is the lack of any document = that explicitly enumerate that IPv6 features for mobile devices. Operators = each in its own contact its device vendor partners and discussion with them= the list of features they would like to see supported. For example, Orange= is editing a 500 pages device requirement document shared with our partner= s. IPv6 is only a small chapter in that document... When discussing with other operators, we noticed that even if we were reque= sting for the same features, some vendors told us we are the only provider = asking for that features. From there, it was obvious for us (a group of ope= rators) there is a need to have a common document which make abstraction of= the frontiers between SDOs but provide a comprehensive list of features we= think are needed. We came naturally to the IETF because there is where the= IPv6 expertise is and better this is an open forum. Because of the particularity of mobile networks, mobile deployments require= strong language for some features compared to what is recorded in the IPv6= node requirement document. This document indicates such cases and why. FWIW, this is not the first document edited by the IETF to cover IPv6 in mo= bile networks; e.g., * http://tools.ietf.org/html/rfc3316 * http://tools.ietf.org/html/rfc6459 * http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04 There are also IETF documents specifying for instance: Transmission of IPv6= Packets over BLUETOOTH Low Energy (http://tools.ietf.org/html/draft-ietf-6= lowpan-btle-12) So, we should not treat draft-ietf-v6ops-mobile-device-profile more than wh= at is intended to do: 1. List in one single document a comprehensive list of IPv6 features for a mobile device, including both IPv6-only and dual-stack mobile deployment contexts. These features cover various network types such as GPRS (General Packet Radio Service), EPC (Evolved Packet Core) or IEEE 802.11 network. 2. Help Operators with the detailed device requirement list preparation (to be exchanged with device suppliers). This is also a contribution to harmonize Operators' requirements towards device vendors. 3. Vendors to be aware of a set of features to allow for IPv6 connectivity and IPv4 service continuity (over an IPv6-only transport). For more details on scope and goals, please refer to the introduction text = of the draft. I hope this clarify your concern. Cheers, Med De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de O= wen DeLong Envoy=E9 : mardi 10 septembre 2013 11:35 =C0 : v6ops@ietf.org WG Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC Perhaps I'm still confused or truly don't understand all of the IP-specific= implications of 3g/4g/other cellular protocols. However, it seems to me that from an IETF perspective, the various interfac= es on a cell phone (802.11, 3gpp, LTE, etc.) are just various layer 2 media= . The phone itself is just another host and/or router. Most of what is contained in this document strikes me as an effort to shift= the work in media adaptation out of the media standards bodies and into th= e IETF solely because the cellular standards bodies, vendors, et. al. don't= seem to be able to come together and build reasonable working documents. Unfortunately, the result is an I-D/RFC that is slightly less complicated t= han the Bluetooth specification and nearly as legible. PDP contexts are a media adaptation problem unique to the (bizarre) choices= of the cellular industry in order to support their arcane billing and lice= nsing schemes. Every other media, it has been left to the media standards group to develop= the necessary media adaptation layers for IP. This document seems to be tr= ying to shift that role into the IETF for this particular implementation of= a combination of media types, some of which already have adaptation layers= specified in their respective standards group, some of which may not, and = many of which are made unusually complex and twisted by the unique nature o= f the accounting systems that are involved. I haven't seen an IETF profile document for Ethernet, Token Ring, PPP, HDLC= , FDDI, Firewire, USB, ATM, etc. The requirements documents for hosts and routers are already in reasonably = good shape. Efforts are already underway to update them with operational ex= perience and more recent lessons learned. It is my opinion that this document will, in the long run, merely create ad= ditional confusion as it is likely to conflict with future output from 3GPP= and other standards bodies responsible for the media that is unique to the= cellular world and overlaps and may also conflict with documents from IEEE= and other standards bodies that control some of the other network interfac= es currently present on cellular devices and/or likely to be present in the= future (such as BLE and 802.16). Yes, the 3GPP standards are currently rather lacking in their IP adaptation= guidance and the cellular industry is a quagmire of competing interests an= d malformed overly-political standards processes. I do not believe that bri= nging that into the IETF will do anything to reduce the quagmire in the cel= lular industry, nor will it do anything to benefit IPv6 or IPv6 deployment. Owen On Sep 10, 2013, at 01:18 , mohamed.boucadair@orange.com wrote: Re-, I really don't see how you can have a phone that "make a phone that works p= erfectly well on an IPv6-only" if you don't support IPv6/IPv4v6 PDP context= , you don't have a means to make work broken applications when IPv6-only is= enabled, if the phone does not follow the procedure for requesting the PDP= context, how you can be compatible with DNSSEC, etc. If what you mean by "perfect" is a degraded level of service, then you are = right. I update the text to reflect this: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. The support of the full set of features may not be required in some contexts (e.g. dual-stack). The support of a subset of the features included in this profile may lead to degraded level of service (e.g., IPv6-only mode). This document uses the normative keywords defined in the previous section only for precision. Is this better? Cheers, Med De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : mardi 10 septembre 2013 09:21 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dave Cridland; v6ops@ietf.org WG; BINET David I= MT/OLN; IETF Discussion Objet : Re: [v6ops] Last Call: (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to= Informational RFC On Tue, Sep 10, 2013 at 3:57 PM, > wrote: I have considered that Lorenzo. "is not required to deploy IPv6" would be a= ccurate if this document is dealing only with dual-stack, but this is not t= rue for the IPv6-only mode. The set of SHOULD recommendations are targeting= that deployment model. I disagree. By my reading, you can make a phone that works perfectly well o= n an IPv6-only carrier network without implementing #2, #3, #9, #10, #11, #= 12, #14, $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. S= ome of those are MUSTs in this document. If you want to do IPv6-only on wifi you need either #9 and #10 (or both plu= s #11 as well), and either #20 or #21 (or both plus #23). But the other one= s are not necessary to deploy an IPv6-only phone. One of your co-authors wi= ll be able to confirm this: I'm told there are multiple IPv6-only phones on= T-Mobile USA today, and I'm sure none of them implement all the requiremen= ts in this document (or even all the MUSTs). [*] How did #18 even make it in? What use is a MAY in a requirements docume= nt? Of course implementors MAY do anything they want, unless they SHOULD NO= T or MUST NOT. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_94C682931C08B048B7A8645303FDC9F36EF0EE7F11PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Owen,

 

The main motivations for us to edit this draft is the lack of any docume= nt that explicitly enumerate that IPv6 features for mobile devices. Operato= rs each in its own contact its device vendor partners and discussion with t= hem the list of features they would like to see supported. For example, Ora= nge is editing a 500 pages device requirement document shared with our part= ners. IPv6 is only a small chapter in that document…

 

When= discussing with other operators, we noticed that even if we were requestin= g for the same features, some vendors told us we are the only provider aski= ng for that features. From there, it was obvious for us (a group of operato= rs) there is a need to have a common document which make abstraction of the= frontiers between SDOs but provide a comprehensive list of features we thi= nk are needed. We came naturally to the IETF because there is where the IPv= 6 expertise is and better this is an open forum.

 

Because of th= e particularity of mobile networks, mobile deployments require strong langu= age for some features compared to what is recorded in the IPv6 node require= ment document. This document indicates such cases and why.

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>FWI= W, this is not the first document edited by the IETF to cover IPv6 in mobil= e networks; e.g.,

 

* http://tools.ietf.org/html/rfc3316

* http://tools.ie= tf.org/html/rfc6459

* http://tools= .ietf.org/html/draft-ietf-v6ops-rfc3316bis-04 =A0

=

 

There are= also IETF documents specifying for instance: Transmission of IPv6 Packets = over BLUETOOTH Low Energy (http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12= )

 

So, we should not treat draft-ietf-v6ops-mobile-device-profil= e more than what is intended to do:

=A0=A0 1.=A0 List in one s= ingle document a comprehensive list of IPv6 features

<= p class=3DMsoNormal>=A0=A0=A0=A0=A0=A0 for a mobile device, including both IP= v6-only and dual-stack

=A0=A0=A0=A0= =A0=A0 mobile deployment contexts.=A0 These features cover various network<= o:p>

=A0=A0=A0=A0=A0=A0 types such as GP= RS (General Packet Radio Service), EPC (Evolved

=A0=A0=A0=A0=A0=A0 Packet Core) or IEEE 802.11 network.

 

=A0=A0 2.=A0 Help Operators with the detailed device requirement list=

=A0=A0=A0=A0=A0=A0 preparation (to= be exchanged with device suppliers).=A0 This is

=A0=A0=A0=A0=A0=A0 also a contribution to harmonize Operators= ' requirements towards

=A0=A0=A0=A0= =A0=A0 device vendors.

 <= /o:p>

=A0=A0 3.=A0 Vendors to be aware of a se= t of features to allow for IPv6

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>=A0= =A0=A0=A0=A0=A0 connectivity and IPv4 service continuity (over an IPv6-only=

=A0=A0=A0=A0=A0=A0 transport).

 

For more details on scope and goals, please refer to the introdu= ction text of the draft.

 = ;

I hope this clarify your concern.=

 

Cheers,

Med

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'> 

De : = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part d<= /span>e Owen DeLong
Envoy=E9 : mardi 10 se= ptembre 2013 11:35
=C0 : v6ops@ietf.org WG
Objet = : Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-04.= txt> (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices= ) to Informational RFC

 

Perhaps I'm still confused or t= ruly don't understand all of the IP-specific implications of 3g/4g/other ce= llular protocols.

 =

However, it seems to me that from an IETF per= spective, the various interfaces on a cell phone (802.11, 3gpp, LTE, etc.) = are just various layer 2 media. The phone itself is just another host and/o= r router.

 

Most of what is contained in this documen= t strikes me as an effort to shift the work in media adaptation out of the = media standards bodies and into the IETF solely because the cellular standa= rds bodies, vendors, et. al. don't seem to be able to come together and bui= ld reasonable working documents.

 

Unfortunately, the= result is an I-D/RFC that is slightly less complicated than the Bluetooth = specification and nearly as legible.

 

PDP contexts a= re a media adaptation problem unique to the (bizarre) choices of the cellul= ar industry in order to support their arcane billing and licensing schemes.=

 

<= div>

Every other media, it has been left to the media s= tandards group to develop the necessary media adaptation layers for IP. Thi= s document seems to be trying to shift that role into the IETF for this par= ticular implementation of a combination of media types, some of which alrea= dy have adaptation layers specified in their respective standards group, so= me of which may not, and many of which are made unusually complex and twist= ed by the unique nature of the accounting systems that are involved.

 

I haven't seen an IETF profile document for Ethernet, Tok= en Ring, PPP, HDLC, FDDI, Firewire, USB, ATM, etc.

 

= The requirements documents for hosts and routers are already in reasonably = good shape. Efforts are already underway to update them with operational ex= perience and more recent lessons learned.

 

It is my = opinion that this document will, in the long run, merely create additional = confusion as it is likely to conflict with future output from 3GPP and othe= r standards bodies responsible for the media that is unique to the cellular= world and overlaps and may also conflict with documents from IEEE and othe= r standards bodies that control some of the other network interfaces curren= tly present on cellular devices and/or likely to be present in the future (= such as BLE and 802.16).

 

Yes, the 3GPP standards ar= e currently rather lacking in their IP adaptation guidance and the cellular= industry is a quagmire of competing interests and malformed overly-politic= al standards processes. I do not believe that bringing that into the IETF w= ill do anything to reduce the quagmire in the cellular industry, nor will i= t do anything to benefit IPv6 or IPv6 deployment.

=

 

O= wen

 

On Sep 10, 2013, at 01:18 , mohamed.boucadair@orange.com wrote:



Re-,

 

I really don&#=
8217;t see how you can have a phone that “make a phone that wo=
rks perfectly well on an IPv6-only” if =
you don’t support IPv6/IPv4v6 PD=
P context, you don’t have a means to make work broken applications wh=
en IPv6-only is enabled, if the phone does not follow the procedure for req=
uesting the PDP context, how you can be compatible with DNSSEC, etc. 
 
If what you mean by “perfe=
ct” is a degraded level of service, then you are right. <=
/o:p>
 
I update the text to reflect this:
 
      =
NOTE WELL: This document is not a standard, and conformance with
    &nb=
sp; it is not required in order to claim conformance with IETF<=
/o:p>
     =
; standards for IPv6.  The support of the full set of features may
   &n=
bsp;  not be required in some contexts (e.g. dual-stack).  The su=
pport
  =
;    of a subset of the features included in this profile ma=
y lead to
 &=
nbsp;    degraded level of service (e.g., IPv6-only mode).
 =

    &nbs=
p; This document uses the normative keywords defined in the previous=

    =
;  section only for precision.
 
Is this better?
 
Ch=
eers,
Med<=
o:p>
 
<=
div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4=
.0pt'>
De : Lorenzo Colitti [ma=
ilto:lorenzo@google.com] 
Envoy=E9 : mardi 10 septembre 2013 09:21
=C0&nbs=
p;: BOUCADAIR Mohamed I=
MT/OLN
Cc : =
Dave Cridland; v6ops@ietf.org WG; BIN=
ET David IMT/OLN; IETF Discussion
Objet : Re: [v6ops] Last Call: <draft-ietf-v6ops-m=
obile-device-profile-04.txt> (Internet Protocol Version 6 (IPv6) Profile=
 for 3GPP Mobile Devices) to Informational RFC
<=
/div>
 
<=
p class=3DMsoNormal>On Tue, Sep 10, 2013 at 3:57 PM, <mohamed.boucadair@orange.com> wrote:
I have considered that Lorenzo. &#=
8220;is not required to deploy IPv6” would be accurate if this d=
ocument is dealing only with dual-stack, but this is not true for the IPv6-=
only mode. The set of SHOULD recommendations are targeting that deployment =
model.
 
I disagr=
ee. By my reading, you can make a phone that works perfectly well on an IPv=
6-only carrier network without implementing #2, #3, #9, #10, #11, #12, #14,=
 $15, #16, #17, #18*, #20, #21, #22, #23, #24, #26, #33, and #36. Some of t=
hose are MUSTs in this document.
 
If you want to do IPv6-only on wifi you need either #9 and #10 (or both=
 plus #11 as well), and either #20 or #21 (or both plus #23). But the other=
 ones are not necessary to deploy an IPv6-only phone. One of your co-author=
s will be able to confirm this: I'm told there are multiple IPv6-only phone=
s on T-Mobile USA today, and I'm sure none of them implement all the requir=
ements in this document (or even all the MUSTs).
=

 
<=
p class=3DMsoNormal> 
[*] How did #18 even make it in? What use is a MAY in a requiremen=
ts document? Of course implementors MAY do anything they want, unless they =
SHOULD NOT or MUST NOT.

_______________________________________________
v6ops mailing l= ist
v6ops@ietf.org
https://www.ietf.org/mailman/li= stinfo/v6ops