From repenno@cisco.com Wed Jan 2 15:29:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D5F21F8837 for ; Wed, 2 Jan 2013 15:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvxFUKX2XK+3 for ; Wed, 2 Jan 2013 15:29:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1B44021F8836 for ; Wed, 2 Jan 2013 15:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=697; q=dns/txt; s=iport; t=1357169383; x=1358378983; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=BJuN+MSncyg9XyhiTvEmk6hCOGofJ9IVv8VcW9zEnxw=; b=bVfBsFnNwwYaFSfeT6uLIZb+M+nlfN7DAr69Ixl6MVadLoBIHZbrQyV6 q/4kw7Dg8X+ZFQb9YY3ye/zCB2nm9sRZ7WzWdoJoGz4Eq/YZr6B2epnBL Qnb+ZO59L7neBOJvehVgWBxjEmtEd3Yk2NJg3OMSmy6IqTSl+isFmhGF4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAIXB5FCtJV2a/2dsb2JhbABFgX+DdLdRFnOCIAEEHR00HQEqFEInBBuICwyZYp16jGKDV2EDlyiPLIJ0gXE1 X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208";a="158281231" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jan 2013 23:29:42 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r02NTgNe025745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jan 2013 23:29:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.33]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 17:29:42 -0600 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHN6UEK8qgMvGaNgE+FsR9vklMqWA== Date: Wed, 2 Jan 2013 23:29:41 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.78.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 23:29:43 -0000 Hello, First of all, Happy new Year! Based on the discussions at IETF Atlanta Meeting we would like to start call of adoption on a few drafts, with the first one below. This email starts a 2-week consensus call on adopting Title : Learn NAT64 PREFIX64s using PCP Author(s) : M. Boucadair Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt URL : http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt Please read the current revision and state you opinion either for or against adoption (and with reasoning why) in the mailing list. The call for adoption ends 16th January 2013. Thanks, From repenno@cisco.com Wed Jan 2 15:34:38 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40F021F8845 for ; Wed, 2 Jan 2013 15:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOwDNVLLAGVG for ; Wed, 2 Jan 2013 15:34:37 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 17B4A21F87FF for ; Wed, 2 Jan 2013 15:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=492; q=dns/txt; s=iport; t=1357169676; x=1358379276; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=CwLkjBIHuzHDv25sAUZp2FigrkZXFmSr0giWDyY4tr8=; b=gUCJBg9kyRrJ8Dr22A8l4vsXzn4zZgOveB0uupxEY9sJPoFWFG6CmSpu SemjQPugsXLgX26xk1+59tfxiVZbaXstA+M2OJFLhczNifm7a1FTYjthK X+c6UcckfT9iFhEtucpvQC7v4+jzh+tNWgIGln3/3WwzP0f7HiCJlcb2O g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAOzC5FCtJV2Z/2dsb2JhbABFgX+DdLdSFnOCIAEEHR00HQEqFEIlAgQbiAsMmWSdeoxig1dhA5cojyyCdIFxNQ X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208";a="158282194" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jan 2013 23:34:35 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r02NYZ3U030552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Jan 2013 23:34:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.33]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 17:34:35 -0600 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG4VAHA/mJ7pE2nEh8Cxk6Ywg== Date: Wed, 2 Jan 2013 23:34:35 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.78.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <1267803D48400A43AB31D9A770779930@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 23:34:38 -0000 Hello, This email starts a 2-week consensus call on adopting Title : Using PCP To Coordinate Between the CGN and Home Gateway Author(s) : Q. Sun et al Filename : draft-tsou-pcp-natcoord-09.txt URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt Please read the current revision and state you opinion either for or against adoption (and with reasoning why) in the mailing list. The call for adoption ends 16th January 2013. Thanks, From dwing@cisco.com Wed Jan 2 17:39:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A839121F8889 for ; Wed, 2 Jan 2013 17:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.524 X-Spam-Level: X-Spam-Status: No, score=-109.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HVbDoiw9mih for ; Wed, 2 Jan 2013 17:39:04 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87C21F881A for ; Wed, 2 Jan 2013 17:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2066; q=dns/txt; s=iport; t=1357177144; x=1358386744; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=k9ggsiUn4ITxILkQPYmyRxYJfu67u2CyuAEbFtd+mkI=; b=YZiKAkhoHTO8ejrpoSWnwwuoB/1dFYwhpJMN99+WPtVv9ItT2VD0rqTB Y84PeN0ZacxE9196yGw8o7uaHUV/M+dtLnMsjw+UkNZDK7tupCjnNvBSQ 9QmS3VVJRqG/suJ98j7nAPxRjjoIjjzMWq/yZxgEf3VH4i1VeQ+ADTXRt w=; X-IronPort-AV: E=Sophos;i="4.84,400,1355097600"; d="scan'208";a="64740499" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 03 Jan 2013 01:39:03 +0000 Received: from DWINGWS01 (sjc-vpn7-1725.cisco.com [10.21.150.189]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r031d38j013774; Thu, 3 Jan 2013 01:39:03 GMT From: "Dan Wing" To: "'Reinaldo Penno \(repenno\)'" , References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> Date: Wed, 2 Jan 2013 17:39:03 -0800 Message-ID: <01ab01cde953$1cbfed70$563fc850$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJCt95bsnCw7XkdTvDDrAOqjgdTl5dNM8YA Content-Language: en-us Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 01:39:04 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno (repenno) > Sent: Wednesday, January 02, 2013 3:35 PM > To: pcp@ietf.org > Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > Hello, > > This email starts a 2-week consensus call on adopting > > Title : Using PCP To Coordinate Between the CGN and Home > Gateway > Author(s) : Q. Sun et al > Filename : draft-tsou-pcp-natcoord-09.txt > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. The Applicability section, title, and section 2 need to be clarified if PCP-NATCOORD works with PRR, works with CGN (as defined by draft-ietf-behave-lsn-requirements), or only works with draft-cui-softwire-b4-translated-ds-lite. Some of the Applicability section is actually in section 2, where section 2 says: ... This mechanism can be applied for lightweight 4over6 [I-D.cui-softwire-b4-translated-ds-lite] in port-set allocation process. It can also be applied to stateless PCP-controlled device, in which the Internal address, External address and Port set is determined algorithmically. Yet, section 6 says "Normally, the PCP server for MAP_PORT_SET will not run NAT" which conflicts with the document's own title ("Using PCP To Coordinate Between the CGN and Home Gateway"). Nit: Figure 2 shows a 24 bit Reserved field, but the description says it is 16 bits. Also, Figure 2 has a cut/paste mistake with Suggested Port Set Index (should be Assigned Port Set Index). What is the status of draft-cui-softwire-b4-translated-ds-lite in SOFTWIRE? -d > The call for adoption ends 16th January 2013. > > Thanks, > > > > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From christian.jacquenet@orange.com Thu Jan 3 01:31:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F5721F88F1 for ; Thu, 3 Jan 2013 01:31:32 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAfGCzqgu+L8 for ; Thu, 3 Jan 2013 01:31:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5421F8A6A for ; Thu, 3 Jan 2013 01:31:30 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4426822CB9A; Thu, 3 Jan 2013 10:31:29 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1E092238070; Thu, 3 Jan 2013 10:31:29 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 3 Jan 2013 10:31:28 +0100 From: To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Thu, 3 Jan 2013 10:31:27 +0100 Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHN6UEK8qgMvGaNgE+FsR9vklMqWJg3Vn9w Message-ID: <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.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: 2012.10.24.110314 Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:31:32 -0000 Hello WG, I support the adoption of the draft as a pcp WG document. The proposed appr= oach is useful to address the typical use cases mentioned in section 2. Cheers, Christian.=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Reina= ldo Penno (repenno) Envoy=E9 : jeudi 3 janvier 2013 00:30 =C0 : pcp@ietf.org Objet : [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-opti= on Hello, First of all, Happy new Year! Based on the discussions at IETF Atlanta Meeting we would like to start cal= l of adoption on a few drafts, with the first one below. This email starts a 2-week consensus call on adopting Title : Learn NAT64 PREFIX64s using PCP Author(s) : M. Boucadair Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt URL : http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt Please read the current revision and state you opinion either for or agains= t adoption (and with reasoning why) in the mailing list. The call for adopt= ion ends 16th January 2013. Thanks, _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From adurand@juniper.net Thu Jan 3 08:44:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB4421F8CA7 for ; Thu, 3 Jan 2013 08:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=1.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0C0klUtaMmw for ; Thu, 3 Jan 2013 08:44:55 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id B231721F85FC for ; Thu, 3 Jan 2013 08:44:55 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUOW1h17LFpBH+EPhufhnyMENOS+FjcAQ@postini.com; Thu, 03 Jan 2013 08:44:55 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 3 Jan 2013 08:40:00 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 3 Jan 2013 08:39:58 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 3 Jan 2013 08:48:15 -0800 Received: from mail12-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 Jan 2013 16:39:58 +0000 Received: from mail12-va3 (localhost [127.0.0.1]) by mail12-va3-R.bigfish.com (Postfix) with ESMTP id 11E7C1E0182 for ; Thu, 3 Jan 2013 16:39:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I1432I1418I4015Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033IL17326ahz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail12-va3 (localhost.localdomain [127.0.0.1]) by mail12-va3 (MessageSwitch) id 1357231195769858_26771; Thu, 3 Jan 2013 16:39:55 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.251]) by mail12-va3.bigfish.com (Postfix) with ESMTP id AE24548005B; Thu, 3 Jan 2013 16:39:55 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 3 Jan 2013 16:39:55 +0000 Received: from BL2PRD0510MB386.namprd05.prod.outlook.com ([169.254.11.166]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0245.002; Thu, 3 Jan 2013 16:39:55 +0000 From: Alain Durand To: "Reinaldo Penno (repenno)" Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG/IWNhS315/EentG942BWJKpg3z2QA Date: Thu, 3 Jan 2013 16:39:54 +0000 Message-ID: <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7185B39D254B4247ABB39CC1256EEA82@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:44:56 -0000 I do not support the adoption of this document as wg item, for essentially = three reasons. 1) This functionality can be achieved very simply on a CPE by sending multi= ple PCP requests. This would remove the complexity of port set indexes, max port set, et= c... 2) There are already several DHCP (v4 and v6) options being defined to addr= ess this very problem, and my understanding is that there is an attempt at converging those i= n DHC & Softwires. If a PCP option absolutely must be defined as well (which honestly I d= oubt), I would hope it would be defined exactly the same way as the yet-to-be-defined fina= l DHCP option. 3) When asking for multiple of those port-sets, one may end-up with port se= ts on different external IP addresses. Also, when ports are running low, connections m= ay be delayed until a new port set is acquired. There are problems associated with these scenarii and they should be an= alyzed. In the end, there is a trade-off between flexibility and complexity. Th= e question is, in REAL operation, is the flexibility of having multiple port sets = needed? In CGN deployments I'm familiar with, ISPs assign a fixed amount of por= ts per user that should be enough for everybody and don't change it. If this is not good enough fo= r a particular user, the simplest thing to do is to take him/her out of the CGN pool and ass= ign him/her a full IPv4 address. In other words, I think that this notion of handing out multiple port = sets with pseudo-random ports is vastly over engineered. Alain. On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) wr= ote: > Hello, >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : Using PCP To Coordinate Between the CGN and Home Gateway > Author(s) : Q. Sun et al > Filename : draft-tsou-pcp-natcoord-09.txt > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt >=20 > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. >=20 > The call for adoption ends 16th January 2013. >=20 > Thanks, >=20 From tireddy@cisco.com Thu Jan 3 19:10:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B546821F8D1A for ; Thu, 3 Jan 2013 19:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-nwi5zNocnC for ; Thu, 3 Jan 2013 19:10:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C37C021F8CF4 for ; Thu, 3 Jan 2013 19:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2874; q=dns/txt; s=iport; t=1357269031; x=1358478631; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s8cm867XWA6X5bFPLDJVT9NrMuOlrtnzuixVPLrBd/c=; b=kIB+mFptMNuulBleeXXe/WRbVKj0PmAdIAfAsrUOdGzyDGK+BEcTCIZo wbn3AGPHRM2G3TcW0u8a4Z0GC4smYLAVMhda8mLSGWJ+VVDqUI1IRfls2 SN6ZAy59MKo7GyfkeBH7alYUOb+KbZu0k8psE7cWWXaMu9J0cx9ZKqVXQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAtH5lCtJXG+/2dsb2JhbABFvU0Wc4IeAQEBBAEBARpRFwQCAQgRBAEBCx0HJwsUCQgCBAESCIgLDLZgjGGDV2EDiC2Oe48sgnSBcTU X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208";a="158769116" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 04 Jan 2013 03:10:30 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r043ATxc015487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jan 2013 03:10:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 21:10:29 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHN6ez7OsJ5hw9qj0CF7Sk48Klaopg4eGKw Date: Fri, 4 Jan 2013 03:10:28 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148C7D28@xmb-rcd-x10.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.86.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 03:10:31 -0000 I also support this draft. Regards, Tiru. > -----Original Message----- > From: christian.jacquenet@orange.com [mailto:christian.jacquenet@orange.c= om] > Sent: Thursday, January 03, 2013 3:01 PM > To: Reinaldo Penno (repenno); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix= 64- > option >=20 > Hello WG, >=20 > I support the adoption of the draft as a pcp WG document. The proposed > approach is useful to address the typical use cases mentioned in section = 2. >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Rei= naldo > Penno (repenno) > Envoy=E9 : jeudi 3 janvier 2013 00:30 > =C0 : pcp@ietf.org > Objet : [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-op= tion >=20 > Hello, >=20 > First of all, Happy new Year! >=20 > Based on the discussions at IETF Atlanta Meeting we would like to start c= all > of adoption on a few drafts, with the first one below. >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : Learn NAT64 PREFIX64s using PCP > Author(s) : M. Boucadair > Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt > URL : > http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt >=20 > Please read the current revision and state you opinion either for or agai= nst > adoption (and with reasoning why) in the mailing list. The call for adopt= ion > ends 16th January 2013. >=20 >=20 > Thanks, >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > _________________________________________________________________________= _____ > ___________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information 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 de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 From zhaojingjing695@gmail.com Thu Jan 3 21:20:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAAF21F8CE8 for ; Thu, 3 Jan 2013 21:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTC8hlJLtOw5 for ; Thu, 3 Jan 2013 21:20:10 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9A30821F8CD7 for ; Thu, 3 Jan 2013 21:20:07 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so9055987pad.24 for ; Thu, 03 Jan 2013 21:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:reply-to:subject:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=/JaLEYHXCtOyTQDFBEFdC/hh8c8AqSnniMP6HwGUkDc=; b=vrO5h3TSs8C2juZRhm+N3WRBmC53OqKO+JnbgRNYR1smzlAB5itFlpoLieRjK8bbt9 o+TaD3kY4s/ovZteuCXVapYzSgGCSRTWKHlvcqUemu+UWSrfEQ46fn/kieXYrzlgrxWR ttmn7VF/4bgM8Ys6iAb0st+ezBT2W7xEfe5uDzr8lmNBCy80xtLA5AVezCTAO76eOijN OZ9Ia4yIuQLJ2sUnf4kUUDZtcb08mNPgWXSEOqFsLvR6BXN/FYEHq0iAVJFhUrgPB+gc H0KC+WyFlLgn1HUCHG+VVqqw7wY4z+ymX3orgRuGLf6J757AMeOjovvhwrImh6ggYrhA QgQw== X-Received: by 10.66.82.200 with SMTP id k8mr151615241pay.56.1357276807087; Thu, 03 Jan 2013 21:20:07 -0800 (PST) Received: from ctbri-sunqiong ([219.142.69.75]) by mx.google.com with ESMTPS id o11sm31577211pby.8.2013.01.03.21.20.02 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 21:20:06 -0800 (PST) Date: Fri, 4 Jan 2013 13:19:52 +0800 From: zhaojingjing695 To: pcp X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201301041315266537225@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart334701532670_=----" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhaojingjing695 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 05:20:13 -0000 This is a multi-part message in MIME format. ------=_001_NextPart334701532670_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgc3VwcG9ydCB0byBhZG9wdCB0aGlzIGRvY3VtZW50LiBJIHRoaW5rIHRo aXMgcG9ydC1zZXQgZXh0ZW5zaW9uIGlzIHF1aXRlIHVzZWZ1bC4NCg0KDQpDaGVlcnMsDQoNCg0K DQoNCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCkZyb206ICJS ZWluYWxkbyBQZW5ubyAocmVwZW5ubykiIDxyZXBlbm5vQGNpc2NvLmNvbT4NClByZWNlZGVuY2U6 IGxpc3QNCk1JTUUtVmVyc2lvbjogMS4wDQpUbzogInBjcEBpZXRmLm9yZyIgPHBjcEBpZXRmLm9y Zz4NCkluLVJlcGx5LVRvOiA8NDVBNjk3QThGRkQ3Q0Y0OEJDRjJCRTdFMTA2RjA2MDQxRTlEMzJA eG1iLXJjZC14MDQuY2lzY28uY29tPg0KRGF0ZTogV2VkLCAyIEphbiAyMDEzIDIzOjM0OjM1ICsw MDAwDQpNZXNzYWdlLUlEOiA8NDVBNjk3QThGRkQ3Q0Y0OEJDRjJCRTdFMTA2RjA2MDQxRTlENDhA eG1iLXJjZC14MDQuY2lzY28uY29tPg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0 PSJ1cy1hc2NpaSINClN1YmplY3Q6IFtwY3BdIFdHIENhbGwgZm9yIEFkb3B0aW9uOiBkcmFmdC10 c291LXBjcC1uYXRjb29yZC0wOQ0KTWVzc2FnZTogMg0KSGVsbG8sDQoNClRoaXMgZW1haWwgc3Rh cnRzIGEgMi13ZWVrIGNvbnNlbnN1cyBjYWxsIG9uIGFkb3B0aW5nDQoNCiAgICAgVGl0bGUgICAg IDogVXNpbmcgUENQIFRvIENvb3JkaW5hdGUgQmV0d2VlbiB0aGUgQ0dOIGFuZCBIb21lIEdhdGV3 YXkNCiAgICAgQXV0aG9yKHMpIDogUS4gU3VuIGV0IGFsDQogICAgIEZpbGVuYW1lICA6IGRyYWZ0 LXRzb3UtcGNwLW5hdGNvb3JkLTA5LnR4dA0KICAgICBVUkwgICAgICAgOiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaWQvZHJhZnQtdHNvdS1wY3AtbmF0Y29vcmQtMDkudHh0DQoNClBsZWFzZSByZWFk IHRoZSBjdXJyZW50IHJldmlzaW9uIGFuZCBzdGF0ZSB5b3Ugb3BpbmlvbiBlaXRoZXIgZm9yIG9y DQphZ2FpbnN0IGFkb3B0aW9uIChhbmQgd2l0aCByZWFzb25pbmcgd2h5KSBpbiB0aGUgbWFpbGlu ZyBsaXN0Lg0KDQpUaGUgY2FsbCBmb3IgYWRvcHRpb24gZW5kcyAxNnRoIEphbnVhcnkgMjAxMy4N Cg0KVGhhbmtzLA0KDQoNCkppbmdqaW5nemhhbyA= ------=_001_NextPart334701532670_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I support to adopt this document. I think this port-set extension is = quite=20 useful.
 
 
Cheers,
 
 
 
 
Content-Transfer-Encoding: quoted-printable
From: "Reinaldo Penno (repenno)" <repenno@cisc= o.com>
Precedence: list
MIME-Version: 1.0
To: "pcp@ietf.org" <pcp@ietf.org>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-= x04.cisco.com>
Date: Wed, 2 Jan 2013 23:34:35 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x= 04.cisco.com>
Content-Type: text/plain; charset=3D"us-ascii"
Subject: [pcp] WG Call for Adoption: dr= aft-tsou-pcp-natcoord-09
Message: 2
Hello,

This email starts a 2-week consensus call on adopting

     Title     : Using PCP To Coordinate Between the CGN and Home Gateway
     Author(s) : Q. Sun et al
     Filename  : draft-tsou-pcp-natcoord-09.txt
     URL       : http://tools.ietf.org/id/draft-tsou-pcp-natcoord=
-09.txt

Please read the current revision and state you opinion either for or
against adoption (and with reasoning why) in the mailing list.

The call for adoption ends 16th January 2013.

Thanks,
Jingjingzhao
 
------=_001_NextPart334701532670_=------ From teemu.savolainen@nokia.com Thu Jan 3 23:01:20 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5732021F8D75 for ; Thu, 3 Jan 2013 23:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShiqguD1ev0i for ; Thu, 3 Jan 2013 23:01:19 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C421F8D6F for ; Thu, 3 Jan 2013 23:01:19 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0471HbV003663; Fri, 4 Jan 2013 09:01:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jan 2013 09:01:17 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.88]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0318.003; Fri, 4 Jan 2013 07:01:16 +0000 From: To: , Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac3qR6Uh+Ye6uFudTa6KVzvjdr/IlQ== Date: Fri, 4 Jan 2013 07:01:16 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204550473@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCe0v9E1GtLYFx/mmaG63icvzPS1iHxB2K1yqR0VpN7cv/EmsYF9McaF8wAjzWwn0XCQ1cMud0xxO50muisYCbVtbSJuf839WbbDjFnK7nQFQSVii7ReQtf3v9rFNt+UQVb9T/eJOp9tBpkQsa7V7YMQj7vMc/Cn81LuF8euhw9+R2Ns5b2UOHdbdSKEXfMyMTjuN8iqONc5zd5KlPXnpF+JzVp6kcPHhsbd1QALBkKPN9ZDBiyTBDaRkPBwyGNXxbk= x-originating-ip: [10.163.162.189] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2013 07:01:17.0408 (UTC) FILETIME=[4AEB9E00:01CDEA49] X-Nokia-AV: Clean Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 07:01:20 -0000 Hi, If the PCP server readily has information about Pref64::/n, then why not te= ll that to PCP client indeed. But if it has not, then I would ask what is t= he benefit of defining PCP option instead of DHCPv6 option? In the Behave WG we have been working on analysis of different Pref64::/n d= iscovery tools, currently in RFC Editor: http://tools.ietf.org/html/draft-= ietf-behave-nat64-learn-analysis-03 The Behave's work resulted in heuristic approach being selected, which is c= urrently in AD evaluation: http://tools.ietf.org/html/draft-ietf-behave-nat= 64-discovery-heuristic-13 Should this document formally update learn-analysis and have a section with= similar analysis, stating pros and cons and then concluding why it is usef= ul to have this solution for PCP deployment scenarios? In this document I would like to see text talking about relation to said an= alysis document and heuristic approach. For example, if a host does Pref64:= :/n discovery with heuristic approach for its generic use (such as local AA= AA record synthesis), is there utility for SIP client to perform separate d= iscovery also with PCP client? Nit: the IPv4-only SIP UA can be IPv4-only, but terminology about IPv6-only= SIP UE is not that accurate IMHO: the draft's SIP UA in IPv6-only *access*= seems to be quite capable of understanding IPv4-world (adding IPv4 address= es to SDP offer), hence maybe better say SIP UA in IPv6-only access, instea= d of IPv6-only SIP UA? Best regards, Teemu > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > ext Reinaldo Penno (repenno) > Sent: 03. tammikuuta 2013 01:30 > To: pcp@ietf.org > Subject: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64- > option >=20 > Hello, >=20 > First of all, Happy new Year! >=20 > Based on the discussions at IETF Atlanta Meeting we would like to start c= all of > adoption on a few drafts, with the first one below. >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : Learn NAT64 PREFIX64s using PCP > Author(s) : M. Boucadair > Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt > URL : > http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt >=20 > Please read the current revision and state you opinion either for or agai= nst > adoption (and with reasoning why) in the mailing list. The call for adopt= ion > ends 16th January 2013. >=20 >=20 > Thanks, >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From bingxuere@gmail.com Fri Jan 4 01:55:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783E721F8EDF for ; Fri, 4 Jan 2013 01:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s16mX9BDJ0Z for ; Fri, 4 Jan 2013 01:55:58 -0800 (PST) Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADAA21F8EDE for ; Fri, 4 Jan 2013 01:55:58 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id k25so13861935iah.9 for ; Fri, 04 Jan 2013 01:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xxjrwyQ6kFZOHyKFTUPGAgNA1Frab2rpVg4yYdJiCzo=; b=m+2qXoqJruIpyl0DH0ZBDBi9ch85XgLO1lYygegXzSbAd1v1Bk4HzXkV1lR8ODZIO8 BSrbZK9/f+Wda01TPGf64JwfAzb2h5XPfn1gQdFjvt9Yim8WTQYbc2K6p9Fo7AEoNjKa JaPEAngVupQVj4GyZELzq7GkLhl5BH+eSwXPZFB0lIqCskt3JMMnL+RT5/nnf13Zn9Ru S6PeVhIBg9BIroAwIfYaeUOlfh5FQxbiEmZkFU9kcnM4X+GAD+AfCqDkmMyLW589SDLR oSEu2QhffztcpFTlWemiuVY/SkYfTVshEYNxBum8JXhjIklq7e/NI/9fSsn2IMf/zqGA EZUQ== Received: by 10.50.36.194 with SMTP id s2mr45699838igj.56.1357293357954; Fri, 04 Jan 2013 01:55:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Fri, 4 Jan 2013 01:55:17 -0800 (PST) In-Reply-To: <01ab01cde953$1cbfed70$563fc850$@cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> From: Qiong Date: Fri, 4 Jan 2013 17:55:17 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=14dae9340dd574f69804d2737c8c Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 09:55:59 -0000 --14dae9340dd574f69804d2737c8c Content-Type: text/plain; charset=UTF-8 Dear Dan, Thanks for your comments. Please see inline ~~ On Thu, Jan 3, 2013 at 9:39 AM, Dan Wing wrote: > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Reinaldo Penno (repenno) > > Sent: Wednesday, January 02, 2013 3:35 PM > > To: pcp@ietf.org > > Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > > > Hello, > > > > This email starts a 2-week consensus call on adopting > > > > Title : Using PCP To Coordinate Between the CGN and Home > > Gateway > > Author(s) : Q. Sun et al > > Filename : draft-tsou-pcp-natcoord-09.txt > > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > > > Please read the current revision and state you opinion either for or > > against adoption (and with reasoning why) in the mailing list. > > The Applicability section, title, and section 2 need to be clarified > if PCP-NATCOORD works with PRR, works with CGN (as defined by > draft-ietf-behave-lsn-requirements), or only works with > draft-cui-softwire-b4-translated-ds-lite. Some of the Applicability > section > is > actually in section 2, where section 2 says: > > ... This mechanism can be applied for lightweight 4over6 > [I-D.cui-softwire-b4-translated-ds-lite] in port-set allocation > process. It can also be applied to stateless PCP-controlled device, > in which the Internal address, External address and Port set is > determined algorithmically. > > Yet, section 6 says "Normally, the PCP server for MAP_PORT_SET will > not run NAT" which conflicts with the document's own title ("Using > PCP To Coordinate Between the CGN and Home Gateway"). > > > [Qiong] Thanks for your suggestion. We will clarify it more clearly. PCP_NATCOORD can not only work with draft-cui-softwire-b4-translated-ds-lite, but can also work with PRR (either using internal IPv4 address, or IPv6 address). In the current draft, "the PCP server for MAP_PORT_SET will not run NAT" because the home gateway will run NAT instead of PCP server, but it would be easy to modify the draft to address the use cases which Reinaldo has pointed out in http://www.ietf.org/mail-archive/web/pcp/current/msg02664.html. The WG can decide which applicabilities should go in it when we agree that we should start work on this port-set Opcode. For the title and content in section 1 and 2, we will take reconsider it once the applicability of MAP_PORT_SET has been determined by the WG. > > Nit: Figure 2 shows a 24 bit Reserved field, but the description > says it is 16 bits. Also, Figure 2 has a cut/paste mistake > with Suggested Port Set Index (should be Assigned Port Set Index). > [Qiong] Thanks ! We will fix it. > > What is the status of draft-cui-softwire-b4-translated-ds-lite in > SOFTWIRE? > [Qiong] As far as I know, the concensus from the Atlanta meeting is that draft-cui-softwire-b4-translated-ds-lite would be moved forward after the softwire WG has a unified CPE draft covering both lightweight 4over6 and MAP. Hope it clarifies. Thanks ! Best wishes Qiong > > -d > > > > The call for adoption ends 16th January 2013. > > > > Thanks, > > > > > > > > > > > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae9340dd574f69804d2737c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Dan,

Thanks for your comments. Plea= se see inline ~~


On Thu, Jan 3, 2013 at 9:39 AM, Dan Wing <dwing@cisco.com> wrote:
> --= ---Original Message-----
> From: pcp-bounces@ietf.org= [mailto:pcp-bounces@ietf.org] = On Behalf Of
> Reinaldo Penno (repenno)
> Sent: Wednesday, January 02, 2013 3:35 PM
> To: pcp@ietf.org
> Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
>
> Hello,
>
> This email starts a 2-week consensus call on adopting
>
> =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 : Using PCP To Coordinate Betw= een the CGN and Home
> Gateway
> =C2=A0 =C2=A0 =C2=A0Author(s) : Q. Sun et al
> =C2=A0 =C2=A0 =C2=A0Filename =C2=A0: draft-tsou-pcp-natcoord-09.txt > =C2=A0 =C2=A0 =C2=A0URL =C2=A0 =C2=A0 =C2=A0 : http://tools= .ietf.org/id/draft-tsou-pcp-natcoord-09.txt
>
> Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list.

The Applicability section, title, and section 2 need to be clarified<= br> if PCP-NATCOORD works with PRR, works with CGN (as defined by
draft-ietf-behave-lsn-requirements), or only works with
draft-cui-softwire-b4-translated-ds-lite. =C2=A0Some of the Applicability s= ection
is
actually in section 2, where section 2 says:

=C2=A0 =C2=A0... This mechanism can be applied for lightweight 4over6
=C2=A0 =C2=A0[I-D.cui-softwire-b4-translated-ds-lite] in port-set allocatio= n
=C2=A0 =C2=A0process. =C2=A0It can also be applied to stateless PCP-control= led device,
=C2=A0 =C2=A0in which the Internal address, External address and Port set i= s
=C2=A0 =C2=A0determined algorithmically.

Yet, section 6 says "Normally, the PCP server for MAP_PORT_SET will not run NAT" which conflicts with the document's own title ("= Using
PCP To Coordinate Between the CGN and Home Gateway").


[Qiong] Thanks for your suggestion. We will clarify i= t more clearly.
PCP_NATCOORD can not only work with draft-cui-softwire-b= 4-translated-ds-lite, but can also work with PRR (either using internal IPv= 4 address, or IPv6 address). In the current draft, "the PCP server for= MAP_PORT_SET will not run NAT" because the home gateway will run NAT = instead of PCP server, but it would be easy to modify the draft to address = the use cases which Reinaldo has pointed out in http://www.ietf.org/mail-ar= chive/web/pcp/current/msg02664.html. The WG can decide which applicabil= ities should go in it when we agree that we should start work on this port-= set Opcode.
For the title and content in sec= tion 1 and=20 2, we will take reconsider it once the applicability of MAP_PORT_SET has be= en=20 determined by the WG.

Nit: Figure 2 shows a 24 bit Reserved field, but the description
says it is 16 bits. =C2=A0Also, Figure 2 has a cut/paste mistake
with Suggested Port Set Index (should be Assigned Port Set Index).

[Qion= g] Thanks ! We=20 will fix it. =C2=A0


What is the status of draft-cui-softwire-b4-translated-ds-lite in
SOFTWIRE?
[Qiong] As far as I know, the concensus from= the Atlanta meeting is that=20 draft-cui-softwire-b4-translated-ds-lite would be moved forward after the= =20 softwire WG has a unified CPE draft covering both lightweight 4over6 and MA= P.

Hope it clarifies. Thanks !

Best wi= shes
Qiong

-d


> The call for adoption ends 16th January 2013.
>
> Thanks,
>
>
>
>
>
>
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp



--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--14dae9340dd574f69804d2737c8c-- From alper.yegin@yegin.org Fri Jan 4 02:07:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234C221F8550 for ; Fri, 4 Jan 2013 02:07:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHR2jqzx9S6f for ; Fri, 4 Jan 2013 02:07:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEAD21F84F8 for ; Fri, 4 Jan 2013 02:07:08 -0800 (PST) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LhO7U-1TDJWX2gCm-00mi7x; Fri, 04 Jan 2013 05:07:06 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 4 Jan 2013 12:06:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> To: Sam Hartman X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:i++Sf2c5JlzwD+b/dPrKUIjjNA+nnDIZoKae7WY8J65 aQSMwYgO7h1JJUftZhYhhWT7/GHOp2fMWAuQwjKFX/netdQu8H Zw+JN9ZILRs/6zwIrl1omQV2qQlUH22Jq/viInNf31rPzWlTJh EkYjwYawdzedUEE1h2iUNV3mG0AmnChpJVFf0i9z7YOXN4h8hI i0c4WGlfFwRRxVOFvT3K5lWJddhX5wgi3tSi0CHWN6thKxoEF9 IE0Rn53eA13qsGvigrUjGJlnEUBrvYSWA6hmMnLMSqefQ+7Zqd GUlQgINzRKkbyzgN5YVkY5CdI0ysb2U3kFjvzSovOXjOWVJgYQ zlepyKhdWFDZyqhxpjv2dKRb3Ll//DQqGtyCNaVKbQXKMrBD4I Y5XV6TAzV1A4g== Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 10:07:10 -0000 Sam, So, the main concern you have is, if the server has an outstanding = message to send to the client and if there is no live SA, then the = server has to queue the message until the SA is generated. The queueing = of that message is your concern.=20 How is that such a big concern to the extent that we should define an = inadequately secured protocol at IETF? I don't get that. The protocol allowing some of the server-side messages fly w/o integrity = protection is a "glaring (security) hole". I'd say we are spending way too much time on some approach that's just = plain broken. (Just add server-initiated re-auth to your solution and be = done with this issue. Simple and straightforward. Not sure why you're = resisting that.). Is there anyone other than Sam who believes this path is worth spending = more time?=20 If not, can we start directing our energy to other aspects? Alper On Dec 11, 2012, at 4:37 PM, Sam Hartman wrote: >=20 > Simon and I spoke about the server-initiated messages last Friday. It > was an interesting conversation and we'd like to report on our = different > approaches to the WG in the hopes of informing the discussion and = moving > things forward. > Simon was approaching PCP authentication from the ISP standpoint, = where > the primary goal is to protect the client. I was approaching things > assuming the primary user of authentication will be enterprise > authentication and protecting the authorization of the server will be > one of the important goals of PCP authentication. >=20 > The big attack that we're concerned about when we consider unsolicited > updates is a change in mappings. For example consider a case where a > client is using a mapping for media announcements in SDP. The server > sends an unsolicited update because the mapping has changed and so the > client starts using the new address in new SDP announcements. If an > attacker convinces the client to use an external address of the > attacker's choice, then the attacker can potentially intercept media. > Simon said that he's most concerned about this type of attack when > considering unsolicited messages. >=20 > Neither of us could come up with very significant attacks on announce > messages. Potentially you could cause a client to spend a lot of time > updating mappings with a fake announce message. >=20 > However, there's a significant gap in our defense against this > attack. We support clients that that only authenticate when the server > requires it. > Such a client sends an unauthenticated request and performs > authentication when it receives an authentication required error. > Rather than attacking an unsolicited update, an attacker could simply > reply to the initial request with an unauthenticated answer. There are > some circumstances where the attacker might not be able to do that but > would be able to attack an unsolicited update.=20 > However, in most circumstances, the same sorts of attacks that could = be > mounted against unsolicited updates can be mounted against initial > responses. >=20 > The full defense against this sort of attack is for the client to > require authentication all the time. I think this is going to require > explicit configuration of the client. Simon and I both agree that > clients that require authentication all the time MUST verify the > integrity of the contents of unsolicited responses. If there are > circumstances where these responses do not include integrity related = to > a current security association, then those messages MUST NOT be = trusted > without soliciting an integrity protected version. Obviously if we end > up with a solution where we have server initiated re-auth that servers > are required to use, then the responses will always be protected by a > current security association. >=20 > Simon is concerned about a solution where integrity protection is > sometimes absent from unsolicited responses. He's concerned that = people > will make an implementation error and accept unprotected responses = when > they should not. he said that having some security information in the > message , including a protected indication that a SA had been deleted, > reduced this concern somewhat. I pointed out that under my proposal, = an > attacker could not generate a valid unprotected message until the > attacker had seen an unprotected message. If the client did > re-authenticate at that point, then the attacker would no longer be = able > to produce an valid unprotected message. >=20 > In my mind the biggest advantage of my proposal is that servers do not > need to queue messages while authentication takes place. > Clients may need to queue information on what mappings to solicit > updates for. >=20 > I think the biggest question to the WG is whether partially defending > against the mapping change attack is worth requiring servers to queue > outgoing unsolicited messages. >=20 > Simon has reviewed this summary and agrees that it describes our > meeting. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From bingxuere@gmail.com Fri Jan 4 05:52:50 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2521F894C for ; Fri, 4 Jan 2013 05:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBYjo7TsW7JY for ; Fri, 4 Jan 2013 05:52:49 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id EA87021F8526 for ; Fri, 4 Jan 2013 05:52:48 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id fa1so9340346pad.21 for ; Fri, 04 Jan 2013 05:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=VTwFySHtLX0OquCre/mmLQfuJ0A/+PVzIfgE7y1fGss=; b=oLndJkOoXQ37JDQg07asgMMc9V4WOF8+RoxZXUlCphRzCEf8N621wgwHO0WP2zz6Ru WigIT/5OKQJjAcmTTvNWzotyLvQGmHxZb0P5xB2QAjJY+cXsotd7/neAJo/NddqiXXuv +xozCDSLzyvIWgn1xUzKHID+Q+IAc+vapD0NEE1928AftPRUOc/Q+IQGXEIy0mkYUaXW nYAL7bFp7xQryEJ1o9YaeGOn6DcGbXMQyE1qPGvctp7BocJeZfc016/hRCXui3XpXSA3 tCfTebr0giGuyf8hfgxf3xEELF5tnGa/t0ScnzuL2LrHWlGjPnl51b1JjLcdi5Ae2o9T xshg== X-Received: by 10.69.1.9 with SMTP id bc9mr162127631pbd.61.1357307568595; Fri, 04 Jan 2013 05:52:48 -0800 (PST) Received: from [192.168.11.17] ([123.120.231.177]) by mx.google.com with ESMTPS id o5sm33239629paz.32.2013.01.04.05.52.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 05:52:47 -0800 (PST) References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> In-Reply-To: <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Message-Id: <26D7AE14-FA24-4119-9F9E-2971E6C0C012@gmail.com> X-Mailer: iPad Mail (9B206) From: bingxuere Date: Fri, 4 Jan 2013 21:52:37 +0800 To: Alain Durand Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:52:50 -0000 Hi Alain, Please see my comments inline below... On 2013-1-4, at =C9=CF=CE=E712:39, Alain Durand wrote:= > I do not support the adoption of this document as wg item, for essentially= three reasons. >=20 > 1) This functionality can be achieved very simply on a CPE by sending mult= iple PCP requests. > This would remove the complexity of port set indexes, max port set, et= c... One port set PCP request is obviously better than multiple individual PCP re= quests. It can not only save the bandwidth of massive PCP requests, reduce t= he mapping entries in PCP server, and greatly reduce the burden of PCP serve= r dealing with individual requests in a short time,etc. Considering one subs= criber will get a port set with 2048 ports, this simple port set Opcode can s= ave 2047 requests for one time. I don't see why we do not use it. >=20 > 2) There are already several DHCP (v4 and v6) options being defined to add= ress this very problem, > and my understanding is that there is an attempt at converging those i= n DHC & Softwires. > If a PCP option absolutely must be defined as well (which honestly I d= oubt), I would hope > it would be defined exactly the same way as the yet-to-be-defined fina= l DHCP option. 1) Using PCP is quite helpful in cases: a. An operator with no DHCP server o= r not enable to upgrade to support this new feature b. An operator planning t= o migrate the dslite AFTR to behave as a port range router. Just as we can h= ave both RFC6334 for dhcp option and RFC6519 for radius option, it is totall= y a deployment choice. Besides, this port set Opcode can also be applied to o= ther use cases as Reinaldo has pointed out.=20 2) Adopting a WG item does not mean the work has finished, rather, we just p= rovide a starting point for which the WG will decide which way to go. This i= s the most efficient way for the sake of this work, and we all see how PCP-b= ase has improved from -01 to -29. In the same way, the specific format of th= is port set Opcode can be modified to reflect the consensus from the WG. >=20 > 3) When asking for multiple of those port-sets, one may end-up with port s= ets on different > external IP addresses. Also, when ports are running low, connections m= ay be delayed until a new port set is acquired. > There are problems associated with these scenarii and they should be an= alyzed. In section 3.3, we have clearly say that the same external address should be= assigned to one subscriber in multiple port set requests. And we also recom= mend that the server assign the maximum allowed port set in a single request= . But I don't think the protocol itself should restrict this capability. It i= s still a deployment choice. >=20 > In the end, there is a trade-off between flexibility and complexity. Th= e question > is, in REAL operation, is the flexibility of having multiple port sets n= eeded? > In CGN deployments I'm familiar with, ISPs assign a fixed amount of por= ts per user that should be > enough for everybody and don't change it. If this is not good enough fo= r a particular user, > the simplest thing to do is to take him/her out of the CGN pool and ass= ign him/her a full IPv4 address. > In other words, I think that this notion of handing out multiple port s= ets with pseudo-random ports > is vastly over engineered. The same with the above one. Best wishes Qiong >=20 > Alain. >=20 >=20 >=20 >=20 > On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) w= rote: >=20 >> Hello, >>=20 >> This email starts a 2-week consensus call on adopting >>=20 >> Title : Using PCP To Coordinate Between the CGN and Home Gateway >> Author(s) : Q. Sun et al >> Filename : draft-tsou-pcp-natcoord-09.txt >> URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt >>=20 >> Please read the current revision and state you opinion either for or >> against adoption (and with reasoning why) in the mailing list. >>=20 >> The call for adoption ends 16th January 2013. >>=20 >> Thanks, >>=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Fri Jan 4 18:09:34 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A921F8A90 for ; Fri, 4 Jan 2013 18:09:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9me0N9tDzgzn for ; Fri, 4 Jan 2013 18:09:33 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 94C3821F87B9 for ; Fri, 4 Jan 2013 18:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4622; q=dns/txt; s=iport; t=1357351773; x=1358561373; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eNsGzDwIy1CZHidiMe6/sw87N/3vD5cuwMHqLMobIr8=; b=g3G5Rk80mu7bmS1AtZwO4UZ98irYiH66KpZBoe+U7Sk1jY+MImb8YOjT LT98iRI+OiUs3FSTV5kQYfc7HF0Zv5trkehOuZsnZYw0n6llwVaVfAJwW VENIpjLuXMM75aLijsZVJS8fccPq+bI8RV01EhJfxu3gKXiaZj/LWYyy5 Q=; X-IronPort-AV: E=Sophos;i="4.84,413,1355097600"; d="scan'208";a="65439526" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Jan 2013 02:09:33 +0000 Received: from DWINGWS01 (sjc-vpn7-1286.cisco.com [10.21.149.6]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0529X8V003827; Sat, 5 Jan 2013 02:09:33 GMT From: "Dan Wing" To: "'Qiong'" References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> In-Reply-To: Date: Fri, 4 Jan 2013 18:09:33 -0800 Message-ID: <037201cdeae9$b4109e80$1c31db80$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGsXrIihwxD8rvFf/g369xONMd8VgJCt95bAuLT/QEB2BZBephFKBSQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 02:09:34 -0000 > -----Original Message----- > From: Qiong [mailto:bingxuere@gmail.com] > Sent: Friday, January 04, 2013 1:55 AM > To: Dan Wing > Cc: Reinaldo Penno (repenno); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > Dear Dan, > > > Thanks for your comments. Please see inline ~~ > > > > On Thu, Jan 3, 2013 at 9:39 AM, Dan Wing wrote: > > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > Behalf Of > > Reinaldo Penno (repenno) > > Sent: Wednesday, January 02, 2013 3:35 PM > > To: pcp@ietf.org > > Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > > > Hello, > > > > This email starts a 2-week consensus call on adopting > > > > Title : Using PCP To Coordinate Between the CGN and Home > > Gateway > > Author(s) : Q. Sun et al > > Filename : draft-tsou-pcp-natcoord-09.txt > > URL : http://tools.ietf.org/id/draft-tsou-pcp- > natcoord-09.txt > > > > Please read the current revision and state you opinion either for > or > > against adoption (and with reasoning why) in the mailing list. > > > The Applicability section, title, and section 2 need to be > clarified > if PCP-NATCOORD works with PRR, works with CGN (as defined by > draft-ietf-behave-lsn-requirements), or only works with > draft-cui-softwire-b4-translated-ds-lite. Some of the > Applicability section > is > actually in section 2, where section 2 says: > > ... This mechanism can be applied for lightweight 4over6 > [I-D.cui-softwire-b4-translated-ds-lite] in port-set allocation > process. It can also be applied to stateless PCP-controlled > device, > in which the Internal address, External address and Port set is > determined algorithmically. > > Yet, section 6 says "Normally, the PCP server for MAP_PORT_SET will > not run NAT" which conflicts with the document's own title ("Using > PCP To Coordinate Between the CGN and Home Gateway"). > > > > > [Qiong] Thanks for your suggestion. We will clarify it more clearly. > PCP_NATCOORD can not only work with draft-cui-softwire-b4-translated-ds- > lite, but can also work with PRR (either using internal IPv4 address, or > IPv6 address). Can it work with a CGN? > In the current draft, "the PCP server for MAP_PORT_SET > will not run NAT" because the home gateway will run NAT instead of PCP > server, but it would be easy to modify the draft to address the use > cases which Reinaldo has pointed out in http://www.ietf.org/mail- > archive/web/pcp/current/msg02664.html. The WG can decide which > applicabilities should go in it when we agree that we should start work > on this port-set Opcode. With the current document text, I cannot understand what sort of deployments where NATCOORD can or cannot be used. Until I understand that, I can't decide if this document is a good idea or a bad idea. > For the title and content in section 1 and 2, we will take reconsider it > once the applicability of MAP_PORT_SET has been determined by the WG. > > > > Nit: Figure 2 shows a 24 bit Reserved field, but the description > says it is 16 bits. Also, Figure 2 has a cut/paste mistake > with Suggested Port Set Index (should be Assigned Port Set Index). > > > [Qiong] Thanks ! We will fix it. > > > > What is the status of draft-cui-softwire-b4-translated-ds-lite in > SOFTWIRE? > > > [Qiong] As far as I know, the concensus from the Atlanta meeting is that > draft-cui-softwire-b4-translated-ds-lite would be moved forward after > the softwire WG has a unified CPE draft covering both lightweight 4over6 > and MAP. -d > > > Hope it clarifies. Thanks ! > > > Best wishes > Qiong > > > > -d > > > > > The call for adoption ends 16th January 2013. > > > > Thanks, > > > > > > > > > > > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =============================================== > From ebiederm@xmission.com Fri Jan 4 23:22:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5721F8525 for ; Fri, 4 Jan 2013 23:22:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaf7iSm9txwz for ; Fri, 4 Jan 2013 23:22:10 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4F04521F8506 for ; Fri, 4 Jan 2013 23:22:10 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TrO51-0003wR-LK; Sat, 05 Jan 2013 00:22:07 -0700 Received: from c-98-207-153-68.hsd1.ca.comcast.net ([98.207.153.68] helo=eric-ThinkPad-X220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1TrO4y-0000O4-Eq; Sat, 05 Jan 2013 00:22:07 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Alper Yegin References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> Date: Fri, 04 Jan 2013 23:22:00 -0800 In-Reply-To: <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> (Alper Yegin's message of "Fri, 4 Jan 2013 12:06:47 +0200") Message-ID: <87obh4f61z.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+nxV2pfF74tiArUQIIrb+zAKMkaYsBQc0= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Alper Yegin X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 07:22:11 -0000 Alper Yegin writes: > Sam, > > So, the main concern you have is, if the server has an outstanding > message to send to the client and if there is no live SA, then the > server has to queue the message until the SA is generated. The > queueing of that message is your concern. > > How is that such a big concern to the extent that we should define an > inadequately secured protocol at IETF? I don't get that. The protocol > allowing some of the server-side messages fly w/o integrity protection > is a "glaring (security) hole". Definitely. It allows MITM attacks and predicting and controlling when the client sends packets. > I'd say we are spending way too much time on some approach that's just > plain broken. (Just add server-initiated re-auth to your solution and > be done with this issue. Simple and straightforward. Not sure why > you're resisting that.). I agree all of your binding lifetimes should be strictly less than your SA lifetimes which makes server-initiated-reauthentication unneeded, and guarantees you have no unathenticated messages. > Is there anyone other than Sam who believes this path is worth > spending more time? Generally unused code paths are invariably coded incorrectly. Both server-initiated-reathentication and sometimes encrypted sometimes not encrypted messages are both cases that will essentially never happen in practice, and add considerable complexity to the implementation. I suspect a lot of clients won't even bother to implement either code path (think iterative rapid development) let alone test them. I certainly believe it is worth spending enough time to remove the over design that is allowing bindings to have lifetimes larger than your security association. PCP is simple please keep it that way. > If not, can we start directing our energy to other aspects? I think this complaint just proves my point. It is hard to care enough about this detail to spend the time to get it right. If you can't do that in protocol design I really can't imagine many developers caring. So as someone who occassionally implements this kind of code, any solution other than having the lifteime of your bindings _always_ _always_ _always_ be less than the lifetime of your SA is desiging in a mistake waiting to happen. Don't do it. If the SA lifetime is less than the minimal binding lifetime the request should be denied. As long as there is a somewhat reasonable SA lifetime there won't be any meaningful operational limitation and it seriously simplifies everyone's implementations. Eric From zhangdacheng@huawei.com Fri Jan 4 23:33:54 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3842521F869A for ; Fri, 4 Jan 2013 23:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afs4WzuQhgDT for ; Fri, 4 Jan 2013 23:33:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73A21F84F9 for ; Fri, 4 Jan 2013 23:33:52 -0800 (PST) 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 AOL59651; Sat, 05 Jan 2013 07:33:51 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 5 Jan 2013 07:33:03 +0000 Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 5 Jan 2013 07:33:50 +0000 Received: from SZXEML548-MBS.china.huawei.com ([169.254.8.171]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.01.0323.003; Sat, 5 Jan 2013 15:33:42 +0800 From: "Zhangdacheng (Dacheng)" To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHN6ZUjs1Gkn+uwP06TqdRi5rdHD5g6WreA Date: Sat, 5 Jan 2013 07:33:41 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 07:33:54 -0000 +1 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > christian.jacquenet@orange.com > Sent: Thursday, January 03, 2013 5:31 PM > To: Reinaldo Penno (repenno); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: > draft-boucadair-pcp-nat64-prefix64-option >=20 > Hello WG, >=20 > I support the adoption of the draft as a pcp WG document. The proposed > approach is useful to address the typical use cases mentioned in section = 2. >=20 > Cheers, >=20 > Christian. >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > Reinaldo Penno (repenno) > Envoy=E9 : jeudi 3 janvier 2013 00:30 > =C0 : pcp@ietf.org > Objet : [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-op= tion >=20 > Hello, >=20 > First of all, Happy new Year! >=20 > Based on the discussions at IETF Atlanta Meeting we would like to start c= all of > adoption on a few drafts, with the first one below. >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : Learn NAT64 PREFIX64s using PCP > Author(s) : M. Boucadair > Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt > URL : > http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt >=20 > Please read the current revision and state you opinion either for or agai= nst > adoption (and with reasoning why) in the mailing list. The call for adopt= ion ends > 16th January 2013. >=20 >=20 > Thanks, >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > ________________________________________________________________ > _________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information 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 de= lete this > message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From bingxuere@gmail.com Sat Jan 5 00:33:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D22521F87AD for ; Sat, 5 Jan 2013 00:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RamDYtsf3C09 for ; Sat, 5 Jan 2013 00:33:47 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDAD21F8756 for ; Sat, 5 Jan 2013 00:33:47 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so20366305ieb.5 for ; Sat, 05 Jan 2013 00:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SgQDLNKwNvKZ9g2dzsWTLePpmY1JPdJR0MQqWqXlHs8=; b=MCSRx2tFKsDDpAFKv+Q0DtXvpii+3F9YpoBFUe3Gl2d98Q5Id+FoF/Cd8Ec5aSTuzr ND02pWB167msB7j1/lDJhhYloCiV0mEEjxAqOLKb65fhyzKmRFvDI5GP6a8pYpwPtRzf XRpgT4PG7xgzj3LW6erQcCMAjZKPv+Z4l3k26DPqCweXhslIuOlqpPjyCa7JdDJC2sQ+ NinD7VHcBGd8wjYvRJBVRHuwxesMMCp1vZj9CmL/aj9gJrDTp2GsE7W38lv+GufyLwBw +r3rulf+h0E53uQc5U1JU6FvLLdAeSruXXXwXEACa2TTbe9a6cweGcuJbKkmATqGAsPQ g4tQ== Received: by 10.50.161.130 with SMTP id xs2mr1112688igb.34.1357374827042; Sat, 05 Jan 2013 00:33:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sat, 5 Jan 2013 00:33:06 -0800 (PST) In-Reply-To: <037201cdeae9$b4109e80$1c31db80$@cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> From: Qiong Date: Sat, 5 Jan 2013 16:33:06 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=14dae934106d6495aa04d2867487 Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 08:33:48 -0000 --14dae934106d6495aa04d2867487 Content-Type: text/plain; charset=UTF-8 Dear Dan, Let me explain the deployment senario of NATCOORD here. The major functionality of NATCOORD is to get the External Port-Set and External public address for the PCP client. It is applied to the senario where NAT is offloaded to the home gateway and the PCP-controlled device does not run NAT(or port-mapping). The home gateway will restrict the source port into the external port-set, and therefore the PCP-controlled device does not need to do port-mapping anymore. Currently, there are several candidate solutions can work with it, including lightweight 4over6, PRR, and SLNAT44. NATCOORD does not work with ordinary CGN because there is no need for the home gateway to get a range of ports if it does not do port restriction. We will clarify it in the document. Thanks a lot for your consideration ! Best wishes Qiong On Sat, Jan 5, 2013 at 10:09 AM, Dan Wing wrote: > > -----Original Message----- > > From: Qiong [mailto:bingxuere@gmail.com] > > Sent: Friday, January 04, 2013 1:55 AM > > To: Dan Wing > > Cc: Reinaldo Penno (repenno); pcp@ietf.org > > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > > > Dear Dan, > > > > > > Thanks for your comments. Please see inline ~~ > > > > > > > > On Thu, Jan 3, 2013 at 9:39 AM, Dan Wing wrote: > > > > > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > > Behalf Of > > > Reinaldo Penno (repenno) > > > Sent: Wednesday, January 02, 2013 3:35 PM > > > To: pcp@ietf.org > > > Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > > > > > > > > [Qiong] Thanks for your suggestion. We will clarify it more clearly. > > PCP_NATCOORD can not only work with draft-cui-softwire-b4-translated-ds- > > lite, but can also work with PRR (either using internal IPv4 address, or > > IPv6 address). > > Can it work with a CGN? > > > > In the current draft, "the PCP server for MAP_PORT_SET > > will not run NAT" because the home gateway will run NAT instead of PCP > > server, but it would be easy to modify the draft to address the use > > cases which Reinaldo has pointed out in http://www.ietf.org/mail- > > archive/web/pcp/current/msg02664.html. The WG can decide which > > applicabilities should go in it when we agree that we should start work > > on this port-set Opcode. > > With the current document text, I cannot understand what sort of > deployments where NATCOORD can or cannot be used. Until I understand > that, I can't decide if this document is a good idea or a bad idea. > > > For the title and content in section 1 and 2, we will take reconsider it > > once the applicability of MAP_PORT_SET has been determined by the WG. > > > > > > > > Nit: Figure 2 shows a 24 bit Reserved field, but the description > > says it is 16 bits. Also, Figure 2 has a cut/paste mistake > > with Suggested Port Set Index (should be Assigned Port Set Index). > > > > > > [Qiong] Thanks ! We will fix it. > > > > > > > > What is the status of draft-cui-softwire-b4-translated-ds-lite in > > SOFTWIRE? > > > > > > [Qiong] As far as I know, the concensus from the Atlanta meeting is that > > draft-cui-softwire-b4-translated-ds-lite would be moved forward after > > the softwire WG has a unified CPE draft covering both lightweight 4over6 > > and MAP. > > -d > > > > > > > Hope it clarifies. Thanks ! > > > > > > Best wishes > > Qiong > > > > > > > > -d > > > > > > > > > The call for adoption ends 16th January 2013. > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > pcp mailing list > > > pcp@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcp > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > > > -- > > ============================================== > > Qiong Sun > > China Telecom Beijing Research Institude > > > > > > Open source code: > > lightweight 4over6: http://sourceforge.net/projects/laft6/ > > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > > =============================================== > > > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae934106d6495aa04d2867487 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Dan,

Let me explain the deploy= ment senario of NATCOORD here.

The major functionality of= NATCOORD is to get the External Port-Set and External public address for t= he PCP client. It is applied to the senario where NAT is offloaded to the h= ome gateway and the PCP-controlled device does not run NAT(or port-mapping)= . The home gateway will restrict the source port into the external port-set= , and therefore the PCP-controlled device does not need to do port-mapping = anymore. Currently, there are several candidate solutions can work with it,= including lightweight 4over6, PRR, and SLNAT44.

NATCOORD does not work with ordinary CGN because there is no= need for the home gateway to get a range of ports if it does not do port r= estriction.

We will clarify it in the document. Thanks a = lot for your consideration !

Best wishes
Qiong

On Sat, Jan 5, 2013 at 10:09 AM, Dan Wing = <= dwing@cisco.com> wrote:
> --= ---Original Message-----
> From: Qiong [mailto:bingxuere@g= mail.com]
> Sent: Friday, January 04, 2013 1:55 AM > To: Dan Wing
> Cc: Reinaldo Penno (repenno); pcp@ietf= .org
> Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 >
> Dear Dan,
>
>
> Thanks for your comments. Please see inline ~~
>
>
>
> On Thu, Jan 3, 2013 at 9:39 AM, Dan Wing <dwing@cisco.com> wrote:
>
>
> =C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
> =C2=A0 =C2=A0 =C2=A0 > From: pcp-bounces@ietf.org [mailto:= pcp-bounces@ietf.org] On
> Behalf Of
> =C2=A0 =C2=A0 =C2=A0 > Reinaldo Penno (repenno)
> =C2=A0 =C2=A0 =C2=A0 > Sent: Wednesday, January 02, 2013 3:35 PM > =C2=A0 =C2=A0 =C2=A0 > To: pcp@ietf= .org
> =C2=A0 =C2=A0 =C2=A0 > Subject: [pcp] WG Call for Adoption: draft-t= sou-pcp-natcoord-09
> =C2=A0 =C2=A0 =C2=A0 >
>
>
> [Qiong] Thanks for your suggestion. We will clarify it more clearly. > PCP_NATCOORD can not only work with draft-cui-softwire-b4-translated-d= s-
> lite, but can also work with PRR (either using internal IPv4 address, = or
> IPv6 address).

Can it work with a CGN?


> In the current draft, "the PCP server for MAP_PORT_SET
> will not run NAT" because the home gateway will run NAT instead o= f PCP
> server, but it would be easy to modify the draft to address the use > cases which Reinaldo has pointed out in http://www.ietf.org/mail-
> archive/web/pcp/current/msg02664.html. The WG can decide which
> applicabilities should go in it when we agree that we should start wor= k
> on this port-set Opcode.

With the current document text, I cannot understand what sort of
deployments where NATCOORD can or cannot be used. =C2=A0Until I understand<= br> that, I can't decide if this document is a good idea or a bad idea.

> For the title and content in section 1 and 2, we will take reconsider = it
> once the applicability of MAP_PORT_SET has been determined by the WG.<= br> >
>
>
> =C2=A0 =C2=A0 =C2=A0 Nit: Figure 2 shows a 24 bit Reserved field, but = the description
> =C2=A0 =C2=A0 =C2=A0 says it is 16 bits. =C2=A0Also, Figure 2 has a cu= t/paste mistake
> =C2=A0 =C2=A0 =C2=A0 with Suggested Port Set Index (should be Assigned= Port Set Index).
>
>
> [Qiong] Thanks ! We will fix it.
>
>
>
> =C2=A0 =C2=A0 =C2=A0 What is the status of draft-cui-softwire-b4-trans= lated-ds-lite in
> =C2=A0 =C2=A0 =C2=A0 SOFTWIRE?
>
>
> [Qiong] As far as I know, the concensus from the Atlanta meeting is th= at
> draft-cui-softwire-b4-translated-ds-lite would be moved forward after<= br> > the softwire WG has a unified CPE draft covering both lightweight 4ove= r6
> and MAP.

-d

>
>
> Hope it clarifies. Thanks !
>
>
> Best wishes
> Qiong
>
>
>
> =C2=A0 =C2=A0 =C2=A0 -d
>
>
>
> =C2=A0 =C2=A0 =C2=A0 > The call for adoption ends 16th January 2013= .
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 > Thanks,
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 >
> =C2=A0 =C2=A0 =C2=A0 > ____________________________________________= ___
> =C2=A0 =C2=A0 =C2=A0 > pcp mailing list
> =C2=A0 =C2=A0 =C2=A0 > pcp@ietf.org=
> =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/pcp >
> =C2=A0 =C2=A0 =C2=A0 _______________________________________________ > =C2=A0 =C2=A0 =C2=A0 pcp mailing list
> =C2=A0 =C2=A0 =C2=A0 pcp@ietf.org<= br> > =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/pcp
>
>
>
>
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Qiong Sun
> China Telecom Beijing Research Institude
>
>
> Open source code:
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >





--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--14dae934106d6495aa04d2867487-- From zhangdacheng@huawei.com Sat Jan 5 17:49:41 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA3F21F8659 for ; Sat, 5 Jan 2013 17:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=-2.401, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GvzPkB+pr9s for ; Sat, 5 Jan 2013 17:49:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C83A921F8623 for ; Sat, 5 Jan 2013 17:49:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOM01036; Sun, 06 Jan 2013 01:49:37 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 Jan 2013 01:48:36 +0000 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 6 Jan 2013 01:49:36 +0000 Received: from SZXEML548-MBS.china.huawei.com ([169.254.8.171]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.003; Sun, 6 Jan 2013 09:49:32 +0800 From: "Zhangdacheng (Dacheng)" To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG/MLjgJR+E6kmXBKQfqgXLIZg3SUoAgAFjmICAAt8YsA== Date: Sun, 6 Jan 2013 01:49:31 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <26D7AE14-FA24-4119-9F9E-2971E6C0C012@gmail.com> In-Reply-To: <26D7AE14-FA24-4119-9F9E-2971E6C0C012@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 01:49:41 -0000 SSBhZ3JlZSB0aGUgd29yayBjYW4gYnJpbmcgc29tZSBiZW5lZml0IChlLmcuLCBzaW1wbGlmeSB0 aGUgb3BlcmF0aW9ucykgaW4gY2VydGFpbiBzY2VuYXJpb3MuIFNvLCBzdXBwb3J0IHRoZSBhZG9w dGlvbiBvZiB0aGlzIHdvcmsgaWYgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIGtlZXAgaW1wcm92aW5n IGl0LiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBwY3AtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4g YmluZ3h1ZXJlDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAwNCwgMjAxMyA5OjUzIFBNDQo+IFRv OiBBbGFpbiBEdXJhbmQNCj4gQ2M6IHBjcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3BjcF0g V0cgQ2FsbCBmb3IgQWRvcHRpb246IGRyYWZ0LXRzb3UtcGNwLW5hdGNvb3JkLTA5DQo+IA0KPiBI aSBBbGFpbiwNCj4gDQo+IFBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lIGJlbG93Li4uDQo+ IA0KPiBPbiAyMDEzLTEtNCwgYXQgyc/O5zEyOjM5LCBBbGFpbiBEdXJhbmQgPGFkdXJhbmRAanVu aXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gPiBJIGRvIG5vdCBzdXBwb3J0IHRoZSBhZG9wdGlvbiBv ZiB0aGlzIGRvY3VtZW50IGFzIHdnIGl0ZW0sIGZvciBlc3NlbnRpYWxseQ0KPiB0aHJlZSByZWFz b25zLg0KPiA+DQo+ID4gMSkgVGhpcyBmdW5jdGlvbmFsaXR5IGNhbiBiZSBhY2hpZXZlZCB2ZXJ5 IHNpbXBseSBvbiBhIENQRSBieSBzZW5kaW5nIG11bHRpcGxlDQo+IFBDUCByZXF1ZXN0cy4NCj4g PiAgICAgVGhpcyB3b3VsZCByZW1vdmUgdGhlIGNvbXBsZXhpdHkgb2YgcG9ydCBzZXQgaW5kZXhl cywgbWF4IHBvcnQgc2V0LA0KPiBldGMuLi4NCj4gT25lIHBvcnQgc2V0IFBDUCByZXF1ZXN0IGlz IG9idmlvdXNseSBiZXR0ZXIgdGhhbiBtdWx0aXBsZSBpbmRpdmlkdWFsIFBDUA0KPiByZXF1ZXN0 cy4gSXQgY2FuIG5vdCBvbmx5IHNhdmUgdGhlIGJhbmR3aWR0aCBvZiBtYXNzaXZlIFBDUCByZXF1 ZXN0cywgcmVkdWNlDQo+IHRoZSBtYXBwaW5nIGVudHJpZXMgaW4gUENQIHNlcnZlciwgYW5kIGdy ZWF0bHkgcmVkdWNlIHRoZSBidXJkZW4gb2YgUENQIHNlcnZlcg0KPiBkZWFsaW5nIHdpdGggaW5k aXZpZHVhbCByZXF1ZXN0cyBpbiBhIHNob3J0IHRpbWUsZXRjLiBDb25zaWRlcmluZyBvbmUgc3Vi c2NyaWJlcg0KPiB3aWxsIGdldCBhIHBvcnQgc2V0IHdpdGggMjA0OCBwb3J0cywgdGhpcyBzaW1w bGUgcG9ydCBzZXQgT3Bjb2RlIGNhbiBzYXZlIDIwNDcNCj4gcmVxdWVzdHMgZm9yIG9uZSB0aW1l LiBJIGRvbid0IHNlZSB3aHkgd2UgZG8gbm90IHVzZSBpdC4NCj4gPg0KPiA+IDIpIFRoZXJlIGFy ZSBhbHJlYWR5IHNldmVyYWwgREhDUCAodjQgYW5kIHY2KSBvcHRpb25zIGJlaW5nIGRlZmluZWQg dG8NCj4gYWRkcmVzcyB0aGlzIHZlcnkgcHJvYmxlbSwNCj4gPiAgICAgYW5kIG15IHVuZGVyc3Rh bmRpbmcgaXMgdGhhdCB0aGVyZSBpcyBhbiBhdHRlbXB0IGF0IGNvbnZlcmdpbmcgdGhvc2UgaW4N Cj4gREhDICYgU29mdHdpcmVzLg0KPiA+ICAgICBJZiBhIFBDUCBvcHRpb24gYWJzb2x1dGVseSBt dXN0IGJlIGRlZmluZWQgYXMgd2VsbCAod2hpY2ggaG9uZXN0bHkgSQ0KPiBkb3VidCksIEkgd291 bGQgaG9wZQ0KPiA+ICAgICBpdCB3b3VsZCBiZSBkZWZpbmVkIGV4YWN0bHkgdGhlIHNhbWUgd2F5 IGFzIHRoZSB5ZXQtdG8tYmUtZGVmaW5lZCBmaW5hbA0KPiBESENQIG9wdGlvbi4NCj4gMSkgVXNp bmcgUENQIGlzIHF1aXRlIGhlbHBmdWwgaW4gY2FzZXM6IGEuIEFuIG9wZXJhdG9yIHdpdGggbm8g REhDUCBzZXJ2ZXIgb3INCj4gbm90IGVuYWJsZSB0byB1cGdyYWRlIHRvIHN1cHBvcnQgdGhpcyBu ZXcgZmVhdHVyZSBiLiBBbiBvcGVyYXRvciBwbGFubmluZyB0bw0KPiBtaWdyYXRlIHRoZSBkc2xp dGUgQUZUUiB0byBiZWhhdmUgYXMgYSBwb3J0IHJhbmdlIHJvdXRlci4gSnVzdCBhcyB3ZSBjYW4g aGF2ZQ0KPiBib3RoIFJGQzYzMzQgZm9yIGRoY3Agb3B0aW9uIGFuZCBSRkM2NTE5IGZvciByYWRp dXMgb3B0aW9uLCBpdCBpcyB0b3RhbGx5IGENCj4gZGVwbG95bWVudCBjaG9pY2UuIEJlc2lkZXMs IHRoaXMgcG9ydCBzZXQgT3Bjb2RlIGNhbiBhbHNvIGJlIGFwcGxpZWQgdG8gb3RoZXINCj4gdXNl IGNhc2VzIGFzIFJlaW5hbGRvIGhhcyBwb2ludGVkIG91dC4NCj4gMikgQWRvcHRpbmcgYSBXRyBp dGVtIGRvZXMgbm90IG1lYW4gdGhlIHdvcmsgaGFzIGZpbmlzaGVkLCByYXRoZXIsIHdlIGp1c3QN Cj4gcHJvdmlkZSBhIHN0YXJ0aW5nIHBvaW50IGZvciB3aGljaCB0aGUgV0cgd2lsbCBkZWNpZGUg d2hpY2ggd2F5IHRvIGdvLiBUaGlzIGlzDQo+IHRoZSBtb3N0IGVmZmljaWVudCB3YXkgZm9yIHRo ZSBzYWtlIG9mIHRoaXMgd29yaywgYW5kIHdlIGFsbCBzZWUgaG93IFBDUC1iYXNlDQo+IGhhcyBp bXByb3ZlZCBmcm9tIC0wMSB0byAtMjkuIEluIHRoZSBzYW1lIHdheSwgdGhlIHNwZWNpZmljIGZv cm1hdCBvZiB0aGlzIHBvcnQNCj4gc2V0IE9wY29kZSBjYW4gYmUgbW9kaWZpZWQgdG8gcmVmbGVj dCB0aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHLg0KPiA+DQo+ID4gMykgV2hlbiBhc2tpbmcgZm9y IG11bHRpcGxlIG9mIHRob3NlIHBvcnQtc2V0cywgb25lIG1heSBlbmQtdXAgd2l0aCBwb3J0IHNl dHMNCj4gb24gZGlmZmVyZW50DQo+ID4gICAgIGV4dGVybmFsIElQIGFkZHJlc3Nlcy4gQWxzbywg d2hlbiBwb3J0cyBhcmUgcnVubmluZyBsb3csIGNvbm5lY3Rpb25zDQo+IG1heSBiZSBkZWxheWVk IHVudGlsIGEgbmV3IHBvcnQgc2V0IGlzIGFjcXVpcmVkLg0KPiA+ICAgIFRoZXJlIGFyZSBwcm9i bGVtcyBhc3NvY2lhdGVkIHdpdGggdGhlc2Ugc2NlbmFyaWkgYW5kIHRoZXkgc2hvdWxkIGJlDQo+ IGFuYWx5emVkLg0KPiBJbiBzZWN0aW9uIDMuMywgd2UgaGF2ZSBjbGVhcmx5IHNheSB0aGF0IHRo ZSBzYW1lIGV4dGVybmFsIGFkZHJlc3Mgc2hvdWxkIGJlDQo+IGFzc2lnbmVkIHRvIG9uZSBzdWJz Y3JpYmVyIGluIG11bHRpcGxlIHBvcnQgc2V0IHJlcXVlc3RzLiBBbmQgd2UgYWxzbw0KPiByZWNv bW1lbmQgdGhhdCB0aGUgc2VydmVyIGFzc2lnbiB0aGUgbWF4aW11bSBhbGxvd2VkIHBvcnQgc2V0 IGluIGEgc2luZ2xlDQo+IHJlcXVlc3QuIEJ1dCBJIGRvbid0IHRoaW5rIHRoZSBwcm90b2NvbCBp dHNlbGYgc2hvdWxkIHJlc3RyaWN0IHRoaXMgY2FwYWJpbGl0eS4gSXQgaXMNCj4gc3RpbGwgYSBk ZXBsb3ltZW50IGNob2ljZS4NCj4gPg0KPiA+ICAgIEluIHRoZSBlbmQsIHRoZXJlIGlzIGEgdHJh ZGUtb2ZmIGJldHdlZW4gZmxleGliaWxpdHkgYW5kIGNvbXBsZXhpdHkuIFRoZQ0KPiBxdWVzdGlv bg0KPiA+ICAgIGlzLCBpbiBSRUFMIG9wZXJhdGlvbiwgaXMgdGhlIGZsZXhpYmlsaXR5IG9mIGhh dmluZyBtdWx0aXBsZSBwb3J0IHNldHMNCj4gbmVlZGVkPw0KPiA+ICAgIEluIENHTiBkZXBsb3lt ZW50cyBJJ20gZmFtaWxpYXIgd2l0aCwgSVNQcyBhc3NpZ24gYSBmaXhlZCBhbW91bnQgb2YgcG9y dHMNCj4gcGVyIHVzZXIgdGhhdCBzaG91bGQgYmUNCj4gPiAgICBlbm91Z2ggZm9yIGV2ZXJ5Ym9k eSBhbmQgZG9uJ3QgY2hhbmdlIGl0LiBJZiB0aGlzIGlzIG5vdCBnb29kIGVub3VnaCBmb3IgYQ0K PiBwYXJ0aWN1bGFyIHVzZXIsDQo+ID4gICAgdGhlIHNpbXBsZXN0IHRoaW5nIHRvIGRvIGlzIHRv IHRha2UgaGltL2hlciBvdXQgb2YgdGhlIENHTiBwb29sIGFuZCBhc3NpZ24NCj4gaGltL2hlciBh IGZ1bGwgSVB2NCBhZGRyZXNzLg0KPiA+ICAgIEluIG90aGVyIHdvcmRzLCBJIHRoaW5rIHRoYXQg dGhpcyBub3Rpb24gb2YgIGhhbmRpbmcgb3V0IG11bHRpcGxlIHBvcnQgc2V0cw0KPiB3aXRoIHBz ZXVkby1yYW5kb20gcG9ydHMNCj4gPiAgICBpcyB2YXN0bHkgb3ZlciBlbmdpbmVlcmVkLg0KPiBU aGUgc2FtZSB3aXRoIHRoZSBhYm92ZSBvbmUuDQo+IA0KPiBCZXN0IHdpc2hlcw0KPiBRaW9uZw0K PiA+DQo+ID4gQWxhaW4uDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBKYW4gMiwgMjAxMywg YXQgNjozNCBQTSwgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4N Cj4gd3JvdGU6DQo+ID4NCj4gPj4gSGVsbG8sDQo+ID4+DQo+ID4+IFRoaXMgZW1haWwgc3RhcnRz IGEgMi13ZWVrIGNvbnNlbnN1cyBjYWxsIG9uIGFkb3B0aW5nDQo+ID4+DQo+ID4+ICAgIFRpdGxl ICAgICA6IFVzaW5nIFBDUCBUbyBDb29yZGluYXRlIEJldHdlZW4gdGhlIENHTiBhbmQgSG9tZQ0K PiBHYXRld2F5DQo+ID4+ICAgIEF1dGhvcihzKSA6IFEuIFN1biBldCBhbA0KPiA+PiAgICBGaWxl bmFtZSAgOiBkcmFmdC10c291LXBjcC1uYXRjb29yZC0wOS50eHQNCj4gPj4gICAgVVJMICAgICAg IDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXRzb3UtcGNwLW5hdGNvb3JkLTA5LnR4 dA0KPiA+Pg0KPiA+PiBQbGVhc2UgcmVhZCB0aGUgY3VycmVudCByZXZpc2lvbiBhbmQgc3RhdGUg eW91IG9waW5pb24gZWl0aGVyIGZvciBvcg0KPiA+PiBhZ2FpbnN0IGFkb3B0aW9uIChhbmQgd2l0 aCByZWFzb25pbmcgd2h5KSBpbiB0aGUgbWFpbGluZyBsaXN0Lg0KPiA+Pg0KPiA+PiBUaGUgY2Fs bCBmb3IgYWRvcHRpb24gZW5kcyAxNnRoIEphbnVhcnkgMjAxMy4NCj4gPj4NCj4gPj4gVGhhbmtz LA0KPiA+Pg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IHBjcCBtYWlsaW5nIGxpc3QNCj4gPiBwY3BAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGNwIG1haWxpbmcg bGlzdA0KPiBwY3BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wY3ANCg== From xiechf01@gmail.com Sun Jan 6 00:41:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34DD21F87D2 for ; Sun, 6 Jan 2013 00:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFX52I-9ai+4 for ; Sun, 6 Jan 2013 00:41:12 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id 518FA21F8808 for ; Sun, 6 Jan 2013 00:41:12 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so18155967vby.33 for ; Sun, 06 Jan 2013 00:41:11 -0800 (PST) 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=0HudTz8SZatEZv863FzyVMa09O60moV9tLfA2OIV1xo=; b=Suy1EzagpvXqNFLtVSpYXIp7xn4K/cjzLR2frMzHKYTfsQRbvAbR6DIMLmlNFPk/at U8p8pXNZ47ac/MlTx9qphecT3OWrUvRQ3yr7Ji/rxj/MIBACA+cn0FewTYOyIAxC0cd+ rl+id8v0ntLskZekfbG72H2jHh87IkOxJ9SdPHgPIZVZq+LNd5wf1Sv+mJMHhlhLGw+i 46wxIm5HjJWsEQgdv/I3D5BcktAmXK2sPBQ8yrcomFWrhDTDr7VyLewQt43hDbHJvjDY agVr8P7xzEcCyNzFSyxeP3VBbCakit26QfCcvDtgq4Yj72k+pZ9yiUxCpjoz00KbY98S aw1g== MIME-Version: 1.0 Received: by 10.220.151.83 with SMTP id b19mr79442750vcw.25.1357461671664; Sun, 06 Jan 2013 00:41:11 -0800 (PST) Received: by 10.220.146.71 with HTTP; Sun, 6 Jan 2013 00:41:11 -0800 (PST) In-Reply-To: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <26D7AE14-FA24-4119-9F9E-2971E6C0C012@gmail.com> Date: Sun, 6 Jan 2013 16:41:11 +0800 Message-ID: From: Chongfeng Xie To: pcp@ietf.org Content-Type: multipart/alternative; boundary=f46d0434bf1ebc5ca704d29aac96 Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 08:41:14 -0000 --f46d0434bf1ebc5ca704d29aac96 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable i support the adoption of this document. Compared with the existing pcp-base, I think pcp-natcood is more effective and efficient for port-set allocation, thanks Chongfeng Xie ---------- Forwarded message ---------- > From: Zhangdacheng (Dacheng) 'cvml', 'zhangdacheng@huawei.com');>> > Date: Sun, Jan 6, 2013 at 9:49 AM > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > To: "pcp@ietf.org " < > pcp@ietf.org > > > > I agree the work can bring some benefit (e.g., simplify the operations) i= n > certain scenarios. So, support the adoption of this work if authors would > like to keep improving it. > > > -----Original Message----- > > From: pcp-bounces@ietf.org 'pcp-bounces@ietf.org');> [mailto:pcp-bounces@ietf.org 'cvml', 'pcp-bounces@ietf.org');>] On Behalf Of > > bingxuere > > Sent: Friday, January 04, 2013 9:53 PM > > To: Alain Durand > > Cc: pcp@ietf.org > > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > > > Hi Alain, > > > > Please see my comments inline below... > > > > On 2013-1-4, at =C9=CF=CE=E712:39, Alain Durand > > wrote: > > > > > I do not support the adoption of this document as wg item, for > essentially > > three reasons. > > > > > > 1) This functionality can be achieved very simply on a CPE by sending > multiple > > PCP requests. > > > This would remove the complexity of port set indexes, max port se= t, > > etc... > > One port set PCP request is obviously better than multiple individual P= CP > > requests. It can not only save the bandwidth of massive PCP requests, > reduce > > the mapping entries in PCP server, and greatly reduce the burden of PCP > server > > dealing with individual requests in a short time,etc. Considering one > subscriber > > will get a port set with 2048 ports, this simple port set Opcode can > save 2047 > > requests for one time. I don't see why we do not use it. > > > > > > 2) There are already several DHCP (v4 and v6) options being defined t= o > > address this very problem, > > > and my understanding is that there is an attempt at converging > those in > > DHC & Softwires. > > > If a PCP option absolutely must be defined as well (which honestl= y > I > > doubt), I would hope > > > it would be defined exactly the same way as the yet-to-be-defined > final > > DHCP option. > > 1) Using PCP is quite helpful in cases: a. An operator with no DHCP > server or > > not enable to upgrade to support this new feature b. An operator > planning to > > migrate the dslite AFTR to behave as a port range router. Just as we ca= n > have > > both RFC6334 for dhcp option and RFC6519 for radius option, it is > totally a > > deployment choice. Besides, this port set Opcode can also be applied to > other > > use cases as Reinaldo has pointed out. > > 2) Adopting a WG item does not mean the work has finished, rather, we > just > > provide a starting point for which the WG will decide which way to go. > This is > > the most efficient way for the sake of this work, and we all see how > PCP-base > > has improved from -01 to -29. In the same way, the specific format of > this port > > set Opcode can be modified to reflect the consensus from the WG. > > > > > > 3) When asking for multiple of those port-sets, one may end-up with > port sets > > on different > > > external IP addresses. Also, when ports are running low, > connections > > may be delayed until a new port set is acquired. > > > There are problems associated with these scenarii and they should = be > > analyzed. > > In section 3.3, we have clearly say that the same external address > should be > > assigned to one subscriber in multiple port set requests. And we also > > recommend that the server assign the maximum allowed port set in a sing= le > > request. But I don't think the protocol itself should restrict this > capability. It is > > still a deployment choice. > > > > > > In the end, there is a trade-off between flexibility and > complexity. The > > question > > > is, in REAL operation, is the flexibility of having multiple port > sets > > needed? > > > In CGN deployments I'm familiar with, ISPs assign a fixed amount o= f > ports > > per user that should be > > > enough for everybody and don't change it. If this is not good > enough for a > > particular user, > > > the simplest thing to do is to take him/her out of the CGN pool an= d > assign > > him/her a full IPv4 address. > > > In other words, I think that this notion of handing out multiple > port sets > > with pseudo-random ports > > > is vastly over engineered. > > The same with the above one. > > > > Best wishes > > Qiong > > > > > > Alain. > > > > > > > > > > > > > > > On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) < > repenno@cisco.com > > > wrote: > > > > > >> Hello, > > >> > > >> This email starts a 2-week consensus call on adopting > > >> > > >> Title : Using PCP To Coordinate Between the CGN and Home > > Gateway > > >> Author(s) : Q. Sun et al > > >> Filename : draft-tsou-pcp-natcoord-09.txt > > >> URL : > http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > >> > > >> Please read the current revision and state you opinion either for or > > >> against adoption (and with reasoning why) in the mailing list. > > >> > > >> The call for adoption ends 16th January 2013. > > >> > > >> Thanks, > > >> > > > > > > > > > _______________________________________________ > > > pcp mailing list > > > pcp@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcp > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --f46d0434bf1ebc5ca704d29aac96 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable i support the adoption of this document. Compared wi= th the existing pcp-base, I think pcp-natcood is more effective and efficie= nt for port-set allocation, 
thanks

Chongfeng Xi= e

---------- Forwarded messa= ge ----------
From: Zhangdacheng (Dacheng)= <zhangdacheng@huawei.com= >
Date: Sun, Jan 6, 2013 at 9:49 AM
Subject: Re: [pcp] WG Call for Adoptio= n: draft-tsou-pcp-natcoord-09
To: "pcp@ietf.org&q= uot; <pcp@ietf.org>


I agree the work can bring some benefit (e.g., simplify the operati= ons) in certain scenarios. So, support the adoption of this work if authors= would like to keep improving it.

> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> bingxuere
> Sent: Friday, January 04, 2013 9:53 PM
> To: Alain Durand
> Cc: pcp@ietf.org
> Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 >
> Hi Alain,
>
> Please see my comments inline below...
>
> On 2013-1-4, at =C9=CF=CE=E712:39, Alain Durand <adurand@juniper.net> wrote:
>
> > I do not support the adoption of this document as wg item, for es= sentially
> three reasons.
> >
> > 1) This functionality can be achieved very simply on a CPE by sen= ding multiple
> PCP requests.
> >     This would remove the complexity of port set indexe= s, max port set,
> etc...
> One port set PCP request is obviously better than multiple individual = PCP
> requests. It can not only save the bandwidth of massive PCP requests, = reduce
> the mapping entries in PCP server, and greatly reduce the burden of PC= P server
> dealing with individual requests in a short time,etc. Considering one = subscriber
> will get a port set with 2048 ports, this simple port set Opcode can s= ave 2047
> requests for one time. I don't see why we do not use it.
> >
> > 2) There are already several DHCP (v4 and v6) options being defin= ed to
> address this very problem,
> >     and my understanding is that there is an attempt at= converging those in
> DHC & Softwires.
> >     If a PCP option absolutely must be defined as well = (which honestly I
> doubt), I would hope
> >     it would be defined exactly the same way as the yet= -to-be-defined final
> DHCP option.
> 1) Using PCP is quite helpful in cases: a. An operator with no DHCP se= rver or
> not enable to upgrade to support this new feature b. An operator plann= ing to
> migrate the dslite AFTR to behave as a port range router. Just as we c= an have
> both RFC6334 for dhcp option and RFC6519 for radius option, it is tota= lly a
> deployment choice. Besides, this port set Opcode can also be applied t= o other
> use cases as Reinaldo has pointed out.
> 2) Adopting a WG item does not mean the work has finished, rather, we = just
> provide a starting point for which the WG will decide which way to go.= This is
> the most efficient way for the sake of this work, and we all see how P= CP-base
> has improved from -01 to -29. In the same way, the specific format of = this port
> set Opcode can be modified to reflect the consensus from the WG.
> >
> > 3) When asking for multiple of those port-sets, one may end-up wi= th port sets
> on different
> >     external IP addresses. Also, when ports are running= low, connections
> may be delayed until a new port set is acquired.
> >    There are problems associated with these scenarii an= d they should be
> analyzed.
> In section 3.3, we have clearly say that the same external address sho= uld be
> assigned to one subscriber in multiple port set requests. And we also<= br> > recommend that the server assign the maximum allowed port set in a sin= gle
> request. But I don't think the protocol itself should restrict thi= s capability. It is
> still a deployment choice.
> >
> >    In the end, there is a trade-off between flexibility= and complexity. The
> question
> >    is, in REAL operation, is the flexibility of having = multiple port sets
> needed?
> >    In CGN deployments I'm familiar with, ISPs assig= n a fixed amount of ports
> per user that should be
> >    enough for everybody and don't change it. If thi= s is not good enough for a
> particular user,
> >    the simplest thing to do is to take him/her out of t= he CGN pool and assign
> him/her a full IPv4 address.
> >    In other words, I think that this notion of  ha= nding out multiple port sets
> with pseudo-random ports
> >    is vastly over engineered.
> The same with the above one.
>
> Best wishes
> Qiong
> >
> > Alain.
> >
> >
> >
> >
> > On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) <repenno@cisco.com>
> wrote:
> >
> >> Hello,
> >>
> >> This email starts a 2-week consensus call on adopting
> >>
> >>    Title     : Using PCP To Coordinate Be= tween the CGN and Home
> Gateway
> >>    Author(s) : Q. Sun et al
> >>    Filename  : draft-tsou-pcp-natcoord-09.txt<= br> > >>    URL       : http://too= ls.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
> >>
> >> Please read the current revision and state you opinion either= for or
> >> against adoption (and with reasoning why) in the mailing list= .
> >>
> >> The call for adoption ends 16th January 2013.
> >>
> >> Thanks,
> >>
> >
> >
> > _______________________________________________
> > pcp mailing list
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp



--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beiji= ng Research Institude


Open source code:
lightweight 4over6: <= i>http= ://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f46d0434bf1ebc5ca704d29aac96-- From simon.perreault@viagenie.ca Mon Jan 7 01:44:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6421F869C for ; Mon, 7 Jan 2013 01:44:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vnkIeM+-nFX for ; Mon, 7 Jan 2013 01:44:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4667321F868F for ; Mon, 7 Jan 2013 01:44:43 -0800 (PST) Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 97FB140110 for ; Mon, 7 Jan 2013 04:44:42 -0500 (EST) Message-ID: <50EA9909.4040401@viagenie.ca> Date: Mon, 07 Jan 2013 10:44:41 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> In-Reply-To: <037201cdeae9$b4109e80$1c31db80$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:44:45 -0000 Dan, Just trying to provide some more clarification... Le 2013-01-05 03:09, Dan Wing a écrit : > Can it work with a CGN? Depends what you mean by CGN. In the current draft version (-09), MAP_PORT_SET assumes that the NAT never changes port numbers. The NAT MAY change addresses. It is possible to remove that assumption. We are planning to do that after the call for adoption. Then MAP_PORT_SET will be exactly like MAP, except that it works with port *sets* (obviously). > With the current document text, I cannot understand what sort of > deployments where NATCOORD can or cannot be used. Until I understand > that, I can't decide if this document is a good idea or a bad idea. Hopefully the above explanation of the protocol will be sufficient for you to figure out its applicability. :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon Jan 7 01:57:20 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B900A21F867D for ; Mon, 7 Jan 2013 01:57:20 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uS6967J+NXb for ; Mon, 7 Jan 2013 01:57:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E85BD21F865D for ; Mon, 7 Jan 2013 01:57:15 -0800 (PST) Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C62B340110 for ; Mon, 7 Jan 2013 04:57:14 -0500 (EST) Message-ID: <50EA9BF9.2010302@viagenie.ca> Date: Mon, 07 Jan 2013 10:57:13 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> In-Reply-To: <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 09:57:20 -0000 Salut Alain, Le 2013-01-03 17:39, Alain Durand a écrit : > 1) This functionality can be achieved very simply on a CPE by sending multiple PCP requests. > This would remove the complexity of port set indexes, max port set, etc... One reason for MAP_PORT_SET is scalability. - On the PCP client: you don't want to deal with e.g. 2048 MAP requests, then 2048 refreshes every X hours, etc. - On the NAT: it allows allocating one single "set" entry, which may very well occupy less state memory than 2048 individual map entries. Another reason is to get a contiguous chunk. There is no guarantee that multiple MAP requests will be able to obtain a contiguous chunk of port numbers. Some applications may find this property necessary (e.g. SIP clients). > 2) There are already several DHCP (v4 and v6) options being defined to address this very problem, No. The DHCP options solve the very specific problem of provisioning a port set to a subscriber, in e.g. the LW4o6 use case. MAP_PORT_SET is different. The best way to see it is as an extension to MAP: it allows to map port sets with PCP instead of single port numbers. It is applicable to LW4o6, but also in other use cases: applications that need chunks of continuous ports, Reinaldo's firewall use case, etc. > 3) When asking for multiple of those port-sets, one may end-up with port sets on different > external IP addresses. The MAP opcode has the same concern, and the same answer applies. Let us know if you think it should be made clearer in the text. > Also, when ports are running low, connections may be delayed until a new port set is acquired. This is up to the PCP client to figure out. The same concern applies to the MAP opcode. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon Jan 7 02:03:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA71621F879D for ; Mon, 7 Jan 2013 02:03:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3JnEL9T2ORO for ; Mon, 7 Jan 2013 02:03:05 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 10A4D21F84A1 for ; Mon, 7 Jan 2013 02:03:05 -0800 (PST) Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4A4ED40110; Mon, 7 Jan 2013 05:03:04 -0500 (EST) Message-ID: <50EA9D57.9050805@viagenie.ca> Date: Mon, 07 Jan 2013 11:03:03 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alper Yegin References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> In-Reply-To: <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 10:03:05 -0000 Le 2013-01-04 11:06, Alper Yegin a écrit : > So, the main concern you have is, if the server has an outstanding > message to send to the client and if there is no live SA, then the > server has to queue the message until the SA is generated. The > queueing of that message is your concern. > > How is that such a big concern to the extent that we should define an > inadequately secured protocol at IETF? I don't get that. The protocol > allowing some of the server-side messages fly w/o integrity > protection is a "glaring (security) hole". IMHO it would be nice if we didn't need to add such a queue on the server. I've said that before. Now, Sam has explained how he sees no security hole in sending server-initiated messages in the clear. I also am uneasy about this, but I cannot come up with an attack. Calling this a "glaring hole" is fine, but explaining the attack you see would help further the discussion. Unless there's an attack, it actually makes implementation easier and the server more scalable. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adurand@juniper.net Mon Jan 7 07:57:28 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90421F8614 for ; Mon, 7 Jan 2013 07:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q0I4BuY4cEm for ; Mon, 7 Jan 2013 07:57:27 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8ED21F842F for ; Mon, 7 Jan 2013 07:57:27 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUOrwZyKVGjP3P8++qk8sY6HVLC2ZnXXw@postini.com; Mon, 07 Jan 2013 07:57:27 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Jan 2013 07:54:55 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 7 Jan 2013 07:54:55 -0800 Received: from CO9EHSOBE035.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 7 Jan 2013 08:03:08 -0800 Received: from mail219-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE035.bigfish.com (10.236.130.98) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 Jan 2013 15:54:54 +0000 Received: from mail219-co9 (localhost [127.0.0.1]) by mail219-co9-R.bigfish.com (Postfix) with ESMTP id CB5041C0149 for ; Mon, 7 Jan 2013 15:54:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -3 X-BigFish: PS-3(zz98dI9371I1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail219-co9 (localhost.localdomain [127.0.0.1]) by mail219-co9 (MessageSwitch) id 1357574093313232_25013; Mon, 7 Jan 2013 15:54:53 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.233]) by mail219-co9.bigfish.com (Postfix) with ESMTP id 403F82004C; Mon, 7 Jan 2013 15:54:53 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 7 Jan 2013 15:54:50 +0000 Received: from BL2PRD0510MB386.namprd05.prod.outlook.com ([169.254.11.99]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0245.002; Mon, 7 Jan 2013 15:54:47 +0000 From: Alain Durand To: Simon Perreault Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG/IWNhS315/EentG942BWJKpg3z2QAgAXY1ICAAGPoAA== Date: Mon, 7 Jan 2013 15:55:49 +0000 Message-ID: <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> In-Reply-To: <50EA9BF9.2010302@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <59970843CC0C5C49AB1A94F5B6EF3CFC@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%VIAGENIE.CA$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:57:28 -0000 On Jan 7, 2013, at 1:57 AM, Simon Perreault wrote: >=20 >> 2) There are already several DHCP (v4 and v6) options being defined to a= ddress this very problem, >=20 > No. >=20 > The DHCP options solve the very specific problem of provisioning a port s= et to a subscriber, in e.g. the LW4o6 use case. >=20 > MAP_PORT_SET is different. The best way to see it is as an extension to M= AP: it allows to map port sets with PCP instead of single port numbers. It = is applicable to LW4o6, but also in other use cases: applications that need= chunks of continuous ports, Reinaldo's firewall use case, etc. I think this is the crux of the issue. The draft needs to articulate exactl= y what the use case is and why other existing technologies are not sufficie= nt. IMHO, simply saying we do not have a DHCP server in the target deployme= nt does not cut it. You will need to introduce new software anyway (the PCP= server) in your architecture, so the only difference between PCP & DHCP is= the format of the bits on the wire. >=20 >> 3) When asking for multiple of those port-sets, one may end-up with port= sets on different >> external IP addresses. >=20 > The MAP opcode has the same concern, and the same answer applies. Let us = know if you think it should be made clearer in the text. Yes. >=20 >> Also, when ports are running low, connections may be delayed until a new= port set is acquired. >=20 > This is up to the PCP client to figure out. The same concern applies to t= he MAP opcode. Not sure. with MAP opcode, the logic is that it is the user application tha= t requests the port, in doing so, it knows that it may have to wait a littl= e. With the option described in the draft, the logic is that the CPE makes the= request for an additional set of ports, unbeknown to the application... Alain. From simon.perreault@viagenie.ca Mon Jan 7 08:13:54 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C6C21F8960 for ; Mon, 7 Jan 2013 08:13:54 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b04zQsTRMZ-f for ; Mon, 7 Jan 2013 08:13:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C521F8967 for ; Mon, 7 Jan 2013 08:13:53 -0800 (PST) Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6EE944039E; Mon, 7 Jan 2013 11:13:52 -0500 (EST) Message-ID: <50EAF43F.1020701@viagenie.ca> Date: Mon, 07 Jan 2013 17:13:51 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alain Durand References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com> In-Reply-To: <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:13:54 -0000 Le 2013-01-07 16:55, Alain Durand a écrit : >>> Also, when ports are running low, connections may be delayed until a new port set is acquired. >> >> This is up to the PCP client to figure out. The same concern applies to the MAP opcode. > > Not sure. with MAP opcode, the logic is that it is the user application that requests the port, in doing so, it knows that it may have to wait a little. > With the option described in the draft, the logic is that the CPE makes the request for an additional set of ports, unbeknown to the application... There is no such difference. A MAP_PORT_SET request may be made either by an individual application or by the operating system, just like a MAP request. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adurand@juniper.net Mon Jan 7 08:22:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A259C21F8525 for ; Mon, 7 Jan 2013 08:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnGxM53dndWG for ; Mon, 7 Jan 2013 08:22:25 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5EB21F86A6 for ; Mon, 7 Jan 2013 08:22:25 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUOr2QBg1aJQOk6D3Sx7GdAeeO8D9wQ9c@postini.com; Mon, 07 Jan 2013 08:22:25 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Jan 2013 08:18:33 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 7 Jan 2013 08:18:33 -0800 Received: from CO9EHSOBE018.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 7 Jan 2013 08:26:46 -0800 Received: from mail28-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 Jan 2013 16:18:32 +0000 Received: from mail28-co9 (localhost [127.0.0.1]) by mail28-co9-R.bigfish.com (Postfix) with ESMTP id AC73F2203B9 for ; Mon, 7 Jan 2013 16:18:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zz98dI9371Ic89bh936eI1432Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail28-co9 (localhost.localdomain [127.0.0.1]) by mail28-co9 (MessageSwitch) id 135757550090791_8105; Mon, 7 Jan 2013 16:18:20 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.233]) by mail28-co9.bigfish.com (Postfix) with ESMTP id 095153C0051; Mon, 7 Jan 2013 16:18:20 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 7 Jan 2013 16:18:14 +0000 Received: from BL2PRD0510MB386.namprd05.prod.outlook.com ([169.254.11.99]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0245.002; Mon, 7 Jan 2013 16:18:07 +0000 From: Alain Durand To: Simon Perreault Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG/IWNhS315/EentG942BWJKpg3z2QAgAXY1ICAAGPoAIAABVKAgAABMoA= Date: Mon, 7 Jan 2013 16:19:08 +0000 Message-ID: <82256834F867D44BBB8E49E40D5448BB065A64F2@BL2PRD0510MB386.namprd05.prod.outlook.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EAF43F.1020701@viagenie.ca> In-Reply-To: <50EAF43F.1020701@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%VIAGENIE.CA$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:22:26 -0000 On Jan 7, 2013, at 8:13 AM, Simon Perreault w= rote: > Le 2013-01-07 16:55, Alain Durand a =E9crit : >>>> Also, when ports are running low, connections may be delayed until a n= ew port set is acquired. >>>=20 >>> This is up to the PCP client to figure out. The same concern applies to= the MAP opcode. >>=20 >> Not sure. with MAP opcode, the logic is that it is the user application = that requests the port, in doing so, it knows that it may have to wait a li= ttle. >> With the option described in the draft, the logic is that the CPE makes = the request for an additional set of ports, unbeknown to the application... >=20 > There is no such difference. A MAP_PORT_SET request may be made either by= an individual application or by the operating system, just like a MAP requ= est. In theory, yes you are correct. In practice, it depends on the domain of ap= plication. If it is for lw4over6 (or similar), then the scenario I describe= is the prevalent case. Alain.= From simon.perreault@viagenie.ca Mon Jan 7 08:23:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EFC11E80AD for ; Mon, 7 Jan 2013 08:23:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STW+cLzzit1s for ; Mon, 7 Jan 2013 08:23:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D38CF11E809C for ; Mon, 7 Jan 2013 08:23:45 -0800 (PST) Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2816A4039E; Mon, 7 Jan 2013 11:23:45 -0500 (EST) Message-ID: <50EAF690.4080505@viagenie.ca> Date: Mon, 07 Jan 2013 17:23:44 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alain Durand References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <82256834F867D44BBB8E49E40D5448BB065A432B@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EAF43F.1020701@viagenie.ca> <82256834F867D44BBB8E49E40D5448BB065A64F2@BL2PRD0510MB386.namprd05.prod.outlook.com> In-Reply-To: <82256834F867D44BBB8E49E40D5448BB065A64F2@BL2PRD0510MB386.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:23:47 -0000 Le 2013-01-07 17:19, Alain Durand a écrit : >> There is no such difference. A MAP_PORT_SET request may be made either by an individual application or by the operating system, just like a MAP request. > > In theory, yes you are correct. In practice, it depends on the domain of application. If it is for lw4over6 (or similar), then the scenario I describe is the prevalent case. Absolutely right. And I'd like to emphasize that we envision multiple usages for the MAP_PORT_SET opcode, one of which is indeed LW4o6. Does this need to be clarified in the text? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Mon Jan 7 08:54:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7880F21F88B5 for ; Mon, 7 Jan 2013 08:54:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg8JBRPjYHST for ; Mon, 7 Jan 2013 08:54:17 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8821F88B0 for ; Mon, 7 Jan 2013 08:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1861; q=dns/txt; s=iport; t=1357577657; x=1358787257; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=LeOj0PSqBtkSvQ+8EovkHPUXBU2hlo8Fe8Y28cNfONQ=; b=OTVEzRQHSCxK+HVaDwYKMIj0mTbOUGxyAommZd4VoUkiE6yC8muQ23yF XUshJXuV2DkIJQOxmEiqZ8VGq8MEoHhbx7TFez2oZu+5QD0Dn137EmeZn R640bD4ZgrvruhjOVhma8hWGlDT4Pd7tau6V9ix+YNIcjDbMhLBo1pGkp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUHAET96lCrRDoG/2dsb2JhbABFg0e6DRZzgh4BAQEDAQgCE1UMBwEDAgkRBAEBKAcZLQkIAgQBEgsFiAEFtWCRFQOILDWFHIgOkEmDFQ X-IronPort-AV: E=Sophos;i="4.84,424,1355097600"; d="scan'208";a="65601931" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 07 Jan 2013 16:54:17 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r07GsHWR011046; Mon, 7 Jan 2013 16:54:17 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> In-Reply-To: <50EA9909.4040401@viagenie.ca> Date: Mon, 7 Jan 2013 08:54:17 -0800 Message-ID: <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGsXrIihwxD8rvFf/g369xONMd8VgJCt95bAuLT/QEB2BZBegGmtVEOAwUpJ06YI+TU0A== Content-Language: en-us Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:54:18 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Simon Perreault > Sent: Monday, January 07, 2013 1:45 AM > To: pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 >=20 > Dan, >=20 > Just trying to provide some more clarification... >=20 > Le 2013-01-05 03:09, Dan Wing a =E9crit : > > Can it work with a CGN? >=20 > Depends what you mean by CGN. Previously, I cited draft-ietf-behave-lsn-requirements, as that is perhaps the best citation the industry has for "what is a CGN". > In the current draft version (-09), MAP_PORT_SET assumes that the NAT > never changes port numbers. The NAT MAY change addresses. Can that be made clearer in the document, *please*. > It is possible to remove that assumption. We are planning to do that > after the call for adoption. Then MAP_PORT_SET will be exactly like = MAP, > except that it works with port *sets* (obviously). Oh, so with that change, NATCOORD could work with CGN. > > With the current document text, I cannot understand what sort of > > deployments where NATCOORD can or cannot be used. Until I = understand > > that, I can't decide if this document is a good idea or a bad idea. >=20 > Hopefully the above explanation of the protocol will be sufficient for > you to figure out its applicability. :) Another question: what is the relationship between = draft-tsou-pcp-natcoord and draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option? I=20 saw there was a request to adopt draft-sun-dhc-port-set-option in DHC, and lots of discussion. I have not seen a discussion of using DHCP versus PCP for this functionality, which concluded that PCP was the better choice. Did=20 that discussion occur? If so, can we get a pointer to that=20 discussion? -d From dwing@cisco.com Mon Jan 7 08:56:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8801521F84D0 for ; Mon, 7 Jan 2013 08:56:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1F1CC6t5YMC for ; Mon, 7 Jan 2013 08:56:51 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B3C5821F8488 for ; Mon, 7 Jan 2013 08:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2775; q=dns/txt; s=iport; t=1357577811; x=1358787411; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=h65rnXIXmwMF9841sB7Whdglu+4TiiPfrX3X6LNDEFw=; b=TUUo0jAelgzxt1VH9O965AZn22ENW8s4TMSQ3yD3v5GIad8tUOcGvNXR 1YXvtfmRV2Hnyrn/7Z6gGCNx20DEP8pzhN5XJkXtKN8/vi4sx59y4vH7a DcU+qbW47FkdbK7mYfzQ5Cd6eJRLccyYRY6wrSPgJMsN4UPjqSlxloucL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUHAET96lCrRDoI/2dsb2JhbABFg0e6DRZzgh4BAQEDAQEBAQUCEwpHFwEDAgkRBAEBKAcZDh8JCAIEARILBYgBBQ21U5EVA4gsNYUciA6BHI8tgxU X-IronPort-AV: E=Sophos;i="4.84,424,1355097600"; d="scan'208";a="65602088" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 07 Jan 2013 16:56:51 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r07GupWO009712; Mon, 7 Jan 2013 16:56:51 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> In-Reply-To: <50EA9BF9.2010302@viagenie.ca> Date: Mon, 7 Jan 2013 08:56:51 -0800 Message-ID: <023601cdecf7$fd33cc80$f79b6580$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJCt95bsnCw7XkdTvDDrAOqjgdTlwHaRCMBAe/BLgeXNi9ykA== Content-Language: en-us Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:56:52 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Simon Perreault > Sent: Monday, January 07, 2013 1:57 AM > To: pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 >=20 > Salut Alain, >=20 > Le 2013-01-03 17:39, Alain Durand a =E9crit : > > 1) This functionality can be achieved very simply on a CPE by = sending > multiple PCP requests. > > This would remove the complexity of port set indexes, max port > set, etc... >=20 > One reason for MAP_PORT_SET is scalability. >=20 > - On the PCP client: you don't want to deal with e.g. 2048 MAP = requests, > then 2048 refreshes every X hours, etc. >=20 > - On the NAT: it allows allocating one single "set" entry, which may > very well occupy less state memory than 2048 individual map entries. >=20 >=20 > Another reason is to get a contiguous chunk. There is no guarantee = that > multiple MAP requests will be able to obtain a contiguous chunk of = port > numbers. Some applications may find this property necessary (e.g. SIP > clients). By SIP, do you mean RTP? If so, it seems draft-boucadair-pcp-rtp-rtcp=20 provides that functionality. draft-tsou-pcp-natcoord could, too, if the size of the port-set is two ports, I guess? Which should a client or a server use? -d > > 2) There are already several DHCP (v4 and v6) options being defined = to > address this very problem, >=20 > No. >=20 > The DHCP options solve the very specific problem of provisioning a = port > set to a subscriber, in e.g. the LW4o6 use case. >=20 > MAP_PORT_SET is different. The best way to see it is as an extension = to > MAP: it allows to map port sets with PCP instead of single port = numbers. > It is applicable to LW4o6, but also in other use cases: applications > that need chunks of continuous ports, Reinaldo's firewall use case, = etc. >=20 > > 3) When asking for multiple of those port-sets, one may end-up with > port sets on different > > external IP addresses. >=20 > The MAP opcode has the same concern, and the same answer applies. Let = us > know if you think it should be made clearer in the text. >=20 > > Also, when ports are running low, connections may be delayed until a > new port set is acquired. >=20 > This is up to the PCP client to figure out. The same concern applies = to > the MAP opcode. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Mon Jan 7 09:04:33 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26AD21F88D8 for ; Mon, 7 Jan 2013 09:04:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDWhCrTplykO for ; Mon, 7 Jan 2013 09:04:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91521F88CA for ; Mon, 7 Jan 2013 09:04:32 -0800 (PST) Received: from porto.nomis80.org (85-169-40-152.rev.numericable.fr [85.169.40.152]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AC2B24039E; Mon, 7 Jan 2013 12:04:31 -0500 (EST) Message-ID: <50EB001E.3030003@viagenie.ca> Date: Mon, 07 Jan 2013 18:04:30 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <023601cdecf7$fd33cc80$f79b6580$@cisco.com> In-Reply-To: <023601cdecf7$fd33cc80$f79b6580$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:04:33 -0000 Le 2013-01-07 17:56, Dan Wing a écrit : >> Another reason is to get a contiguous chunk. There is no guarantee that >> multiple MAP requests will be able to obtain a contiguous chunk of port >> numbers. Some applications may find this property necessary (e.g. SIP >> clients). > > By SIP, do you mean RTP? If so, it seems draft-boucadair-pcp-rtp-rtcp > provides that functionality. draft-tsou-pcp-natcoord could, too, if > the size of the port-set is two ports, I guess? Which should a client > or a server use? Right, but I was thinking about a slightly different use case than draft-boucadair: some applications just like to get ownership of a chunk of ports when they start. This is mostly an implementation artifact, not really a protocol constraint. I had SIP apps in mind, but I guess the same could be said of BitTorrent apps or other apps that eat ports. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From hartmans@painless-security.com Mon Jan 7 09:15:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6FC21F8A08 for ; Mon, 7 Jan 2013 09:15:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBVr1JgJvobC for ; Mon, 7 Jan 2013 09:15:12 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C24DC21F893D for ; Mon, 7 Jan 2013 09:15:12 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 052D920144; Mon, 7 Jan 2013 12:12:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5A7B343F0; Mon, 7 Jan 2013 12:15:03 -0500 (EST) From: Sam Hartman To: Simon Perreault References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50EA9BF9.2010302@viagenie.ca> <023601cdecf7$fd33cc80$f79b6580$@cisco.com> <50EB001E.3030003@viagenie.ca> Date: Mon, 07 Jan 2013 12:15:03 -0500 In-Reply-To: <50EB001E.3030003@viagenie.ca> (Simon Perreault's message of "Mon, 07 Jan 2013 18:04:30 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:15:13 -0000 >>>>> "Simon" == Simon Perreault writes: Simon> Right, but I was thinking about a slightly different use case Simon> than draft-boucadair: some applications just like to get Simon> ownership of a chunk of ports when they start. This is mostly Simon> an implementation artifact, not really a protocol Simon> constraint. I had SIP apps in mind, but I guess the same Simon> could be said of BitTorrent apps or other apps that eat Simon> ports. Let me give a concrete example. A SIP PBX starts. It wants to get a number of ports to use for media termination; probably one or two for however many calls it might handle concurrently. That's on over-estimate because of course ports can be reused if the endpoints don't overlap. The PBX doesn't want to generate PCP requests during call setup if it has another option, so reserving a chunk of ports up front would be valuable. --Sam From marc.blanchet@viagenie.ca Mon Jan 7 12:30:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F118521F88D8 for ; Mon, 7 Jan 2013 12:30:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GME38qZDfF2 for ; Mon, 7 Jan 2013 12:30:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 884FE21F8837 for ; Mon, 7 Jan 2013 12:30:18 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B1F1A4039E; Mon, 7 Jan 2013 15:30:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Marc Blanchet In-Reply-To: <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> Date: Mon, 7 Jan 2013 15:30:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <50FB9E0F-A528-44DC-A723-69A8C82BC685@viagenie.ca> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> To: "Reinaldo Penno (repenno)" X-Mailer: Apple Mail (2.1283) Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:30:19 -0000 support. it brings a feature that is valuable in some deployments and = use cases. Marc. > On Jan 2, 2013, at 6:34 PM, Reinaldo Penno (repenno) = wrote: >=20 >> Hello, >>=20 >> This email starts a 2-week consensus call on adopting >>=20 >> Title : Using PCP To Coordinate Between the CGN and Home = Gateway >> Author(s) : Q. Sun et al >> Filename : draft-tsou-pcp-natcoord-09.txt >> URL : = http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt >>=20 >> Please read the current revision and state you opinion either for or >> against adoption (and with reasoning why) in the mailing list. >>=20 >> The call for adoption ends 16th January 2013. >>=20 >> Thanks, >>=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From diego@tid.es Mon Jan 7 13:37:01 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF0721F8556 for ; Mon, 7 Jan 2013 13:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGydxW2Y+d38 for ; Mon, 7 Jan 2013 13:37:00 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id E84A321F854C for ; Mon, 7 Jan 2013 13:36:57 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MG900I8WYPJ1T@tid.hi.inet> for pcp@ietf.org; Mon, 07 Jan 2013 22:36:56 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 94.9E.02896.7FF3BE05; Mon, 07 Jan 2013 22:36:55 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MG900IRGYPI19@tid.hi.inet> for pcp@ietf.org; Mon, 07 Jan 2013 22:36:55 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.223]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Mon, 07 Jan 2013 22:34:11 +0100 Date: Mon, 07 Jan 2013 21:36:54 +0000 From: "Diego R. Lopez" In-reply-to: <50FB9E0F-A528-44DC-A723-69A8C82BC685@viagenie.ca> X-Originating-IP: [10.95.64.115] To: Marc Blanchet Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-index: AQHN7RXN7lt5dKgTCUioEnF7IeXWxJg+Uz6A X-AuditID: 0a5f4e69-b7f636d000000b50-a2-50eb3ff732d5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXCFe9nqPvd/nWAwaElBhaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo+28ywFM4Qrrlw7y9jAeEOoi5GTQ0LARGLptEeMELaYxIV7 69m6GLk4hAS2MUrs+rcEyvnGKLF9TQcLhDOTUeLgpWnsIC0sAqoSKxaeYwGx2YDsR82/geIc HMICzhJPHhuCmJwC9hIds2QhFihI/Dn3GKxaREBXYvbOFcwgNrNAqMS/D2fBjuAV8JbY2XmC HSJuJnHq7URWiLigxI/J91hARjILqEtMmZILUSIu0dx6kwXCVpSYtqgBbAwj0C/fT61hgljl IrFq/Soo20ji4O6vzBDnCEgs2XMeyhaVePn4HyvEh9cYJb5d+8A4gVFiFpIzZiE5YxbCGbOQ nDELyRkLGFlXMYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKExFzmDsblO1UOMQpwMCrx8Cas fxUgxJpYVlyZe4hRkoNJSZQ33u51gBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3m8PgMp5UxIr q1KL8mFSMhwcShK860DaBItS01Mr0jJzgIkFJs3EwQnSzgPUPgukhre4IDG3ODMdIn+KUZVj f/vdp4xCLHn5ealS4hCDBECKMkrz4Oa8YhQHOliYtxokywNMjXATXgENZwIanvr4OcjwkkSE lFQDo1yveJfJ9R+JySpPdpsFHiqdxd+k926Jbwpz+yYbnuvfLS9EmRx8oTp19ufo/V836fXt VFwk0dj+lrHkmZdUTNNUF4vCIPvyjSZRssc/TZ//7d+kyDU8m3oXOzTX/fouzPI1Olwovb35 Q4On43sP0bsc9qLPQ2Te31ZZLuzyNbKpN1zg5hRlJZbijERDLeai4kQAjPfrbkoDAAA= References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <82256834F867D44BBB8E49E40D5448BB065955DC@BL2PRD0510MB386.namprd05.prod.outlook.com> <50FB9E0F-A528-44DC-A723-69A8C82BC685@viagenie.ca> Cc: "" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:37:01 -0000 SSBhbHNvIHN1cHBvcnQgaXQuIEluIGRlc3BpdGUgb2YgdGhlIHN0aWxsIG9wZW4gaXNzdWVzIEkg dGhpbmsgaXQgY2FuIGJlDQpvZiBpbnRlcmVzdCBmb3IgY2VydGFpbiBjYXNlcy4NCg0KQmUgZ29v ZGUsDQoNCk9uIDcgSmFuIDIwMTMsIGF0IDIxOjMwICwgTWFyYyBCbGFuY2hldCB3cm90ZToNCg0K PiBzdXBwb3J0LiBpdCBicmluZ3MgYSBmZWF0dXJlIHRoYXQgaXMgdmFsdWFibGUgaW4gc29tZSBk ZXBsb3ltZW50cyBhbmQgdXNlIGNhc2VzLiBNYXJjLg0KPg0KPj4gT24gSmFuIDIsIDIwMTMsIGF0 IDY6MzQgUE0sIFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVwZW5ub0BjaXNjby5jb20+IHdy b3RlOg0KPj4NCj4+PiBIZWxsbywNCj4+Pg0KPj4+IFRoaXMgZW1haWwgc3RhcnRzIGEgMi13ZWVr IGNvbnNlbnN1cyBjYWxsIG9uIGFkb3B0aW5nDQo+Pj4NCj4+PiAgIFRpdGxlICAgICA6IFVzaW5n IFBDUCBUbyBDb29yZGluYXRlIEJldHdlZW4gdGhlIENHTiBhbmQgSG9tZSBHYXRld2F5DQo+Pj4g ICBBdXRob3IocykgOiBRLiBTdW4gZXQgYWwNCj4+PiAgIEZpbGVuYW1lICA6IGRyYWZ0LXRzb3Ut cGNwLW5hdGNvb3JkLTA5LnR4dA0KPj4+ICAgVVJMICAgICAgIDogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LXRzb3UtcGNwLW5hdGNvb3JkLTA5LnR4dA0KPj4+DQo+Pj4gUGxlYXNlIHJl YWQgdGhlIGN1cnJlbnQgcmV2aXNpb24gYW5kIHN0YXRlIHlvdSBvcGluaW9uIGVpdGhlciBmb3Ig b3INCj4+PiBhZ2FpbnN0IGFkb3B0aW9uIChhbmQgd2l0aCByZWFzb25pbmcgd2h5KSBpbiB0aGUg bWFpbGluZyBsaXN0Lg0KPj4+DQo+Pj4gVGhlIGNhbGwgZm9yIGFkb3B0aW9uIGVuZHMgMTZ0aCBK YW51YXJ5IDIwMTMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4NCj4+DQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBjcCBtYWlsaW5nIGxp c3QNCj4+IHBjcEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wY3ANCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gcGNwIG1haWxpbmcgbGlzdA0KPiBwY3BAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3ANCg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxh cmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2Eg SStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0 aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2 YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRp Y2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVu bGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVz aXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBv biB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9F Uy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From tom.taylor.stds@gmail.com Mon Jan 7 15:29:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12C121F87E1 for ; Mon, 7 Jan 2013 15:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VITZOn454U5V for ; Mon, 7 Jan 2013 15:29:43 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 611D621F87E0 for ; Mon, 7 Jan 2013 15:29:43 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so17107232iad.13 for ; Mon, 07 Jan 2013 15:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=TQuhSyGFY71x8azVhgvku9+87d32BkxiJw1lH4FCcDI=; b=QhW9nw3QEvtNKfhrN3MJJazIU00zk1u2zDYMyNugZOtyiXsSkqC7Nupb/tJFHC10uv t4lcEYbmBQ/2WVGsVcG4K48MUN7+eA43VqFGLnETosyUWUEnG76gmPN3uqnOIopE9Vsh IFhq77tYHT93dCoZ/oKJUhnh7OFFss1JxpKIjZycUkKsZUU9yYOv7bju57aOJE+pdLtn SxPxjTN7cPVUr7U+G8i7eIYvGhv/3kcRYO0+HeAHldGZ1FaUh75UTzzY8+TeEQWzqHWJ YJBpNveYZc57VBjRk9WmxXheIiF4nsVqhOSGNiq6+0oZBUrfkowAn9HHqFnw98dKuNSf NCyg== X-Received: by 10.50.45.166 with SMTP id o6mr7052504igm.0.1357601382971; Mon, 07 Jan 2013 15:29:42 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id aa6sm8338567igc.14.2013.01.07.15.29.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jan 2013 15:29:42 -0800 (PST) Message-ID: <50EB5A67.9010708@gmail.com> Date: Mon, 07 Jan 2013 18:29:43 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130107-0, 07/01/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 23:29:44 -0000 Support. On 02/01/2013 6:34 PM, Reinaldo Penno (repenno) wrote: > Hello, > > This email starts a 2-week consensus call on adopting > > Title : Using PCP To Coordinate Between the CGN and Home Gateway > Author(s) : Q. Sun et al > Filename : draft-tsou-pcp-natcoord-09.txt > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. > > The call for adoption ends 16th January 2013. > > Thanks, > > > > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From eleven.fuyu@huawei.com Mon Jan 7 19:48:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CD821F8782 for ; Mon, 7 Jan 2013 19:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDqLwZ9yXPWh for ; Mon, 7 Jan 2013 19:48:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6988421F8726 for ; Mon, 7 Jan 2013 19:48:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AON52598; Tue, 08 Jan 2013 03:47:57 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 03:46:50 +0000 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 8 Jan 2013 03:47:56 +0000 Received: from SZXEML512-MBX.china.huawei.com ([169.254.5.193]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.003; Tue, 8 Jan 2013 11:47:46 +0800 From: "Fuyu (Eleven)" To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG/0/LqDydtsUat3zA//LFqwZg+BR6AgADM7hA= Date: Tue, 8 Jan 2013 03:47:45 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <50EB5A67.9010708@gmail.com> In-Reply-To: <50EB5A67.9010708@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 03:48:04 -0000 Support +1 although there are some issues being discussed now in the Mailin= g list=20 but I think it is useful for some use case. BR Yu -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: Tuesday, January 08, 2013 7:30 AM To: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Support. On 02/01/2013 6:34 PM, Reinaldo Penno (repenno) wrote: > Hello, > > This email starts a 2-week consensus call on adopting > > Title : Using PCP To Coordinate Between the CGN and Home Gatewa= y > Author(s) : Q. Sun et al > Filename : draft-tsou-pcp-natcoord-09.txt > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. > > The call for adoption ends 16th January 2013. > > Thanks, > > > > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Tue Jan 8 03:00:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC95321F8ED3 for ; Tue, 8 Jan 2013 03:00:40 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K61dJ71yvVT for ; Tue, 8 Jan 2013 03:00:40 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1C21F8ED5 for ; Tue, 8 Jan 2013 03:00:39 -0800 (PST) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M700b-1T6jQ41kwP-00wMxj; Tue, 08 Jan 2013 06:00:38 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <50EA9D57.9050805@viagenie.ca> Date: Tue, 8 Jan 2013 13:00:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> <50EA9D57.9050805@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:ytpBOsFZAKOuSu+DLQecjFTKQyw+AzffQRXWGoh4OL3 HM6eSPNdqFRM8aIEfMaUqKOIADd1wC6wqZkYX29QJTZ+zuFG4V xCiIa0886iHws5IJJul6VS9rNIzJdFCh6bGIGVP7+9RDGI+OrK Sy0r9/k5+vJcXAG6qvS/eXA1ZO4mfvzRtkWPvJnjXB7MJRjM9R bH4I0XIzwbK1FY5/H1eVfS4EkhIRLjaKEPlC1z/rwrZhjKx7BJ fMO+P+iEnTmfKb1iFH0fKR7qcOgo1SMOaKOj13Q0+aEA3jlnA7 bKgH3qOueuGxysOf/Dw8QJA001QCLhCFUazoFGo7I9gorbkHUF rGYOJVcIT+tuJtqrMlp8pJI9nseTclOSoLkkcUMExT4TLWqYTP x/K9ws4h1W7zw== Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 11:00:40 -0000 Hi Simon, Sam's remedy (i.e., unsolicited message from server triggering the = client to re-auth and request the same message this time securely) is = simply reinventing the server-side re-auth in a hacky way. I did explain = this well before. = http://www.ietf.org/mail-archive/web/pcp/current/msg02666.html Besides, how does that really circumvent the server's need to queue the = request? Server needs to hold on to the copy of the unsolicited message = even after it sent the message insecurely, so that when the client = performs re-auth and requests the message again the server has the same = message securely delivered to the client. Alper On Jan 7, 2013, at 12:03 PM, Simon Perreault wrote: > Le 2013-01-04 11:06, Alper Yegin a =E9crit : >> So, the main concern you have is, if the server has an outstanding >> message to send to the client and if there is no live SA, then the >> server has to queue the message until the SA is generated. The >> queueing of that message is your concern. >>=20 >> How is that such a big concern to the extent that we should define an >> inadequately secured protocol at IETF? I don't get that. The protocol >> allowing some of the server-side messages fly w/o integrity >> protection is a "glaring (security) hole". >=20 > IMHO it would be nice if we didn't need to add such a queue on the > server. I've said that before. >=20 > Now, Sam has explained how he sees no security hole in sending > server-initiated messages in the clear. I also am uneasy about this, = but > I cannot come up with an attack. >=20 > Calling this a "glaring hole" is fine, but explaining the attack you = see > would help further the discussion. >=20 > Unless there's an attack, it actually makes implementation easier and > the server more scalable. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Jan 8 04:25:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF26621F88FB for ; Tue, 8 Jan 2013 04:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1-kWHrJlRis for ; Tue, 8 Jan 2013 04:25:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37C1F21F886D for ; Tue, 8 Jan 2013 04:25:46 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D9B48403C7; Tue, 8 Jan 2013 07:25:44 -0500 (EST) Message-ID: <50EC1073.9020604@viagenie.ca> Date: Tue, 08 Jan 2013 13:26:27 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alper Yegin References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> <50EA9D57.9050805@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 12:25:46 -0000 Le 2013-01-08 12:00, Alper Yegin a écrit : > Besides, how does that really circumvent the server's need to queue > the request? Server needs to hold on to the copy of the unsolicited > message even after it sent the message insecurely, so that when the > client performs re-auth and requests the message again the server has > the same message securely delivered to the client. The client doesn't ask for a *retransmission*. It would ask for a brand new message, which would usually have the same content as the previous one. How I see it: 1. Server: "(unauthenticated) Mapping XYZ is now at a.b.c.d:1234." 2. Client: "Tell me about mapping XYZ using these auth bits: ..." 3. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234." You see, in message 2 the client only asks for mapping XYZ's status. The only link between message 1 and message 2 is the implicit fact that message 1 triggered message 2 in the client's state machine, as well as the "XYZ" piece of data which uniquely identifies a mapping (which is effectively the mapping's internal address, port, and nonce). The server forgets all about message 1 right after sending it. It can generate message 3 from message 2 and from its NAT state table. There is no guarantee that message 3 would have the same content as message 1 because the NAT state table may have changed in the meantime. But it doesn't matter. What matters to the client is the latest state of the mapping. Sam, feel free to correct any misunderstanding of mine. Simon From bingxuere@gmail.com Wed Jan 9 05:27:25 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1AD21F846B for ; Wed, 9 Jan 2013 05:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qsxGp8Z8gSl for ; Wed, 9 Jan 2013 05:27:24 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id EBAD221F8440 for ; Wed, 9 Jan 2013 05:27:23 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so2177906obc.13 for ; Wed, 09 Jan 2013 05:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pYnhINNajK4bmdSUSP9qJo4SI0DPa8kLfjhoizXFAzE=; b=sPAURy+aKomzpuaocN2PkhPgyYn90nK85QUHW7Xqsrsb8+ETTWNgMP3wLQ3l+pFM52 CvlJ3O49IH2UwJnXpEYZaOHKLYiHvKXJ4Uyp5YqUrRDSUQLtCWwscWO3tMWAcAjsqovG H5BCTgY0E6vQe00i5AYMvPA1tTBkK6CVmD3YM13G/4ImIVL1TxRXqlgmuvwb4HyX58N/ h+iT3S8T6sQTmQytEm7c0Yim6U5RFnu6gSvEfepoXBWy+iqMaxk0s2SjRd6uNUY6kY9f +Qd6IOTGKPX2kdLn9j89iVa9X05jtN/Oq0rIOwDOt6w5yhH4DrqgdWTEInp2TR9w7l3x BrzA== Received: by 10.60.31.68 with SMTP id y4mr39563302oeh.121.1357738043571; Wed, 09 Jan 2013 05:27:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Wed, 9 Jan 2013 05:26:43 -0800 (PST) In-Reply-To: <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> From: Qiong Date: Wed, 9 Jan 2013 21:26:43 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=e89a8f642aa8c8ff0f04d2db05fa Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:27:25 -0000 --e89a8f642aa8c8ff0f04d2db05fa Content-Type: text/plain; charset=UTF-8 Dear Dan, Another question: what is the relationship between draft-tsou-pcp-natcoord > and draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option? I > saw there was a request to adopt draft-sun-dhc-port-set-option in DHC, > and lots of discussion. > > I have not seen a discussion of using DHCP versus PCP for this > functionality, which concluded that PCP was the better choice. Did > that discussion occur? If so, can we get a pointer to that > discussion? > [Qiong] For the relationship between draft-tsou-pcp-natcoord, draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option, draft-tsou-pcp-natcoord is a port-set extension for pcp-base and draft-sun-dhc-port-set-option(updated version of draft-wu-dhc-port-set-option ) is a port-set extension on dhcpv4. Both draft-tsou-pcp-natcoord and draft-sun-dhc-port-set-option can work with lightweight 4over6, but draft-tsou-pcp-natcoord is not only designed for lw4over6 use case. It can also be used for other cases like Reinaldo's firewall, SLNAT44, application-based port-set reservation, etc. For lw4over6 use case, we do have a discussion of using DHCP or PCP among lw4over6 co-authors (no much discussion in the mailing-list). But it's truely hard to say which one is better. Different operators will have different situations. For example, for operators with existing DHCP server and is not planning to deploy CGN, they may prefer dhcp solution; while for operators with no existing DHCP server and will deploy CGN in the early stage, they may prefer pcp solution. So it is really a deployment choice for them. Hope it clarifies. Best wishes Qiong first > > -d > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --e89a8f642aa8c8ff0f04d2db05fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Dan,


Another question: =C2=A0what is the relationship between draft-tsou-pcp-nat= coord
and draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option? =C2=A0I=
saw there was a request to adopt draft-sun-dhc-port-set-option in DHC,
and lots of discussion.

I have not seen a discussion of using DHCP versus PCP for this
functionality, which concluded that PCP was the better choice. =C2=A0Did that discussion occur? =C2=A0If so, can we get a pointer to that
discussion?
[Qiong] For the relationship between draft= -tsou-pcp-natcoord, draft-sun-dhc-port-set-option and draft-wu-dhc-port-set= -option, draft-tsou-pcp-natcoord is a port-set extension for pcp-base and d= raft-sun-dhc-port-set-option(updated version of draft-wu-dhc-port-set-optio= n ) is a port-set extension on dhcpv4. Both draft-tsou-pcp-natcoord and dra= ft-sun-dhc-port-set-option can work with lightweight 4over6, but draft-tsou= -pcp-natcoord is not only designed for lw4over6 use case. It can also be us= ed for other cases like Reinaldo's firewall, SLNAT44, application-based= port-set reservation, etc.

For lw4over6 use case, we do have a discussion of using DHCP= or PCP among lw4over6 co-authors (no much discussion in the mailing-list).= But it's truely hard to say which one is better. Different operators w= ill have different situations. For example, for operators with existing DHC= P server and is not planning to deploy CGN, they may prefer dhcp solution; = while for operators with no existing DHCP server and will deploy CGN in the= early stage, they may prefer pcp solution. So it is really a deployment ch= oice for them.

Hope it clarifies.

Best wishes
Qiong



=C2=A0 first
= =C2=A0

-d



_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp



--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--e89a8f642aa8c8ff0f04d2db05fa-- From dwing@cisco.com Wed Jan 9 07:48:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A5F21F86C1 for ; Wed, 9 Jan 2013 07:48:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDbXc0jFGHpl for ; Wed, 9 Jan 2013 07:48:43 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9D21F8698 for ; Wed, 9 Jan 2013 07:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3004; q=dns/txt; s=iport; t=1357746523; x=1358956123; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=KQfhPFhUw2nZGUVMTbSoF2V8JEDuHpQ9iStZOC86kZQ=; b=ROoRg7uOEa48FxbrTL8FK8KypPwB/zO9nxTQcdNUWamnzqaNBDSPS8MD 6+prVjVO+0XCv5eAcWYSZVxtiSQdeMRqSFjd2Aeps1B2HXXY4e+x/Qfxn VETx+ySSRec18xJghWoEhJFmj72AqH+u8M4UAN1S/eWDGU4UHCuU7jPg5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8IAGKQ7VCrRDoG/2dsb2JhbABEg0eCcrcZFnOCHgEBAQMBAQEBBQITBksEAgUMAQMCCREEAQEDAiMDAgIZCAYfCQgCBBMLBQuHagMJBQ2mOIkPDYY/gSKKQYQagRMDiGGFHYY4gVaBHIobhRKDFQ X-IronPort-AV: E=Sophos;i="4.84,438,1355097600"; d="scan'208";a="65776084" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 09 Jan 2013 15:48:43 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r09FmhIk004029; Wed, 9 Jan 2013 15:48:43 GMT From: "Dan Wing" To: "'Qiong'" References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> In-Reply-To: Date: Wed, 9 Jan 2013 07:48:43 -0800 Message-ID: <0b8101cdee80$cd8962d0$689c2870$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGsXrIihwxD8rvFf/g369xONMd8VgJCt95bAuLT/QEB2BZBegGmtVEOAwUpJ04B3ZNQZAJxA806mASCeKA= Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:48:44 -0000 > -----Original Message----- > From: Qiong [mailto:bingxuere@gmail.com] > Sent: Wednesday, January 09, 2013 5:27 AM > To: Dan Wing > Cc: Simon Perreault; pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 > > Dear Dan, > > > > > Another question: what is the relationship between draft-tsou-pcp- > natcoord > and draft-sun-dhc-port-set-option and draft-wu-dhc-port-set-option? > I > saw there was a request to adopt draft-sun-dhc-port-set-option in > DHC, > and lots of discussion. > > I have not seen a discussion of using DHCP versus PCP for this > functionality, which concluded that PCP was the better choice. Did > that discussion occur? If so, can we get a pointer to that > discussion? > > > [Qiong] For the relationship between draft-tsou-pcp-natcoord, draft-sun- > dhc-port-set-option and draft-wu-dhc-port-set-option, draft-tsou-pcp- > natcoord is a port-set extension for pcp-base and draft-sun-dhc-port- > set-option(updated version of draft-wu-dhc-port-set-option ) is a port- > set extension on dhcpv4. Both draft-tsou-pcp-natcoord and draft-sun-dhc- > port-set-option can work with lightweight 4over6, but draft-tsou-pcp- > natcoord is not only designed for lw4over6 use case. It can also be used > for other cases like Reinaldo's firewall, SLNAT44, application-based > port-set reservation, etc. > > > For lw4over6 use case, we do have a discussion of using DHCP or PCP > among lw4over6 co-authors (no much discussion in the mailing-list). But > it's truely hard to say which one is better. Different operators will > have different situations. For example, for operators with existing DHCP > server and is not planning to deploy CGN, they may prefer dhcp solution; > while for operators with no existing DHCP server and will deploy CGN in > the early stage, they may prefer pcp solution. So it is really a > deployment choice for them. We all know the industry is best served with a single standard, rather than multiple standards (both a PCP mechanism and a DHCP mechanism). Too many choices is actually harmful, rather than helpful. I would really like to see the need for both PCP and DHCP before either working group adopts a mechanism. If we don't do that now, the same question is likely to arise when during IETF last call or during IESG review. -d > > Hope it clarifies. > > > Best wishes > > Qiong > > > > > first > > > > > -d > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =============================================== > From simon.perreault@viagenie.ca Wed Jan 9 07:52:02 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670DE21F8554 for ; Wed, 9 Jan 2013 07:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+8NmgphoNim for ; Wed, 9 Jan 2013 07:52:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C5C2E21F854D for ; Wed, 9 Jan 2013 07:52:01 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A146841494; Wed, 9 Jan 2013 10:51:57 -0500 (EST) Message-ID: <50ED9248.8000306@viagenie.ca> Date: Wed, 09 Jan 2013 16:52:40 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dan Wing References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> <0b8101cdee80$cd8962d0$689c2870$@cisco.com> In-Reply-To: <0b8101cdee80$cd8962d0$689c2870$@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:52:02 -0000 Le 2013-01-09 16:48, Dan Wing a écrit : > I would really like to see the need for both PCP and DHCP before either > working group adopts a mechanism. If we don't do that now, the > same question is likely to arise when during IETF last call or during > IESG review. Even if the DHCP mechanism would get chosen for LW4o6, I would argue that MAP_PORT_SET still has merit on its own, for the non-LW4o6 purposes we have described. So I don't see the LW4o6 aspect as a killer, at all. It's just one potential customer. Simon From alper.yegin@yegin.org Thu Jan 10 10:39:21 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF921F8935 for ; Thu, 10 Jan 2013 10:39:21 -0800 (PST) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2iMGOAzYjHO for ; Thu, 10 Jan 2013 10:39:21 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAD421F87F3 for ; Thu, 10 Jan 2013 10:39:21 -0800 (PST) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M71H3-1T5pJP1p0H-00wQIz; Thu, 10 Jan 2013 13:39:19 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1E254F6B-29BC-4404-BF67-E2D6D79B3397" From: Alper Yegin In-Reply-To: <50EC1073.9020604@viagenie.ca> Date: Thu, 10 Jan 2013 20:38:59 +0200 Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> <50EA9D57.9050805@viagenie.ca> <50EC1073.9020604@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:O1GrM7I+4wKwSs20jNt2oYPCMEe/jAEPp/2S7M2qqKT FVe7f5R7Lfd148Gq1lAV9jX8YjgOjWFNeUz6tFZiLdV/Snxczl 1YhRb7uv4eMhkIKRMwcly4n8UEcvTqMA6ia3GxyJxfKuL99oWo q1zucng5PKnciMCagp+Q/jeEdSVXiphUA7zqHZcsmeo/3mOYwU 5T8szts2fsuW9sMVOJWlrLpCzaOXCmrQ+wrQ4MlTW4VXVFn1MI m0/DMas6jvR4zvAeeXzpFOw2aqmKg5yQR3b+LXU1P6kmkO3lLl YjchBWpD7OY0PKr8a/ahj5Eegv/m4DT32EtIw5y0GWmWvZ2GJh e6GXmfv7TDJxEw8YobNCk+UIuIL3gC4cM6hsngLhfnZrE8t63H BTPcd0CAJUOZA== Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:39:22 -0000 --Apple-Mail=_1E254F6B-29BC-4404-BF67-E2D6D79B3397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 More complete sequence in Sam's case is this: 1a. Server: "(unauthenticated) Mapping XYZ is now at a.b.c.d:1234." 2a. Client: Initiate re-auth (upon detecting that server is trying to = send a message and there is no SA) 3a. Mutual re-auth takes place 4a. Client: "Tell me about mapping XYZ using these auth bits: ..." 5a. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234." The call-flow we are proposing is: 1b. Server: Initiate re-auth (upon detecting that there is a pending = message and there is no SA) 2b. Mutual re-auth takes place 3b. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234." First one is unnecessarily cumbersome. (Look, first one is simply a = hacked up version of server-initiated re-auth. Message #1a is implicitly = used to improvise the effect of Message #1b). It does save the server from buffering. But it moves the buffering to = the client. Client has to remember the unauthenticated message to ask = for it again. So, it's just moving the problem around. What if the server sent the mapping for ABC and not XYZ, and a = intermediate entity overwritten it with XYZ? Client cannot assume the = server has something to say about XYZ. In fact, the client shall not use = any of the information in Message 1a.=20 Alper On Jan 8, 2013, at 2:26 PM, Simon Perreault wrote: > Le 2013-01-08 12:00, Alper Yegin a =E9crit : >> Besides, how does that really circumvent the server's need to queue >> the request? Server needs to hold on to the copy of the unsolicited >> message even after it sent the message insecurely, so that when the >> client performs re-auth and requests the message again the server has >> the same message securely delivered to the client. >=20 > The client doesn't ask for a *retransmission*. It would ask for a = brand new message, which would usually have the same content as the = previous one. >=20 > How I see it: >=20 > 1. Server: "(unauthenticated) Mapping XYZ is now at a.b.c.d:1234." > 2. Client: "Tell me about mapping XYZ using these auth bits: ..." > 3. Server: "(authenticated) Mapping XYZ is now at a.b.c.d:1234." >=20 > You see, in message 2 the client only asks for mapping XYZ's status. = The only link between message 1 and message 2 is the implicit fact that = message 1 triggered message 2 in the client's state machine, as well as = the "XYZ" piece of data which uniquely identifies a mapping (which is = effectively the mapping's internal address, port, and nonce). >=20 > The server forgets all about message 1 right after sending it. It can = generate message 3 from message 2 and from its NAT state table. There is = no guarantee that message 3 would have the same content as message 1 = because the NAT state table may have changed in the meantime. But it = doesn't matter. What matters to the client is the latest state of the = mapping. >=20 > Sam, feel free to correct any misunderstanding of mine. >=20 > Simon --Apple-Mail=_1E254F6B-29BC-4404-BF67-E2D6D79B3397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 1a. = Server: "(unauthenticated) Mapping XYZ is now at = a.b.c.d:1234."
2a. Client: Initiate = re-auth (upon detecting that server is trying to send a message and = there is no SA)
3a. Mutual re-auth = takes place
4a. Client: "Tell me = about mapping XYZ using these auth bits: ..."
5a. Server: "(authenticated) Mapping XYZ is = now at a.b.c.d:1234."


The =  call-flow we are proposing is:

1b. Server: Initiate re-auth (upon detecting = that there is a pending message and there is no SA)
2b. Mutual re-auth takes place
3b. Server: = "(authenticated) Mapping XYZ is now at = a.b.c.d:1234."


First one is = unnecessarily cumbersome. (Look, first one is simply a hacked up version = of server-initiated re-auth. Message #1a is implicitly used to improvise = the effect of Message #1b).

It does save the = server from buffering. But it moves the buffering to the client. Client = has to remember the unauthenticated message to ask for it again. So, = it's just moving the problem around.

What if = the server sent the mapping for ABC and not XYZ, and a intermediate = entity overwritten it with XYZ?  Client cannot assume the server = has something to say about XYZ. In fact, the client shall not use any of = the information in Message = 1a. 

Alper





On Jan 8, 2013, at 2:26 PM, Simon Perreault wrote:

Le = 2013-01-08 12:00, Alper Yegin a =E9crit :
Besides, how does that really circumvent the server's need = to queue
the request? Server = needs to hold on to the copy of the = unsolicited
message even after = it sent the message insecurely, so that when = the
client performs re-auth = and requests the message again the server = has
the same message securely = delivered to the client.

The client doesn't ask for = a *retransmission*. It would ask for a brand new message, which would = usually have the same content as the previous one.

How I see = it:

1. Server: "(unauthenticated) Mapping XYZ is now at = a.b.c.d:1234."
2. Client: "Tell me about mapping XYZ using these auth = bits: ..."
3. Server: "(authenticated) Mapping XYZ is now at = a.b.c.d:1234."

You see, in message 2 the client only asks for = mapping XYZ's status. The only link between message 1 and message 2 is = the implicit fact that message 1 triggered message 2 in the client's = state machine, as well as the "XYZ" piece of data which uniquely = identifies a mapping (which is effectively the mapping's internal = address, port, and nonce).

The server forgets all about message 1 = right after sending it. It can generate message 3 from message 2 and = from its NAT state table. There is no guarantee that message 3 would = have the same content as message 1 because the NAT state table may have = changed in the meantime. But it doesn't matter. What matters to the = client is the latest state of the mapping.

Sam, feel free to = correct any misunderstanding of = mine.

Simon

= --Apple-Mail=_1E254F6B-29BC-4404-BF67-E2D6D79B3397-- From sunqi.thu@gmail.com Sun Jan 13 07:19:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52D221F86C2 for ; Sun, 13 Jan 2013 07:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aTOINIScPzC for ; Sun, 13 Jan 2013 07:19:45 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 29B4921F86C0 for ; Sun, 13 Jan 2013 07:19:45 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id wz12so1732173pbc.27 for ; Sun, 13 Jan 2013 07:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=GZCmzI301ILw92PGvBp7YcTNgokLpZUumXKVQt5/l20=; b=m8EtYCPLcw/hEDqG7y8+FPwTMYkE4NVzFRWeEebtXsNIpdC1XWpPRJnrPnZrF3089X oF4iPBzq5WnctXb3v3jBauGxdG5qfVWZH1oMnYK2qUZyyZ5K68JnfCPwr8s5qMTkUAh3 MJJUoMOhSc+3Ko7hftlP0jRiHtIpoqFpgrFQfijQhg7HM0fHoRHkv6YVUdOzjZW3Bsmw DWGY2yUbmLAF7O4FwURthVqf1mca9X5FRriFgBgLty9Y6gyruTw0i6wdPx/aPVAKuybh iEQ5dd4Sf73AiM8ekRShSmiNLKivDl45rbT/Y1n4L5KMMbojJ2Sc9FWjMYP9/unOTdEQ 1EKQ== X-Received: by 10.66.75.100 with SMTP id b4mr224669568paw.0.1358090384863; Sun, 13 Jan 2013 07:19:44 -0800 (PST) Received: from [192.168.0.113] ([114.255.40.13]) by mx.google.com with ESMTPS id kc4sm6475072pbc.23.2013.01.13.07.19.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 07:19:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <0b8101cdee80$cd8962d0$689c2870$@cisco.com> Date: Sun, 13 Jan 2013 23:19:35 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> <0b8101cdee80$cd8962d0$689c2870$@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 15:19:45 -0000 Dear all, I'm in favor of this draft. I think it should move forward. Best Regards! Qi Sun Tsinghua Univ. On 2013-1-9, at =E4=B8=8B=E5=8D=8811:48, Dan Wing wrote: >> -----Original Message----- >> From: Qiong [mailto:bingxuere@gmail.com] >> Sent: Wednesday, January 09, 2013 5:27 AM >> To: Dan Wing >> Cc: Simon Perreault; pcp@ietf.org >> Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 >>=20 >> Dear Dan, >>=20 >>=20 >>=20 >>=20 >> Another question: what is the relationship between = draft-tsou-pcp- >> natcoord >> and draft-sun-dhc-port-set-option and = draft-wu-dhc-port-set-option? >> I >> saw there was a request to adopt draft-sun-dhc-port-set-option = in >> DHC, >> and lots of discussion. >>=20 >> I have not seen a discussion of using DHCP versus PCP for this >> functionality, which concluded that PCP was the better choice. = Did >> that discussion occur? If so, can we get a pointer to that >> discussion? >>=20 >>=20 >> [Qiong] For the relationship between draft-tsou-pcp-natcoord, = draft-sun- >> dhc-port-set-option and draft-wu-dhc-port-set-option, draft-tsou-pcp- >> natcoord is a port-set extension for pcp-base and draft-sun-dhc-port- >> set-option(updated version of draft-wu-dhc-port-set-option ) is a = port- >> set extension on dhcpv4. Both draft-tsou-pcp-natcoord and = draft-sun-dhc- >> port-set-option can work with lightweight 4over6, but draft-tsou-pcp- >> natcoord is not only designed for lw4over6 use case. It can also be = used >> for other cases like Reinaldo's firewall, SLNAT44, application-based >> port-set reservation, etc. >>=20 >>=20 >> For lw4over6 use case, we do have a discussion of using DHCP or PCP >> among lw4over6 co-authors (no much discussion in the mailing-list). = But >> it's truely hard to say which one is better. Different operators will >> have different situations. For example, for operators with existing = DHCP >> server and is not planning to deploy CGN, they may prefer dhcp = solution; >> while for operators with no existing DHCP server and will deploy CGN = in >> the early stage, they may prefer pcp solution. So it is really a >> deployment choice for them. >=20 > We all know the industry is best served with a single standard,=20 > rather than multiple standards (both a PCP mechanism and a DHCP=20 > mechanism). Too many choices is actually harmful, rather than > helpful. >=20 > I would really like to see the need for both PCP and DHCP before = either > working group adopts a mechanism. If we don't do that now, the > same question is likely to arise when during IETF last call or during > IESG review. >=20 > -d >=20 >=20 >=20 >>=20 >> Hope it clarifies. >>=20 >>=20 >> Best wishes >>=20 >> Qiong >>=20 >>=20 >>=20 >>=20 >> first >>=20 >>=20 >>=20 >>=20 >> -d >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Qiong Sun >> China Telecom Beijing Research Institude >>=20 >>=20 >> Open source code: >> lightweight 4over6: http://sourceforge.net/projects/laft6/ >> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yangyue0830@gmail.com Sun Jan 13 21:57:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75F21F854F for ; Sun, 13 Jan 2013 21:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUx+FmVlPY-Z for ; Sun, 13 Jan 2013 21:57:38 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id DC63221F8477 for ; Sun, 13 Jan 2013 21:57:38 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so1660814dan.9 for ; Sun, 13 Jan 2013 21:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:reply-to:subject:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=6OEKd7DaBwitV+/hw8dHhfI7li5lQ14u4TccblNvDJ4=; b=CDFv2Tf+4hjBuiNonpcHo+RN3XAF9Xm0bJFFxNpXWnIPWsmb8mE14R/i+SoVKFgdPG FhKpJIKasguhoiL4w8IQvmBRphSw4+covoXlJZEaKWew1WrGeby455b/ntXUUSpyra/e 92aYoK3JYchG1spUqa2AipSRC82oXC47sWPEYN9F1JABzfwYfyvRM5tyVaIHmCqT6CBQ rnpk1cZtOAQPDTleP/CuMgp9oHbsUi8YATjHbjMBvjj0DVTSGp333XVS4Am1JOJjxJhD VD7VDnwTVE6Zq5teE2ChC1gwMme5gPojBWew7yOZ9Ca2zDSqCwaEdhWiGkKfNuuoCylB ZaiA== X-Received: by 10.66.52.79 with SMTP id r15mr229856415pao.46.1358143058453; Sun, 13 Jan 2013 21:57:38 -0800 (PST) Received: from ctbri-sunqiong ([219.142.69.75]) by mx.google.com with ESMTPS id rk6sm7590677pbc.20.2013.01.13.21.57.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 13 Jan 2013 21:57:37 -0800 (PST) Date: Mon, 14 Jan 2013 13:57:18 +0800 From: yangyue0830 To: pcp X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201301141357143254948@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart046468166585_=----" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: yangyue0830 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 06:14:59 -0000 This is a multi-part message in MIME format. ------=_001_NextPart046468166585_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQoNCg0KQWdyZWUgdG8gc3VwcG9ydCBhZG9wdGluZyB0aGlzIGRvY3VtZW50LiBU aGlzIHBvcnQtc2V0IE9wY29kZSBoYXMgc3BlY2lhbCBtZXJpdCBmb3Igc29tZSB1c2UgY2FzZS4N Cg0KDQoNCll1ZSBZYW5nDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0t LS0tDQpGcm9tOiBTaW1vbiBQZXJyZWF1bHQgPHNpbW9uLnBlcnJlYXVsdEB2aWFnZW5pZS5jYT4N CkRhdGU6IFdlZCwgSmFuIDksIDIwMTMgYXQgMTE6NTIgUE0NClN1YmplY3Q6IFJlOiBbcGNwXSBX RyBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtdHNvdS1wY3AtbmF0Y29vcmQtMDkNClRvOiBEYW4g V2luZyA8ZHdpbmdAY2lzY28uY29tPg0KQ2M6IFFpb25nIDxiaW5neHVlcmVAZ21haWwuY29tPiwg cGNwQGlldGYub3JnDQoNCg0KDQoNCkxlIDIwMTMtMDEtMDkgMTY6NDgsIERhbiBXaW5nIGEgw6lj cml0IDoNCg0KDQoNCg0KSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgdGhlIG5lZWQgZm9yIGJv dGggUENQIGFuZCBESENQIGJlZm9yZSBlaXRoZXINCndvcmtpbmcgZ3JvdXAgYWRvcHRzIGEgbWVj aGFuaXNtLiAgSWYgd2UgZG9uJ3QgZG8gdGhhdCBub3csIHRoZQ0Kc2FtZSBxdWVzdGlvbiBpcyBs aWtlbHkgdG8gYXJpc2Ugd2hlbiBkdXJpbmcgSUVURiBsYXN0IGNhbGwgb3IgZHVyaW5nDQpJRVNH IHJldmlldy4NCg0KDQoNCg0KDQoNCkV2ZW4gaWYgdGhlIERIQ1AgbWVjaGFuaXNtIHdvdWxkIGdl dCBjaG9zZW4gZm9yIExXNG82LCBJIHdvdWxkIGFyZ3VlIHRoYXQgTUFQX1BPUlRfU0VUIHN0aWxs IGhhcyBtZXJpdCBvbiBpdHMgb3duLCBmb3IgdGhlIG5vbi1MVzRvNiBwdXJwb3NlcyB3ZSBoYXZl IGRlc2NyaWJlZC4NCg0KDQpTbyBJIGRvbid0IHNlZSB0aGUgTFc0bzYgYXNwZWN0IGFzIGEga2ls bGVyLCBhdCBhbGwuIEl0J3MganVzdCBvbmUgcG90ZW50aWFsIGN1c3RvbWVyLg0KDQoNClNpbW9u ------=_001_NextPart046468166585_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Dear all:

Agree to support adopting this document. This port-set Opcode has spe= cial=20 merit for some use case.

Yue Yang

---------- Forwarded message ----------
From: Simon Perreault <simon.perreault@viagenie.ca>
Date: Wed, Jan 9, 2013 at 11:52 PM
Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
To: Dan Wing <dwing@cisco.com>
Cc: Qiong <bingxuere@gmail.com>, pcp@ietf.org


Le 2013-01-09 16:48, Dan Wing a =C3=A9crit :


I would really like to see the need for both PCP and DHCP before=20 either
working group adopts a mechanism.  If we don't do that now, the<= /DIV>
same question is likely to arise when during IETF last call or during=
IESG review.



Even if the DHCP mechanism would get chosen for LW4o6, I would argue = that=20 MAP_PORT_SET still has merit on its own, for the non-LW4o6 purposes we hav= e=20 described.

So I don't see the LW4o6 aspect as a killer, at all. It's just one=20 potential customer.

Simon
------=_001_NextPart046468166585_=------ From hartmans@painless-security.com Mon Jan 14 06:12:36 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C689421F8549 for ; Mon, 14 Jan 2013 06:12:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zU85KS4Z3LE for ; Mon, 14 Jan 2013 06:12:31 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D221F848B for ; Mon, 14 Jan 2013 06:12:30 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 07A3A20161; Mon, 14 Jan 2013 09:09:10 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B79F542B2; Mon, 14 Jan 2013 09:12:22 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> <5A0CB697-1D7F-4E20-AA0D-C8369D330693@yegin.org> <50EA9D57.9050805@viagenie.ca> <50EC1073.9020604@viagenie.ca> Date: Mon, 14 Jan 2013 09:12:22 -0500 In-Reply-To: (Alper Yegin's message of "Thu, 10 Jan 2013 20:38:59 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:12:36 -0000 At this point I favor servers requesting re-auth if they have an unsolicited message to send and there was a previous SA in place. I think moving the buffering problem to the client is a significant advantage, however: 1) It adds a constraint to the problem that all unsolicited messages need to be things that can be reconstructed given client prompting. Certainly true today, probably true in the future, but a real issue. 2) People are nervous about it. I'm fairly sure there is not a significant security issue, but it seems like it's easier to build consensus and go on with a simpler proposal. If the server buffering were a huge deal people would be screaming about it more. So, I think simplicity and a proposal people find easier to analyze is valuable. I'll note that describing things as "hacks," or "simply moving problems around," doesn't really add to the discussion. It's quite obvious that participants have different design esthetics here and that some of us will disagree on what is a clean solution vs what is an ugly solution. Moving things around is very commonly desirable in security protocols especially where state is concerned. --Sam From ian.farrer@telekom.de Mon Jan 14 08:54:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A121F8844 for ; Mon, 14 Jan 2013 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajdXJ+I25QKn for ; Mon, 14 Jan 2013 08:54:18 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id BE11E21F86D3 for ; Mon, 14 Jan 2013 08:54:17 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jan 2013 17:54:02 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 14 Jan 2013 17:54:02 +0100 From: To: Date: Mon, 14 Jan 2013 17:54:01 +0100 Thread-Topic: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: Ac3yYi+clS7kaFvbTaGmNw5Xl4esVQ== Message-ID: <8A1B81989BCFAE44A22B2B86BF2B763189618470ED@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B763189618470EDHE111643EMEA1_" MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:54:18 -0000 --_000_8A1B81989BCFAE44A22B2B86BF2B763189618470EDHE111643EMEA1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting this draft. It would be good like to see more other use cases (aside from lw4o6) in the= next version. Regards, Ian On 02/01/2013 6:34 PM, Reinaldo Penno (rpenno) wrote: Hello, This email starts a 2-week consensus call on adopting Title : Using PCP To Coordinate Between the CGN and Home Gateway Author(s) : Q. Sun et al Filename : draft-tsou-pcp-natcoord-09.txt URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt Please read the current revision and state you opinion either for or against adoption (and with reasoning why) in the mailing list. The call for adoption ends 16th January 2013. Thanks, --_000_8A1B81989BCFAE44A22B2B86BF2B763189618470EDHE111643EMEA1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support adopting thi= s draft.
It would be good like = to see more other use cases (aside from lw4o6) in the next version.
Regards,
Ian
On 02/01/2013 6:34 PM,= Reinaldo Penno (rpenno) wrote:
Hello,
 
This email starts a = 2-week consensus call on adopting
 
   &n= bsp; Title     : Using PCP To Coordinate Between the CG= N and Home Gateway
   &n= bsp; Author(s) : Q. Sun et al
   &n= bsp; Filename  : draft-tsou-pcp-natcoord-09.txt
 
Please read the curr= ent revision and state you opinion either for or
against adoption (an= d with reasoning why) in the mailing list.
 
The call for adoptio= n ends 16th January 2013.
 
Thanks,
 
 
 
 --_000_8A1B81989BCFAE44A22B2B86BF2B763189618470EDHE111643EMEA1_-- From achatz@forthnetgroup.gr Mon Jan 14 09:13:21 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67A21F8550 for ; Mon, 14 Jan 2013 09:13:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Lsfj2jFda4N for ; Mon, 14 Jan 2013 09:13:20 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 23A6C21F84E0 for ; Mon, 14 Jan 2013 09:13:19 -0800 (PST) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0EHDIFr006600 for ; Mon, 14 Jan 2013 19:13:18 +0200 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0EHDIsj014170 for ; Mon, 14 Jan 2013 19:13:18 +0200 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0EHDHgc000472; Mon, 14 Jan 2013 19:13:17 +0200 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50F43CAB.7000206@forthnetgroup.gr> Date: Mon, 14 Jan 2013 19:13:15 +0200 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 MIME-Version: 1.0 To: "pcp@ietf.org" References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:13:21 -0000 I support this draft, but i would like to see more cases covered (and some parts are not very clearly written). Also, as i already have informed the pcp authors about the base spec, i was hoping to see a solution for non-continuous port assignments in a single request. Any plans for that? Thanks, Tassos Reinaldo Penno (repenno) wrote on 03/01/2013 01:34: > Hello, > > This email starts a 2-week consensus call on adopting > > Title : Using PCP To Coordinate Between the CGN and Home Gateway > Author(s) : Q. Sun et al > Filename : draft-tsou-pcp-natcoord-09.txt > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. > > The call for adoption ends 16th January 2013. > > Thanks, > > > > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From adurand@juniper.net Mon Jan 14 10:31:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962BC21F88E2 for ; Mon, 14 Jan 2013 10:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87KQ37esvadS for ; Mon, 14 Jan 2013 10:31:37 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 094F521F88D6 for ; Mon, 14 Jan 2013 10:31:36 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUPRPCALT7GKa121SFM9qFdhnV0EyJ8fD@postini.com; Mon, 14 Jan 2013 10:31:37 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Jan 2013 10:30:17 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 14 Jan 2013 10:30:17 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 14 Jan 2013 10:38:23 -0800 Received: from mail109-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Mon, 14 Jan 2013 18:30:15 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id 9B1DF3603BB for ; Mon, 14 Jan 2013 18:30:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zz98dI9371Ic89bh936eI1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1358188214150497_11158; Mon, 14 Jan 2013 18:30:14 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id 223CC20067; Mon, 14 Jan 2013 18:30:14 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 14 Jan 2013 18:30:13 +0000 Received: from BL2PRD0510MB386.namprd05.prod.outlook.com ([169.254.11.99]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0257.004; Mon, 14 Jan 2013 18:30:12 +0000 From: Alain Durand To: Simon Perreault Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG/IWNhS315/EentG942BWJKpg207WAgAIc+oCAARA1gIADo9OAgAB4CICAAuqrgIAAJ6yAgAABGwCACAergA== Date: Mon, 14 Jan 2013 18:30:11 +0000 Message-ID: <82256834F867D44BBB8E49E40D5448BB065B0451@BL2PRD0510MB386.namprd05.prod.outlook.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> <0b8101cdee80$cd8962d0$689c2870$@cisco.com> <50ED9248.8000306@viagenie.ca> In-Reply-To: <50ED9248.8000306@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%VIAGENIE.CA$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:31:37 -0000 On Jan 9, 2013, at 10:52 AM, Simon Perreault = wrote: > Le 2013-01-09 16:48, Dan Wing a =E9crit : >> I would really like to see the need for both PCP and DHCP before either >> working group adopts a mechanism. If we don't do that now, the >> same question is likely to arise when during IETF last call or during >> IESG review. >=20 > Even if the DHCP mechanism would get chosen for LW4o6, I would argue that= MAP_PORT_SET still has merit on its own, for the non-LW4o6 purposes we hav= e described. I would like to see those merits being fully articulated before the wg adop= t this draft. - Alain. From bingxuere@gmail.com Mon Jan 14 18:23:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0021F8AB8 for ; Mon, 14 Jan 2013 18:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-ib0E3s0CAS for ; Mon, 14 Jan 2013 18:23:36 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9467421F8A1C for ; Mon, 14 Jan 2013 18:23:36 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id ta14so4570754obb.19 for ; Mon, 14 Jan 2013 18:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Mn3oTbT0MQOI4feMWO+IVeMkdoE1XhmtpAgG1UruJlM=; b=wuXtH17FxibI+iaa+yfOPwdly8WG4TBAqBhT19vssO0+fdyqQthYaN8YzC+mz+gkW1 I5JbvtlMb+aWl5fztPi5gfnwDWiellBCscUtZWV0gmgONZuJ8q0px7iQaun5y63OXUEK 5Uv0CUu0q07lsDBkNvylgeX9PqSZgxgxeO/8N133mAI0CP55KbCSz5QKcx3qsnRzThW1 IamNX4klIFynd0mKeCq/6T691sNk83EKtYsukaCpTRcO7aJ8RNnmD10iRqZFRCytVAIb iW3u+M+wBgyrtMXHpBqTkrccM7RJ9/W8V6eUhxDYL59SQFfbj2YAAcjXUdP6cekx8z+c 6C+Q== Received: by 10.60.170.242 with SMTP id ap18mr52768490oec.97.1358216616079; Mon, 14 Jan 2013 18:23:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Mon, 14 Jan 2013 18:22:55 -0800 (PST) In-Reply-To: <50F43CAB.7000206@forthnetgroup.gr> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <50F43CAB.7000206@forthnetgroup.gr> From: Qiong Date: Tue, 15 Jan 2013 10:22:55 +0800 Message-ID: To: Tassos Chatzithomaoglou Content-Type: multipart/alternative; boundary=bcaec54d3f84edf1ab04d34a72a2 Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:23:37 -0000 --bcaec54d3f84edf1ab04d34a72a2 Content-Type: text/plain; charset=UTF-8 Dear Tassos, Yes, we can easily modify to support it. Could you explain a little more on the intention of this use case ? Best wishes Qiong On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou < achatz@forthnetgroup.gr> wrote: > I support this draft, but i would like to see more cases covered (and some > parts are not very clearly written). > > Also, as i already have informed the pcp authors about the base spec, i > was hoping to see a solution for non-continuous > port assignments in a single request. > Any plans for that? > > Thanks, > Tassos > > Reinaldo Penno (repenno) wrote on 03/01/2013 01:34: > > Hello, > > > > This email starts a 2-week consensus call on adopting > > > > Title : Using PCP To Coordinate Between the CGN and Home Gateway > > Author(s) : Q. Sun et al > > Filename : draft-tsou-pcp-natcoord-09.txt > > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt > > > > Please read the current revision and state you opinion either for or > > against adoption (and with reasoning why) in the mailing list. > > > > The call for adoption ends 16th January 2013. > > > > Thanks, > > > > > > > > > > > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --bcaec54d3f84edf1ab04d34a72a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Tassos,

Yes, we can easily m= odify to support it. Could you explain a little more on the intention of th= is use case ?

Best wishes
Qiong


On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou <achatz= @forthnetgroup.gr> wrote:
I support this draft, but i would like to se= e more cases covered (and some parts are not very clearly written).

Also, as i already have informed the pcp authors about the base spec, i was= hoping to see a solution for non-continuous
port assignments in a single request.
Any plans for that?

Thanks,
Tassos

Reinaldo Penno (repenno) wrote on 03/01/2013 01:34:
> Hello,
>
> This email starts a 2-week consensus call on adopting
>
> =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 : Using PCP To Coordinate Betw= een the CGN and Home Gateway
> =C2=A0 =C2=A0 =C2=A0Author(s) : Q. Sun et al
> =C2=A0 =C2=A0 =C2=A0Filename =C2=A0: draft-tsou-pcp-natcoord-09.txt > =C2=A0 =C2=A0 =C2=A0URL =C2=A0 =C2=A0 =C2=A0 : http://tools= .ietf.org/id/draft-tsou-pcp-natcoord-09.txt
>
> Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list.
>
> The call for adoption ends 16th January 2013.
>
> Thanks,
>
>
>
>
>
>
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>

_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--bcaec54d3f84edf1ab04d34a72a2-- From bingxuere@gmail.com Mon Jan 14 21:10:19 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4111E8099 for ; Mon, 14 Jan 2013 21:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sttYXMOtR07E for ; Mon, 14 Jan 2013 21:10:18 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7987F11E809C for ; Mon, 14 Jan 2013 21:10:18 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so4741093oag.23 for ; Mon, 14 Jan 2013 21:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pZgeQmdZFKC/GOleoP/3dwuqrjMqTZ+bR/ew5T6KOuk=; b=lEFpr0zvzgANSy/n+Gq0dDiE+NwfRs/QgPOT5II8lBrhAOiATbaKDUxYQ5OQ6QPVM6 Ya8swWAcSuw7y/xDmngcZ/huOCbu6WkiSvlPHUTl5TmdjGEsRF5o3KJTVVbflHnMctl5 IN+MYWSL1wK0dvQQV1yrpRyn+Sda+KikiorJB9BmqMmXBYjb8UieYS/mrQzCwb+0OsU6 K4UYphNK1cy2CD0XBFjHBfoTe4lcF60MaRWGeSRziaZohcqwJLo0EIVmlxC2RPvcqFXM e/+CvU2kAVtqUM8DBw9aloyEd72korLsGeXSdZkAcpdH65Kwm5xVclUwIhj7zI+n1kMq YinA== Received: by 10.60.170.242 with SMTP id ap18mr53015556oec.97.1358226618089; Mon, 14 Jan 2013 21:10:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Mon, 14 Jan 2013 21:09:36 -0800 (PST) In-Reply-To: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> From: Qiong Date: Tue, 15 Jan 2013 13:09:36 +0800 Message-ID: To: "Zhangdacheng (Dacheng)" Content-Type: multipart/alternative; boundary=bcaec54d3f8418807704d34cc7bc Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 05:10:19 -0000 --bcaec54d3f8418807704d34cc7bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of this draft. Support to move forward. Best wishes Qiong On Sat, Jan 5, 2013 at 3:33 PM, Zhangdacheng (Dacheng) < zhangdacheng@huawei.com> wrote: > +1 > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > christian.jacquenet@orange.com > > Sent: Thursday, January 03, 2013 5:31 PM > > To: Reinaldo Penno (repenno); pcp@ietf.org > > Subject: Re: [pcp] WG Call for Adoption: > > draft-boucadair-pcp-nat64-prefix64-option > > > > Hello WG, > > > > I support the adoption of the draft as a pcp WG document. The proposed > > approach is useful to address the typical use cases mentioned in sectio= n > 2. > > > > Cheers, > > > > Christian. > > > > -----Message d'origine----- > > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > > Reinaldo Penno (repenno) > > Envoy=C3=A9 : jeudi 3 janvier 2013 00:30 > > =C3=80 : pcp@ietf.org > > Objet : [pcp] WG Call for Adoption: > draft-boucadair-pcp-nat64-prefix64-option > > > > Hello, > > > > First of all, Happy new Year! > > > > Based on the discussions at IETF Atlanta Meeting we would like to start > call of > > adoption on a few drafts, with the first one below. > > > > This email starts a 2-week consensus call on adopting > > > > Title : Learn NAT64 PREFIX64s using PCP > > Author(s) : M. Boucadair > > Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt > > URL : > > > http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt > > > > Please read the current revision and state you opinion either for or > against > > adoption (and with reasoning why) in the mailing list. The call for > adoption ends > > 16th January 2013. > > > > > > Thanks, > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > > > ________________________________________________________________ > > _________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles 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 message= s > > electroniques etant susceptibles d'alteration, > > France Telecom - Orange decline toute responsabilite si ce message a et= e > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information 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 > delete this > > message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > messages > > that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --bcaec54d3f8418807704d34cc7bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of this draft. Support to move forward.
=
Best wishes
Qiong


On Sat, Jan 5, 2013 at= 3:33 PM, Zhangdacheng (Dacheng) <zhangdacheng@huawei.com> wrote:
+1

> -----Original Message-----
> From: pcp-bounces@ietf.org= [mailto:pcp-bounces@ietf.org] = On Behalf Of
> christian.jacquenet@orange.com
> Sent: Thursday, January 03, 2013 5:31 PM
> To: Reinaldo Penno (repenno); pcp@ietf= .org
> Subject: Re: [pcp] WG Ca= ll for Adoption:
> draft-boucadair-pcp-nat64-prefix64-option
>
> Hello WG,
>
> I support the adoption of the draft as a pcp WG document. The proposed=
> approach is useful to address the typical use cases mentioned in secti= on 2.
>
> Cheers,
>
> Christian.
>
> -----Message d'origine-----
> De : pcp-bounces@ietf.org = [mailto:pcp-bounces@ietf.org] D= e la part de
> Reinaldo Penno (repenno)
> Envoy=C3=A9 : jeudi 3 janvier 2013 00:30
> =C3=80 : pcp@ietf.org
> Objet : [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64= -option
>
> Hello,
>
> First of all, Happy new Year!
>
> Based on the discussions at IETF Atlanta Meeting we would like to star= t call of
> adoption on a few drafts, with the first one below.
>
> This email starts a 2-week consensus call on adopting
>
> =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Learn N= AT64 PREFIX64s using PCP
> =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : M. Boucadair
> =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-boucad= air-pcp-nat64-prefix64-option-02.txt
> =C2=A0 =C2=A0 =C2=A0URL =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : > http://tools.ietf.org/id/draft-boucadair-= pcp-nat64-prefix64-option-02.txt
>
> Please read the current revision and state you opinion either for or a= gainst
> adoption (and with reasoning why) in the mailing list. The call for ad= option ends
> 16th January 2013.
>
>
> Thanks,
>
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>
> ________________________________________________________________
> _________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles 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 me= ssages
> electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a e= te
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privilege= d
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.<= br> > If you have received this email in error, please notify the sender and= delete this
> message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for me= ssages
> that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--bcaec54d3f8418807704d34cc7bc-- From liushucheng@huawei.com Mon Jan 14 23:14:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E878621F8B48; Mon, 14 Jan 2013 23:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WmoAwf+kFt9; Mon, 14 Jan 2013 23:14:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A756B21F8B46; Mon, 14 Jan 2013 23:14:29 -0800 (PST) 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 ANN96945; Tue, 15 Jan 2013 07:14:26 +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.1.323.3; Tue, 15 Jan 2013 07:14:18 +0000 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 07:14:24 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.40]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 15:14:17 +0800 From: "Will Liu (Shucheng)" To: "pcp-bounces@ietf.org" CC: "pcp@ietf.org" Thread-Topic: WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UHAxZacg/OQEUCune0mmF6YNZhJ+B6ggAAEWJA= Date: Tue, 15 Jan 2013 07:14:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:14:31 -0000 Folks, I have read draft-tsou-pcp-natcoord-09 and consider the PCP extension point= ed here significant. The document proposed a simple but applicable strategy= to reserve port sets for internal hosts, consequently enhance PCP with the= ability. With the extended configuration and definition, the draft has the= guiding significance for supporting lightweight 4over6, stateless PCP-cont= rolled device and other similar scenarios.=20 I support the adoption of this document as WG document. Regards, Will > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of=20 > Reinaldo Penno (repenno) > Sent: Thursday, January 03, 2013 7:35 AM > To: pcp@ietf.org > Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 >=20 > Hello, >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : Using PCP To Coordinate Between the CGN and Home > Gateway > Author(s) : Q. Sun et al > Filename : draft-tsou-pcp-natcoord-09.txt > URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt >=20 > Please read the current revision and state you opinion either for or=20 > against adoption (and with reasoning why) in the mailing list. >=20 > The call for adoption ends 16th January 2013. >=20 > Thanks, >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yangtianle@hotmail.com Tue Jan 15 03:03:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF8F21F86BA; Tue, 15 Jan 2013 03:03:48 -0800 (PST) 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=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpcBGAnJSSdZ; Tue, 15 Jan 2013 03:03:48 -0800 (PST) Received: from snt0-omc3-s24.snt0.hotmail.com (snt0-omc3-s24.snt0.hotmail.com [65.55.90.163]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDC921F86B7; Tue, 15 Jan 2013 03:03:48 -0800 (PST) Received: from SNT120-W21 ([65.55.90.137]) by snt0-omc3-s24.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jan 2013 03:03:47 -0800 X-EIP: [4FyEd38qIDQRUb4pO56/otf/HAi6czmJ0xrRFJKbiz4=] X-Originating-Email: [yangtianle@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ba24da5f-f013-405e-95f3-d0e16650775e_" From: yangtianle To: , Date: Tue, 15 Jan 2013 19:03:46 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jan 2013 11:03:47.0218 (UTC) FILETIME=[FDD3AF20:01CDF30F] Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:03:49 -0000 --_ba24da5f-f013-405e-95f3-d0e16650775e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi£¬all, I¡¯ve read this draft. The extension of PCP is useful and it should be moved forward. I support adopting the draft as WG document. Tianle Yang > -----Original Message-----> From: pcp-bounces at ietf.org [mailto:pcp-bounces at ietf.org] On Behalf Of > Reinaldo Penno (repenno)> Sent: Thursday, January 03, 2013 7:35 AM> To: pcp at ietf.org> Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09> > Hello,> > This email starts a 2-week consensus call on adopting> > Title : Using PCP To Coordinate Between the CGN and Home> Gateway> Author(s) : Q. Sun et al> Filename : draft-tsou-pcp-natcoord-09.txt> URL : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt> > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list.> > The call for adoption ends 16th January 2013.> > Thanks,> > > --_ba24da5f-f013-405e-95f3-d0e16650775e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit

Hi£¬all,

 

I¡¯ve read this draft. The extension of PCP is useful and it should be moved forward.

 

I support adopting the draft as WG document.

 

 

Tianle Yang

 

 

> -----Original Message-----
> From: pcp-bounces at ietf.org [mailto:pcp-bounces at ietf.org] On Behalf Of 
> Reinaldo Penno (repenno)
> Sent: Thursday, January 03, 2013 7:35 AM
> To: pcp at ietf.org
> Subject: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09
> 
> Hello,
> 
> This email starts a 2-week consensus call on adopting
> 
>      Title     : Using PCP To Coordinate Between the CGN and Home
> Gateway
>      Author(s) : Q. Sun et al
>      Filename  : draft-tsou-pcp-natcoord-09.txt
>      URL       : 
 http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
> 
> Please read the current revision and state you opinion either for or 
> against adoption (and with reasoning why) in the mailing list.
> 
> The call for adoption ends 16th January 2013.
> 
> Thanks,
> 
> 
 
>

 

--_ba24da5f-f013-405e-95f3-d0e16650775e_-- From wenmei_chao@126.com Tue Jan 15 05:11:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCB021F8800 for ; Tue, 15 Jan 2013 05:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.873 X-Spam-Level: *** X-Spam-Status: No, score=3.873 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_220=2.118] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GPVg2TrLn2j for ; Tue, 15 Jan 2013 05:11:45 -0800 (PST) Received: from m15-1.126.com (m15-1.126.com [220.181.15.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8393C21F87D9 for ; Tue, 15 Jan 2013 05:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Received:Date:From:To:Subject:Content-Type: MIME-Version:Message-ID; bh=Pgwmcc0mh139eSE58s2HgO5F/rQfRd/DG78j UDkD8Q4=; b=XhknZnlEFV4pRc6iRlMXiwh1geMwcWxrmzrfh35FlXruXceDzamV rGF2XiJS5ssRsZ8v3LXWv7PlVlAOA1o0BqTtzvfjdLXqrvyBHMo7qpfbkb5lBQWe 8x6fZrb+Bil7xWkfB2ikW/uBrciP8/dEtMZLuaZHt15XoAetnIWE6/8= Received: from wenmei_chao$126.com ( [59.64.255.109] ) by ajax-webmail-wmsvr1 (Coremail) ; Tue, 15 Jan 2013 21:11:30 +0800 (CST) X-Originating-IP: [59.64.255.109] Date: Tue, 15 Jan 2013 21:11:30 +0800 (CST) From: wenmei_chao To: pcp@ietf.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20121219(21170.5156.5150) Copyright (c) 2002-2013 www.mailtech.cn 126com X-CM-CTRLDATA: Fl3a7WZvb3Rlcl9odG09MTM5ODo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_278911_882906095.1358255490734" MIME-Version: 1.0 Message-ID: <6fed0059.127a0.13c3e5606ae.Coremail.wenmei_chao@126.com> X-CM-TRANSID: AcqowEBZykODVfVQOWg5AA--.17152W X-CM-SenderInfo: 5zhqzvxlbfxtbr6rjloofrz/1tbi7QKlqk0vN1NZvQAAsC X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 13:13:24 -0000 ------=_Part_278911_882906095.1358255490734 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGmjrGV2ZXJ5b25lLApTdXBwb3J0ICsxLiBJdCBzaG91bGQgYmUgdXNlZCBpbiBzZXZlcmFsIHVz YWdlIHNjZW5hcmlvcyBpbiB0aGUgZnV0dXJlLgoKCk1laUNoYW8gV2VuCgoKLS0tLS0tLS0tLSBG b3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZyb206IFNpbW9uIFBlcnJlYXVsdCA8c2ltb24u cGVycmVhdWx0QHZpYWdlbmllLmNhPgpEYXRlOiBXZWQsIEphbiA5LCAyMDEzIGF0IDExOjUyIFBN ClN1YmplY3Q6IFJlOiBbcGNwXSBXRyBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtdHNvdS1wY3At bmF0Y29vcmQtMDkKVG86IERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb20+CkNjOiBRaW9uZyA8Ymlu Z3h1ZXJlQGdtYWlsLmNvbT4sIHBjcEBpZXRmLm9yZwoKCgoKTGUgMjAxMy0wMS0wOSAxNjo0OCwg RGFuIFdpbmcgYSCopmNyaXQgOgoKCgoKSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgdGhlIG5l ZWQgZm9yIGJvdGggUENQIGFuZCBESENQIGJlZm9yZSBlaXRoZXIKd29ya2luZyBncm91cCBhZG9w dHMgYSBtZWNoYW5pc20uICBJZiB3ZSBkb24ndCBkbyB0aGF0IG5vdywgdGhlCnNhbWUgcXVlc3Rp b24gaXMgbGlrZWx5IHRvIGFyaXNlIHdoZW4gZHVyaW5nIElFVEYgbGFzdCBjYWxsIG9yIGR1cmlu ZwpJRVNHIHJldmlldy4KCgoKCgoKRXZlbiBpZiB0aGUgREhDUCBtZWNoYW5pc20gd291bGQgZ2V0 IGNob3NlbiBmb3IgTFc0bzYsIEkgd291bGQgYXJndWUgdGhhdCBNQVBfUE9SVF9TRVQgc3RpbGwg aGFzIG1lcml0IG9uIGl0cyBvd24sIGZvciB0aGUgbm9uLUxXNG82IHB1cnBvc2VzIHdlIGhhdmUg ZGVzY3JpYmVkLgoKClNvIEkgZG9uJ3Qgc2VlIHRoZSBMVzRvNiBhc3BlY3QgYXMgYSBraWxsZXIs IGF0IGFsbC4gSXQncyBqdXN0IG9uZSBwb3RlbnRpYWwgY3VzdG9tZXIuCgoKU2ltb24KCg== ------=_Part_278911_882906095.1358255490734 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6YXJpYWwiPjxkaXY+SGmjrGV2ZXJ5b25lLDwvZGl2PjxkaXY+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4JPC9zcGFuPlN1cHBv cnQgKzEuIEl0IHNob3VsZCBiZSB1c2VkIGluIHNldmVyYWwgdXNhZ2Ugc2NlbmFyaW9zIGluIHRo ZSBmdXR1cmUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5NZWlDaGFvIFdlbjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+LS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPC9k aXY+PGRpdj5Gcm9tOiBTaW1vbiBQZXJyZWF1bHQgJmx0O3NpbW9uLnBlcnJlYXVsdEB2aWFnZW5p ZS5jYSZndDs8L2Rpdj48ZGl2PkRhdGU6IFdlZCwgSmFuIDksIDIwMTMgYXQgMTE6NTIgUE08L2Rp dj48ZGl2PlN1YmplY3Q6IFJlOiBbcGNwXSBXRyBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtdHNv dS1wY3AtbmF0Y29vcmQtMDk8L2Rpdj48ZGl2PlRvOiBEYW4gV2luZyAmbHQ7ZHdpbmdAY2lzY28u Y29tJmd0OzwvZGl2PjxkaXY+Q2M6IFFpb25nICZsdDtiaW5neHVlcmVAZ21haWwuY29tJmd0Oywg cGNwQGlldGYub3JnPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5MZSAy MDEzLTAxLTA5IDE2OjQ4LCBEYW4gV2luZyBhIKimY3JpdCA6PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5JIHdvdWxkIHJlYWxseSBsaWtlIHRvIHNlZSB0aGUgbmVlZCBm b3IgYm90aCBQQ1AgYW5kIERIQ1AgYmVmb3JlIGVpdGhlcjwvZGl2PjxkaXY+d29ya2luZyBncm91 cCBhZG9wdHMgYSBtZWNoYW5pc20uICZuYnNwO0lmIHdlIGRvbid0IGRvIHRoYXQgbm93LCB0aGU8 L2Rpdj48ZGl2PnNhbWUgcXVlc3Rpb24gaXMgbGlrZWx5IHRvIGFyaXNlIHdoZW4gZHVyaW5nIElF VEYgbGFzdCBjYWxsIG9yIGR1cmluZzwvZGl2PjxkaXY+SUVTRyByZXZpZXcuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5FdmVuIGlmIHRoZSBE SENQIG1lY2hhbmlzbSB3b3VsZCBnZXQgY2hvc2VuIGZvciBMVzRvNiwgSSB3b3VsZCBhcmd1ZSB0 aGF0IE1BUF9QT1JUX1NFVCBzdGlsbCBoYXMgbWVyaXQgb24gaXRzIG93biwgZm9yIHRoZSBub24t TFc0bzYgcHVycG9zZXMgd2UgaGF2ZSBkZXNjcmliZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj5TbyBJIGRvbid0IHNlZSB0aGUgTFc0bzYgYXNwZWN0IGFzIGEga2lsbGVyLCBhdCBhbGwuIEl0 J3MganVzdCBvbmUgcG90ZW50aWFsIGN1c3RvbWVyLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ U2ltb248L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRl YXNlZm9vdGVyIj48c3BhbiBpZD0ibmV0ZWFzZV9tYWlsX2Zvb3RlciI+PC9zcGFuPjwvc3Bhbj4= ------=_Part_278911_882906095.1358255490734-- From cathy.zhou@huawei.com Tue Jan 15 23:44:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0846321F873C for ; Tue, 15 Jan 2013 23:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhaMHRuSqOUP for ; Tue, 15 Jan 2013 23:44:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7E21F875C for ; Tue, 15 Jan 2013 23:44:46 -0800 (PST) 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 ANO89464; Wed, 16 Jan 2013 07:44:44 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 07:44:33 +0000 Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Jan 2013 07:44:43 +0000 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.141]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.01.0323.003; Wed, 16 Jan 2013 15:43:10 +0800 From: "Zhouqian (Cathy)" To: Qiong , "Zhangdacheng (Dacheng)" Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: AQHN8t6j8adughw2k0yhWkEjP1JOp5hLlEJg Date: Wed, 16 Jan 2013 07:43:09 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <10808_1357205489_50E54FF1_10808_426_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15A651CB439@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF2D560EA6szxeml527mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 07:44:49 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D560EA6szxeml527mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCBSZWdhcmRzLA0KQ2F0aHkNCg0KRnJvbTogcGNwLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpwY3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFFpb25nDQpT ZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE1LCAyMDEzIDE6MTAgUE0NClRvOiBaaGFuZ2RhY2hlbmcg KERhY2hlbmcpDQpDYzogcGNwQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BjcF0gV0cgQ2FsbCBm b3IgQWRvcHRpb246IGRyYWZ0LWJvdWNhZGFpci1wY3AtbmF0NjQtcHJlZml4NjQtb3B0aW9uDQoN CkkgYW0gaW4gZmF2b3Igb2YgdGhpcyBkcmFmdC4gU3VwcG9ydCB0byBtb3ZlIGZvcndhcmQuDQoN CkJlc3Qgd2lzaGVzDQpRaW9uZw0KDQpPbiBTYXQsIEphbiA1LCAyMDEzIGF0IDM6MzMgUE0sIFpo YW5nZGFjaGVuZyAoRGFjaGVuZykgPHpoYW5nZGFjaGVuZ0BodWF3ZWkuY29tPG1haWx0bzp6aGFu Z2RhY2hlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KKzENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBwY3AtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGNwLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86cGNwLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBjcC1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+IGNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNv bTxtYWlsdG86Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tPg0KPiBTZW50OiBUaHVyc2Rh eSwgSmFudWFyeSAwMywgMjAxMyA1OjMxIFBNDQo+IFRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5u byk7IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3Bj cF0gV0cgQ2FsbCBmb3IgQWRvcHRpb246DQo+IGRyYWZ0LWJvdWNhZGFpci1wY3AtbmF0NjQtcHJl Zml4NjQtb3B0aW9uDQo+DQo+IEhlbGxvIFdHLA0KPg0KPiBJIHN1cHBvcnQgdGhlIGFkb3B0aW9u IG9mIHRoZSBkcmFmdCBhcyBhIHBjcCBXRyBkb2N1bWVudC4gVGhlIHByb3Bvc2VkDQo+IGFwcHJv YWNoIGlzIHVzZWZ1bCB0byBhZGRyZXNzIHRoZSB0eXBpY2FsIHVzZSBjYXNlcyBtZW50aW9uZWQg aW4gc2VjdGlvbiAyLg0KPg0KPiBDaGVlcnMsDQo+DQo+IENocmlzdGlhbi4NCj4NCj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogcGNwLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnBjcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpwY3AtYm91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQgZGUNCj4gUmVpbmFsZG8gUGVubm8g KHJlcGVubm8pDQo+IEVudm95w6kgOiBqZXVkaSAzIGphbnZpZXIgMjAxMyAwMDozMA0KPiDDgCA6 IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPg0KPiBPYmpldCA6IFtwY3BdIFdHIENh bGwgZm9yIEFkb3B0aW9uOiBkcmFmdC1ib3VjYWRhaXItcGNwLW5hdDY0LXByZWZpeDY0LW9wdGlv bg0KPg0KPiBIZWxsbywNCj4NCj4gRmlyc3Qgb2YgYWxsLCBIYXBweSBuZXcgWWVhciENCj4NCj4g QmFzZWQgb24gdGhlIGRpc2N1c3Npb25zIGF0IElFVEYgQXRsYW50YSBNZWV0aW5nIHdlIHdvdWxk IGxpa2UgdG8gc3RhcnQgY2FsbCBvZg0KPiBhZG9wdGlvbiBvbiBhIGZldyBkcmFmdHMsIHdpdGgg dGhlIGZpcnN0IG9uZSBiZWxvdy4NCj4NCj4gVGhpcyBlbWFpbCBzdGFydHMgYSAyLXdlZWsgY29u c2Vuc3VzIGNhbGwgb24gYWRvcHRpbmcNCj4NCj4gICAgICBUaXRsZSAgICAgICAgICAgOiBMZWFy biBOQVQ2NCBQUkVGSVg2NHMgdXNpbmcgUENQDQo+ICAgICAgQXV0aG9yKHMpICAgICAgIDogTS4g Qm91Y2FkYWlyDQo+ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtYm91Y2FkYWlyLXBjcC1u YXQ2NC1wcmVmaXg2NC1vcHRpb24tMDIudHh0DQo+ICAgICAgVVJMICAgICAgICAgICAgIDoNCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWJvdWNhZGFpci1wY3AtbmF0NjQtcHJlZml4 NjQtb3B0aW9uLTAyLnR4dA0KPg0KPiBQbGVhc2UgcmVhZCB0aGUgY3VycmVudCByZXZpc2lvbiBh bmQgc3RhdGUgeW91IG9waW5pb24gZWl0aGVyIGZvciBvciBhZ2FpbnN0DQo+IGFkb3B0aW9uIChh bmQgd2l0aCByZWFzb25pbmcgd2h5KSBpbiB0aGUgbWFpbGluZyBsaXN0LiBUaGUgY2FsbCBmb3Ig YWRvcHRpb24gZW5kcw0KPiAxNnRoIEphbnVhcnkgMjAxMy4NCj4NCj4NCj4gVGhhbmtzLA0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBw Y3AgbWFpbGluZyBsaXN0DQo+IHBjcEBpZXRmLm9yZzxtYWlsdG86cGNwQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPg0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlDQo+IG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzDQo+IGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gRnJhbmNlIFRlbGVjb20g LSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl DQo+IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+IFRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkDQo+IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+IHRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzDQo+IG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAt IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcw0KPiB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGNwIG1haWxpbmcgbGlz dA0KPiBwY3BAaWV0Zi5vcmc8bWFpbHRvOnBjcEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3ANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwY3AgbWFpbGluZyBsaXN0DQpwY3BAaWV0Zi5vcmc8bWFpbHRv OnBjcEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNw DQoNCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUWlvbmcgU3VuDQpDaGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dWRlDQoN Cg0KT3BlbiBzb3VyY2UgY29kZToNCmxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJjZWZv cmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8NClBDUC1uYXRjb29yZDogaHR0cDovL3NvdXJjZWZvcmdl Lm5ldC9wcm9qZWN0cy9wY3Bwb3J0c2V0ZGVtby8NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo= --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D560EA6szxeml527mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5 MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DYXRoeTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBwY3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBjcC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5RaW9uZzxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBKYW51YXJ5IDE1LCAyMDEzIDE6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFpoYW5n ZGFjaGVuZyAoRGFjaGVuZyk8YnI+DQo8Yj5DYzo8L2I+IHBjcEBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3BjcF0gV0cgQ2FsbCBmb3IgQWRvcHRpb246IGRyYWZ0LWJvdWNhZGFp ci1wY3AtbmF0NjQtcHJlZml4NjQtb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgYW0gaW4gZmF2b3Igb2YgdGhpcyBkcmFmdC4gU3VwcG9ydCB0byBtb3Zl IGZvcndhcmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCB3 aXNoZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UWlvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24g U2F0LCBKYW4gNSwgMjAxMyBhdCAzOjMzIFBNLCBaaGFuZ2RhY2hlbmcgKERhY2hlbmcpICZsdDs8 YSBocmVmPSJtYWlsdG86emhhbmdkYWNoZW5nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj56 aGFuZ2RhY2hlbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mIzQzOzE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZy b206IDxhIGhyZWY9Im1haWx0bzpwY3AtYm91bmNlc0BpZXRmLm9yZyI+cGNwLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnIj5w Y3AtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20iPg0K Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsgU2VudDogVGh1cnNk YXksIEphbnVhcnkgMDMsIDIwMTMgNTozMSBQTTxicj4NCiZndDsgVG86IFJlaW5hbGRvIFBlbm5v IChyZXBlbm5vKTsgPGEgaHJlZj0ibWFpbHRvOnBjcEBpZXRmLm9yZyI+cGNwQGlldGYub3JnPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTdWJqZWN0OiBSZTogW3BjcF0gV0cg Q2FsbCBmb3IgQWRvcHRpb246PGJyPg0KJmd0OyBkcmFmdC1ib3VjYWRhaXItcGNwLW5hdDY0LXBy ZWZpeDY0LW9wdGlvbjxicj4NCiZndDs8YnI+DQomZ3Q7IEhlbGxvIFdHLDxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhlIGRyYWZ0IGFzIGEgcGNwIFdHIGRv Y3VtZW50LiBUaGUgcHJvcG9zZWQ8YnI+DQomZ3Q7IGFwcHJvYWNoIGlzIHVzZWZ1bCB0byBhZGRy ZXNzIHRoZSB0eXBpY2FsIHVzZSBjYXNlcyBtZW50aW9uZWQgaW4gc2VjdGlvbiAyLjxicj4NCiZn dDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaHJpc3RpYW4uPGJyPg0K Jmd0Ozxicj4NCiZndDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyBEZSA6 IDxhIGhyZWY9Im1haWx0bzpwY3AtYm91bmNlc0BpZXRmLm9yZyI+cGNwLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnIj5wY3At Ym91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGU8YnI+DQomZ3Q7IFJlaW5hbGRvIFBl bm5vIChyZXBlbm5vKTxicj4NCiZndDsgRW52b3nDqSA6IGpldWRpIDMgamFudmllciAyMDEzIDAw OjMwPGJyPg0KJmd0OyDDgCA6IDxhIGhyZWY9Im1haWx0bzpwY3BAaWV0Zi5vcmciPnBjcEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7IE9iamV0IDogW3BjcF0gV0cgQ2FsbCBmb3IgQWRvcHRpb246IGRy YWZ0LWJvdWNhZGFpci1wY3AtbmF0NjQtcHJlZml4NjQtb3B0aW9uPGJyPg0KJmd0Ozxicj4NCiZn dDsgSGVsbG8sPGJyPg0KJmd0Ozxicj4NCiZndDsgRmlyc3Qgb2YgYWxsLCBIYXBweSBuZXcgWWVh ciE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbnMgYXQgSUVURiBB dGxhbnRhIE1lZXRpbmcgd2Ugd291bGQgbGlrZSB0byBzdGFydCBjYWxsIG9mPGJyPg0KJmd0OyBh ZG9wdGlvbiBvbiBhIGZldyBkcmFmdHMsIHdpdGggdGhlIGZpcnN0IG9uZSBiZWxvdy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBUaGlzIGVtYWlsIHN0YXJ0cyBhIDItd2VlayBjb25zZW5zdXMgY2FsbCBv biBhZG9wdGluZzxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0bGUg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IExlYXJuIE5BVDY0IFBSRUZJWDY0 cyB1c2luZyBQQ1A8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXV0aG9yKHMpICZuYnNw OyAmbmJzcDsgJm5ic3A7IDogTS4gQm91Y2FkYWlyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO0ZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtYm91Y2FkYWly LXBjcC1uYXQ2NC1wcmVmaXg2NC1vcHRpb24tMDIudHh0PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1VSTCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYm91Y2FkYWly LXBjcC1uYXQ2NC1wcmVmaXg2NC1vcHRpb24tMDIudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtYm91Y2FkYWlyLXBjcC1uYXQ2NC1wcmVmaXg2NC1v cHRpb24tMDIudHh0PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSByZWFkIHRoZSBjdXJy ZW50IHJldmlzaW9uIGFuZCBzdGF0ZSB5b3Ugb3BpbmlvbiBlaXRoZXIgZm9yIG9yIGFnYWluc3Q8 YnI+DQomZ3Q7IGFkb3B0aW9uIChhbmQgd2l0aCByZWFzb25pbmcgd2h5KSBpbiB0aGUgbWFpbGlu ZyBsaXN0LiBUaGUgY2FsbCBmb3IgYWRvcHRpb24gZW5kczxicj4NCiZndDsgMTZ0aCBKYW51YXJ5 IDIwMTMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IHBjcCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzpwY3BAaWV0Zi5vcmciPnBjcEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3A8L2E+PGJyPg0KJmd0Ozxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z PGJyPg0KJmd0OyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYzxicj4NCiZndDsgcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlPGJyPg0KJmd0OyBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KJmd0OyBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXM8 YnI+DQomZ3Q7IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8 YnI+DQomZ3Q7IEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZTxicj4NCiZndDsgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZDxicj4NCiZn dDsgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQomZ3Q7IHRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLjxicj4NCiZndDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpczxicj4NCiZndDsg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCiZndDsgQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl czxicj4NCiZndDsgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Ljxicj4NCiZndDsgVGhhbmsgeW91Ljxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBwY3AgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86cGNwQGlldGYub3JnIj5wY3BAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3BjcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGNwPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KcGNwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpwY3BA aWV0Zi5vcmciPnBjcEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NClFpb25nIFN1bjxicj4NCkNo aW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1ZGU8YnI+DQo8YnI+DQo8YnI+DQpP cGVuIHNvdXJjZSBjb2RlOjxicj4NCmxpZ2h0d2VpZ2h0IDRvdmVyNjogPGk+PGEgaHJlZj0iaHR0 cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8iIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL2xhZnQ2LzwvYT48L2k+PGJyPg0KUENQLW5hdGNv b3JkOjxpPiA8YSBocmVmPSJodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3BjcHBvcnRz ZXRkZW1vLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0 cy9wY3Bwb3J0c2V0ZGVtby88L2E+IDwvaT48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D560EA6szxeml527mbxchi_-- From mohamed.boucadair@orange.com Wed Jan 16 05:30:30 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB5221F882E for ; Wed, 16 Jan 2013 05:30:30 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ly0-J6XoZu5 for ; Wed, 16 Jan 2013 05:30:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9D90521F882B for ; Wed, 16 Jan 2013 05:30:29 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0AD2A2DC303; Wed, 16 Jan 2013 14:30:29 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DE53627C053; Wed, 16 Jan 2013 14:30:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 16 Jan 2013 14:30:28 +0100 From: To: "Tirumaleswar Reddy (tireddy)" , "pcp@ietf.org" Date: Wed, 16 Jan 2013 14:30:27 +0100 Thread-Topic: [pcp] draft-ietf-pcp-proxy-01 Thread-Index: AQHN3uybfXVjAbB6bU6t4S6LHaLs+ZgizVgwgClNTIA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EA601E417@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A148C07A6@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A148C07A6@xmb-rcd-x10.cisco.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: 2012.10.24.110314 Subject: Re: [pcp] draft-ietf-pcp-proxy-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 13:30:30 -0000 Hi Tiru, Many thanks for the comments.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 >Envoy=E9 : vendredi 21 d=E9cembre 2012 07:43 >=C0 : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org >Objet : Re: [pcp] draft-ietf-pcp-proxy-01 > >Hi Med, > >Comments > >[1] Section 3 PCP Server Discovery and Provisioning :=20 >You may also want to add details that PCP Proxy would use=20 >similar mechanism just like PCP client to discover the PCP server. Med: I updated the text with an explicit ref to Section 8.1 of draft-ietf-p= cp-base. > >[2] Section 5 Control of the Firewall :=20 >Firewall rules would be typically to block any unsolicited=20 >traffic from outside to inside. For PCP request/response this=20 >will not be a problem, but would have issues with unsolicited=20 >ANNOUNCE. In this case PCP Authentication looks mandatory to=20 >handle man-in-middle attacks trying to act as PCP Server. Med: is that a problem even if the pcp server is known to the pcp proxy? > >[3] Section 5 : Replace REMOTE_PEER_FILTER with FILTER option Med: Fixed. Thanks. > >[4] Section 8 MAP/PEER handling : you may also want to clarify=20 >PCP proxy behavior when PCP client uses THIRD_PARTY option. Med: I updated the text to explicitly require the PCP server follows the pc= p server recommendations detailed in section 13.1 of draft-ietf-pcp-base. > >[5] Section 10.1 Multiple PCP servers : There could be another=20 >scenarios that PCP proxy would forward the PCP request to one=20 >of the PCP servers depending on the fields set in PCP request=20 >(for specific use cases please refer to=20 >http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery >-00 ,=20 >http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-02# >section-8)] > Med: what change you want to see in that section? Thanks. >[6] How is it ensured that only the PCP proxy can communicate=20 >with the PCP server and not any other PCP client ? Med: Should this be part of the PCP Proxy spec? > >--Tiru. > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Friday, August 17, 2012 5:33 PM >> To: pcp@ietf.org >> Subject: [pcp] draft-ietf-pcp-proxy-01 >>=20 >> Dear all, >>=20 >> A new version is now available online: >> http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 >>=20 >> The main changes in -01 are as follows: >>=20 >> * The reference architecture is updated: the PCP proxy is=20 >not restricted to >> the CP router deployment case. >> * Add a new section to specify the behaviour when the PCP=20 >Proxy is not >> co-located with a NAT function >> * Add a new section for mappings repair >> * More discussion for the multiple PCP Servers scenario >> * Text is cleanup >>=20 >> A detailed diff is available here: >>=20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 >>=20 >> Please review this new version and provide input. >>=20 >> Cheers, >> Med >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >= From mohamed.boucadair@orange.com Wed Jan 16 05:55:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDA321F889D for ; Wed, 16 Jan 2013 05:55:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiBckhhG5NbK for ; Wed, 16 Jan 2013 05:55:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 446DC21F8615 for ; Wed, 16 Jan 2013 05:55:51 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id EBA152DC7E1; Wed, 16 Jan 2013 14:55:49 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D2F2B4C079; Wed, 16 Jan 2013 14:55:49 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 16 Jan 2013 14:55:49 +0100 From: To: "Zhouqian (Cathy)" , "pcp@ietf.org" Date: Wed, 16 Jan 2013 14:55:48 +0100 Thread-Topic: draft-ietf-pcp-proxy-01 Thread-Index: AQHNfFtQglT2FR9y7E+uIv3odqkuvJghxfUAgCsiAtA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EA601E445@PUEXCB1B.nanterre.francetelecom.fr> References: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E512B43CD@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: 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.1.16.113630 Subject: Re: [pcp] draft-ietf-pcp-proxy-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 13:55:53 -0000 Dear Cathy, Apologies for the delay to answer this message.=20 I wonder whether your case isn't covered in this text (Section 9); especial= ly the last sentence: Upon receipt of an unsolicited ANNOUNCE response from a PCP Server, the PCP Proxy proceeds to renewing the mappings and checks whether there are changes compared to a local cache if it is maintained by the PCP Proxy. If no change is detected, no unsolicited ANNOUNCE is generated towards PCP Clients. If a change is detected, the PCP Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate PCP Clients. If the PCP Proxy does not maintain a local cache for the mappings, unsolicited ANNOUNCE messages are relayed to PCP Clients. If not, please let me know what change you want to see added to that text. = Thanks. Cheers, Med=20 >-----Message d'origine----- >De : Zhouqian (Cathy) [mailto:cathy.zhou@huawei.com]=20 >Envoy=E9 : jeudi 20 d=E9cembre 2012 09:28 >=C0 : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org >Objet : RE: draft-ietf-pcp-proxy-01 > >Dear Med and all, >When looking over section 10 of this document, there is one=20 >more advanced feature in my mind that may be added for PCP proxy.=20 >In [I-D.ietf-pcp-base], the PCP server could send the ANNOUNCE=20 >response to both multicast and unicast addresses. For=20 >multicast address case, it only applies when the network is=20 >layer2 network and there is a multicast link between PCP=20 >client and PCP server. If there is no multicast link between=20 >PCP client and PCP server, one access router (e.g., PCP proxy)=20 >may perform the multicast address/unicast address conversion=20 >function. When the PCP proxy receives the ANNOUNCE message=20 >from the PCP server, it replaces the unicast address of itself=20 >with the PCP client's multicast address and sends ANNOUNCE=20 >message to the multicast address. It is required that the=20 >network between the PCP proxy and the PCP client is layer2.=20 >Any comments? > >Best Regards, >Cathy > > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> mohamed.boucadair@orange.com >> Sent: Friday, August 17, 2012 5:33 PM >> To: pcp@ietf.org >> Subject: [pcp] draft-ietf-pcp-proxy-01 >>=20 >> Dear all, >>=20 >> A new version is now available online: >> http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 >>=20 >> The main changes in -01 are as follows: >>=20 >> * The reference architecture is updated: the PCP proxy is=20 >not restricted to >> the CP router deployment case. >> * Add a new section to specify the behaviour when the PCP=20 >Proxy is not >> co-located with a NAT function >> * Add a new section for mappings repair >> * More discussion for the multiple PCP Servers scenario >> * Text is cleanup >>=20 >> A detailed diff is available here: >>=20 >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 >>=20 >> Please review this new version and provide input. >>=20 >> Cheers, >> Med >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >= From cathy.zhou@huawei.com Wed Jan 16 23:48:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232BC21F8B2E for ; Wed, 16 Jan 2013 23:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbJzuUbzSKgV for ; Wed, 16 Jan 2013 23:48:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8303421F876E for ; Wed, 16 Jan 2013 23:48:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOW00409; Thu, 17 Jan 2013 07:48:24 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Jan 2013 07:48:09 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Jan 2013 07:48:24 +0000 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.141]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 17 Jan 2013 15:48:16 +0800 From: "Zhouqian (Cathy)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: draft-ietf-pcp-proxy-01 Thread-Index: AQHNfFtQglT2FR9y7E+uIv3odqkuvJghxfUAgCsiAtCAASh3kA== Date: Thu, 17 Jan 2013 07:48:15 +0000 Message-ID: References: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E512B43CD@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EA601E445@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA601E445@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] draft-ietf-pcp-proxy-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 07:48:29 -0000 Dear Med, Thanks for your reply. In my understanding, the unsolicited ANNOUNCE message sent from the PCP ser= ver could be unicast or multicast. But if the PCP Proxy does not maintain a= local cache for the mappings, the PCP proxy need to send the multicast uns= olicited ANNOUNCE message to the PCP client. So my proposed modification to= the last sentence is as below: "If the PCP Proxy does not maintain a local cache for the mappings, unsolic= ited ANNOUNCE messages are relayed to PCP Clients using the multicast addre= ss." Best Regards, Cathy > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, January 16, 2013 9:56 PM > To: Zhouqian (Cathy); pcp@ietf.org > Subject: RE: draft-ietf-pcp-proxy-01 >=20 > Dear Cathy, >=20 > Apologies for the delay to answer this message. >=20 > I wonder whether your case isn't covered in this text (Section 9); especi= ally > the last sentence: >=20 > Upon receipt of an unsolicited ANNOUNCE response from a PCP Server, > the PCP Proxy proceeds to renewing the mappings and checks whether > there are changes compared to a local cache if it is maintained by > the PCP Proxy. If no change is detected, no unsolicited ANNOUNCE is > generated towards PCP Clients. If a change is detected, the PCP > Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate > PCP Clients. If the PCP Proxy does not maintain a local cache for > the mappings, unsolicited ANNOUNCE messages are relayed to PCP > Clients. >=20 > If not, please let me know what change you want to see added to that text= . > Thanks. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : Zhouqian (Cathy) [mailto:cathy.zhou@huawei.com] > >Envoy=E9 : jeudi 20 d=E9cembre 2012 09:28 > >=C0 : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org > >Objet : RE: draft-ietf-pcp-proxy-01 > > > >Dear Med and all, > >When looking over section 10 of this document, there is one > >more advanced feature in my mind that may be added for PCP proxy. > >In [I-D.ietf-pcp-base], the PCP server could send the ANNOUNCE > >response to both multicast and unicast addresses. For > >multicast address case, it only applies when the network is > >layer2 network and there is a multicast link between PCP > >client and PCP server. If there is no multicast link between > >PCP client and PCP server, one access router (e.g., PCP proxy) > >may perform the multicast address/unicast address conversion > >function. When the PCP proxy receives the ANNOUNCE message > >from the PCP server, it replaces the unicast address of itself > >with the PCP client's multicast address and sends ANNOUNCE > >message to the multicast address. It is required that the > >network between the PCP proxy and the PCP client is layer2. > >Any comments? > > > >Best Regards, > >Cathy > > > > > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > >> mohamed.boucadair@orange.com > >> Sent: Friday, August 17, 2012 5:33 PM > >> To: pcp@ietf.org > >> Subject: [pcp] draft-ietf-pcp-proxy-01 > >> > >> Dear all, > >> > >> A new version is now available online: > >> http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 > >> > >> The main changes in -01 are as follows: > >> > >> * The reference architecture is updated: the PCP proxy is > >not restricted to > >> the CP router deployment case. > >> * Add a new section to specify the behaviour when the PCP > >Proxy is not > >> co-located with a NAT function > >> * Add a new section for mappings repair > >> * More discussion for the multiple PCP Servers scenario > >> * Text is cleanup > >> > >> A detailed diff is available here: > >> > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 > >> > >> Please review this new version and provide input. > >> > >> Cheers, > >> Med > >> _______________________________________________ > >> pcp mailing list > >> pcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcp > > From tireddy@cisco.com Thu Jan 17 04:27:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DCA21F88CB for ; Thu, 17 Jan 2013 04:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRCs1+pKe0XQ for ; Thu, 17 Jan 2013 04:27:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DD11021F88CA for ; Thu, 17 Jan 2013 04:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4643; q=dns/txt; s=iport; t=1358425646; x=1359635246; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bBfmkcDrexRQx1Oti7lFPNe/J7xvI0Cf56wJFpHo+fs=; b=GNKtNzcrrjSGOa2FcX+CpaVjM5OgJz728BZ/4TV1DJMHbk3QPUEkbkId nvhmFZW24wYXIqCxsZpsja+qmR8fQlpyCkstkaYocxTM4xyQvEwqhIHkn UN7KY64okt7EXomzLqU7+iIa6e80hnZLEaqgevj1KyV0uiGoF39JviUbV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAITt91CtJXG8/2dsb2JhbAA7CYN1ui4Wc4IeAQEBBAEBAWsXBAIBCBEBAwEBCwMaBycLFAMGCAIEARIIAYgQBwW5V4x1EoNQYQOILI58jy2CdYIk X-IronPort-AV: E=Sophos;i="4.84,486,1355097600"; d="scan'208";a="163794587" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jan 2013 12:27:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0HCRPvi018333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 12:27:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 06:27:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] draft-ietf-pcp-proxy-01 Thread-Index: AQHN3uybfXVjAbB6bU6t4S6LHaLs+ZgizVgwgClNTICAAAN+wA== Date: Thu, 17 Jan 2013 12:27:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148E56D5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A148C07A6@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36EA601E417@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA601E417@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.127] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] draft-ietf-pcp-proxy-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:27:27 -0000 Hi Med, Please see inline [Tiru] > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, January 16, 2013 7:00 PM > To: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: RE: [pcp] draft-ietf-pcp-proxy-01 >=20 > Hi Tiru, >=20 > Many thanks for the comments. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >Envoy=E9 : vendredi 21 d=E9cembre 2012 07:43 > >=C0 : BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org > >Objet : Re: [pcp] draft-ietf-pcp-proxy-01 > > > >Hi Med, > > > >Comments > > > >[1] Section 3 PCP Server Discovery and Provisioning : > >You may also want to add details that PCP Proxy would use > >similar mechanism just like PCP client to discover the PCP server. >=20 > Med: I updated the text with an explicit ref to Section 8.1 of draft-ietf= -pcp- > base. >=20 > > > >[2] Section 5 Control of the Firewall : > >Firewall rules would be typically to block any unsolicited > >traffic from outside to inside. For PCP request/response this > >will not be a problem, but would have issues with unsolicited > >ANNOUNCE. In this case PCP Authentication looks mandatory to > >handle man-in-middle attacks trying to act as PCP Server. >=20 > Med: is that a problem even if the pcp server is known to the pcp proxy ? The PCP server could be in a different administrative domain that may or ma= y have IP source guard; attacker can spoof the well-known IP address of the= PCP server and send ANNOUNCE. PCP authentication looks mandatory. >=20 > > > >[3] Section 5 : Replace REMOTE_PEER_FILTER with FILTER option >=20 > Med: Fixed. Thanks. >=20 > > > >[4] Section 8 MAP/PEER handling : you may also want to clarify > >PCP proxy behavior when PCP client uses THIRD_PARTY option. >=20 > Med: I updated the text to explicitly require the PCP server follows the = pcp > server recommendations detailed in section 13.1 of draft-ietf-pcp-base. >=20 > > > >[5] Section 10.1 Multiple PCP servers : There could be another > >scenarios that PCP proxy would forward the PCP request to one > >of the PCP servers depending on the fields set in PCP request > >(for specific use cases please refer to > >http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery > >-00 , > >http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-02# > >section-8)] > > >=20 > Med: what change you want to see in that section? Thanks. The PCP proxy based on various fields set in the PCP request, client identi= ty will forward the PCP request to different PCP servers. For example in th= e case of PMIPv6 based on the UE subscription traffic offload rules will be= installed on the MAG. MAG acting as PCP proxy can either handle the PCP re= quest in the local access network itself or relay the PCP request to the PC= P server in the home network. I guess similar mechanism would be needed in = 3GPP network with SIPTO. >=20 > >[6] How is it ensured that only the PCP proxy can communicate > >with the PCP server and not any other PCP client ? >=20 > Med: Should this be part of the PCP Proxy spec ? This can be solved by simple techniques like ACL to block PCP client from c= ommunicating directly with the PCP server. You can mention it in security c= onsiderations. --Tiru. >=20 > > > >--Tiru. > > > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > >> mohamed.boucadair@orange.com > >> Sent: Friday, August 17, 2012 5:33 PM > >> To: pcp@ietf.org > >> Subject: [pcp] draft-ietf-pcp-proxy-01 > >> > >> Dear all, > >> > >> A new version is now available online: > >> http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 > >> > >> The main changes in -01 are as follows: > >> > >> * The reference architecture is updated: the PCP proxy is > >not restricted to > >> the CP router deployment case. > >> * Add a new section to specify the behaviour when the PCP > >Proxy is not > >> co-located with a NAT function > >> * Add a new section for mappings repair > >> * More discussion for the multiple PCP Servers scenario > >> * Text is cleanup > >> > >> A detailed diff is available here: > >> > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 > >> > >> Please review this new version and provide input. > >> > >> Cheers, > >> Med > >> _______________________________________________ > >> pcp mailing list > >> pcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcp > > > > From hartmans@painless-security.com Fri Jan 18 11:24:15 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD2321F870A for ; Fri, 18 Jan 2013 11:24:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTAoY65wDjWy for ; Fri, 18 Jan 2013 11:24:14 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A5B9521F8684 for ; Fri, 18 Jan 2013 11:24:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 320DC20289 for ; Fri, 18 Jan 2013 14:20:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DC8C243F7; Fri, 18 Jan 2013 14:24:07 -0500 (EST) From: Sam Hartman To: pcp@ietf.org Date: Fri, 18 Jan 2013 14:24:07 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] Authentication: how do we make a decision about the approach X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 19:24:15 -0000 I for one don't really know how to get the working group more information on which to make a decision about which authentication approach to choose. We all seem to agree that it's possible to specify PCP-based security with any of the PANA approaches or simply by creating an EAP lower layer. Stuart, Alan, myself and a few others have said they believe the EAP lower layer approach will be easier to implement. Alper, Yoshi and a few others have indicated they favor PANA. The sense of the room roughly favored an EAP specific approach in Atlanta, but I'm not sure the chairs felt comfortable calling it a rough consensus of the room. When we asked the same question earlier, we got a different result. Of course we've explored the issues more. That was before I looked at various implementation strategies and before we had the architectural discussion. So, what now? For myself, the discussions have strengthened my opinion that we'd be better off defining an EAP lower layer for all the reasons that we've discussed. So I rather strongly prefer that approach, and will argue for that position until the consensus call is made. However, I'm in this discussion to work on PCP security. If I end up in the rough on this issue, I'll contribute to the PANA approach and would be able and willing to contribute heavily to documents in that space. Sure, I'd like to see the approach I think best be chosen, but more important is providing a quality security solution for PCP. From achatz@forthnetgroup.gr Sun Jan 20 04:27:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23B121F84FB for ; Sun, 20 Jan 2013 04:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC+-EbAWGuRl for ; Sun, 20 Jan 2013 04:27:59 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0F621F84F0 for ; Sun, 20 Jan 2013 04:27:58 -0800 (PST) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0KCRtDK028235; Sun, 20 Jan 2013 14:27:55 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id r0KCRtIt007247; Sun, 20 Jan 2013 14:27:55 +0200 Received: from [192.168.1.2] (178.128.174.19.dsl.dyn.forthnet.gr [178.128.174.19]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0KCRs3k001078; Sun, 20 Jan 2013 14:27:54 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50FBE2C9.3060009@forthnetgroup.gr> Date: Sun, 20 Jan 2013 14:27:53 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15 MIME-Version: 1.0 To: Qiong References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <50F43CAB.7000206@forthnetgroup.gr> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 12:27:59 -0000
Hi Qiong,

I'm quoting my original email to the pcp authors.
If you need more info, please don't hesitate to contact me.

I've read the draft (26) twice during the last weeks (we'll hopefully try PCP soon in our network) and i think i'm missing the feature to include multiple ports in the same request/response (when talking about CPE as PCP client and a router/AFTR as PCP server). I've read draft-tsou-pcp-natcoord which came out due to a different motivation, but i don't think it fits in and i would certainly prefer to have it in the base spec. If i'm not wrong, the absence of this feature means that there is no way to have the PCP client instruct the PCP server to assign any external ip address, as long as ALL the specific port requirements of a single request are met.

Take the following scenario for example:

If a PCP client wants ports 80,443,8080 (the user has configured port forwarding for these ports in his/her CPE) and these are not available on its current external ip address, then by trying continuous one port requests the client might never get all three ports in the same ip address, while at the time of any single request there could be at least one external ip address with all these three ports available.
i.e. as a solution an extra option should be given to change (causing a session "disconnect" if needed) to a new external ip address that can offer ALL three ports (such an option could be activated on the PCP client by the provider, probably as a new DHCP option while discovering the PCP server). If such an external ip address is not available, then the behavior of PREFER_FAILURE should be followed (if explicitly requested).

Keeping that in mind, i couldn't also find any recommendations on whether the PCP server should try to service requests from PCP clients in a specific order that will allow as many PCP clients as possible to succeed in their port requirements. Is this somehow arranged by some other functionality/protocol/entity?
If multiple ports could be assigned in the same request/response, then it would be easier for the PCP server to assign external addresses/ports after a mass reconnect of PCP clients.
After all, i don't expect port forwarding rules to change often in CPEs after the initial configuration.

Generally, i'm worried of having a lot of subscribers using external ip addresses that do not have the requested ports available after some time, while many other addresses can satisfy their port requirements. In such a case i would prefer to have the option (or give the option to subscriber) of "transferring" him/her from one ip to another, in order to satisfy all his/her requirements. 


Thanks,
Tassos
Qiong wrote on 15/1/2013 04:22:
Dear Tassos,

Yes, we can easily modify to support it. Could you explain a little more on the intention of this use case ?

Best wishes
Qiong


On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
I support this draft, but i would like to see more cases covered (and some parts are not very clearly written).

Also, as i already have informed the pcp authors about the base spec, i was hoping to see a solution for non-continuous
port assignments in a single request.
Any plans for that?

Thanks,
Tassos

Reinaldo Penno (repenno) wrote on 03/01/2013 01:34:
> Hello,
>
> This email starts a 2-week consensus call on adopting
>
>      Title     : Using PCP To Coordinate Between the CGN and Home Gateway
>      Author(s) : Q. Sun et al
>      Filename  : draft-tsou-pcp-natcoord-09.txt
>      URL       : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
>
> Please read the current revision and state you opinion either for or
> against adoption (and with reasoning why) in the mailing list.
>
> The call for adoption ends 16th January 2013.
>
> Thanks,
>
>
>
>
>
>
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>

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



--
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================


From j.schoenwaelder@jacobs-university.de Mon Jan 21 01:23:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2390921F86BB for ; Mon, 21 Jan 2013 01:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v59SL030The4 for ; Mon, 21 Jan 2013 01:23:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D0C2B21F86B8 for ; Mon, 21 Jan 2013 01:23:44 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3281020BD7 for ; Mon, 21 Jan 2013 10:23:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R6N-RmhCge3T for ; Mon, 21 Jan 2013 10:23:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14A1120A6D for ; Mon, 21 Jan 2013 10:23:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 84920240F5F4; Mon, 21 Jan 2013 10:23:47 +0100 (CET) Resent-From: Juergen Schoenwaelder Resent-Date: Mon, 21 Jan 2013 10:23:47 +0100 Resent-Message-ID: <20130121092347.GA39858@elstar.local> Resent-To: pcp@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS02.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.2.328.9; Mon, 21 Jan 2013 10:21:21 +0100 Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A13A120BDA; Mon, 21 Jan 2013 10:21:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mAEMlkUhyT5g; Mon, 21 Jan 2013 10:21:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E7D120BD7; Mon, 21 Jan 2013 10:21:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 192DA240F4EE; Mon, 21 Jan 2013 10:21:25 +0100 (CET) Date: Mon, 21 Jan 2013 10:21:25 +0100 From: Juergen Schoenwaelder To: Message-ID: <20130121092125.GA39809@elstar.local> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 09:23:45 -0000 Hi, I have read draft-tsou-pcp-natcoord-09 and it seems a reasonable starting point if the need to allocate port sets via PCP is needed. Most of the traditional applications (e.g. softphones) likely do not need this functionality. The document mentions LW 4over6 as primary motivation. My understanding is that PCP is used here as an 'allocation' mechanism, that is, the NAT function allocates port sets via PCP from a (remote) PCP server (instead of getting the port set provisioned, e.g. via DHCP). Since I am not building home gateways or CGNs, I can't really judge how relevant this use case is. I was thinking as well whether it is possible to have an OS kernel (or system daemon) to pre-allocate port sets using this option such that applications that want to provide services do not have to engage into PCP interactions themself. I am not sure this is a viable use case, it is just an idea that popped up while thinking about use cases for this proposed new option. /js (who obviously is not an expert on pcp) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bingxuere@gmail.com Mon Jan 21 06:24:21 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4590E21F8824 for ; Mon, 21 Jan 2013 06:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUZ+inr+fKO9 for ; Mon, 21 Jan 2013 06:24:20 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id EED5521F881D for ; Mon, 21 Jan 2013 06:24:19 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id h16so6136909oag.33 for ; Mon, 21 Jan 2013 06:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=J5VSXrpxm8cgL0yVgWeTPd4Sz1Bv3SUpzw5iozUZ4Vo=; b=eN6/m3bfEdL8tai/W6efLXsWc9DcTg2x91K+dNPuPprXTkUuDUdq8k+T5TXSpZvxBf 3N3uSpAbL/Lvq5s2VmtTQnsl4aqkKBw8gBGvI7zrUEtqf/uqtXDtIPlmHEWSwT9EHChb Q7P5NJiuCauPm1zxMg90qFNQgIrtWVaK2c415ggxcJppr2bNsDgJPNePt99JVQ5eT2tJ Yqt2g/9rxSN45TyYEc+RoxRkzAJhwX10EEU1zqzNQYjPVMcmKIam9qlU0tMWa9NoIp10 7xqasDcmMue/9moFJPuUTpWVLjZLz5pYS0HoahMpFhwXGFn2dU1B1LyNa6W63axGW4bg Uu1Q== X-Received: by 10.182.130.38 with SMTP id ob6mr14134071obb.100.1358778259405; Mon, 21 Jan 2013 06:24:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Mon, 21 Jan 2013 06:23:39 -0800 (PST) In-Reply-To: <50FBE2C9.3060009@forthnetgroup.gr> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <50F43CAB.7000206@forthnetgroup.gr> <50FBE2C9.3060009@forthnetgroup.gr> From: Qiong Date: Mon, 21 Jan 2013 22:23:39 +0800 Message-ID: To: Tassos Chatzithomaoglou Content-Type: multipart/alternative; boundary=14dae93b567a7afcfa04d3cd372d Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 14:24:21 -0000 --14dae93b567a7afcfa04d3cd372d Content-Type: text/plain; charset=UTF-8 Dear Tassos, Thanks for your explaination. I now understand your case. I think the only difference is the port-set format. The current draft only defines contiguous port-mask format. In order to support your case, we can add an option to convey these individual non-contiguous ports in a single request with PREFER_FAILURE. Then, the PCP server will only reply the client when it can find an available external address to meet all his/her requirements (follow the PREFER_FAILURE option). Is it ok for you ? Best wishes Qiong On Sun, Jan 20, 2013 at 8:27 PM, Tassos Chatzithomaoglou < achatz@forthnetgroup.gr> wrote: > Hi Qiong, > > I'm quoting my original email to the pcp authors. > If you need more info, please don't hesitate to contact me. > > I've read the draft (26) twice during the last weeks (we'll hopefully try > PCP soon in our network) and i think i'm missing the feature to include > multiple ports in the same request/response (when talking about CPE as PCP > client and a router/AFTR as PCP server). I've read draft-tsou-pcp-natcoord > which came out due to a different motivation, but i don't think it fits in > and i would certainly prefer to have it in the base spec. If i'm not wrong, > the absence of this feature means that there is no way to have the PCP > client instruct the PCP server to assign any external ip address, as long > as ALL the specific port requirements of a single request are met. > > Take the following scenario for example: > > If a PCP client wants ports 80,443,8080 (the user has configured port > forwarding for these ports in his/her CPE) and these are not available on > its current external ip address, then by trying continuous one port > requests the client might never get all three ports in the same ip address, > while at the time of any single request there could be at least one > external ip address with all these three ports available. > i.e. as a solution an extra option should be given to change (causing a > session "disconnect" if needed) to a new external ip address that can offer > ALL three ports (such an option could be activated on the PCP client by the > provider, probably as a new DHCP option while discovering the PCP server). > If such an external ip address is not available, then the behavior of > PREFER_FAILURE should be followed (if explicitly requested). > > Keeping that in mind, i couldn't also find any recommendations on whether > the PCP server should try to service requests from PCP clients in a > specific order that will allow as many PCP clients as possible to succeed > in their port requirements. Is this somehow arranged by some other > functionality/protocol/entity? > If multiple ports could be assigned in the same request/response, then it > would be easier for the PCP server to assign external addresses/ports after > a mass reconnect of PCP clients. > After all, i don't expect port forwarding rules to change often in CPEs > after the initial configuration. > > Generally, i'm worried of having a lot of subscribers using external ip > addresses that do not have the requested ports available after some time, > while many other addresses can satisfy their port requirements. In such a > case i would prefer to have the option (or give the option to subscriber) > of "transferring" him/her from one ip to another, in order to satisfy all > his/her requirements. > > > > Thanks, > Tassos > > > > Qiong wrote on 15/1/2013 04:22: > > Dear Tassos, > > Yes, we can easily modify to support it. Could you explain a little more > on the intention of this use case ? > > Best wishes > Qiong > > > On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou < > achatz@forthnetgroup.gr> wrote: > >> I support this draft, but i would like to see more cases covered (and >> some parts are not very clearly written). >> >> Also, as i already have informed the pcp authors about the base spec, i >> was hoping to see a solution for non-continuous >> port assignments in a single request. >> Any plans for that? >> >> Thanks, >> Tassos >> >> Reinaldo Penno (repenno) wrote on 03/01/2013 01:34: >> > Hello, >> > >> > This email starts a 2-week consensus call on adopting >> > >> > Title : Using PCP To Coordinate Between the CGN and Home >> Gateway >> > Author(s) : Q. Sun et al >> > Filename : draft-tsou-pcp-natcoord-09.txt >> > URL : >> http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt >> > >> > Please read the current revision and state you opinion either for or >> > against adoption (and with reasoning why) in the mailing list. >> > >> > The call for adoption ends 16th January 2013. >> > >> > Thanks, >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > pcp mailing list >> > pcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/pcp >> > >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae93b567a7afcfa04d3cd372d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Tassos,

Thanks for your explainati= on. I now understand your case.

I think the = only difference is the port-set format. The current draft only defines cont= iguous port-mask format. In order to support your case, we can add an optio= n to convey these individual non-contiguous ports in a single request with= =C2=A0PREFER_FAILURE. Then, the PCP server will only reply the client when = it can find an available external address to meet all his/her requirements = (follow the=C2=A0PREFER_FAILURE option). Is it ok for you ?

Best wishes
Qiong

On Sun, Jan 20, = 2013 at 8:27 PM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
=20 =20 =20
Hi Qiong,

I'm quoting my original email to the pcp authors.
If you need more info, please don't hesitate to contact me.

I've read the draft (26) twice during t= he last weeks (we'll hopefully try PCP soon in our network) and i think i'm missing the feature to include multiple ports in the same request/response (when talking about CPE as PCP client and a router/AFTR as PCP server). I've read draft-tsou-pcp-natcoord which came out due to a different motivation, but i don't think it fits in and i would certainly prefer to have it in the base spec. If i'm not wrong, the absence of this feature means that there is no way to have the PCP client instruct the PCP server to assign any external ip address, as long as ALL the specific port requirements of a single request are met.

Take the following scenario for example:

If a PCP client wants ports 80,443,8080 (the user has configured port forwarding for these ports in his/her CPE) and these are not available on its current external ip address, then by trying continuous one port requests the client might never get all three ports in the same ip address, while at the time of any single request there could be at least one external ip address with all these three ports available.
i.e. as a solution an extra option should be given to change (causing a session "disconnect" if needed) to a new exter= nal ip address that can offer ALL three ports (such an option could be activated on the PCP client by the provider, probably as a new DHCP option while discovering the PCP server). If such an external ip address is not available, then the behavior of PREFER_FAILURE should be followed (if explicitly requested).

Keeping that in mind, i couldn't also find any recommendations on whether the PCP server should try to service requests from PCP clients in a specific order that will allow as many PCP clients as possible to succeed in their port requirements. Is this somehow arranged by some other functionality/protocol/entity?
If multiple ports could be assigned in the same request/response, then it would be easier for the PCP server to assign external addresses/ports after a mass reconnect of PCP clients.
After all, i don't expect port forwarding rules to change often in CPEs after the initial configuration.

Generally, i'm worried of having a lot of subscribers using external ip addresses that do not have the requested ports available after some time, while many other addresses can satisfy their port requirements. In such a case i would prefer to have the option (or give the option to subscriber) of "transferring" him/her from one ip to another, in order t= o satisfy all his/her requirements. 


Thanks,
Tassos
Qiong wrote on 15/1/2013 04:22:
Dear Tassos,

Yes, we can easily modify to support it. Could you explain a little more on the intention of this use case ?

Best wishes
Qiong


On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
I support this draft, but i would like to see more cases covered (and some parts are not very clearly written).

Also, as i already have informed the pcp authors about the base spec, i was hoping to see a solution for non-continuous port assignments in a single request.
Any plans for that?

Thanks,
Tassos

Reinaldo Penno (repenno) wrote on 03/01/2013 01:34:
> Hello,
>
> This email starts a 2-week consensus call on adopting
>
> =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 : Using PCP To= Coordinate Between the CGN and Home Gateway
> =C2=A0 =C2=A0 =C2=A0Author(s) : Q. Sun et al
> =C2=A0 =C2=A0 =C2=A0Filename =C2=A0: draft-tsou-pcp-na= tcoord-09.txt
> =C2=A0 =C2=A0 =C2=A0URL =C2=A0 =C2=A0 =C2=A0 : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
>
> Please read the current revision and state you opinion either for or
> against adoption (and with reasoning why) in the mailing list.
>
> The call for adoption ends 16th January 2013.
>
> Thanks,
>
>
>
>
>
>
>
> _______________________________________________
> pcp mailing list
> pcp@= ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=





--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--14dae93b567a7afcfa04d3cd372d-- From tireddy@cisco.com Mon Jan 21 19:19:55 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF221F8414 for ; Mon, 21 Jan 2013 19:19:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEijIuEezND3 for ; Mon, 21 Jan 2013 19:19:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C65C621F8319 for ; Mon, 21 Jan 2013 19:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12106; q=dns/txt; s=iport; t=1358824794; x=1360034394; h=from:to:subject:date:message-id:mime-version; bh=xmhr5Jsh5SoOZCLXuvur5HNZ1TnPq/SBC6osINFr4Sw=; b=JMySnzvDtblZ82tj/w3gSsvgPccBF/cFQglLgzkjPHRboliLv1aLvrd9 DPdsKvWC8C6FE09gkHxf+NBj8ByPpADg048WwHrwRDiFEeRmDYNxc859+ QWyHNhjBcjlNOugDFNTTtAnw0c1pTbK+UkDYPNa4ldSKssR34v76CvxzB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoFAP8D/lCtJXG8/2dsb2JhbABEgkiBLYJQpUGJDAGIKHoWc4IeAQEBBCMKSg4GAQgRBAEBCx0DAgQwFAcBAQUFBBMIAYgQBwWbPo5VgkCPKZAjMmEDlyiPLYJoDYIk X-IronPort-AV: E=Sophos;i="4.84,511,1355097600"; d="scan'208,217";a="165869460" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jan 2013 03:19:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0M3JsM7015884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jan 2013 03:19:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 21 Jan 2013 21:19:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-reddy-pcp-optimize-keepalives-01.txt Thread-Index: AQHN97YGXpquGj9CKkefMxbInrD+d5hTkA4A Date: Tue, 22 Jan 2013 03:19:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148E9CE1@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.68.55] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A148E9CE1xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-reddy-pcp-optimize-keepalives-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 03:19:55 -0000 --_000_913383AAA69FF945B8F946018B75898A148E9CE1xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQp3ZSBoYXZlIGFkZHJlc3NlZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSB0 aGUgV0cgYW5kIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVk DQoNCg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1wY3Atb3B0aW1p emUta2VlcGFsaXZlcy0wMQ0KDQpUaGFua3MgdG8gRGF2ZSBUaGFsZXIgZm9yIHRoZSBkZXRhaWxl ZCByZXZpZXcuDQoNCg0KDQpQbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1l bnRzLCBzdWdnZXN0aW9ucyB0byBpbXByb3ZlIHRoZSBkcmFmdC4NCg0KDQoNClRoYW5rcw0KDQot LWF1dGhvcnMuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2Vu dDogTW9uZGF5LCBKYW51YXJ5IDIxLCAyMDEzIDI6MzIgUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQpDYzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IERhbiBXaW5nIChk d2luZyk7IG1hcmt1cy5pc29tYWtpQG5va2lhLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcy0wMS50eHQN Cg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktcGNwLW9wdGltaXpl LWtlZXBhbGl2ZXMtMDEudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg VGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlDQoNCklFVEYgcmVwb3NpdG9yeS4N Cg0KDQoNCkZpbGVuYW1lOiAgIGRyYWZ0LXJlZGR5LXBjcC1vcHRpbWl6ZS1rZWVwYWxpdmVzDQoN ClJldmlzaW9uOiAgIDAxDQoNClRpdGxlOiAgICAgICAgICAgIE9wdGltaXppbmcgTkFUIGFuZCBG aXJld2FsbCBLZWVwYWxpdmVzIFVzaW5nIFBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKQ0KDQpD cmVhdGlvbiBkYXRlOiAgICAyMDEzLTAxLTIxDQoNCldHIElEOiAgICAgICAgICAgIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KDQpOdW1iZXIgb2YgcGFnZXM6IDE1DQoNClVSTDogICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktcGNwLW9wdGlt aXplLWtlZXBhbGl2ZXMtMDEudHh0DQoNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcw0KDQpI dG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXBj cC1vcHRpbWl6ZS1rZWVwYWxpdmVzLTAxDQoNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVkZHktcGNwLW9wdGltaXplLWtlZXBhbGl2ZXMt MDENCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgUG9y dCBDb250cm9sIFByb3RvY29sIGlzIHVzZWZ1bCB0byByZWR1Y2UNCg0KICAgTkFUIGFuZCBmaXJl d2FsbCBrZWVwYWxpdmUgbWVzc2FnZXMgZm9yIGEgdmFyaWV0eSBvZiBhcHBsaWNhdGlvbnMuDQoN Cg0KDQoNCg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A148E9CE1xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25z ICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu VGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNl Y3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij53ZSBoYXZlIGFkZHJlc3NlZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSB0aGUgV0cg YW5kIHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVkPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJlZGR5LXBjcC1vcHRpbWl6ZS1rZWVwYWxpdmVzLTAxIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcy0wMTwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyB0byBEYXZlIFRo YWxlciBmb3IgdGhlIGRldGFpbGVkIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UGxlYXNlIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cywgc3VnZ2VzdGlv bnMgdG8gaW1wcm92ZSB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo YW5rczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS1hdXRob3JzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gPGJyPg0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDIxLCAyMDEzIDI6MzIgUE08 YnI+DQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCkNjOiBQcmFzaGFudGgg UGF0aWwgKHByYXNwYXRpKTsgRGFuIFdpbmcgKGR3aW5nKTsgbWFya3VzLmlzb21ha2lAbm9raWEu Y29tPGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRk eS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcy0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktcGNwLW9wdGltaXplLWtlZXBhbGl2ZXMtMDEu dHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5oYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRo ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SUVURiByZXBvc2l0b3J5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5GaWxlbmFtZTombmJzcDsmbmJzcDsgZHJh ZnQtcmVkZHktcGNwLW9wdGltaXplLWtlZXBhbGl2ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlJldmlzaW9uOiZuYnNwOyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9wdGltaXppbmcgTkFUIGFu ZCBGaXJld2FsbCBLZWVwYWxpdmVzIFVzaW5nIFBvcnQgQ29udHJvbCBQcm90b2NvbCAoUENQKTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q3JlYXRpb24gZGF0ZTombmJz cDsmbmJzcDsmbmJzcDsgMjAxMy0wMS0yMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+V0cgSUQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TnVtYmVyIG9mIHBhZ2VzOiAxNTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS1wY3At b3B0aW1pemUta2VlcGFsaXZlcy0wMS50eHQiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtcmVkZHktcGNwLW9wdGltaXplLWtlZXBhbGl2ZXMtMDEudHh0PC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3RhdHVzOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXBjcC1vcHRpbWl6ZS1rZWVw YWxpdmVzIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHktcGNw LW9wdGltaXplLWtlZXBhbGl2ZXM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktcGNwLW9w dGltaXplLWtlZXBhbGl2ZXMtMDEiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cmVkZHktcGNwLW9wdGltaXplLWtlZXBhbGl2ZXMtMDE8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1yZWRkeS1wY3Atb3B0aW1pemUta2VlcGFsaXZlcy0w MSI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1yZWRkeS1wY3Atb3B0 aW1pemUta2VlcGFsaXZlcy0wMTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWJz dHJhY3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IFBvcnQgQ29udHJvbCBQcm90b2NvbCBpcyB1 c2VmdWwgdG8gcmVkdWNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgTkFUIGFuZCBmaXJld2FsbCBrZWVwYWxpdmUgbWVzc2FnZXMgZm9yIGEgdmFy aWV0eSBvZiBhcHBsaWNhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgSUVURiBT ZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A148E9CE1xmbrcdx10ciscoc_-- From dthaler@microsoft.com Sat Jan 26 17:59:36 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3071E21F8540 for ; Sat, 26 Jan 2013 17:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_MEN=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVG0524VI42c for ; Sat, 26 Jan 2013 17:59:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3526D21F8528 for ; Sat, 26 Jan 2013 17:59:34 -0800 (PST) Received: from BY2FFO11FD003.protection.gbl (10.1.15.201) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sun, 27 Jan 2013 01:59:32 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Sun, 27 Jan 2013 01:59:31 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 27 Jan 2013 01:59:31 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.137]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0328.011; Sat, 26 Jan 2013 17:59:30 -0800 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 Thread-Index: AQHN6UG9cOD8YmlPSEid70vfsIAiKpg3WdGAgAIc+oCAARA1gIADo9OAgAB4CICAAuqrgIAAJ62AgAABGgCAGtnjkA== Date: Sun, 27 Jan 2013 01:59:30 +0000 Message-ID: <341064315C6D0D498193B256F238CF97334A22@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D32@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <01ab01cde953$1cbfed70$563fc850$@cisco.com> <037201cdeae9$b4109e80$1c31db80$@cisco.com> <50EA9909.4040401@viagenie.ca> <023501cdecf7$a19b9e20$e4d2da60$@cisco.com> <0b8101cdee80$cd8962d0$689c2870$@cisco.com> <50ED9248.8000306@viagenie.ca> In-Reply-To: <50ED9248.8000306@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(51856001)(50466001)(63696002)(49866001)(47976001)(74662001)(47776003)(4396001)(77982001)(44976002)(23676001)(74502001)(54316002)(20776003)(31966008)(55846006)(53806001)(47446002)(56776001)(54356001)(33656001)(56816002)(47736001)(79102001)(59766001)(16406001)(50986001)(46102001)(76482001)(57646009); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB020; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073966E86B Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 01:59:36 -0000 SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBhbGwgb2YgdGhlIGVtYWlscyBmcm9tIG90aGVycyBy ZWdhcmRpbmcgaXQuDQoNCkZyb20gdGhlIGxpc3QgZGlzY3Vzc2lvbiwgdGhlcmUgZG9lcyBhcHBl YXIgdG8gYmUgcm91Z2ggY29uc2Vuc3VzIGZvcg0KaGF2aW5nIHRoZSBhYmlsaXR5IGZvciBhbiBh cHBsaWNhdGlvbiB0byBnZXQgYSByYW5nZSBvZiBwb3J0cyBpbiBvbmUNClBDUCBtZXNzYWdlIGV4 Y2hhbmdlIHJhdGhlciB0aGFuIHJlcXVpcmluZyBhIHNlcGFyYXRlIGV4Y2hhbmdlIHBlciBwb3J0 Lg0KDQpUaGF0IHNhaWQsIEkgZG8gbm90IHRoaW5rIHRoYXQgZHJhZnQtdHNvdS1wY3AtbmF0Y29v cmQtMDkgaXMgcmVhZHkgdG8gYmUNCmFkb3B0ZWQgYXMgYSBXRyBkcmFmdC4NCg0KRmlyc3QsIGl0 IHNlZW1zIGNsZWFyIHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHVzZSBjYXNlcyBmb3Igd2hp Y2ggYSByYW5nZQ0Kb2YgcG9ydHMgaXMgdXNlZnVsIChhcyBTaW1vbiwgU2FtLCBhbmQgSWFuIGFt b25nIG90aGVycyBoYXZlDQpwb2ludGVkIG91dCkuICBIb3dldmVyLCBkcmFmdC10c291LXBjcC1u YXRjb29yZCBpcyB0b28gaGVhdmlseSBmb2N1c2VkDQpvbiBvbmUgcGFydGljdWxhciBzY2VuYXJp bywgYm90aCBpbiB0ZXJtcyBvZiBtb3RpdmF0aW9uIHRleHQgYW5kIGluIHRlcm1zDQpvZiB0aGUg cGFja2V0IGZvcm1hdCBwcm9wb3NlZCkuICBBbmQgaXQgc2VlbXMgaXQncyBzdGlsbCB1bmNsZWFy DQooYXMgQWxhaW4gYW5kIERhbiBoYXZlIHN0YXRlZCkgd2hldGhlciBQQ1AgaXMgdGhlIHJpZ2h0 IHNvbHV0aW9uIGZvcg0KdGhhdCBzY2VuYXJpby4gIEZvciB0aGUgbW9yZSBnZW5lcmljIHVzZSBj YXNlcywgSSBwZXJzb25hbGx5IGJlbGlldmUgdGhlDQpzcGVjaWZpYyBwYWNrZXQgZm9ybWF0IHBy b3Bvc2VkIGlzIG5vdCBhIGdvb2QgbWF0Y2ggYXMgbm90ZWQgYmVsb3cuDQoNClNwZWNpZmljIGZl ZWRiYWNrOg0KDQoxKSBQZXJzb25hbGx5IEkgZmluZCB0aGUgdXNlIG9mIHBvcnQgc2V0IHByZWZp eC9zdWZmaXgvaW5kZXgvbWFzaw0KICAgY29uZnVzaW5nIGFuZCB1bm5lY2Vzc2FyaWx5IGNvbXBs ZXggZm9yIHRoZSBtb3JlIGdlbmVyYWwgc2NlbmFyaW9zDQogICBvZiAicGxlYXNlIGdpdmUgbWUg TiBwb3J0cyIuICBGb3IgYSBnZW5lcmFsIG1lY2hhbmlzbSBJIHdvdWxkIGluc3RlYWQNCiAgIGV4 cGVjdCBhIHNpbXBsZSAibnVtYmVyIG9mIHBvcnRzIGRlc2lyZWQvYWxsb2NhdGVkIi4gIFRoYXQg c2ltcGxlDQogICBtZWNoYW5pc20gd291bGQgYWxzbyBiZSBtb3JlIGZsZXhpYmxlLiAgRm9yIGV4 YW1wbGUsIGl0IGNvdWxkIGFsbG93DQogICBzaXplcyB0aGF0IGFyZSBub3QgYSBwb3dlciBvZiB0 d28sIHRodXMgcHJldmVudGluZyB3YXN0ZWQgcG9ydHMgaW4NCiAgIHNvbWUgc2NlbmFyaW9zLg0K DQoyKSBJIGJlbGlldmUgYSBuZXcgT3Bjb2RlIGlzIG5vdCB0aGUgcmlnaHQgc29sdXRpb24gZm9y IHJlcXVlc3RpbmcgYQ0KICAgcmFuZ2Ugb2YgcG9ydHMuICBJbnN0ZWFkLCBJIHRoaW5rIGl0IHdv dWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gaGF2ZQ0KICAgYW4gT3B0aW9uLCB1c2FibGUgd2l0 aCB0aGUgZXhpc3RpbmcgTUFQIE9wY29kZSwgdGhhdCBoYWQgdGhlIG51bWJlcg0KICAgb2YgcG9y dHMgZGVzaXJlZC9hbGxvY2F0ZWQgc3RhcnRpbmcgYXQgdGhlIGV4dGVybmFsIHBvcnQgbnVtYmVy IGFscmVhZHkNCiAgIHByZXNlbnQgaW4gdGhlIE1BUCBPcGNvZGUuICBUaGlzIGFsbG93cyB0aGUg ZXhpc3RpbmcgbG9naWMgYW5kIGNvbnN0cmFpbnRzDQogICByZWdhcmRpbmcgTUFQIHRvIGJlIGFw cGxpZWQgd2l0aG91dCBkdXBsaWNhdGluZyBpdCBpbiBhbm90aGVyIHNwZWMNCiAgIG9yIGluIGFu b3RoZXIgc2V0IG9mIGNvZGUuDQoNCjMpIFRoZSBtb3RpdmF0aW9uIHRleHQgZG9lcyBub3QgdGFs ayBhYm91dCBvdGhlciB1c2UgY2FzZXMsIGFuZCBpbmRlZWQNCiAgIEknZCBwcmVmZXIgdGhhdCBh IGRvY3VtZW50IHdlIGFkb3B0IGJlIGdlbmVyaWMgaW4gc3VwcG9ydGluZyBwb3J0DQogICByYW5n ZSBzY2VuYXJpb3MgYW5kIG5vdCBmb2N1cyBvbiBhIHVzZSBjYXNlIG9uIHdoaWNoIHRoZXJlIGlz bid0IGNsZWFyDQogICBjb25zZW5zdXMgd2hldGhlciBQQ1AgaXMgdGhlIHJpZ2h0IHNvbHV0aW9u Lg0KDQo0KSBUaGUgdGl0bGUgYW5kIGZpbGVuYW1lIGFyZSBub3QgcGFydGljdWxhcmx5IGhlbHBm dWwgaW4gY29udmV5aW5nIHdoYXQNCiAgIHRoZSBkb2N1bWVudCBpcyBhYm91dC4gIEknZCBleHBl Y3QgYSBkb2N1bWVudCB3aG9zZSB0aXRsZSBhbmQgZmlsZW5hbWUNCiAgIGFyZSBhYm91dCBhIHBv cnQgcmFuZ2UgZXh0ZW5zaW9uLg0KDQpJZiB0aGUgYWJvdmUgaXRlbXMgd2VyZSBkb25lIGluIGEg ZG9jLCBpdCdzIHBvc3NpYmxlIHRoZSByZXN1bHQgbWlnaHQgaGF2ZQ0KbGl0dGxlIG9yIG5vIHRl eHQgZnJvbSB0aGUgY3VycmVudCBkb2N1bWVudCwgYW5kIEkgd29uZGVyIHdoZXRoZXIgaXQnZA0K YmUgZmFzdGVyIHRvIHN0YXJ0IGZyb20gc2NyYXRjaC4gIEhlbmNlIEkgZG9uJ3QgdGhpbmsgaXQn cyByZWFkeSB0byBiZQ0KYWRvcHRlZCBhcyBhIFdHIGRyYWZ0IHlldC4NCg0KLURhdmUNCg== From dthaler@microsoft.com Sat Jan 26 18:26:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE621F8939 for ; Sat, 26 Jan 2013 18:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzGvPRVmNM6z for ; Sat, 26 Jan 2013 18:26:25 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 416D121F88F5 for ; Sat, 26 Jan 2013 18:26:25 -0800 (PST) Received: from BL2FFO11FD002.protection.gbl (10.173.161.201) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.596.13; Sun, 27 Jan 2013 02:26:23 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Sun, 27 Jan 2013 02:26:22 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 27 Jan 2013 02:26:22 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.137]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0328.011; Sat, 26 Jan 2013 18:26:21 -0800 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac3qR6UhmcFJiIzJLE23V46U3knafAR7Mi5Q Date: Sun, 27 Jan 2013 02:26:20 +0000 Message-ID: <341064315C6D0D498193B256F238CF97334AC5@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <916CE6CF87173740BC8A2CE44309696204550473@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696204550473@008-AM1MPN1-053.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(189002)(377454001)(13464002)(199002)(164054002)(31966008)(54316002)(44976002)(49866001)(74502001)(15202345001)(4396001)(74662001)(47776003)(47736001)(47446002)(47976001)(46102001)(46406002)(5343635001)(77982001)(79102001)(59766001)(5343655001)(20776003)(63696002)(50986001)(55846006)(56816002)(33656001)(56776001)(50466001)(16406001)(23726001)(51856001)(54356001)(76482001)(53806001)(57646009); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB024; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073966E86B Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 02:26:26 -0000 I have read the draft and the list discussion. I think there is need for a mechanism to explicitly learn the PREFIX64, and= indeed in the document shepherd writeup I did for http://tools.ietf.org/html/draft= -ietf- behave-nat64-learn-analysis-03 I referred to this draft: > The document specifies a heuristic that is not perfect and so some > points were rough, but the constraint for this document was to operate > without changes to code (only configuration) in existing networks. > Given that constraint, there was strong consensus. Relaxing the > constraint would allow one to do better, and that is the focus of a > draft recently submitted to the PCP WG. So I do not think this draft should update or obsolete that one, as the=20 constraints are quite different. That is, use an explicit mechanism if su= pported, else use the heuristic. I believe draft-boucadair-pcp-nat64-prefix64-option needs work but is a decent starting point (for instance it should not keep both the Opcode an= d the Option, and in my view the Option is better) should the PCP WG take on this work. The biggest open question that would affect adoption however is the= =20 one Teemu raised in the email below: " what is the benefit of defining PCP option instead of DHCPv6 option?" After all, we're defining a DHCP option to learn the PCP server(s), so why wouldn't the client be able to learn the PREFIX64(s) in the same DHCP excha= nge? I haven't seen an answer to this question yet, and would like to see consen= sus on the answer before confirming adoption. -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > teemu.savolainen@nokia.com > Sent: Thursday, January 3, 2013 11:01 PM > To: repenno@cisco.com; pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix= 64- > option >=20 > Hi, >=20 > If the PCP server readily has information about Pref64::/n, then why not = tell > that to PCP client indeed. But if it has not, then I would ask what is th= e > benefit of defining PCP option instead of DHCPv6 option? >=20 > In the Behave WG we have been working on analysis of different Pref64::/n > discovery tools, currently in RFC Editor: http://tools.ietf.org/html/dra= ft-ietf- > behave-nat64-learn-analysis-03 >=20 > The Behave's work resulted in heuristic approach being selected, which is > currently in AD evaluation: http://tools.ietf.org/html/draft-ietf-behave- > nat64-discovery-heuristic-13 >=20 > Should this document formally update learn-analysis and have a section wi= th > similar analysis, stating pros and cons and then concluding why it is use= ful to > have this solution for PCP deployment scenarios? >=20 > In this document I would like to see text talking about relation to said = analysis > document and heuristic approach. For example, if a host does Pref64::/n > discovery with heuristic approach for its generic use (such as local AAAA > record synthesis), is there utility for SIP client to perform separate di= scovery > also with PCP client? >=20 > Nit: the IPv4-only SIP UA can be IPv4-only, but terminology about IPv6-on= ly > SIP UE is not that accurate IMHO: the draft's SIP UA in IPv6-only *access= * > seems to be quite capable of understanding IPv4-world (adding IPv4 > addresses to SDP offer), hence maybe better say SIP UA in IPv6-only acces= s, > instead of IPv6-only SIP UA? >=20 > Best regards, >=20 > Teemu >=20 >=20 >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > ext Reinaldo Penno (repenno) > > Sent: 03. tammikuuta 2013 01:30 > > To: pcp@ietf.org > > Subject: [pcp] WG Call for Adoption: > > draft-boucadair-pcp-nat64-prefix64- > > option > > > > Hello, > > > > First of all, Happy new Year! > > > > Based on the discussions at IETF Atlanta Meeting we would like to > > start call of adoption on a few drafts, with the first one below. > > > > This email starts a 2-week consensus call on adopting > > > > Title : Learn NAT64 PREFIX64s using PCP > > Author(s) : M. Boucadair > > Filename : draft-boucadair-pcp-nat64-prefix64-option-02.txt > > URL : > > http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02. > > txt > > > > Please read the current revision and state you opinion either for or > > against adoption (and with reasoning why) in the mailing list. The > > call for adoption ends 16th January 2013. > > > > > > Thanks, > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From achatz@forthnetgroup.gr Sun Jan 27 11:33:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9DF21F879D for ; Sun, 27 Jan 2013 11:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36fBpGTWZMQH for ; Sun, 27 Jan 2013 11:33:48 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6221F8581 for ; Sun, 27 Jan 2013 11:33:47 -0800 (PST) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0RJXihg008392; Sun, 27 Jan 2013 21:33:44 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0RJXiiv029595; Sun, 27 Jan 2013 21:33:44 +0200 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0RJXhCL019400; Sun, 27 Jan 2013 21:33:44 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <51058118.5050006@forthnetgroup.gr> Date: Sun, 27 Jan 2013 21:33:44 +0200 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15.1 MIME-Version: 1.0 To: Qiong References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <50F43CAB.7000206@forthnetgroup.gr> <50FBE2C9.3060009@forthnetgroup.gr> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: draft-tsou-pcp-natcoord-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 19:33:49 -0000
Hi Qiong,

Your proposal seems ok (and agrees with mine), as long as this behavior can be disabled in order to use the default one.

--
Tassos
Qiong wrote on 21/01/2013 16:23:
Dear Tassos,

Thanks for your explaination. I now understand your case.

I think the only difference is the port-set format. The current draft only defines contiguous port-mask format. In order to support your case, we can add an option to convey these individual non-contiguous ports in a single request with PREFER_FAILURE. Then, the PCP server will only reply the client when it can find an available external address to meet all his/her requirements (follow the PREFER_FAILURE option). Is it ok for you ?

Best wishes
Qiong

On Sun, Jan 20, 2013 at 8:27 PM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
Hi Qiong,

I'm quoting my original email to the pcp authors.
If you need more info, please don't hesitate to contact me.

I've read the draft (26) twice during the last weeks (we'll hopefully try PCP soon in our network) and i think i'm missing the feature to include multiple ports in the same request/response (when talking about CPE as PCP client and a router/AFTR as PCP server). I've read draft-tsou-pcp-natcoord which came out due to a different motivation, but i don't think it fits in and i would certainly prefer to have it in the base spec. If i'm not wrong, the absence of this feature means that there is no way to have the PCP client instruct the PCP server to assign any external ip address, as long as ALL the specific port requirements of a single request are met.

Take the following scenario for example:

If a PCP client wants ports 80,443,8080 (the user has configured port forwarding for these ports in his/her CPE) and these are not available on its current external ip address, then by trying continuous one port requests the client might never get all three ports in the same ip address, while at the time of any single request there could be at least one external ip address with all these three ports available.
i.e. as a solution an extra option should be given to change (causing a session "disconnect" if needed) to a new external ip address that can offer ALL three ports (such an option could be activated on the PCP client by the provider, probably as a new DHCP option while discovering the PCP server). If such an external ip address is not available, then the behavior of PREFER_FAILURE should be followed (if explicitly requested).

Keeping that in mind, i couldn't also find any recommendations on whether the PCP server should try to service requests from PCP clients in a specific order that will allow as many PCP clients as possible to succeed in their port requirements. Is this somehow arranged by some other functionality/protocol/entity?
If multiple ports could be assigned in the same request/response, then it would be easier for the PCP server to assign external addresses/ports after a mass reconnect of PCP clients.
After all, i don't expect port forwarding rules to change often in CPEs after the initial configuration.

Generally, i'm worried of having a lot of subscribers using external ip addresses that do not have the requested ports available after some time, while many other addresses can satisfy their port requirements. In such a case i would prefer to have the option (or give the option to subscriber) of "transferring" him/her from one ip to another, in order to satisfy all his/her requirements. 


Thanks,
Tassos
Qiong wrote on 15/1/2013 04:22:
Dear Tassos,

Yes, we can easily modify to support it. Could you explain a little more on the intention of this use case ?

Best wishes
Qiong


On Tue, Jan 15, 2013 at 1:13 AM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
I support this draft, but i would like to see more cases covered (and some parts are not very clearly written).

Also, as i already have informed the pcp authors about the base spec, i was hoping to see a solution for non-continuous
port assignments in a single request.
Any plans for that?

Thanks,
Tassos

Reinaldo Penno (repenno) wrote on 03/01/2013 01:34:
> Hello,
>
> This email starts a 2-week consensus call on adopting
>
>      Title     : Using PCP To Coordinate Between the CGN and Home Gateway
>      Author(s) : Q. Sun et al
>      Filename  : draft-tsou-pcp-natcoord-09.txt
>      URL       : http://tools.ietf.org/id/draft-tsou-pcp-natcoord-09.txt
>
> Please read the current revision and state you opinion either for or
> against adoption (and with reasoning why) in the mailing list.
>
> The call for adoption ends 16th January 2013.
>
> Thanks,
>
>
>
>
>
>
>
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>

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



--
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================





--
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================


From mohamed.boucadair@orange.com Mon Jan 28 02:03:14 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75ED21F8552 for ; Mon, 28 Jan 2013 02:03:14 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwNvikvZtJ+R for ; Mon, 28 Jan 2013 02:03:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7822E21F857D for ; Mon, 28 Jan 2013 02:03:13 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id F2B7B2DC25F; Mon, 28 Jan 2013 11:03:11 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D6C9723806B; Mon, 28 Jan 2013 11:03:11 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 28 Jan 2013 11:03:11 +0100 From: To: Dave Thaler , "pcp@ietf.org" Date: Mon, 28 Jan 2013 11:03:10 +0100 Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac3qR6UhmcFJiIzJLE23V46U3knafAR7Mi5QAEGtKHA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EA87A942D@PUEXCB1B.nanterre.francetelecom.fr> References: <916CE6CF87173740BC8A2CE44309696204550473@008-AM1MPN1-053.mgdnok.nokia.com> <341064315C6D0D498193B256F238CF97334AC5@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <341064315C6D0D498193B256F238CF97334AC5@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.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.1.28.81523 Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 10:03:14 -0000 Dear Dave, For your question about DHCP, I have already answered to this question here= : http://www.ietf.org/mail-archive/web/pcp/current/msg02258.html. Additional items in which PCP is superior to DHCP are: * Retrieving the information directly from the discovered PCP Server(s) is = more flexible from an operational perspective: think about changing the PRE= FIX64 configured to a NAT64, for planned maintenance operations the traffic= may be redirected to another NAT64 (can be achieved by using a distinct PR= EFIX64 for that backup NAT64), deployment of several NAT64 with distinct PR= EFIX64s, etc.=20 * For organizations which adopt a two-level indirection (centralized DHCP s= erver for generic configuration) and a regional team to operate regional po= rtions of the network, the information about the PREFIX64 used in each regi= onal area may not be available at the DHCP level.=20 * Unlike DHCP, applications may embed a PCP Client (see for instance http:/= /tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-4.2) Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : dimanche 27 janvier 2013 03:26 >=C0 : pcp@ietf.org >Objet : Re: [pcp] WG Call for Adoption:=20 >draft-boucadair-pcp-nat64-prefix64-option > >I have read the draft and the list discussion. > >I think there is need for a mechanism to explicitly learn the=20 >PREFIX64, and indeed >in the document shepherd writeup I did for=20 >http://tools.ietf.org/html/draft-ietf- >behave-nat64-learn-analysis-03 I referred to this draft: >> The document specifies a heuristic that is not perfect and so some >> points were rough, but the constraint for this document was=20 >to operate >> without changes to code (only configuration) in existing networks. >> Given that constraint, there was strong consensus. Relaxing the >> constraint would allow one to do better, and that is the focus of a >> draft recently submitted to the PCP WG. > >So I do not think this draft should update or obsolete that=20 >one, as the=20 >constraints are quite different. That is, use an explicit=20 >mechanism if supported, >else use the heuristic. > >I believe draft-boucadair-pcp-nat64-prefix64-option needs work but is >a decent starting point (for instance it should not keep both=20 >the Opcode and the >Option, and in my view the Option is better) should the PCP WG=20 >take on this >work. The biggest open question that would affect adoption=20 >however is the=20 >one Teemu raised in the email below: >" what is the benefit of defining PCP option instead of DHCPv6 option?" >After all, we're defining a DHCP option to learn the PCP=20 >server(s), so why >wouldn't the client be able to learn the PREFIX64(s) in the=20 >same DHCP exchange? > >I haven't seen an answer to this question yet, and would like=20 >to see consensus >on the answer before confirming adoption. > >-Dave > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> teemu.savolainen@nokia.com >> Sent: Thursday, January 3, 2013 11:01 PM >> To: repenno@cisco.com; pcp@ietf.org >> Subject: Re: [pcp] WG Call for Adoption:=20 >draft-boucadair-pcp-nat64-prefix64- >> option >>=20 >> Hi, >>=20 >> If the PCP server readily has information about Pref64::/n,=20 >then why not tell >> that to PCP client indeed. But if it has not, then I would=20 >ask what is the >> benefit of defining PCP option instead of DHCPv6 option? >>=20 >> In the Behave WG we have been working on analysis of=20 >different Pref64::/n >> discovery tools, currently in RFC Editor: =20 >http://tools.ietf.org/html/draft-ietf- >> behave-nat64-learn-analysis-03 >>=20 >> The Behave's work resulted in heuristic approach being=20 >selected, which is >> currently in AD evaluation:=20 >http://tools.ietf.org/html/draft-ietf-behave- >> nat64-discovery-heuristic-13 >>=20 >> Should this document formally update learn-analysis and have=20 >a section with >> similar analysis, stating pros and cons and then concluding=20 >why it is useful to >> have this solution for PCP deployment scenarios? >>=20 >> In this document I would like to see text talking about=20 >relation to said analysis >> document and heuristic approach. For example, if a host does=20 >Pref64::/n >> discovery with heuristic approach for its generic use (such=20 >as local AAAA >> record synthesis), is there utility for SIP client to=20 >perform separate discovery >> also with PCP client? >>=20 >> Nit: the IPv4-only SIP UA can be IPv4-only, but terminology=20 >about IPv6-only >> SIP UE is not that accurate IMHO: the draft's SIP UA in=20 >IPv6-only *access* >> seems to be quite capable of understanding IPv4-world (adding IPv4 >> addresses to SDP offer), hence maybe better say SIP UA in=20 >IPv6-only access, >> instead of IPv6-only SIP UA? >>=20 >> Best regards, >>=20 >> Teemu >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=20 >On Behalf Of >> > ext Reinaldo Penno (repenno) >> > Sent: 03. tammikuuta 2013 01:30 >> > To: pcp@ietf.org >> > Subject: [pcp] WG Call for Adoption: >> > draft-boucadair-pcp-nat64-prefix64- >> > option >> > >> > Hello, >> > >> > First of all, Happy new Year! >> > >> > Based on the discussions at IETF Atlanta Meeting we would like to >> > start call of adoption on a few drafts, with the first one below. >> > >> > This email starts a 2-week consensus call on adopting >> > >> > Title : Learn NAT64 PREFIX64s using PCP >> > Author(s) : M. Boucadair >> > Filename :=20 >draft-boucadair-pcp-nat64-prefix64-option-02.txt >> > URL : >> >=20 >http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02. >> > txt >> > >> > Please read the current revision and state you opinion=20 >either for or >> > against adoption (and with reasoning why) in the mailing list. The >> > call for adoption ends 16th January 2013. >> > >> > >> > Thanks, >> > >> > >> > _______________________________________________ >> > pcp mailing list >> > pcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/pcp >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From teemu.savolainen@nokia.com Mon Jan 28 06:26:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8461421F8871 for ; Mon, 28 Jan 2013 06:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNSqy6H-5wAG for ; Mon, 28 Jan 2013 06:26:48 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 40EC621F86DE for ; Mon, 28 Jan 2013 06:26:47 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0SEQew4010078; Mon, 28 Jan 2013 16:26:44 +0200 Received: from smtp.mgd.nokia.com ([94.245.81.65]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jan 2013 16:26:05 +0200 Received: from 008-DB3MRN1-051.mgdnok.nokia.com ([169.254.5.195]) by 008-DB3MMR1-013.mgdnok.nokia.com ([94.245.81.65]) with mapi id 14.02.0318.003; Mon, 28 Jan 2013 14:26:04 +0000 From: To: , , Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option Thread-Index: Ac3qR6UhmcFJiIzJLE23V46U3knafAR7Mi5QAEGtKHAACf0nkA== Date: Mon, 28 Jan 2013 14:26:04 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962045986A9@008-DB3MRN1-051.mgdnok.nokia.com> References: <916CE6CF87173740BC8A2CE44309696204550473@008-AM1MPN1-053.mgdnok.nokia.com> <341064315C6D0D498193B256F238CF97334AC5@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36EA87A942D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA87A942D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCe0v9E1GtLYFx/mmaG63icvzPS1iHxB2K1yqR0VpN7cv/EmsYF9McaF8wAjzWwn0XCQ1cMud0xxO50muisYCbVtbSJuf839WbbDjFnK7nQFQSVii7ReQtf3v9rFNt+UQVb9T/eJOp9tBpkQsa7V7YMQj7vMc/Cn81LuF8euhw9+R2Ns5b2UOHdbdSKEXfMyMTjuN8iqONc5zd5KlPXnpF+JzVp6kcPHhsbd1QALBkKPN9ZDBiyTBDaRkPBwyGNXxbk= x-originating-ip: [10.163.162.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2013 14:26:05.0256 (UTC) FILETIME=[68080C80:01CDFD63] X-Nokia-AV: Clean Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:26:49 -0000 Med, Thank you for the pointer and extra justifications. Consider my concern cle= ared and hence I'm also positive for adoption. Best regards, Teemu > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > ext mohamed.boucadair@orange.com > Sent: 28. tammikuuta 2013 12:03 > To: Dave Thaler; pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix= 64- > option > > Dear Dave, > > For your question about DHCP, I have already answered to this question > here: http://www.ietf.org/mail-archive/web/pcp/current/msg02258.html. > > Additional items in which PCP is superior to DHCP are: > > * Retrieving the information directly from the discovered PCP Server(s) i= s > more flexible from an operational perspective: think about changing the > PREFIX64 configured to a NAT64, for planned maintenance operations the > traffic may be redirected to another NAT64 (can be achieved by using a > distinct PREFIX64 for that backup NAT64), deployment of several NAT64 wit= h > distinct PREFIX64s, etc. > > * For organizations which adopt a two-level indirection (centralized DHCP > server for generic configuration) and a regional team to operate regional > portions of the network, the information about the PREFIX64 used in each > regional area may not be available at the DHCP level. > > * Unlike DHCP, applications may embed a PCP Client (see for instance > http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments- > 00#section-4.2) > > Cheers, > Med > > >-----Message d'origine----- > >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >Dave Thaler Envoy=E9 : dimanche 27 janvier 2013 03:26 =C0 : pcp@ietf.org > >Objet : Re: [pcp] WG Call for Adoption: > >draft-boucadair-pcp-nat64-prefix64-option > > > >I have read the draft and the list discussion. > > > >I think there is need for a mechanism to explicitly learn the PREFIX64, > >and indeed in the document shepherd writeup I did for > >http://tools.ietf.org/html/draft-ietf- > >behave-nat64-learn-analysis-03 I referred to this draft: > >> The document specifies a heuristic that is not perfect and so some > >> points were rough, but the constraint for this document was > >to operate > >> without changes to code (only configuration) in existing networks. > >> Given that constraint, there was strong consensus. Relaxing the > >> constraint would allow one to do better, and that is the focus of a > >> draft recently submitted to the PCP WG. > > > >So I do not think this draft should update or obsolete that one, as the > >constraints are quite different. That is, use an explicit > >mechanism if supported, > >else use the heuristic. > > > >I believe draft-boucadair-pcp-nat64-prefix64-option needs work but is a > >decent starting point (for instance it should not keep both the Opcode > >and the Option, and in my view the Option is better) should the PCP WG > >take on this > >work. The biggest open question that would affect adoption > >however is the > >one Teemu raised in the email below: > >" what is the benefit of defining PCP option instead of DHCPv6 option?" > >After all, we're defining a DHCP option to learn the PCP server(s), so > >why wouldn't the client be able to learn the PREFIX64(s) in the same > >DHCP exchange? > > > >I haven't seen an answer to this question yet, and would like to see > >consensus on the answer before confirming adoption. > > > >-Dave > > > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > >> teemu.savolainen@nokia.com > >> Sent: Thursday, January 3, 2013 11:01 PM > >> To: repenno@cisco.com; pcp@ietf.org > >> Subject: Re: [pcp] WG Call for Adoption: > >draft-boucadair-pcp-nat64-prefix64- > >> option > >> > >> Hi, > >> > >> If the PCP server readily has information about Pref64::/n, > >then why not tell > >> that to PCP client indeed. But if it has not, then I would > >ask what is the > >> benefit of defining PCP option instead of DHCPv6 option? > >> > >> In the Behave WG we have been working on analysis of > >different Pref64::/n > >> discovery tools, currently in RFC Editor: > >http://tools.ietf.org/html/draft-ietf- > >> behave-nat64-learn-analysis-03 > >> > >> The Behave's work resulted in heuristic approach being > >selected, which is > >> currently in AD evaluation: > >http://tools.ietf.org/html/draft-ietf-behave- > >> nat64-discovery-heuristic-13 > >> > >> Should this document formally update learn-analysis and have > >a section with > >> similar analysis, stating pros and cons and then concluding > >why it is useful to > >> have this solution for PCP deployment scenarios? > >> > >> In this document I would like to see text talking about > >relation to said analysis > >> document and heuristic approach. For example, if a host does > >Pref64::/n > >> discovery with heuristic approach for its generic use (such > >as local AAAA > >> record synthesis), is there utility for SIP client to > >perform separate discovery > >> also with PCP client? > >> > >> Nit: the IPv4-only SIP UA can be IPv4-only, but terminology > >about IPv6-only > >> SIP UE is not that accurate IMHO: the draft's SIP UA in > >IPv6-only *access* > >> seems to be quite capable of understanding IPv4-world (adding IPv4 > >> addresses to SDP offer), hence maybe better say SIP UA in > >IPv6-only access, > >> instead of IPv6-only SIP UA? > >> > >> Best regards, > >> > >> Teemu > >> > >> > >> > >> > -----Original Message----- > >> > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] > >On Behalf Of > >> > ext Reinaldo Penno (repenno) > >> > Sent: 03. tammikuuta 2013 01:30 > >> > To: pcp@ietf.org > >> > Subject: [pcp] WG Call for Adoption: > >> > draft-boucadair-pcp-nat64-prefix64- > >> > option > >> > > >> > Hello, > >> > > >> > First of all, Happy new Year! > >> > > >> > Based on the discussions at IETF Atlanta Meeting we would like to > >> > start call of adoption on a few drafts, with the first one below. > >> > > >> > This email starts a 2-week consensus call on adopting > >> > > >> > Title : Learn NAT64 PREFIX64s using PCP > >> > Author(s) : M. Boucadair > >> > Filename : > >draft-boucadair-pcp-nat64-prefix64-option-02.txt > >> > URL : > >> > > >http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02. > >> > txt > >> > > >> > Please read the current revision and state you opinion > >either for or > >> > against adoption (and with reasoning why) in the mailing list. The > >> > call for adoption ends 16th January 2013. > >> > > >> > > >> > Thanks, > >> > > >> > > >> > _______________________________________________ > >> > pcp mailing list > >> > pcp@ietf.org > >> > https://www.ietf.org/mailman/listinfo/pcp > >> _______________________________________________ > >> pcp mailing list > >> pcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Thu Jan 31 05:00:34 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7056021F85DA for ; Thu, 31 Jan 2013 05:00:34 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9yx2GEeBpQL for ; Thu, 31 Jan 2013 05:00:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E91D721F84E6 for ; Thu, 31 Jan 2013 05:00:33 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id B1FC818C65E; Thu, 31 Jan 2013 14:00:32 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 75E94238048; Thu, 31 Jan 2013 14:00:32 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 31 Jan 2013 14:00:32 +0100 From: To: "pcp@ietf.org" Importance: high X-Priority: 1 Date: Thu, 31 Jan 2013 14:00:31 +0100 Thread-Topic: draft-ietf-pcp-dhcp Thread-Index: Ac3/svMhIiSqbDmMSHGU8XxAMPj6cQ== Message-ID: <94C682931C08B048B7A8645303FDC9F36EA9C83E5A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: Ted Lemon Subject: [pcp] draft-ietf-pcp-dhcp X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:00:34 -0000 Dear all, As agreed in the last IETF meeting, I contacted Ted in Atlanta to check wit= h him what is the recommended approach to encode multiple strings included = in the same dhcp option. As a reminder, -05 assumes a space character is us= ed as separator. Ted prefers the use of length-encoded string. I updated th= e text accordingly. I also updated the text to recall the consensus of the = wg and explain why RFC1035-encoding was abandoned in favor of UTF-8 string = encoding (the main reason is to not restrict it to DNS as other resolution = libraries can be supported). The new revised text includes also changes to = resolve the comments received in the WGLC.=20 Even if -06 is ready for submission, I preferred to not submit it before ch= ecking with the WG how to resolve an issue raised by Ted. Ted (as a chair o= f dhc) thinks the use of UTF-8 string encoding is a bad design because it i= s difficult to validate the option. I already answered to that objection as= DNS itself does not put any restriction on labels except a label must not = be more than 63 characters. That's my personal opinion but as an editor of = the document, I need more input for the WG on how to proceed given the comm= ent raised from Ted:=20 (1) maintain the current design which is aligned with the wg consensus (2) roll-back to the RFC1035-encoding we had in -00, -01, 02- and -03 rev = of the draft and explain what to do for trailing dot when an IP address lit= eral is included. Thanks in advance.=20 Cheers, Med= From Ted.Lemon@nominum.com Thu Jan 31 05:41:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3127121F85E8 for ; Thu, 31 Jan 2013 05:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBiLo51WIpbg for ; Thu, 31 Jan 2013 05:41:43 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 70D8D21F8770 for ; Thu, 31 Jan 2013 05:41:43 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUQp0ks7iVzbnKoLHWBHF6ZxEDiFzdQxK@postini.com; Thu, 31 Jan 2013 05:41:43 PST 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 9F06B1B8404 for ; Thu, 31 Jan 2013 05:41:37 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-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 966A5190043 for ; Thu, 31 Jan 2013 05:41:37 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 05:41:37 -0800 From: Ted Lemon To: "pcp@ietf.org" Thread-Topic: draft-ietf-pcp-dhcp Thread-Index: Ac3/svMhIiSqbDmMSHGU8XxAMPj6cQASMtEA Importance: high X-Priority: 1 Date: Thu, 31 Jan 2013 13:41:36 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747476816@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36EA9C83E5A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA9C83E5A@PUEXCB1B.nanterre.francetelecom.fr> 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: <52C47057582E96449D73C395439ED676@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] draft-ietf-pcp-dhcp X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 13:41:44 -0000 On Jan 31, 2013, at 8:00 AM, mohamed.boucadair@orange.com wrote: > Even if -06 is ready for submission, I preferred to not submit it before = checking with the WG how to resolve an issue raised by Ted. Ted (as a chair= of dhc) thinks the use of UTF-8 string encoding is a bad design because it= is difficult to validate the option. I already answered to that objection = as DNS itself does not put any restriction on labels except a label must no= t be more than 63 characters. This completely misrepresents the concern I expressed. First of all, DNS = _wire format_ allows any value in any field, but DNS _representation format= _ is not clearly defined anywhere, and there are complexities, particularly= since you want to be able to parse both FQDNs and IP addresses out of the = same string representation, and since you have to support internationalized= domain names. Of course, there are implementations of library routines that take a user-s= upplied string and parse an FQDN or IP address out of it=97it's not rocket = science. But there is no clear specification; no BNF we can follow to det= ermine which strings are valid and which aren't. More to the point, thoug= h, this is not how other DHCP options with similar use cases have been done= . Inventing new formats to represent the same data complicates implementa= tions, and we'd prefer to avoid it. The DHC working group has a fairly cl= ear consensus that there are preferred ways to do it, which we have attempt= ed to communicate. We asked Med to articulate a use case that motivates t= his particular solution over the preferred solutions, and he did not articu= late an actual use case. We also asked Med to explain why it was necessary to use an FQDN rather tha= n having the DHCP server derive an IP address from an FQDN in its configura= tion, and the only answer I could get was that there might be some situatio= n where there'd be a split DNS configuration, and the correct answer would = be available to the DHCP client and not the DHCP server. In general I'm a= bit of a purist, and have trouble with the idea that an IETF protocol shou= ld bend over backwards to accommodate this use case. I also wonder if the= working group really considers this a serious use case. In general, the way that DHCP handles this problem is that the DHCP server = administrator configures an FQDN on the DHCP server. When a request comes= in, the DHCP server does a DNS lookup, resolving the FQDN into one or mor= e IP addresses. These addresses are then sent to the client. This relie= ves the client of the need to do the FQDN lookup itself, which is generally= considered desirable since some consumers of DHCP service are fairly low-l= evel devices, like boot proms, which don't have their own resolvers. This= solution addresses every use case Med presented except the split DNS use c= ase. In the split DNS use case, a wire-encoded FQDN is adequate; there is= no need to invent a new encoding. So I'd really appreciate it if the PCP working group would at least conside= r stopping trying to cram config file strings into DHCP packets, and follow= the recommendations of the DHC working group as to how to represent addres= ses. I think that's the place to start=97if somebody has a strong requirement th= at is not satisfied by the usual practice, that requirement should be state= d explicitly. It should be the case that current practice does not satisf= y that requirement; not merely that there is a personal preference for goin= g against current practice. From mohamed.boucadair@orange.com Thu Jan 31 06:04:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82821F84F9 for ; Thu, 31 Jan 2013 06:04:32 -0800 (PST) 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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsl3AYKTBcWV for ; Thu, 31 Jan 2013 06:04:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF921F8540 for ; Thu, 31 Jan 2013 06:04:31 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D20B6264674; Thu, 31 Jan 2013 15:04:29 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B81064C060; Thu, 31 Jan 2013 15:04:29 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 31 Jan 2013 15:04:29 +0100 From: To: Ted Lemon , "pcp@ietf.org" Date: Thu, 31 Jan 2013 15:04:28 +0100 Thread-Topic: draft-ietf-pcp-dhcp Thread-Index: Ac3/svMhIiSqbDmMSHGU8XxAMPj6cQASMtEAABCLoNA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EA9C83EFB@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EA9C83E5A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747476816@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747476816@mbx-01.win.nominum.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: 2012.10.24.110314 Subject: Re: [pcp] draft-ietf-pcp-dhcp X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:04:32 -0000 Hi Ted, Thank you Ted for detailing your concerns. This is the purpose of this thre= ad and this is why I cced you.=20 Mandating the server to resolve the name and return an IP-Address is a depl= oyment option but this is not a valid option for some providers. I already = discussed this in http://tools.ietf.org/html/draft-boucadair-dhc-address-na= me-encoding-03. We had a long discussion in dhc mailing list, no need to re= play that discussion here. Instead of opening the endless discussion IP address vs. FQDN, I really hop= e to scope this discussion to the encoding options of a name: the working a= chieved a consensus to encode a name as a string and not over specify the o= ption to be DNS-specific (see http://www.ietf.org/mail-archive/web/pcp/curr= ent/msg01776.html). Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Ted Lemon >Envoy=E9 : jeudi 31 janvier 2013 14:42 >=C0 : pcp@ietf.org >Objet : Re: [pcp] draft-ietf-pcp-dhcp >Importance : Haute > >On Jan 31, 2013, at 8:00 AM, mohamed.boucadair@orange.com wrote: >> Even if -06 is ready for submission, I preferred to not=20 >submit it before checking with the WG how to resolve an issue=20 >raised by Ted. Ted (as a chair of dhc) thinks the use of UTF-8=20 >string encoding is a bad design because it is difficult to=20 >validate the option. I already answered to that objection as=20 >DNS itself does not put any restriction on labels except a=20 >label must not be more than 63 characters. > >This completely misrepresents the concern I expressed. First=20 >of all, DNS _wire format_ allows any value in any field, but=20 >DNS _representation format_ is not clearly defined anywhere,=20 >and there are complexities, particularly since you want to be=20 >able to parse both FQDNs and IP addresses out of the same=20 >string representation, and since you have to support=20 >internationalized domain names. > >Of course, there are implementations of library routines that=20 >take a user-supplied string and parse an FQDN or IP address=20 >out of it-it's not rocket science. But there is no clear=20 >specification; no BNF we can follow to determine which strings=20 >are valid and which aren't. More to the point, though, this=20 >is not how other DHCP options with similar use cases have been=20 >done. Inventing new formats to represent the same data=20 >complicates implementations, and we'd prefer to avoid it. =20 >The DHC working group has a fairly clear consensus that there=20 >are preferred ways to do it, which we have attempted to=20 >communicate. We asked Med to articulate a use case that=20 >motivates this particular solution over the preferred=20 >solutions, and he did not articulate an actual use case. > >We also asked Med to explain why it was necessary to use an=20 >FQDN rather than having the DHCP server derive an IP address=20 >from an FQDN in its configuration, and the only answer I could=20 >get was that there might be some situation where there'd be a=20 >split DNS configuration, and the correct answer would be=20 >available to the DHCP client and not the DHCP server. In=20 >general I'm a bit of a purist, and have trouble with the idea=20 >that an IETF protocol should bend over backwards to=20 >accommodate this use case. I also wonder if the working=20 >group really considers this a serious use case. > >In general, the way that DHCP handles this problem is that the=20 >DHCP server administrator configures an FQDN on the DHCP=20 >server. When a request comes in, the DHCP server does a DNS=20 >lookup, resolving the FQDN into one or more IP addresses. =20 >These addresses are then sent to the client. This relieves=20 >the client of the need to do the FQDN lookup itself, which is=20 >generally considered desirable since some consumers of DHCP=20 >service are fairly low-level devices, like boot proms, which=20 >don't have their own resolvers. This solution addresses=20 >every use case Med presented except the split DNS use case. =20 >In the split DNS use case, a wire-encoded FQDN is adequate;=20 >there is no need to invent a new encoding. > >So I'd really appreciate it if the PCP working group would at=20 >least consider stopping trying to cram config file strings=20 >into DHCP packets, and follow the recommendations of the DHC=20 >working group as to how to represent addresses. > >I think that's the place to start-if somebody has a strong=20 >requirement that is not satisfied by the usual practice, that=20 >requirement should be stated explicitly. It should be the=20 >case that current practice does not satisfy that requirement;=20 >not merely that there is a personal preference for going=20 >against current practice. > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From mohamed.boucadair@orange.com Thu Jan 31 06:08:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6F21F862A for ; Thu, 31 Jan 2013 06:08:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgL91fE7P8SJ for ; Thu, 31 Jan 2013 06:08:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8547221F8628 for ; Thu, 31 Jan 2013 06:08:25 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id E5C873B43A9; Thu, 31 Jan 2013 15:08:24 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CBAD54C060; Thu, 31 Jan 2013 15:08:24 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 31 Jan 2013 15:08:24 +0100 From: To: Ted Lemon , "pcp@ietf.org" Date: Thu, 31 Jan 2013 15:08:23 +0100 Thread-Topic: OFFLINE RE: draft-ietf-pcp-dhcp Thread-Index: Ac3/svMhIiSqbDmMSHGU8XxAMPj6cQASMtEAABCLoNAAIIEs0A== Message-ID: <94C682931C08B048B7A8645303FDC9F36EA9C83F0A@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EA9C83E5A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747476816@mbx-01.win.nominum.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: 2012.10.24.110314 Subject: [pcp] OFFLINE RE: draft-ietf-pcp-dhcp X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:08:26 -0000 Ted,=20 I really appreciate your help.=20 As an editor of the document, I cannot change the encoding on my own and ro= ll back to rfc1035 encoding we had in earlier versions of the document. I h= ope this thread will stimulate discussion and see more inputs.=20 In the lack of any additional argument from the wg, I will abandon the utf-= 8 string encoding.=20 Cheers, Med >-----Message d'origine----- >De : BOUCADAIR Mohamed OLNC/OLN=20 >Envoy=E9 : jeudi 31 janvier 2013 15:04 >=C0 : 'Ted Lemon'; pcp@ietf.org >Objet : RE: draft-ietf-pcp-dhcp > >Hi Ted, > >Thank you Ted for detailing your concerns. This is the purpose=20 >of this thread and this is why I cced you.=20 > >Mandating the server to resolve the name and return an=20 >IP-Address is a deployment option but this is not a valid=20 >option for some providers. I already discussed this in=20 >http://tools.ietf.org/html/draft-boucadair-dhc-address-name-enc >oding-03. We had a long discussion in dhc mailing list, no=20 >need to replay that discussion here. > >Instead of opening the endless discussion IP address vs. FQDN,=20 >I really hope to scope this discussion to the encoding options=20 >of a name: the working achieved a consensus to encode a name=20 >as a string and not over specify the option to be DNS-specific=20 >(see http://www.ietf.org/mail-archive/web/pcp/current/msg01776.html). > >Cheers, >Med=20 > >>-----Message d'origine----- >>De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >>part de Ted Lemon >>Envoy=E9 : jeudi 31 janvier 2013 14:42 >>=C0 : pcp@ietf.org >>Objet : Re: [pcp] draft-ietf-pcp-dhcp >>Importance : Haute >> >>On Jan 31, 2013, at 8:00 AM, mohamed.boucadair@orange.com wrote: >>> Even if -06 is ready for submission, I preferred to not=20 >>submit it before checking with the WG how to resolve an issue=20 >>raised by Ted. Ted (as a chair of dhc) thinks the use of UTF-8=20 >>string encoding is a bad design because it is difficult to=20 >>validate the option. I already answered to that objection as=20 >>DNS itself does not put any restriction on labels except a=20 >>label must not be more than 63 characters. >> >>This completely misrepresents the concern I expressed. First=20 >>of all, DNS _wire format_ allows any value in any field, but=20 >>DNS _representation format_ is not clearly defined anywhere,=20 >>and there are complexities, particularly since you want to be=20 >>able to parse both FQDNs and IP addresses out of the same=20 >>string representation, and since you have to support=20 >>internationalized domain names. >> >>Of course, there are implementations of library routines that=20 >>take a user-supplied string and parse an FQDN or IP address=20 >>out of it-it's not rocket science. But there is no clear=20 >>specification; no BNF we can follow to determine which strings=20 >>are valid and which aren't. More to the point, though, this=20 >>is not how other DHCP options with similar use cases have been=20 >>done. Inventing new formats to represent the same data=20 >>complicates implementations, and we'd prefer to avoid it. =20 >>The DHC working group has a fairly clear consensus that there=20 >>are preferred ways to do it, which we have attempted to=20 >>communicate. We asked Med to articulate a use case that=20 >>motivates this particular solution over the preferred=20 >>solutions, and he did not articulate an actual use case. >> >>We also asked Med to explain why it was necessary to use an=20 >>FQDN rather than having the DHCP server derive an IP address=20 >>from an FQDN in its configuration, and the only answer I could=20 >>get was that there might be some situation where there'd be a=20 >>split DNS configuration, and the correct answer would be=20 >>available to the DHCP client and not the DHCP server. In=20 >>general I'm a bit of a purist, and have trouble with the idea=20 >>that an IETF protocol should bend over backwards to=20 >>accommodate this use case. I also wonder if the working=20 >>group really considers this a serious use case. >> >>In general, the way that DHCP handles this problem is that the=20 >>DHCP server administrator configures an FQDN on the DHCP=20 >>server. When a request comes in, the DHCP server does a DNS=20 >>lookup, resolving the FQDN into one or more IP addresses. =20 >>These addresses are then sent to the client. This relieves=20 >>the client of the need to do the FQDN lookup itself, which is=20 >>generally considered desirable since some consumers of DHCP=20 >>service are fairly low-level devices, like boot proms, which=20 >>don't have their own resolvers. This solution addresses=20 >>every use case Med presented except the split DNS use case. =20 >>In the split DNS use case, a wire-encoded FQDN is adequate;=20 >>there is no need to invent a new encoding. >> >>So I'd really appreciate it if the PCP working group would at=20 >>least consider stopping trying to cram config file strings=20 >>into DHCP packets, and follow the recommendations of the DHC=20 >>working group as to how to represent addresses. >> >>I think that's the place to start-if somebody has a strong=20 >>requirement that is not satisfied by the usual practice, that=20 >>requirement should be stated explicitly. It should be the=20 >>case that current practice does not satisfy that requirement;=20 >>not merely that there is a personal preference for going=20 >>against current practice. >> >>_______________________________________________ >>pcp mailing list >>pcp@ietf.org >>https://www.ietf.org/mailman/listinfo/pcp >>= From Ted.Lemon@nominum.com Thu Jan 31 06:48:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AED421F8622 for ; Thu, 31 Jan 2013 06:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuRNmzAUELNg for ; Thu, 31 Jan 2013 06:48:36 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id B1EC521F8507 for ; Thu, 31 Jan 2013 06:48:36 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUQqERGS5i9OvJUk+PF7TvqQVJ8Ro9DF9@postini.com; Thu, 31 Jan 2013 06:48:36 PST 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 50EF11B8259 for ; Thu, 31 Jan 2013 06:48:36 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-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 482B0190043; Thu, 31 Jan 2013 06:48:36 -0800 (PST) (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; Thu, 31 Jan 2013 06:48:30 -0800 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: draft-ietf-pcp-dhcp Thread-Index: Ac3/svMhIiSqbDmMSHGU8XxAMPj6cQASMtEAABCLoND//45SgA== Date: Thu, 31 Jan 2013 14:48:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747476A86@mbx-01.win.nominum.com> References: <94C682931C08B048B7A8645303FDC9F36EA9C83E5A@PUEXCB1B.nanterre.francetelecom.fr> <8D23D4052ABE7A4490E77B1A012B630747476816@mbx-01.win.nominum.com> <94C682931C08B048B7A8645303FDC9F36EA9C83EFB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA9C83EFB@PUEXCB1B.nanterre.francetelecom.fr> 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: <87E00BB2324EFB4DBD152929C7F524E5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-dhcp X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:48:37 -0000 On Jan 31, 2013, at 9:04 AM, mohamed.boucadair@orange.com wrote: > Mandating the server to resolve the name and return an IP-Address is a de= ployment option but this is not a valid option for some providers. I alread= y discussed this inhttp://tools.ietf.org/html/draft-boucadair-dhc-address-n= ame-encoding-03. We had a long discussion in dhc mailing list, no need to r= eplay that discussion here. You discuss this, but nobody has yet presented a valid use case. No valid= use case is presented in your document, unless you agree that the use case= is the split DNS use case. In the discussion you cite, no motivating use= case is given=97it's just taken as read that this is going to be represent= ed as a string. My motivation here is to try to help you to get the document into a state w= here it will pass muster in the DHC working group. At the moment, it will= not pass muster. So despite the discussion that you cite, I think we rea= lly need to reopen the issue of what the motivating use case is for this di= vergence from standard practice. If there is a motivating use case, that's great=97let's figure out how to a= ddress it. But until such a use case has been explicitly stated (maybe it= was stated in some discussion that you summarized, but left out of the sum= mary?) I think the default should be to just use an IP address, and let the= DHCP server do the name resolution. I will point out that in the discussion you summarized, one motivation for = not saying "FQDN" is that different name service infrastructures might be u= sed. If that is indeed a motivating use case, this argues _strongly_ for = sending an IP address, and letting the DHCP server do the name service look= up. Otherwise you are depending on all the nodes on your network to be ab= le to support whatever name service infrastructure you intend to use; I don= 't think this is realistic.