From nobody Tue Apr 1 00:40:54 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732151A7012; Tue, 1 Apr 2014 00:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44kdJwhKqscS; Tue, 1 Apr 2014 00:40:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A996E1A0024; Tue, 1 Apr 2014 00:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401074049.4622.12277.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 00:40:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/I7PoLFKzO_lNr8_PBQ2_FfClB_c Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-10.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 07:40:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : DHCP Options for the Port Control Protocol (PCP) Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-10.txt Pages : 9 Date : 2014-04-01 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which use of DHCPv4 or DHCPv6 apply are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-dhcp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 1 08:08:00 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066971A07AB; Tue, 1 Apr 2014 08:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PCacWAmYNat; Tue, 1 Apr 2014 08:07:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 304A31A0871; Tue, 1 Apr 2014 08:07:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401150742.1496.87941.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 08:07:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/znzd3YY93iywmHKbBNpewoci4u4 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-11.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 15:07:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : DHCP Options for the Port Control Protocol (PCP) Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-11.txt Pages : 9 Date : 2014-04-01 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which use of DHCPv4 or DHCPv6 apply are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-dhcp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 2 05:00:03 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657CA1A01F8 for ; Wed, 2 Apr 2014 05:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9uSKVNsqV7C for ; Wed, 2 Apr 2014 04:59:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C93BD1A01F9 for ; Wed, 2 Apr 2014 04:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4574; q=dns/txt; s=iport; t=1396439986; x=1397649586; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9HDRI7qB/SfS2PHZM2cHZsZ2I+EWQbvVUv4d1rJ8Ng4=; b=J7UFEESs1IDvv/94nXbI7qlO2WfFCa1Ds1ebArl2ehgdrNUHXcbvo7N2 /67iZtGbKBaA8KLnoLYZGOqjklrXuxhf0TprO9js/b4/JKsJuaw1oFbQP qyHBPKbfyELyqELQqp5O+pSuI0OQ7U8EQppi4a2vTGmcpGQVKhhqHownH 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAJv6O1OtJA2J/2dsb2JhbABPCoMGO1EGgwrAXRmBBBZ0giUBAQEEIxE6CQ4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYdwCAWsdaI2F4EpjGsrOAaCaTWBFASaCZEGgzCCKw X-IronPort-AV: E=Sophos;i="4.97,780,1389744000"; d="scan'208";a="314546064" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2014 11:59:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s32Bxibc017016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 2 Apr 2014 11:59:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 06:59:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-wing-pcp-third-party-authz-03.txt Thread-Index: AQHPTmp/oENGWDqd9UGApl6Rd2RaGZr+OMkA Date: Wed, 2 Apr 2014 11:59:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242FDE74@xmb-rcd-x10.cisco.com> References: <20140402115538.32361.89102.idtracker@ietfa.amsl.com> In-Reply-To: <20140402115538.32361.89102.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/BdU4h34NCmSkJBU9dE2rTHpvHCk Subject: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 12:00:00 -0000 UmV2aXNlZCBkcmFmdC13aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMyBoYXMgYmVlbiBwdWJs aXNoZWQuIFRoZSB1cGRhdGUgaW5jb3Jwb3JhdGVzIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9t IHRoZSBXRy4gIEFsc28gcmVzcG9uZGluZyB0byB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSBT dHVhcnQNCg0KQ29tbWVudDE+IFdoeSB3b3VsZCBzaXRlcyB1c2UgYSBibG9ja2luZyBtZWNoYW5p c20gdGhhdCBubyBhcHBzIGN1cnJlbnRseSBzdXBwb3J0Pw0KDQpSZXBseT4gVGhlIHByb2JsZW0g d2l0aCBXZWJSVEMgYXBwbGljYXRpb25zIGlzIHRoYXQgRW50ZXJwcmlzZXMgd2l0aCByZXN0cmlj dGl2ZSBGaXJld2FsbCBwb2xpY2llcyBhcmUgYmxvY2tpbmcgUDJQIG1lZGlhIHN0cmVhbXMgYW5k IGRhdGEgY2hhbm5lbHMuIEluIHN1Y2ggZGVwbG95bWVudHMsIFBDUCBjYW4gYmUgdXNlZCB0byBp ZGVudGlmeSB0aGUgbWVkaWEgc2Vzc2lvbiBpbml0aWF0ZWQgdXNpbmcgdHJ1c3RlZCB0aGlyZCBw YXJ0eSBXZWJSVEMgc2VydmljZSBwcm92aWRlcnMuIFBDUCByZXF1ZXN0cyB3aXRob3V0IHRoaXJk IHBhcnR5IGF1dGhvcml6YXRpb24gY2FuIGJlIHVzZWQgdG8gaWRlbnRpZnkgbm9uLWJ1c2luZXNz IHJlbGF0ZWQgbWVkaWEgc3RyZWFtcyBhbmQgdGh1cyB0aGVzZSBmbG93cyBjYW4gYmUgcHJpb3Jp dGl6ZWQgYWNjb3JkaW5nbHkuIFRoZSBnb2FsIGlzIG5vdCB0byBibG9jaywgYnV0IGdpdmUgZGlm ZmVyZW50aWF0ZWQgc2VydmljZSB0byB0aGVzZSBmbG93cy4gVGhpcyBwcm9ibGVtIHdhcyBhbHNv IGRpc2N1c3NlZCBpbiBQTlRBVyBpZXRmIG1haWxpbmcgbGlzdCBzb21ldGltZSBiYWNrLg0KDQpD b21tZW50Mj4gV2h5IHdvdWxkIGFwcCB2ZW5kb3JzIGFkb3B0IGEgbWVjaGFuaXNtIHRvIGNpcmN1 bXZlbnQgYSBibG9ja2luZyBtZWNoYW5pc20gd2hlbiBubyBzaXRlcyBhcmUgY3VycmVudGx5IHVz aW5nIHRoZSBibG9ja2luZyBtZWNoYW5pc20gb3Igc3VwcG9ydGluZyB0aGUgY2lyY3VtdmVudGlv biBtZWNoYW5pc20/DQoNClJlcGx5PiBUaGlzIGRyYWZ0IHNvbHZlcyB0d28gcHJvYmxlbXMsIHRo YXQgaW50ZXJlc3RzIGFwcGxpY2F0aW9uIHZlbmRvcnMNCg0KMSkgVG8gc29sdmUgdGhlIHByb2Js ZW1zIGV4cGxhaW5lZCBpbiB0aGUgcmVzcG9uc2UgdG8gdGhlIGZpcnN0IGNvbW1lbnQuDQoyKSBU aGlzIG1lY2hhbmlzbSBjYW4gYWxzbyBiZSB1c2VkIGJ5IHRoZSBJU1AgdG8gaWRlbnRpZnkgYW5k IHByaW9yaXRpemUgbWVkaWEgc3RyZWFtcyBpbml0aWF0ZWQgdXNpbmcgdGhpcmQgcGFydHkgV2Vi UlRDIHNlcnZpY2UgcHJvdmlkZXJzIHRoYXQgaGF2ZSB0aWUtdXAgd2l0aCB0aGUgSVNQLiBVc2Fn ZSBvZiBQQ1AgdGhpcmQgcGFydHkgYXV0aG9yaXphdGlvbiBpbiBNb2JpbGUgTmV0d29ya3MgdG8g cHJpb3JpdGl6ZSBtZWRpYSBzdHJlYW1zIGlzIGRpc2N1c3NlZCBpbiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1wZW5uby1wY3AtbW9iaWxlLXFvcy0wMC4gDQoNClRoYW5rcyBhbmQg UmVnYXJkcywNCi1UaXJ1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogV2VkbmVzZGF5LCBBcHJpbCAwMiwgMjAxNCA1OjI2IFBNDQpUbzogUHJhc2hhbnRoIFBh dGlsIChwcmFzcGF0aSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFByYXNoYW50aCBQ YXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBEYW4gV2luZyAo ZHdpbmcpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IERhbiBXaW5nIChkd2luZyk7IFJlaW5h bGRvIFBlbm5vIChyZXBlbm5vKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC13aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMy50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHotMDMudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13aW5nLXBjcC10aGly ZC1wYXJ0eS1hdXRoeg0KUmV2aXNpb246CTAzDQpUaXRsZToJCVBDUCBFeHRlbnNpb24gZm9yIFRo aXJkIFBhcnR5IEF1dGhvcml6YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMDQtMDINCkdyb3Vw OgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE1DQpVUkw6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFy dHktYXV0aHotMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHovDQpIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHkt YXV0aHotMDMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC13aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMw0KDQpBYnN0cmFjdDoNCiAgIEl0 IGlzIG9mdGVuIGRlc2lyYWJsZSBmb3IgYW4gYXBwbGljYXRpb24gc2VydmVyIHRvIHBlcm1pdCBh IGZsb3cNCiAgIGFjcm9zcyBhIGZpcmV3YWxsLCBhcyBoYXBwZW5zIHRvZGF5IHdoZW4gYSBmaXJl d2FsbCBpbmNsdWRlcyBhbg0KICAgQXBwbGljYXRpb24gTGF5ZXIgR2F0ZXdheSAoQUxHKSBmdW5j dGlvbi4gIEhvd2V2ZXIsIGFuIEFMRyBoYXMNCiAgIHNldmVyYWwgd2Vha25lc3Nlcy4NCg0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjcnlwdG9ncmFwaGljIHRlY2huaXF1ZSBmb3IgYW4g YXBwbGljYXRpb24NCiAgIHNlcnZlciB0byBwZXJtaXQgYSBmbG93IGFjcm9zcyBhIGZpcmV3YWxs LiAgVGhpcyB0ZWNobmlxdWUgdXNlcyBPQXV0aA0KICAgYW5kIGEgbmV3IFBDUCBvcHRpb24uDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Apr 10 05:56:37 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4661A0278; Thu, 10 Apr 2014 05:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PEs6C22fKsv; Thu, 10 Apr 2014 05:56:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CE81A026B; Thu, 10 Apr 2014 05:56:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140410125631.24599.74846.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 05:56:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/mAaE4WhS_inl5_olfyncvBkvBqg Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-12.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 12:56:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : DHCP Options for the Port Control Protocol (PCP) Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-12.txt Pages : 10 Date : 2014-04-10 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which use of DHCPv4 or DHCPv6 apply are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-dhcp-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 12 08:07:59 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1E91A01C8 for ; Sat, 12 Apr 2014 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.073 X-Spam-Level: X-Spam-Status: No, score=-12.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0QtOsBLV7Q8 for ; Sat, 12 Apr 2014 08:07:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD051A01C4 for ; Sat, 12 Apr 2014 08:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1741; q=dns/txt; s=iport; t=1397315270; x=1398524870; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=srxXjBS1uwnDVlVa6XB3st53jqFNZRD2NesaKo7zXjE=; b=CSECigeQueSzELpM6iTWdqxkyZszofRPFOhtRclCLXPiJ9QYfVk1NV0q 6E93YMo5YIqUreu/IYUf2mpatOWCPGQWq7zQQcYa8MDQwabNaVHPnbsco Fy16sm1tuCbvvNuNfy0Y1mvf4m9b/KRTmGn8W8l2ZNw30ewfvpPvxN2uX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFALNVSVOrRDoG/2dsb2JhbABPCoMGwx2BHoEZFnSCJQEBAQMBOj8FCwtGVwYTh3QHyysXjhIpMweDJIEUBIlcjwWSQ4NRHQ X-IronPort-AV: E=Sophos;i="4.97,848,1389744000"; d="scan'208";a="107019601" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 12 Apr 2014 15:07:50 +0000 Received: from sjc-vpn7-1931.cisco.com (sjc-vpn7-1931.cisco.com [10.21.151.139]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3CF7nhr015118; Sat, 12 Apr 2014 15:07:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <1DA8CEC3F3E989439069663C05A865D335A2F70F@nkgeml508-mbx.china.huawei.com> Date: Sat, 12 Apr 2014 08:07:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8E0B1F77-5374-4997-AE88-84AD5D4C24D7@cisco.com> References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B88@nkgeml508-mbx.china.huawei.com> <80955F6E-204D-4B6B-BE45-9C1A0F0DD072@cisco.com> <1DA8CEC3F3E989439069663C05A865D335A2F70F@nkgeml508-mbx.china.huawei.com> To: "Zhangzhan (Channy)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/anGCxWkyNvQ8foLvl70M8WTEalU Cc: PCP Working Group Subject: Re: [pcp] About how to achieve the Options for PCP as PCP clients? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 15:07:56 -0000 On Apr 10, 2014, at 1:52 AM, Zhangzhan (Channy) = wrote: > If CPE as the PCP client, to achieve the Options, how to identify? >=20 > For example, THIRD_PARTY, what scene this option will be used? How the = Third Party Equipment interact with the CPE and CPE can use the option? = Any example or network topology? >=20 > For example, FILTER, internal hosts can communication with CPE using = the UPnP protocol for open some service port, then CPE as the PCP client = can send PCP MAP to get mapping, but CPE how to realize the FILTER = option? I think CPE is unable to know what remote address or port can be = allowed to access internal hosts. Instead of, the application layer = software of internal hosts is more suitable to achieve it. Yes, application software above PCP sets FILTER. But that is true of = most everything else with PCP -- PCP is expected to be run by an = application calling into a PCP library. But the connections arrive at = the end host, so no need for a separate 'controller' and no need for = THIRD_PARTY. The end host has enough information to set the FILTER; the = IP address in that packet (that arrived at the end host) is unchanged in = that direction through the subscriber's NAPT. For example, a TCP SYN = that arrives at a NAS inside someone's home has the IP source address = and TCP source port, and NAS could use that IP address and TCP port to = set the PCP FILTER. If FILTER wants to be set by the host prior to = receiving the first packet, a rendezvous protocol is necessary to learn = the remote host's IP address prior to the remote host sends a packet = (e.g., H.323, SIP, or dozens and dozens of other rendezvous protocols). -d From nobody Sun Apr 13 22:59:35 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109961A0366; Sun, 13 Apr 2014 22:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KhWaAMyrJYh; Sun, 13 Apr 2014 22:59:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A02271A02E7; Sun, 13 Apr 2014 22:59:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140414055926.15641.96652.idtracker@ietfa.amsl.com> Date: Sun, 13 Apr 2014 22:59:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/GssSJYdOoYQ-wu-SXJ8ppAo2t14 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-13.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 05:59:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : DHCP Options for the Port Control Protocol (PCP) Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-13.txt Pages : 10 Date : 2014-04-13 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which use of DHCPv4 or DHCPv6 apply are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-dhcp-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 15 10:54:24 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9761A02E3 for ; Tue, 15 Apr 2014 10:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMPyZ7xlEOES for ; Tue, 15 Apr 2014 10:54:22 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4661A01E7 for ; Tue, 15 Apr 2014 10:54:22 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A074F1B8017 for ; Tue, 15 Apr 2014 10:54:19 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9A29F19005C for ; Tue, 15 Apr 2014 10:54:19 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Apr 2014 10:54:19 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Apr 2014 12:54:17 -0500 To: PCP Working Group Message-ID: MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/C3TH-KYrQLH_HgS9ActcNh1foj0 Subject: [pcp] Additional requirements for PCP Authentication. X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:54:23 -0000 I've mentioned this before, and got a response from Sam Hartman, but = then the discussion died down. Stephen Farrell raised the following = DISCUSS points with respect to the PCP DHCP option: (2) How can PCP authentication (based on the WG draft, draft-ietf-pcp-authentication I assume?) make sense with this use of DHCP? I guess that that can make sense but I'm not getting it right now sorry. Can you explain? (Note: its quite possible no change is needed, just to explain the plan to a semi-ignorant AD:-) (3) How does a client know that the security identity of one, some of all of the PCP server addresses returned are the same or not? (You might cover this as part of discuss point 2 above, not sure.) I think that the PCP authentication needs to have the ability to provide = an identifier to the client that the client can use to choose which = credentials to provide to the PCP server in order to address point 3. = So I'd like to ask the working group whether they agree or disagree with = this. Secondly, in order to address point 2, the authentication protocol needs = to have some text talking about how to use it in the context of = dynamically-discovered PCP server addresses. I think that if my = suggestion above is taken, then it can work, and it's useful: by = configuring PCP server addresses with DHCP, we avoid having to have the = client maintain a static mapping between server IP addresses and = credentials, which I think would be a bad idea anyway. So a site that = uses PCP authentication can use DHCP to configure PCP, and clients will = be able to authenticate using pre-configured credentials. Does this make sense? From nobody Tue Apr 15 17:14:29 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26F21A0065 for ; Tue, 15 Apr 2014 17:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8oL6CGXEEbq for ; Tue, 15 Apr 2014 17:14:19 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F18751A004A for ; Tue, 15 Apr 2014 17:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2446; q=dns/txt; s=iport; t=1397607256; x=1398816856; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FdW/DAZ4vPHPvL8K4fEBbXaU4et6asGStlwp346jLVc=; b=AVlxLmAsRHOUaqopSAV7dgTMP5Pw+s98vyYcoyS+HFtGjWNTC5DPzKtn qwVvqU9/+7BffXExzQRGv09GbzCC9mgVPejCX8xG/xXoOzZ1U0r1NGS2q 8gp9Hng1oJxBHFUeisRq3O9zmoXeexg/QB5apoFu40bxkCGF8hCQJIYPd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAMrKTVOrRDoH/2dsb2JhbABRCYMGxEKBIxZ0giUBAQEDATo/BQsLRlcGE4d0B8xLF44IKDMHgySBFASJXIsZg22SRYNRHQ X-IronPort-AV: E=Sophos;i="4.97,867,1389744000"; d="scan'208";a="110459406" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Apr 2014 00:14:15 +0000 Received: from sjc-vpn5-425.cisco.com (sjc-vpn5-425.cisco.com [10.21.89.169]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3G0EEMp021759; Wed, 16 Apr 2014 00:14:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: Date: Tue, 15 Apr 2014 17:14:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ted Lemon X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/F27cadN9f1ALoilcbKm68pLRqLg Cc: PCP Working Group Subject: Re: [pcp] Additional requirements for PCP Authentication. X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 00:14:24 -0000 On Apr 15, 2014, at 10:54 AM, Ted Lemon wrote: > I've mentioned this before, and got a response from Sam Hartman, but = then the discussion died down. Stephen Farrell raised the following = DISCUSS points with respect to the PCP DHCP option: >=20 > (2) How can PCP authentication (based on the WG draft, > draft-ietf-pcp-authentication I assume?) make sense > with this use of DHCP? I guess that that can make > sense but I'm not getting it right now sorry. Can you > explain? (Note: its quite possible no change is > needed, just to explain the plan to a semi-ignorant > AD:-) >=20 > (3) How does a client know that the security identity > of one, some of all of the PCP server addresses > returned are the same or not? (You might cover this as > part of discuss point 2 above, not sure.) >=20 > I think that the PCP authentication needs to have the ability to = provide an identifier to the client that the client can use to choose = which credentials to provide to the PCP server in order to address point = 3. So I'd like to ask the working group whether they agree or disagree = with this. Yes I agree that PCP authentication needs to obtain the server's = identity so that the PCP client can choose which credentials to use with = that particular PCP server. But that isn't the fault of the DHCP = option. Without the DHCP option, a PCP client will communicate with its = default router, which it only knows by IP address. If that client and = server understand PCP authentication, the PCP client still only knows = the IP address but would really want a "name". draft-ietf-pcp-dhcp = suffers the same problem, in that the client only knows IP addresses of = the PCP servers, and not its name.=20 > Secondly, in order to address point 2, the authentication protocol = needs to have some text talking about how to use it in the context of = dynamically-discovered PCP server addresses. I think that if my = suggestion above is taken, then it can work, and it's useful: by = configuring PCP server addresses with DHCP, we avoid having to have the = client maintain a static mapping between server IP addresses and = credentials, which I think would be a bad idea anyway. So a site that = uses PCP authentication can use DHCP to configure PCP, and clients will = be able to authenticate using pre-configured credentials. >=20 > Does this make sense? -d From nobody Tue Apr 15 22:50:23 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7218A1A005A for ; Tue, 15 Apr 2014 22:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQk85sI14HF9 for ; Tue, 15 Apr 2014 22:50:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9D1A0055 for ; Tue, 15 Apr 2014 22:50:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:52870 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WaIja-0002Zr-LG; Wed, 16 Apr 2014 07:50:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: stephen.farrell@cs.tcd.ie, mohamed.boucadair@orange.com X-Trac-Project: pcp Date: Wed, 16 Apr 2014 05:50:10 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/72 Message-ID: <066.069df104a00cfb287d15ef3663b742e8@tools.ietf.org> X-Trac-Ticket-ID: 72 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: stephen.farrell@cs.tcd.ie, mohamed.boucadair@orange.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/3QDL6pLAuv-Uy6ZHAPEuRuj-wB0 Cc: pcp@ietf.org Subject: [pcp] #72 (authentication): PCP server discovery & PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 05:50:20 -0000 #72: PCP server discovery & PCP authentication Stephen Farrell raised the following DISCUSS points with respect to the PCP DHCP option: (2) How can PCP authentication (based on the WG draft, draft-ietf-pcp-authentication I assume?) make sense with this use of DHCP? I guess that that can make sense but I'm not getting it right now sorry. Can you explain? (Note: its quite possible no change is needed, just to explain the plan to a semi-ignorant AD:-) (3) How does a client know that the security identity of one, some of all of the PCP server addresses returned are the same or not? (You might cover this as part of discuss point 2 above, not sure.) === T. Lemon comment: I think that the PCP authentication needs to have the ability to provide an identifier to the client that the client can use to choose which credentials to provide to the PCP server in order to address point 3. So I'd like to ask the working group whether they agree or disagree with this. Secondly, in order to address point 2, the authentication protocol needs to have some text talking about how to use it in the context of dynamically-discovered PCP server addresses. I think that if my suggestion above is taken, then it can work, and it's useful: by configuring PCP server addresses with DHCP, we avoid having to have the client maintain a static mapping between server IP addresses and credentials, which I think would be a bad idea anyway. So a site that uses PCP authentication can use DHCP to configure PCP, and clients will be able to authenticate using pre-configured credentials. M. Boucadair: The applicability of the DHCP PCP server option and its potential implications in the Advanced Threat Model should be discussed in the PCP authentication document. -- -------------------------------------+------------------------------------- Reporter: | Owner: Stephen Farrell mohamed.boucadair@orange.com | Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: pcp From nobody Wed Apr 16 05:41:38 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06231A0127; Wed, 16 Apr 2014 05:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgwZeH3HnGQ1; Wed, 16 Apr 2014 05:41:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 881041A015A; Wed, 16 Apr 2014 05:41:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416124127.17502.6511.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 05:41:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/eg1UJmzOLXxpTq7pSjKQ8Bsg8XU Cc: pcp mailing list , pcp chair , RFC Editor Subject: [pcp] Protocol Action: 'DHCP Options for the Port Control Protocol (PCP)' to Proposed Standard (draft-ietf-pcp-dhcp-13.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 12:41:32 -0000 The IESG has approved the following document: - 'DHCP Options for the Port Control Protocol (PCP)' (draft-ietf-pcp-dhcp-13.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ Technical Summary: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. Working Group Summary: There was controversy around the use of IP address vs hostnames vs strings passed to getaddrinfo (which could be hostname or IP literal). The WG eventually achieved rough consensus on the IP address mechanism recommended by Ted Lemon, referencing [I-D.ietf-dhc-topo-conf] informatively for discussion on how various scenarios can still be solved using that mechanism. Document Quality: One implementation is documented at http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.9 Other implementations are expected. Ted Lemon performed DHCP review and raised issues with the previous approach (strings passed to getaddrinfo). A significant discussion ensued which resulted in Ted authoring draft-ietf-dhc-topo-conf for WGs and documents to reference. That document was presented to the PCP WG, which then got consensus on the final approach (IP addresses, and referencing that draft for discussion of operational guidance). Personnel: Dave Thaler is the Document Shepherd. Ted Lemon is the Responsible Area Director. RFC Editor Note: In section 8, please make the following change: OLD: The PCP Server option targets mainly the simple threat model (Section 18.1 of [RFC6887]). It is out of scope of this document to discuss potential implications of the use of this option in the advanced threat model (Section 18.2 of [RFC6887]). NEW: The PCP server option defined here is applicable when operating under the simple threat model (Section 18.1 of [RFC6887]). Operation under the advanced threat model (section 18.2 of [RFC6887]) may or may not be appropriate; analysis of this question is out of scope for this document. From nobody Wed Apr 16 22:49:34 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B331A0459 for ; Wed, 16 Apr 2014 22:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7UaI1J9qMfu for ; Wed, 16 Apr 2014 22:49:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD431A0439 for ; Wed, 16 Apr 2014 22:49:31 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3A2483241D6 for ; Thu, 17 Apr 2014 07:49:27 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 211214C0B6 for ; Thu, 17 Apr 2014 07:49:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 17 Apr 2014 07:49:26 +0200 From: To: "pcp@ietf.org" Date: Thu, 17 Apr 2014 07:49:24 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt Thread-Index: Ac9ZcqTW4c5dD8OYRq2XA6WUy4zAbwAjet+A Message-ID: <94C682931C08B048B7A8645303FDC9F36F56FCB2AD@PUEXCB1B.nanterre.francetelecom.fr> References: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> In-Reply-To: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.17.20919 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/OYiTUc4c1bSEX9D7khzUQK5Ps4Y Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 05:49:33 -0000 Dear all, I submitted this new draft to discuss issues related to the control of pack= et classier.=20 Comments are more than welcome. Cheers, Med -----Message d'origine----- De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de in= ternet-drafts@ietf.org Envoy=E9=A0: mercredi 16 avril 2014 14:48 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP as a Traffic Classifier Control Protocol Author : Mohamed Boucadair Filename : draft-boucadair-pcp-sfc-classifier-control-00.txt Pages : 7 Date : 2014-04-16 Abstract: This document specifies how PCP (Port Control Protocol) can be used as a classifier control protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sfc-classifier-control= / There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Apr 17 01:20:28 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184791A0299 for ; Thu, 17 Apr 2014 01:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkLgeMWG8sEg for ; Thu, 17 Apr 2014 01:20:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 358651A01FA for ; Thu, 17 Apr 2014 01:20:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDE97525; Thu, 17 Apr 2014 08:20:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 09:18:38 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 09:20:02 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 16:19:55 +0800 From: "Zhangdacheng (Dacheng)" To: pcp issue tracker , "stephen.farrell@cs.tcd.ie" , "mohamed.boucadair@orange.com" , Sam Hartman Thread-Topic: [pcp] #72 (authentication): PCP server discovery & PCP authentication Thread-Index: AQHPWTfIcISYnWFWAkmAereIZHeINpsVWJkA Date: Thu, 17 Apr 2014 08:19:54 +0000 Message-ID: References: <066.069df104a00cfb287d15ef3663b742e8@tools.ietf.org> In-Reply-To: <066.069df104a00cfb287d15ef3663b742e8@tools.ietf.org> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/PepnIAiqhGFeZy14lVF7xeKZqkA Cc: "pcp@ietf.org" Subject: Re: [pcp] #72 (authentication): PCP server discovery & PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 08:20:24 -0000 Sorry to join the discussion a little late.=20 When we designed the PCP authentication protocol, we tried to use this prot= ocol to transport EAP packets and use the keys generated in the EAP authent= ication to secure the PCP packet exchanges. So, we assume a client will kno= w which credential will be used for the authentication, and how the EAP imp= lementation selects a credential is out of scope our current work.=20 Inline please. >=20 > Stephen Farrell raised the following DISCUSS points with respect to the = PCP > DHCP option: >=20 > (2) How can PCP authentication (based on the WG draft, > draft-ietf-pcp-authentication I assume?) make sense with this use of DHC= P? I > guess that that can make sense but I'm not getting it right now sorry. C= an > you explain? (Note: its quite possible no change is needed, just to exp= lain > the plan to a semi-ignorant > AD:-) >=20 > (3) How does a client know that the security identity of one, some of a= ll of > the PCP server addresses returned are the same or not? (You might cover > this as part of discuss point 2 above, not sure.) =3D=3D=3D >=20 > T. Lemon comment: > I think that the PCP authentication needs to have the ability to provide= an > identifier to the client that the client can use to choose which > credentials to provide to the PCP server in order to address point 3. = So > I'd like to ask the working group whether they agree or disagree with t= his. [Dacheng Zhang:]=20 [Dacheng Zhang:]=20 First Let us assume there should be identifiers for the client to find the = proper credentials, although we haven't exploited how to get the identifier= s securely at the moment. ^_^ Assume a client have got the ip address of PCP server from a DHCP server. T= hen it sends out a PCP-Auth message to the PCP server and applies to start = an EAP authentication, the server then replies with a PCP-Auth message cont= aining an EAP message. This EAP message is forwarded to the EAP implementat= ion of the client. At this stage, the EAP implementation on the client side= needs to know which credential should be used. So, there are two candidate= methods for the client to get the identifier, 1) The PCP server sends the = identifier back the identifier in the PCP-Auth message. 2) The client gets = the identifier from somebody else after getting the IP address from the DHC= P packet.=20 We can achieve the first approach by extending the protocol. However, the c= oncern is whether this approach works well with EAP. I don't know there is = any EAP implementation supporting identifiers for locating credentials (but= I am not an EAP expert). So, will this approach introduce additional imple= mentation complexity? I believe Sam is in the better position to give the c= omments.=20 The second type of approach is out of scope of the PCP authentication proto= col. I think it is very intuitive to use DHCP to transfer the credential id= entifier. Yes, the identifier might be tampered during the DHCP packet deli= very. However, when we select to use DHCP, we need to take the security ris= ks. In addition, the identifier is not cryptographically protected in the f= irst approach as well. So, if we decide to use identifiers, I personally li= ke this idea. Then we discuss whether it is necessary to introduce identifiers. (I haven'= t got a clear idea yet. ) If there is no identifier, the client will try the credentials it maintains= one by one to authenticate the PCP server when it gets the IP address of t= he server from a DHCP packet. If the number of the credential is large, thi= s approach will affect the system performance a lot. If the number is 1, th= en this approach is perfectly simple and efficient. So, the question is no= rmally how many credentials that a client will maintain for the authenticat= ion with different PCP servers. If the number is small, I think I am ok wit= h this approach.=20 When using identifiers, the client still needs to maintain the mapping info= rmation of identifiers and credentials. However, when using identifiers, we= don't have to pre-configure the ip address of pcp servers. I agree this is= an advantage brought by identifiers. Above are some initial thoughts. Open for discussion. Cheers Dacheng >=20 > Secondly, in order to address point 2, the authentication protocol needs= to > have some text talking about how to use it in the context of > dynamically-discovered PCP server addresses. I think that if my > suggestion above is taken, then it can work, and it's useful: by config= uring > PCP server addresses with DHCP, we avoid having to have the client maint= ain > a static mapping between server IP addresses and > credentials, which I think would be a bad idea anyway. So a site that > uses PCP authentication can use DHCP to configure PCP, and clients will = be > able to authenticate using pre-configured credentials. >=20 > M. Boucadair: > The applicability of the DHCP PCP server option and its potential > implications in the Advanced Threat Model should be discussed in the PCP > authentication document. >=20 > -- > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: Stephen Farrell > mohamed.boucadair@orange.com | > Type: defect | Status: new > Priority: major | Milestone: > Component: authentication | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+---------------------------------- > -------------------------------------+--- >=20 > Ticket URL: > pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From nobody Thu Apr 17 06:44:24 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FCD1A0127 for ; Thu, 17 Apr 2014 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDN2sFYq0IRE for ; Thu, 17 Apr 2014 06:44:17 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9AC1A018D for ; Thu, 17 Apr 2014 06:44:14 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 142BC1B81DC for ; Thu, 17 Apr 2014 06:44:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DF8D319005C; Thu, 17 Apr 2014 06:44:10 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 17 Apr 2014 06:44:10 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Thu, 17 Apr 2014 08:44:07 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <8888E5F2-6F18-4F7E-B35C-ABD4140EF176@nominum.com> References: <066.069df104a00cfb287d15ef3663b742e8@tools.ietf.org> To: "Zhangdacheng (Dacheng)" X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Of_wG16lurO8lvI9CyqE_lhb-90 Cc: "pcp@ietf.org" , pcp issue tracker , Sam Hartman , Stephen Farrell Subject: Re: [pcp] #72 (authentication): PCP server discovery & PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:44:22 -0000 On Apr 17, 2014, at 3:19 AM, Zhangdacheng (Dacheng) = wrote: > We can achieve the first approach by extending the protocol. However, = the concern is whether this approach works well with EAP. I don't know = there is any EAP implementation supporting identifiers for locating = credentials (but I am not an EAP expert). So, will this approach = introduce additional implementation complexity? I believe Sam is in the = better position to give the comments.=20 There's a third option: have the PCP server provide its identity along = with the EAP message. If the identity is just a selector for keys, = there's no real value in spoofing it. From nobody Thu Apr 17 19:21:52 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706231A025D for ; Thu, 17 Apr 2014 19:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kT41NSZzSqa for ; Thu, 17 Apr 2014 19:21:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04C1A00BE for ; Thu, 17 Apr 2014 19:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1725; q=dns/txt; s=iport; t=1397787703; x=1398997303; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9hrER19BocKH7xlHHdolhdn5+HTU0CPpDBqQatcZdBo=; b=Lpzs9LbXquUAz5bCFQ85hF64KtgW8TrQCEiSjLVC/hilFGegNYPj/FLA GXgo5YHjscYW6erN6UCPdvBIvSIYGKqBSrXt7snSXz6aSEGD+/Hv2wROV ZPA0OAsz+yjGEe/vjy9UhOVXrhMNVnbM4LCZsekvgdlqQyJd9E1CJKOE6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOGKUFOtJA2N/2dsb2JhbABPAQmDBjtXw2iBIxZ0giUBAQEEOjEODAQCAQgRBAEBAQoUCQcyFAkIAgQBDQMCCId0DcwYF44GASoxBwaDHoEUAQOaJZEWgzFBgWo X-IronPort-AV: E=Sophos;i="4.97,882,1389744000"; d="scan'208";a="318715427" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 18 Apr 2014 02:21:43 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s3I2LhS3024503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 02:21:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 17 Apr 2014 21:21:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ted Lemon , "Zhangdacheng (Dacheng)" Thread-Topic: [pcp] #72 (authentication): PCP server discovery & PCP authentication Thread-Index: AQHPWm9L9LbcUqpKJUqQ8O4B7hFu8ZsWo7yQ Date: Fri, 18 Apr 2014 02:21:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A243172BD@xmb-rcd-x10.cisco.com> References: <066.069df104a00cfb287d15ef3663b742e8@tools.ietf.org> <8888E5F2-6F18-4F7E-B35C-ABD4140EF176@nominum.com> In-Reply-To: <8888E5F2-6F18-4F7E-B35C-ABD4140EF176@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.44.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/nKGwj_NLGYjvBNt91zU8Y-hfzf8 Cc: Sam Hartman , "pcp@ietf.org" , pcp issue tracker , Stephen Farrell Subject: Re: [pcp] #72 (authentication): PCP server discovery & PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 02:21:51 -0000 > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: Thursday, April 17, 2014 7:14 PM > To: Zhangdacheng (Dacheng) > Cc: pcp@ietf.org; pcp issue tracker; Sam Hartman; Stephen Farrell > Subject: Re: [pcp] #72 (authentication): PCP server discovery & PCP > authentication >=20 > On Apr 17, 2014, at 3:19 AM, Zhangdacheng (Dacheng) > wrote: > > We can achieve the first approach by extending the protocol. However, t= he > concern is whether this approach works well with EAP. I don't know there = is any > EAP implementation supporting identifiers for locating credentials (but I= am not > an EAP expert). So, will this approach introduce additional implementatio= n > complexity? I believe Sam is in the better position to give the comments. >=20 > There's a third option: have the PCP server provide its identity along wi= th the EAP > message. If the identity is just a selector for keys, there's no real v= alue in > spoofing it. We may want to explore the third option. EAP-FAST (http://tools.ietf.org/ht= ml/rfc5422) also has a similar problem and uses A-ID is used to uniquely id= entify the authentication server. 7 - A-ID-Info=20 Authority Identifier Information is intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a human-readable format. This TLV serves as an aid to the peer to better inform the end-user about the A-ID. The name is encoded in UTF-8 [RFC3629] format. This attribute MUST be included in the PAC-Info. -Tiru >=20 From nobody Fri Apr 18 04:54:47 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40871A01BB for ; Fri, 18 Apr 2014 04:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUmTGN2zw4Fs for ; Fri, 18 Apr 2014 04:54:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 73B751A01CF for ; Fri, 18 Apr 2014 04:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1418; q=dns/txt; s=iport; t=1397822079; x=1399031679; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=qYlNoi7S1V+7XuUyFJf7ZxcvMWEBzgcPSBqYhWaFkJU=; b=izLH0N6z02pHO3+D1rcdfKsJyR1pX5l3RESVY9ereQnZBf5L0z8sNT1W /k54zq//bz/9HQfe+3eE2jKljycHxLaMjwS82M4yObSqU0EgudRaeOPJz W/LCtqoUMYyqGB5TLmVLY28ATlbVTpKluLq27vAbFzqneypQ6TWmS31R7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAKgRUVOtJV2d/2dsb2JhbABQAQmDBk9Xw2+BHBZ0giUBAQEDATo/BQcGAQgRBAEBCxQJORQJCQEEDgMCCIgxCA3MQReOBgEqMQ2DHoEUBJolkRiDMUGBag X-IronPort-AV: E=Sophos;i="4.97,884,1389744000"; d="scan'208";a="318715095" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 18 Apr 2014 11:54:38 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3IBsc27027027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 11:54:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 06:54:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Sam Hartman Thread-Topic: [pcp] #72 (authentication): PCP server discovery & PCP authentication Thread-Index: Ac9a/ODpkaH/9bGTTMulrmUwQ+KHBw== Date: Fri, 18 Apr 2014 11:54:37 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24317753@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.52.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/UfBt_2vjB_GRxr9sIfF8afr1ZTw Cc: Stephen Farrell , pcp issue tracker , "pcp@ietf.org" Subject: Re: [pcp] #72 (authentication): PCP server discovery & PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:54:46 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Friday, April 18, 2014 7:57 AM > To: Tirumaleswar Reddy (tireddy) > Cc: Ted Lemon; Zhangdacheng (Dacheng); pcp@ietf.org; pcp issue tracker; > Stephen Farrell > Subject: Re: [pcp] #72 (authentication): PCP server discovery & PCP > authentication >=20 > >>>>> "Tirumaleswar" =3D=3D Tirumaleswar Reddy (tireddy) > writes: >=20 > Tirumaleswar> We may want to explore the third option. EAP-FAST > (http://tools.ietf.org/html/rfc5422) also has a similar problem and uses = A-ID is > used to uniquely identify the authentication server. >=20 > If this is something that some EAP methods do, then it seems like a bad c= hoice > for PCP to also do. =20 But A-ID is sent in PAC TLV within EAP Method EAP-FAST that enables secure = communication between a peer and a server by using the Transport Layer Secu= rity (TLS). In PCP authentication, EAP method will not be EAP-FAST. So why is it a bad method for PCP authentication to solve the problem simil= arly i.e. give hint of the server's identity that would be useful in helpin= g the PCP client in selecting the appropriate credential to use ? -Tiru > Clark's original end to end argument generalizes to the idea > that it is rarely a good idea to do the same thing at multiple layers. > That seems to apply here. From nobody Mon Apr 21 15:59:29 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C4E1A02DC for ; Mon, 21 Apr 2014 15:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5dBFMHPR24N for ; Mon, 21 Apr 2014 15:59:22 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1031A02D1 for ; Mon, 21 Apr 2014 15:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2556; q=dns/txt; s=iport; t=1398121157; x=1399330757; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/+uon90mJlr7zrf2NWJyk1I5fB1P4T+YtWEky1PxtUQ=; b=POBWxbZujEe/SLYUSHP6Uy9IFeWa2GAVVB7lvWJjAFUcTdXQhHm9TYVU oSYTrP2ZczMVZsfoSyr3D1bzL4q+8WkssKmaXDzhwrYPtHxKWuox21uWG BXRGZ2am4k9oxHTiGSHQxiPLCWdektQE89t1PQhvwK2ZTKKkrCBz8p6yM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FANKhVVOtJA2J/2dsb2JhbABZgwZPV7xWhzyBIBZ0giYBAQQBAQFrBBcCAQg/BycLFBECBAESCYg4Dc06F45kBYQ4BIkrj0OBN4tKhU6DMYIr X-IronPort-AV: E=Sophos;i="4.97,898,1389744000"; d="scan'208";a="37569411" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 21 Apr 2014 22:59:16 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3LMxGNa027314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Apr 2014 22:59:16 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 21 Apr 2014 17:59:16 -0500 From: "Charles Eckel (eckelcu)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt Thread-Index: AQHPXbVR7ORaOuOAEki2xGXAWXepCQ== Date: Mon, 21 Apr 2014 22:59:16 +0000 Message-ID: References: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F56FCB2AD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F56FCB2AD@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.70.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <004317AC9A9C93499E2142DFED61ECFF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/RB2b6kHCta13BMaNG_TR3xQxk6E Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:59:26 -0000 Hi Med, This is a good draft. I was envisioning a similar relationship between PCP and SFC in which flow characteristics communicated via PCP could be used as input into the an SFC classifier. In addition to L2/L3/L4 information, the information included in the proposed PCP Flowdata Option (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00) seem useful as well. Using PCP to help with SFC classification is a good example of the more general problem described in the AEON problem statement and requirements draft=20 (http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). Cheers, Charles On 4/16/14, 10:49 PM, "mohamed.boucadair@orange.com" wrote: >Dear all, > >I submitted this new draft to discuss issues related to the control of >packet classier.=20 > >Comments are more than welcome. > >Cheers, >Med > >-----Message d'origine----- >De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9 : mercredi 16 avril 2014 14:48 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : PCP as a Traffic Classifier Control Protocol > Author : Mohamed Boucadair > Filename : draft-boucadair-pcp-sfc-classifier-control-00.txt > Pages : 7 > Date : 2014-04-16 > >Abstract: > This document specifies how PCP (Port Control Protocol) can be used > as a classifier control protocol. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-boucadair-pcp-sfc-classifier-contro >l/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Tue Apr 22 00:59:32 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635FF1A013D for ; Tue, 22 Apr 2014 00:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwUR4_UU6C28 for ; Tue, 22 Apr 2014 00:59:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8FE1A0139 for ; Tue, 22 Apr 2014 00:59:27 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 1447BC00A9; Tue, 22 Apr 2014 09:59:21 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BF32338407E; Tue, 22 Apr 2014 09:59:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 22 Apr 2014 09:59:20 +0200 From: To: "Charles Eckel (eckelcu)" , "pcp@ietf.org" Date: Tue, 22 Apr 2014 09:59:18 +0200 Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt Thread-Index: AQHPXbVR7ORaOuOAEki2xGXAWXepCZsdMePA Message-ID: <94C682931C08B048B7A8645303FDC9F36F56FCB81E@PUEXCB1B.nanterre.francetelecom.fr> References: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F56FCB2AD@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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.22.55720 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/h7ePGXxKonCcy6bwFE2TCx70IyQ Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 07:59:31 -0000 Hi Charles, Thank you for your message.=20 FLOWDATA is indeed an option that could be used for classification purposes= . This is recorded briefly in the draft: o Explicit actions: re-mark, drop, shape (can be used with FLOWDATA). The exact details on how FLOWDATA can be used are not included in this vers= ion because I wanted -00 to focus on the problem to be solved. It seems to me that aeon is application-driven, which is not the case for t= he pcp classifier draft. The classification function is not controlled by a= user/external application, it is under the responsibility of the administr= ative entity managing the network. Cheers, Med >-----Message d'origine----- >De=A0: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Envoy=E9=A0: mardi 22 avril 2014 00:59 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; pcp@ietf.org >Objet=A0: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier- >control-00.txt > >Hi Med, > >This is a good draft. I was envisioning a similar relationship between PCP >and SFC in which flow characteristics communicated via PCP could be used >as input into the an SFC classifier. In addition to L2/L3/L4 information, >the information included in the proposed PCP Flowdata Option >(http://tools.ietf.org/html/draft-wing-pcp-flowdata-00) seem useful as >well. Using PCP to help with SFC classification is a good example of the >more general problem described in the AEON problem statement and >requirements draft >(http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). > >Cheers, >Charles > >On 4/16/14, 10:49 PM, "mohamed.boucadair@orange.com" > wrote: > >>Dear all, >> >>I submitted this new draft to discuss issues related to the control of >>packet classier. >> >>Comments are more than welcome. >> >>Cheers, >>Med >> >>-----Message d'origine----- >>De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>internet-drafts@ietf.org >>Envoy=E9 : mercredi 16 avril 2014 14:48 >>=C0 : i-d-announce@ietf.org >>Objet : I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : PCP as a Traffic Classifier Control Protocol >> Author : Mohamed Boucadair >> Filename : draft-boucadair-pcp-sfc-classifier-control-00.txt >> Pages : 7 >> Date : 2014-04-16 >> >>Abstract: >> This document specifies how PCP (Port Control Protocol) can be used >> as a classifier control protocol. >> >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-boucadair-pcp-sfc-classifier-contr= o >>l/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>_______________________________________________ >>pcp mailing list >>pcp@ietf.org >>https://www.ietf.org/mailman/listinfo/pcp From nobody Thu Apr 24 02:26:31 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAE01A07EF for ; Thu, 24 Apr 2014 02:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePWupi_b49aU for ; Thu, 24 Apr 2014 02:26:29 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id B43341A07DC for ; Thu, 24 Apr 2014 02:26:28 -0700 (PDT) Received: from kosame.lan (80.220.67.193) by jenni2.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D2ABA00A6CE1B; Thu, 24 Apr 2014 12:26:21 +0300 From: Markus Stenberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Apr 2014 12:26:21 +0300 Message-Id: To: pcp@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/_EwNEQL7SjXlWNrmKaycvFfWBms Subject: [pcp] draft-ietf-pcp-proxy-05 + homenet (notably multihoming) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:26:30 -0000 I=92m somewhat confused (nothing new there). Section 3.5 (manual repair) = states that local mapping cache is not mandatory. However, section 3 = seems to assume it, and describes the NAT-only case. I think this part = use some clarification. Especially as mapping cacheless proxy would be = quite different beast from just =91logical back to back client and = server=92 (see below). At the moment I=92m thinking of implementing very lightweight pcp proxy = for homenet style use _within home_, which doesn=92t even have firewalls = _or_ NATs among consenting inner routers. However, the reason proxy is = needed is that: a) there=92s lots of legacy hosts there that don=92t support pcp-dhcp, = pcp-zones, and pcp-server selection, , and b) in case of IPv4, the CPE(s) are most likely NATting, and outbound = from inner routers affects where traffic will wind up anyway. As I don=92t see any way of addressing b) even with the existing set of = drafts for server selection (unless you assume you have some sort of = coupling of IPv4 routing state and PCP that works beyond next-hop = routing), there seems to be some sort of gap in the drafts to me. Please = explain to me if there isn=92t, I=92d appreciate that too. [1] To me the simple choice seems to do _very_ lightweight pcp proxy = per-hop, and do server selection based on current IPv4/IPv6 routing = state (=3Dwhere the packets with given source(+destination if PEER) = would wind up in any case). Given lack of firewalls and NATs, only state = it would need to track is the set of next hops for IPv6 source prefixes, = and IPv4 default route. If any of those change, epoch=3D0, and multicast = ANNOUNCEs (and conservatively forward announces on links not heard on = recently, or using some tree topology available from some other source). With that sort of solution, there would be no cache of mappings on the = lightweight proxy, but just idea of upstream connectivity (per-prefix = IPv6 / default route for IPv4), and some ANNOUNCE multicast spam if that = changes. I think the design could work at least given routing is moderately = stable. Comments? Alternative design is of course to do what the current draft mainly = describes - keep full mapping state, and cleverly try to repair it (in = event of routing state change) and reset epoch only if you have to, and = unicast ANNOUNCEs to clients if they should do something. With that = design, low-power devices are spared from extra spam, which is nice, at = cost of some implementation complexity and state on the routers. Still, I can=92t wrap my head around non hop-by-hop PCP unless it=92s = =93one tube to internet=94 home which isn=92t really interesting from my = point of view.=20 Cheers, -Markus [1] I know RFC6887 assumes single-homed network, but I=92d rather see = multi-homed solution work in some way too. From nobody Thu Apr 24 03:42:43 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2581A01C1 for ; Thu, 24 Apr 2014 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAMz8fcsDwPn for ; Thu, 24 Apr 2014 03:42:29 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id CCBB61A01B3 for ; Thu, 24 Apr 2014 03:42:21 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 065EF1B8067 for ; Thu, 24 Apr 2014 03:42:16 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id DF4BD19005C; Thu, 24 Apr 2014 03:42:15 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 03:42:15 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Thu, 24 Apr 2014 06:42:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <033CEC61-EFCE-403E-BDF1-A306A19F8CEB@nominum.com> References: To: Markus Stenberg X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/-9EsisVBzK4sP1oQ0aEpbP2fuCc Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-proxy-05 + homenet (notably multihoming) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 10:42:32 -0000 On Apr 24, 2014, at 5:26 AM, Markus Stenberg = wrote: > I think the design could work at least given routing is moderately = stable. Comments? That's a pretty big "if". From nobody Thu Apr 24 04:03:10 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEB21A017B for ; Thu, 24 Apr 2014 04:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3KSMV4Ucfor for ; Thu, 24 Apr 2014 04:03:05 -0700 (PDT) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3001F1A0188 for ; Thu, 24 Apr 2014 04:03:04 -0700 (PDT) Received: from kosame.lan (80.220.67.193) by jenni1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 534D293000A97270; Thu, 24 Apr 2014 14:02:54 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Markus Stenberg In-Reply-To: <033CEC61-EFCE-403E-BDF1-A306A19F8CEB@nominum.com> Date: Thu, 24 Apr 2014 14:02:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4BD985AF-EBF1-4FFF-88ED-D2211CCD0807@iki.fi> References: <033CEC61-EFCE-403E-BDF1-A306A19F8CEB@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/dybRkRgUgacvKpSVHWHl4Hju1XA Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-proxy-05 + homenet (notably multihoming) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:03:07 -0000 On 24.4.2014, at 13.42, Ted Lemon wrote: > On Apr 24, 2014, at 5:26 AM, Markus Stenberg = wrote: >> I think the design could work at least given routing is moderately = stable. Comments? > That=92s a pretty big "if". In a homenet-ish IPv4 case, you have to have moderately stable routing, = or you may flap between different CPEs. And bad things happen in that = case given different NATs in each, even without PCP.. Cheers, -Markus From nobody Thu Apr 24 04:13:13 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9171A01AA for ; Thu, 24 Apr 2014 04:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmN7gS9iyICp for ; Thu, 24 Apr 2014 04:13:03 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 195A61A0191 for ; Thu, 24 Apr 2014 04:13:01 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 398AF1B8078 for ; Thu, 24 Apr 2014 04:12:55 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2978B19005C; Thu, 24 Apr 2014 04:12:55 -0700 (PDT) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Apr 2014 04:12:54 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <4BD985AF-EBF1-4FFF-88ED-D2211CCD0807@iki.fi> Date: Thu, 24 Apr 2014 07:12:51 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <033CEC61-EFCE-403E-BDF1-A306A19F8CEB@nominum.com> <4BD985AF-EBF1-4FFF-88ED-D2211CCD0807@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/cyTvKsO9qZ30iCYrJBn3GUdTd0I Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-proxy-05 + homenet (notably multihoming) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:13:07 -0000 On Apr 24, 2014, at 7:02 AM, Markus Stenberg = wrote: > In a homenet-ish IPv4 case, you have to have moderately stable = routing, or you may flap between different CPEs. And bad things happen = in that case given different NATs in each, even without PCP.. Possibly so. What you are proposing sounds brittle to me, but that is = just an intuitive reaction, and it may be that if you presented a more = detailed analysis I would react differently. From nobody Thu Apr 24 06:04:04 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7701A01D5 for ; Thu, 24 Apr 2014 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.326 X-Spam-Level: X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_66=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bbbUSXfOBzE for ; Thu, 24 Apr 2014 06:04:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2911A01CD for ; Thu, 24 Apr 2014 06:04:00 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2DF8C40402 for ; Thu, 24 Apr 2014 09:03:54 -0400 (EDT) Message-ID: <53590BB9.9000405@viagenie.ca> Date: Thu, 24 Apr 2014 09:03:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Ww0Qj-GYbh4S4EvVXWviFt1V-YQ Subject: Re: [pcp] draft-ietf-pcp-proxy-05 + homenet (notably multihoming) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:04:01 -0000 Le 2014-04-24 05:26, Markus Stenberg a écrit : > Still, I can’t wrap my head around non hop-by-hop PCP Assuming that what you mean is what I think you mean, I had the same issue until I thought of the kind of very lightweight PCP proxy you're implementing as a degenerate case of a not-so-lightweight PCP server+client where the server happens to control a stateless firewall that passes everything. This makes the server+client model apply to everything, and still allows the implementation shortcuts you envision. Does that model help you in any way? Regarding ANNOUNCE relaying, the current text seems to allow both approaches you are considering. See the last sentence in particular: Upon receipt of an unsolicited ANNOUNCE response from a PCP server, the PCP Proxy proceeds to renew 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 multicast ANNOUNCE messages are sent to PCP clients. 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 nobody Thu Apr 24 09:31:51 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0111A020F for ; Thu, 24 Apr 2014 09:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDyYQFiwaSdT for ; Thu, 24 Apr 2014 09:31:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7F41A00CB for ; Thu, 24 Apr 2014 09:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4104; q=dns/txt; s=iport; t=1398357101; x=1399566701; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zE9y3vl4AC7NZq/VL1BhpyDuc/g75mh9oar69lJ0NPA=; b=bMUjAnrAJ0/S/IPSae8xHhCmwok1u5W/3MzQaOAu1pt2xgWFxvKikOux YLvc4CJf4yrEOSszpiGEk5lynya3uM3svoABLGN09TeHdyvf2keXVLjZ5 eszxPiuNYgsKP/cyJ99RG1AoGcZPJIQhZbJH4iFHWXQoBVVQOc21i1ytd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANg7WVOtJV2Y/2dsb2JhbABZgwZPV70DhziBHRZ0giUBAQEEAQEBawQXAgEIGCcHJwsUEQIEARIJiDcBDctCF45bBYQ5BIkvj0qBOItQhVGDMYIr X-IronPort-AV: E=Sophos;i="4.97,920,1389744000"; d="scan'208";a="320050018" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 24 Apr 2014 16:31:41 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3OGVeJp026970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Apr 2014 16:31:40 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 11:31:40 -0500 From: "Charles Eckel (eckelcu)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt Thread-Index: AQHPXbVR7ORaOuOAEki2xGXAWXepCZsdMePAgAOmgIA= Date: Thu, 24 Apr 2014 16:31:39 +0000 Message-ID: References: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F56FCB2AD@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F56FCB81E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F56FCB81E@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.13] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <00D2F22CD2573A4486FD6E95F07BFF49@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/PkkL5VNvz_Eop_VkACnICTxKTJI Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:31:49 -0000 On 4/22/14, 12:59 AM, "mohamed.boucadair@orange.com" wrote: >Hi Charles, > >Thank you for your message. > >FLOWDATA is indeed an option that could be used for classification >purposes. This is recorded briefly in the draft: > > o Explicit actions: re-mark, drop, shape (can be used with > FLOWDATA). > >The exact details on how FLOWDATA can be used are not included in this >version because I wanted -00 to focus on the problem to be solved. > >It seems to me that aeon is application-driven, which is not the case for >the pcp classifier draft. The classification function is not controlled >by a user/external application, it is under the responsibility of the >administrative entity managing the network. True; however, flowdata specified by the PCP client as a result of user/external application input may be useful to the classification function if provided to it by the PCP server. If not specified by the user/application, how else would you anticipate getting the flowdata in the first place? Cheers, Charles > >Cheers, >Med > >>-----Message d'origine----- >>De : Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>Envoy=E9 : mardi 22 avril 2014 00:59 >>=C0 : BOUCADAIR Mohamed IMT/OLN; pcp@ietf.org >>Objet : Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier- >>control-00.txt >> >>Hi Med, >> >>This is a good draft. I was envisioning a similar relationship between >>PCP >>and SFC in which flow characteristics communicated via PCP could be used >>as input into the an SFC classifier. In addition to L2/L3/L4 information, >>the information included in the proposed PCP Flowdata Option >>(http://tools.ietf.org/html/draft-wing-pcp-flowdata-00) seem useful as >>well. Using PCP to help with SFC classification is a good example of the >>more general problem described in the AEON problem statement and >>requirements draft >>(http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). >> >>Cheers, >>Charles >> >>On 4/16/14, 10:49 PM, "mohamed.boucadair@orange.com" >> wrote: >> >>>Dear all, >>> >>>I submitted this new draft to discuss issues related to the control of >>>packet classier. >>> >>>Comments are more than welcome. >>> >>>Cheers, >>>Med >>> >>>-----Message d'origine----- >>>De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>>internet-drafts@ietf.org >>>Envoy=E9 : mercredi 16 avril 2014 14:48 >>>=C0 : i-d-announce@ietf.org >>>Objet : I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : PCP as a Traffic Classifier Control Protocol >>> Author : Mohamed Boucadair >>> Filename : draft-boucadair-pcp-sfc-classifier-control-00.txt >>> Pages : 7 >>> Date : 2014-04-16 >>> >>>Abstract: >>> This document specifies how PCP (Port Control Protocol) can be used >>> as a classifier control protocol. >>> >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-boucadair-pcp-sfc-classifier-cont >>>ro >>>l/ >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00 >>> >>> >>>Please note that it may take a couple of minutes from the time of >>>submission >>>until the htmlized version and diff are available at tools.ietf.org. >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>Internet-Draft directories: http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>>_______________________________________________ >>>pcp mailing list >>>pcp@ietf.org >>>https://www.ietf.org/mailman/listinfo/pcp > From nobody Thu Apr 24 23:49:34 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A671A0447 for ; Thu, 24 Apr 2014 23:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI7WWlk-HTt0 for ; Thu, 24 Apr 2014 23:49:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0991C1A0412 for ; Thu, 24 Apr 2014 23:49:31 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 60E35190875; Fri, 25 Apr 2014 08:49:24 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 48F4B38406C; Fri, 25 Apr 2014 08:49:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 25 Apr 2014 08:49:24 +0200 From: To: "Charles Eckel (eckelcu)" , "pcp@ietf.org" Date: Fri, 25 Apr 2014 08:49:21 +0200 Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt Thread-Index: AQHPXbVR7ORaOuOAEki2xGXAWXepCZsdMePAgAOmgICAAQ1t4A== Message-ID: <94C682931C08B048B7A8645303FDC9F36F58B451A6@PUEXCB1B.nanterre.francetelecom.fr> References: <20140416124740.17502.90360.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F56FCB2AD@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36F56FCB81E@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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.24.223920 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Q6DwXGyTxU1F2tjYQ0rqc2AI-f0 Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 06:49:33 -0000 Hi Charles, The FLOWDATA can be a result of requirements expressed by a service provide= r or an internal service team to the network provider. This can be for inst= ance captured using a connectivity provisioning profile (see for example ht= tps://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-pr= ofile/) or a result of a provisioning negotiation cycle (see for example ht= tps://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-pr= otocol/). This model does not require an explicit invocation from the clien= t. The network is prepared (i.e., policies are enforced to handle packets f= rom the client) without any involved from the client side. The model described above and AEON are not conflicting as both may co-exist= in a network. I see both of them as means to trigger policy enforcement to= accommodate as much as possible customers' requirements. Cheers, Med >-----Message d'origine----- >De=A0: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >Envoy=E9=A0: jeudi 24 avril 2014 18:32 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; pcp@ietf.org >Objet=A0: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier- >control-00.txt > >On 4/22/14, 12:59 AM, "mohamed.boucadair@orange.com" > wrote: > >>Hi Charles, >> >>Thank you for your message. >> >>FLOWDATA is indeed an option that could be used for classification >>purposes. This is recorded briefly in the draft: >> >> o Explicit actions: re-mark, drop, shape (can be used with >> FLOWDATA). >> >>The exact details on how FLOWDATA can be used are not included in this >>version because I wanted -00 to focus on the problem to be solved. >> >>It seems to me that aeon is application-driven, which is not the case for >>the pcp classifier draft. The classification function is not controlled >>by a user/external application, it is under the responsibility of the >>administrative entity managing the network. > >True; however, flowdata specified by the PCP client as a result of >user/external application input may be useful to the classification >function if provided to it by the PCP server. If not specified by the >user/application, how else would you anticipate getting the flowdata in >the first place? > >Cheers, >Charles > >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>>Envoy=E9 : mardi 22 avril 2014 00:59 >>>=C0 : BOUCADAIR Mohamed IMT/OLN; pcp@ietf.org >>>Objet : Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sfc-classifier- >>>control-00.txt >>> >>>Hi Med, >>> >>>This is a good draft. I was envisioning a similar relationship between >>>PCP >>>and SFC in which flow characteristics communicated via PCP could be used >>>as input into the an SFC classifier. In addition to L2/L3/L4 information= , >>>the information included in the proposed PCP Flowdata Option >>>(http://tools.ietf.org/html/draft-wing-pcp-flowdata-00) seem useful as >>>well. Using PCP to help with SFC classification is a good example of the >>>more general problem described in the AEON problem statement and >>>requirements draft >>>(http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). >>> >>>Cheers, >>>Charles >>> >>>On 4/16/14, 10:49 PM, "mohamed.boucadair@orange.com" >>> wrote: >>> >>>>Dear all, >>>> >>>>I submitted this new draft to discuss issues related to the control of >>>>packet classier. >>>> >>>>Comments are more than welcome. >>>> >>>>Cheers, >>>>Med >>>> >>>>-----Message d'origine----- >>>>De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >>>>internet-drafts@ietf.org >>>>Envoy=E9 : mercredi 16 avril 2014 14:48 >>>>=C0 : i-d-announce@ietf.org >>>>Objet : I-D Action: draft-boucadair-pcp-sfc-classifier-control-00.txt >>>> >>>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>directories. >>>> >>>> >>>> Title : PCP as a Traffic Classifier Control Protocol >>>> Author : Mohamed Boucadair >>>> Filename : draft-boucadair-pcp-sfc-classifier-control-00.txt >>>> Pages : 7 >>>> Date : 2014-04-16 >>>> >>>>Abstract: >>>> This document specifies how PCP (Port Control Protocol) can be used >>>> as a classifier control protocol. >>>> >>>> >>>> >>>>The IETF datatracker status page for this draft is: >>>>https://datatracker.ietf.org/doc/draft-boucadair-pcp-sfc-classifier-con= t >>>>ro >>>>l/ >>>> >>>>There's also a htmlized version available at: >>>>http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-0= 0 >>>> >>>> >>>>Please note that it may take a couple of minutes from the time of >>>>submission >>>>until the htmlized version and diff are available at tools.ietf.org. >>>> >>>>Internet-Drafts are also available by anonymous FTP at: >>>>ftp://ftp.ietf.org/internet-drafts/ >>>> >>>>_______________________________________________ >>>>I-D-Announce mailing list >>>>I-D-Announce@ietf.org >>>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>>Internet-Draft directories: http://www.ietf.org/shadow.html >>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>>_______________________________________________ >>>>pcp mailing list >>>>pcp@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcp >> From nobody Fri Apr 25 07:52:02 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191A41A04B6 for ; Fri, 25 Apr 2014 07:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.422 X-Spam-Level: X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYa2t6mqejR6 for ; Fri, 25 Apr 2014 07:51:57 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id 450CE1A0300 for ; Fri, 25 Apr 2014 07:51:56 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from ) id 1WdhTW-0007Sa-R7; Fri, 25 Apr 2014 16:51:38 +0200 Date: Fri, 25 Apr 2014 16:51:38 +0200 From: Sebastian Kiesel To: draft-ietf-pcp-server-selection@tools.ietf.org Message-ID: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/530ujWjKtw86bp1V8G5cM0jyofQ Cc: pcp@ietf.org Subject: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:51:59 -0000 Hi, draft-ietf-pcp-server-selection-02 says in Section 3: 1. If the PCP client can use both address families when communicating to a particular PCP server, the PCP client SHOULD select the source address of the PCP request to be of the same IP address family as its requested PCP mapping (i.e., the address family of the Requested External IP Address). What is the reason for saying it SHOULD use the same familiy as the requested EXTERNAL IP address? I think it would make more sense to use the same familiy as the INTERNAL address (if there is a difference at all). Thanks Sebastian From nobody Fri Apr 25 07:57:57 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10A1A04AF for ; Fri, 25 Apr 2014 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vexBknylkU2r for ; Fri, 25 Apr 2014 07:57:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BCD741A04CD for ; Fri, 25 Apr 2014 07:57:51 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 202734034D for ; Fri, 25 Apr 2014 10:57:45 -0400 (EDT) Message-ID: <535A77E8.7010201@viagenie.ca> Date: Fri, 25 Apr 2014 10:57:44 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: pcp@ietf.org References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> In-Reply-To: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/bMXsxQpm8K_XzpEzroohqwRVRZE Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 14:57:54 -0000 Le 2014-04-25 10:51, Sebastian Kiesel a écrit : > draft-ietf-pcp-server-selection-02 says in Section 3: > > 1. If the PCP client can use both address families when > communicating to a particular PCP server, the PCP client SHOULD > select the source address of the PCP request to be of the same IP > address family as its requested PCP mapping (i.e., the address > family of the Requested External IP Address). > > > What is the reason for saying it SHOULD use the same familiy as the > requested EXTERNAL IP address? I think it would make more sense to use > the same familiy as the INTERNAL address (if there is a difference at > all). +1 I stated this in my review. 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 nobody Sat Apr 26 13:38:51 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF95F1A06B3 for ; Sat, 26 Apr 2014 13:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.724 X-Spam-Level: X-Spam-Status: No, score=-13.724 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSTKvvq-wGRb for ; Sat, 26 Apr 2014 13:38:48 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7E91A02F2 for ; Sat, 26 Apr 2014 13:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1205; q=dns/txt; s=iport; t=1398544721; x=1399754321; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0gRS3kepMinoIquM5Y2WdrrW3C5mm3cUqAizv9aYXMg=; b=IErGZFiylVy6zhFKLY+5YgWq501AGu/DyQ1HT+PQGPLF6wbBtyEteQQv NSheJX+gaDwNAsWzBOdgkbQpD9oiY5hr+wlIaOzpn0RKp5zurrvE9WvjR rvqOmnb8LO0s2cgrDyt6IeSilcfFLBbVyICATIuapWOB02b9Rc0qBVWEI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPoXXFOrRDoG/2dsb2JhbABZgwbGBIELFnSCJQEBAQMBeQULC0ZXBgESiDkHyWMXjiYzB4MkgRUEiXGPG4ZdjAGDUR0 X-IronPort-AV: E=Sophos;i="4.97,934,1389744000"; d="scan'208";a="108662843" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 26 Apr 2014 20:38:41 +0000 Received: from [10.21.102.114] ([10.21.102.114]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3QKcNrf030177; Sat, 26 Apr 2014 20:38:40 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <535A77E8.7010201@viagenie.ca> Date: Fri, 25 Apr 2014 18:42:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> To: Simon Perreault , Sebastian Kiesel X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/pQLs3kHcCylV4Ur71lP3WNBmUh0 Cc: PCP Working Group Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 20:38:50 -0000 On Apr 25, 2014, at 7:57 AM, Simon Perreault = wrote: > Le 2014-04-25 10:51, Sebastian Kiesel a =E9crit : >> draft-ietf-pcp-server-selection-02 says in Section 3: >>=20 >> 1. If the PCP client can use both address families when >> communicating to a particular PCP server, the PCP client SHOULD >> select the source address of the PCP request to be of the same = IP >> address family as its requested PCP mapping (i.e., the address >> family of the Requested External IP Address). >>=20 >>=20 >> What is the reason for saying it SHOULD use the same familiy as the >> requested EXTERNAL IP address? I think it would make more sense to = use >> the same familiy as the INTERNAL address (if there is a difference at >> all). >=20 > +1 >=20 > I stated this in my review. The intent of the wording is to avoid NAT64 (or NAT46) where NAT44 or no = NAT was necessary at all. If the wording is backwards, let's fix it. I = have now read it three times, and the existing text seems to avoid = NAT64. In any event, yes, there should be an explanation ("To avoid = unnecessary IP address family translation, ..."). -d From nobody Sat Apr 26 14:38:17 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC801A069C for ; Sat, 26 Apr 2014 14:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6WsZi0gEX7L for ; Sat, 26 Apr 2014 14:38:13 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id 23A4B1A0663 for ; Sat, 26 Apr 2014 14:38:12 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from ) id 1WeAIH-00009g-Sa; Sat, 26 Apr 2014 23:37:57 +0200 Date: Sat, 26 Apr 2014 23:37:57 +0200 From: Sebastian Kiesel To: Dan Wing Message-ID: <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/21PrMn38ykxbZC5SdR8PYsU78_A Cc: PCP Working Group Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 21:38:15 -0000 On Fri, Apr 25, 2014 at 06:42:53PM -0700, Dan Wing wrote: > > On Apr 25, 2014, at 7:57 AM, Simon Perreault wrote: > > > Le 2014-04-25 10:51, Sebastian Kiesel a écrit : > >> draft-ietf-pcp-server-selection-02 says in Section 3: > >> > >> 1. If the PCP client can use both address families when > >> communicating to a particular PCP server, the PCP client SHOULD > >> select the source address of the PCP request to be of the same IP > >> address family as its requested PCP mapping (i.e., the address > >> family of the Requested External IP Address). > >> > >> > >> What is the reason for saying it SHOULD use the same familiy as the > >> requested EXTERNAL IP address? I think it would make more sense to use > >> the same familiy as the INTERNAL address (if there is a difference at > >> all). > > > > +1 > > > > I stated this in my review. > > The intent of the wording is to avoid NAT64 (or NAT46) where NAT44 or > no NAT was necessary at all. reasonable goal, but does text about that belong here? this text is about PCP messages, and I think they should use the same address family as the actual user data flow on their side of the NAT. > If the wording is backwards, let's fix it. I have now read it three > times, and the existing text seems to avoid NAT64. In any event, yes, > there should be an explanation ("To avoid unnecessary IP address family > translation, ..."). Thanks Sebastian From nobody Sun Apr 27 22:37:31 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350ED1A070F for ; Sun, 27 Apr 2014 22:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.56 X-Spam-Level: X-Spam-Status: No, score=-13.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKAlouWrRgeT for ; Sun, 27 Apr 2014 22:37:28 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9626F1A0714 for ; Sun, 27 Apr 2014 22:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1788; q=dns/txt; s=iport; t=1398663446; x=1399873046; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RV9ouxeInDVv07JcHJkTUxkFl4agfNnnaV1/wDpCiKQ=; b=e+hneeZ8COLDMyv1oj3z3OTumM8Tu1+pDPkbkH0U6Zmd0oTTxDnR6/tm EluMvbY2lwGfeYIiujpuOpa0Ggwl6Mj7QVoaLGVaBXM1uw7v3HkYWECFa pKuWts/WKyNuampdy+dU/+akSEPBSXx7XbGZsDOXDDKYM1XxyiAmSgAh8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8JAA/oXVOrRDoH/2dsb2JhbABZJ4JfxgyBDBZ0giUBAQEDAXkFCwsOCi5XBhOIOQfJSheOJjMHgySBFQSJcY8bhl2MAYNRHQ X-IronPort-AV: E=Sophos;i="4.97,942,1389744000"; d="scan'208";a="111328257" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Apr 2014 05:37:24 +0000 Received: from [10.21.102.114] ([10.21.102.114]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3S5bNSh003669; Mon, 28 Apr 2014 05:37:24 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Dan Wing In-Reply-To: <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> Date: Sun, 27 Apr 2014 17:52:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09A44D3D-B395-459D-86DD-66874E914521@cisco.com> References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> To: Sebastian Kiesel X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/LL3G0AfuVY1yUwnJXM-MvA1zLVg Cc: PCP Working Group Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 05:37:29 -0000 On Apr 26, 2014, at 2:37 PM, Sebastian Kiesel = wrote: > On Fri, Apr 25, 2014 at 06:42:53PM -0700, Dan Wing wrote: >>=20 >> On Apr 25, 2014, at 7:57 AM, Simon Perreault = wrote: >>=20 >>> Le 2014-04-25 10:51, Sebastian Kiesel a =E9crit : >>>> draft-ietf-pcp-server-selection-02 says in Section 3: >>>>=20 >>>> 1. If the PCP client can use both address families when >>>> communicating to a particular PCP server, the PCP client = SHOULD >>>> select the source address of the PCP request to be of the same = IP >>>> address family as its requested PCP mapping (i.e., the address >>>> family of the Requested External IP Address). >>>>=20 >>>>=20 >>>> What is the reason for saying it SHOULD use the same familiy as the >>>> requested EXTERNAL IP address? I think it would make more sense to = use >>>> the same familiy as the INTERNAL address (if there is a difference = at >>>> all). >>>=20 >>> +1 >>>=20 >>> I stated this in my review. >>=20 >> The intent of the wording is to avoid NAT64 (or NAT46) where NAT44 or >> no NAT was necessary at all.=20 >=20 > reasonable goal, but does text about that belong here? >=20 > this text is about PCP messages, and I think they should use the > same address family as the actual user data flow on their side of > the NAT. If that avoids IP address family translation, sounds good to me. Or is = there some other value or purpose? -d >> If the wording is backwards, let's fix it. I have now read it three >> times, and the existing text seems to avoid NAT64. In any event, = yes, >> there should be an explanation ("To avoid unnecessary IP address = family >> translation, ..."). >=20 > Thanks > Sebastian From nobody Mon Apr 28 04:07:54 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C511A0977; Mon, 28 Apr 2014 04:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSkfw0bFLDI4; Mon, 28 Apr 2014 04:07:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4450F1A095F; Mon, 28 Apr 2014 04:07:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428110749.25879.71053.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 04:07:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/1XJ7riCTtJRvlol-wJzjyhm6_6E Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-server-selection-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:07:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : PCP Server Selection Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Prashanth Patil Tirumaleswar Reddy Filename : draft-ietf-pcp-server-selection-03.txt Pages : 11 Date : 2014-04-28 Abstract: The document specifies the behavior to be followed by a PCP client to contact its PCP server(s) when one or several PCP server IP addresses are configured. This document updates RFC6887. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-server-selection-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-server-selection-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 05:40:50 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E001A09E8 for ; Mon, 28 Apr 2014 05:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b80HvqRl8NcH for ; Mon, 28 Apr 2014 05:40:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96F601A07CD for ; Mon, 28 Apr 2014 05:40:47 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AF06F403DD; Mon, 28 Apr 2014 08:40:46 -0400 (EDT) Message-ID: <535E4C4E.5050507@viagenie.ca> Date: Mon, 28 Apr 2014 08:40:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dan Wing , Sebastian Kiesel References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> <09A44D3D-B395-459D-86DD-66874E914521@cisco.com> In-Reply-To: <09A44D3D-B395-459D-86DD-66874E914521@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/AE-_xYT5hWw0v-_TIuIdUom6RQ4 Cc: PCP Working Group Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:40:49 -0000 Le 2014-04-27 20:52, Dan Wing a écrit : > > On Apr 26, 2014, at 2:37 PM, Sebastian Kiesel wrote: > >> On Fri, Apr 25, 2014 at 06:42:53PM -0700, Dan Wing wrote: >>> >>> On Apr 25, 2014, at 7:57 AM, Simon Perreault wrote: >>> >>>> Le 2014-04-25 10:51, Sebastian Kiesel a écrit : >>>>> draft-ietf-pcp-server-selection-02 says in Section 3: >>>>> >>>>> 1. If the PCP client can use both address families when >>>>> communicating to a particular PCP server, the PCP client SHOULD >>>>> select the source address of the PCP request to be of the same IP >>>>> address family as its requested PCP mapping (i.e., the address >>>>> family of the Requested External IP Address). >>>>> >>>>> >>>>> What is the reason for saying it SHOULD use the same familiy as the >>>>> requested EXTERNAL IP address? I think it would make more sense to use >>>>> the same familiy as the INTERNAL address (if there is a difference at >>>>> all). >>>> >>>> +1 >>>> >>>> I stated this in my review. >>> >>> The intent of the wording is to avoid NAT64 (or NAT46) where NAT44 or >>> no NAT was necessary at all. >> >> reasonable goal, but does text about that belong here? >> >> this text is about PCP messages, and I think they should use the >> same address family as the actual user data flow on their side of >> the NAT. > > If that avoids IP address family translation, sounds good to me. Or is there some other value or purpose? I understand what you want, but the text doesn't get you what you want. I want something different, but we can both get what we want with appropriate text. First, "sending over IPvX" doesn't imply that the internal address is IPvX, because of THIRD_PARTY. What you want is: "the client SHOULD pick an internal address of the same family as that of the mapping's external address." Second, what I want is to avoid THIRD_PARTY. So that's why you need to send the request using the chosen internal address as source for the PCP request. (This is actually stricter than just using the same address family, in case you have multiple addresses of that address family.) Summarizing: "If a PCP client has access to internal addresses of multiple families, then it SHOULD choose the mapping's internal address such that it is of the same family as that of the mapping's external address. This is done to avoid address family translation when possible. The PCP client SHOULD use the mapping's internal address as source for the PCP request. This is done to avoid using the THIRD_PARTY option when possible." 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 nobody Mon Apr 28 05:46:06 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486021A09FC; Mon, 28 Apr 2014 05:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIOEvDOWZqMz; Mon, 28 Apr 2014 05:45:59 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 794071A0A01; Mon, 28 Apr 2014 05:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1764; q=dns/txt; s=iport; t=1398689159; x=1399898759; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HTCX8QrOv//O1jlK4KfNJhF7QLMYUSIPEk1qUKcTnKE=; b=fi/+IPXzWi3j+/1SAhsGZ92IyFUACvlMICx2BGWLAh+w3drG8ZRESbVz 7qtk6sEHMRvKQxygMEMJaXisbSW+tJ9BiPVScW4OjqXcWSz/jl6ZzciWP RteOyDQ4AGa74z6MBEACK28N64Zy0jnkIAjC/XKj3cOAfW6Euzob8BYgi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoHAOBMXlOtJV2b/2dsb2JhbABZgwZPUQa9Loc5gRQWdIImAQEEAQEBNzQLEAIBCDYQJwslAgQBDQUJiDgIBclwF45ZB4Q5BJkMgTqRJIMxgis X-IronPort-AV: E=Sophos;i="4.97,944,1389744000"; d="scan'208";a="39329552" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 28 Apr 2014 12:45:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3SCjwBF003325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 12:45:58 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.202]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 07:45:58 -0500 From: "Prashanth Patil (praspati)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-server-selection-03.txt Thread-Index: AQHPYt/MoyG9ex16l0CudN0ciw47xw== Date: Mon, 28 Apr 2014 12:45:56 +0000 Message-ID: References: <20140428110749.25879.71053.idtracker@ietfa.amsl.com> In-Reply-To: <20140428110749.25879.71053.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [173.39.66.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <07E0F83EDC100D4F9B62DB266DD50EF0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/hXARWlpvRM96LnxmI4rSDrjWQ7w Cc: "pcp@ietf.org" Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:46:05 -0000 Revised PCP server selection draft has been published. The update addresses comments listed in the issue tracker. -Prashanth On 4/28/14 4:37 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : PCP Server Selection > Authors : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Filename : draft-ietf-pcp-server-selection-03.txt > Pages : 11 > Date : 2014-04-28 > >Abstract: > The document specifies the behavior to be followed by a PCP client to > contact its PCP server(s) when one or several PCP server IP addresses > are configured. > > This document updates RFC6887. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-server-selection-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-03 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Mon Apr 28 05:47:49 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58441A09FC for ; Mon, 28 Apr 2014 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYSJ_d6tXUZr for ; Mon, 28 Apr 2014 05:47:44 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id BA0F11A09E8 for ; Mon, 28 Apr 2014 05:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3292; q=dns/txt; s=iport; t=1398689264; x=1399898864; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S7u5v4AYACVuUTe0DlJ0qHZpeYz1/q0bVAdhjWXE73E=; b=iXR6z2RgdBHqwODf5s8DkT/lqBiPvNg38ZRipUxCmkBVSX3lH0K1Zykb Cx7F47lchvSTyaXPLXtl4zoD3ZMz60f87EmR8lkHTat2C6nYLPqqEux6m v4xZWw6WCFA3gYpdh34GvULlHID3CXG+2NNtaZe49TnfMbBN29yqtKiqj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAJ5MXlOtJV2c/2dsb2JhbABZgwZPV70uhzmBFBZ0giUBAQEEAQEBJEcLEAIBCBguJwslAgQBDQWIQQ3JcReOWQeEOQSJN49VgTqRJIMxgis X-IronPort-AV: E=Sophos;i="4.97,944,1389744000"; d="scan'208";a="39325201" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 28 Apr 2014 12:47:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3SClhOb005550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 12:47:43 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.202]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 07:47:43 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , "Dan Wing (dwing)" , Sebastian Kiesel Thread-Topic: [pcp] PCP Server Selection - Address Family Selection Thread-Index: AQHPYuAM5gpwgGe04ECCDToCb6dOqQ== Date: Mon, 28 Apr 2014 12:47:43 +0000 Message-ID: References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> <09A44D3D-B395-459D-86DD-66874E914521@cisco.com> <535E4C4E.5050507@viagenie.ca> In-Reply-To: <535E4C4E.5050507@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [173.39.66.133] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/SKmWW4hYmrCH2qdWD7tJoDkZ50w Cc: PCP Working Group Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:47:47 -0000 We've tried to simplify text around this in the revised draft. Hopefully, it is more obvious now. -Prashanth On 4/28/14 6:10 PM, "Simon Perreault" wrote: >Le 2014-04-27 20:52, Dan Wing a =E9crit : >>=20 >> On Apr 26, 2014, at 2:37 PM, Sebastian Kiesel >>wrote: >>=20 >>> On Fri, Apr 25, 2014 at 06:42:53PM -0700, Dan Wing wrote: >>>> >>>> On Apr 25, 2014, at 7:57 AM, Simon Perreault >>>> wrote: >>>> >>>>> Le 2014-04-25 10:51, Sebastian Kiesel a =E9crit : >>>>>> draft-ietf-pcp-server-selection-02 says in Section 3: >>>>>> >>>>>> 1. If the PCP client can use both address families when >>>>>> communicating to a particular PCP server, the PCP client SHOULD >>>>>> select the source address of the PCP request to be of the same >>>>>>IP >>>>>> address family as its requested PCP mapping (i.e., the address >>>>>> family of the Requested External IP Address). >>>>>> >>>>>> >>>>>> What is the reason for saying it SHOULD use the same familiy as the >>>>>> requested EXTERNAL IP address? I think it would make more sense to >>>>>>use >>>>>> the same familiy as the INTERNAL address (if there is a difference >>>>>>at >>>>>> all). >>>>> >>>>> +1 >>>>> >>>>> I stated this in my review. >>>> >>>> The intent of the wording is to avoid NAT64 (or NAT46) where NAT44 or >>>> no NAT was necessary at all. >>> >>> reasonable goal, but does text about that belong here? >>> >>> this text is about PCP messages, and I think they should use the >>> same address family as the actual user data flow on their side of >>> the NAT. >>=20 >> If that avoids IP address family translation, sounds good to me. Or is >>there some other value or purpose? > >I understand what you want, but the text doesn't get you what you want. >I want something different, but we can both get what we want with >appropriate text. > >First, "sending over IPvX" doesn't imply that the internal address is >IPvX, because of THIRD_PARTY. What you want is: "the client SHOULD pick >an internal address of the same family as that of the mapping's external >address." > >Second, what I want is to avoid THIRD_PARTY. So that's why you need to >send the request using the chosen internal address as source for the PCP >request. (This is actually stricter than just using the same address >family, in case you have multiple addresses of that address family.) > >Summarizing: > >"If a PCP client has access to internal addresses of multiple families, >then it SHOULD choose the mapping's internal address such that it is of >the same family as that of the mapping's external address. This is done >to avoid address family translation when possible. > >The PCP client SHOULD use the mapping's internal address as source for >the PCP request. This is done to avoid using the THIRD_PARTY option when >possible." > >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 > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Mon Apr 28 05:49:33 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC401A09E8 for ; Mon, 28 Apr 2014 05:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIdY5JPgctn5 for ; Mon, 28 Apr 2014 05:49:30 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id E95B01A0A07 for ; Mon, 28 Apr 2014 05:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1767; q=dns/txt; s=iport; t=1398689367; x=1399898967; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GpRKU4NnCYJWf+zPY61jL7kzjqBA2qCNflNRfM7m9ac=; b=ISVqHMtB/Y5GoDjNktJLDk1b5hbuTqovaHNKDOWvQm5epKHsuqqZChPf 08o2GqZw0wdZ47RWHA+YVs40ENg8kHWUGWVccECt4wKr1hXTEnJYefyfS 3tCucIuzZv3LIUS3mw1SFuXFuE5j0BBf6SN/DAEVarKCqlJ4Xto6Yr48j w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkHAJNNXlOtJV2Z/2dsb2JhbABZgwZPUQa9Loc5gRQWdIImAQEEAQEBNzQbAgEINhAnCyUCBBMJiDgIBclqF45ghDkEmQyBOpEkgzGCKw X-IronPort-AV: E=Sophos;i="4.97,944,1389744000"; d="scan'208";a="39336210" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 28 Apr 2014 12:49:27 +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 s3SCnRtY024923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 12:49:27 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 07:49:26 -0500 From: "Prashanth Patil (praspati)" To: PCP Working Group Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-server-selection-03.txt Thread-Index: AQHPYuBJoyG9ex16l0CudN0ciw47xw== Date: Mon, 28 Apr 2014 12:49:26 +0000 Message-ID: References: <20140428110749.25879.71053.idtracker@ietfa.amsl.com> In-Reply-To: <20140428110749.25879.71053.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [173.39.66.133] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/uXRuUpSRsGHpuUdP5lowsJLTOAY Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:49:31 -0000 Revised PCP server selection draft has been published. The update addresses comments listed in the issue tracker. =20 -Prashanth On 4/28/14 4:37 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : PCP Server Selection > Authors : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Filename : draft-ietf-pcp-server-selection-03.txt > Pages : 11 > Date : 2014-04-28 > >Abstract: > The document specifies the behavior to be followed by a PCP client to > contact its PCP server(s) when one or several PCP server IP addresses > are configured. > > This document updates RFC6887. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-server-selection-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-03 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Mon Apr 28 05:56:35 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC301A09E8 for ; Mon, 28 Apr 2014 05:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2Mpv7ocZaPE for ; Mon, 28 Apr 2014 05:56:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC851A047C for ; Mon, 28 Apr 2014 05:56:28 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:15b:212f:d481:de2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5BD99403DD; Mon, 28 Apr 2014 08:56:27 -0400 (EDT) Message-ID: <535E4FFB.4020109@viagenie.ca> Date: Mon, 28 Apr 2014 08:56:27 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "Dan Wing (dwing)" , Sebastian Kiesel References: <20140425145138.GC4891@gw01.ehlo.wurstkaes.de> <535A77E8.7010201@viagenie.ca> <79E3AFAF-D801-4152-94AC-57FA4B5D1BED@cisco.com> <20140426213757.GD4891@gw01.ehlo.wurstkaes.de> <09A44D3D-B395-459D-86DD-66874E914521@cisco.com> <535E4C4E.5050507@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/o_YBGHX5INsTRfS0FhUDcMrdaJg Cc: PCP Working Group Subject: Re: [pcp] PCP Server Selection - Address Family Selection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:56:30 -0000 Le 2014-04-28 08:47, Prashanth Patil (praspati) a écrit : > We've tried to simplify text around this in the revised draft. Hopefully, > it is more obvious now. I'll do another full review in a new thread. 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 nobody Mon Apr 28 23:07:03 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1971A884F for ; Mon, 28 Apr 2014 23:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhB7xkCvI9IF for ; Mon, 28 Apr 2014 23:07:00 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7751A8840 for ; Mon, 28 Apr 2014 23:07:00 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id ih12so5570349qab.30 for ; Mon, 28 Apr 2014 23:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MYzNEsgtewUxHvVsShtXdgyc1FRdkVI68+5ul/RslNA=; b=tlKNe9kkiauSoa8Xb26kbpJ0kWDVcNkrfeyjSgmiV75tYZBnqabQ5H8ZAzPy93x84q P3cqifm0+pVKUfYfPimMqvLwqyiXuPkIcP85YLSlYSj57jBfLsEOUsT32A0meWWSdRjA LY4NiYo4eKjVlhDQGhbbSJ6DO1247R9mqcBB/0fNrX0xNQkZBWZcmt7rm2SL0d2DTs4E jx8TAmXGBD+MVeBguX6j3EVDxhzZ91W1Xh6EP7aKKP89YMephw7e578Ox5HP6cOQ+urd EPEAF08F/d9C2nukjBnF2SVkR20Gk0q1Ft7GsFEq8vYEH44sgib0UJSBoAagqWdTF53I msxQ== MIME-Version: 1.0 X-Received: by 10.224.61.200 with SMTP id u8mr39804420qah.18.1398751619403; Mon, 28 Apr 2014 23:06:59 -0700 (PDT) Received: by 10.224.51.137 with HTTP; Mon, 28 Apr 2014 23:06:59 -0700 (PDT) Date: Tue, 29 Apr 2014 14:06:59 +0800 Message-ID: From: GangChen To: "pcp@ietf.org" , draft-penno-pcp-mobile-qos@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/RfTM7eqQYVsacqMCWJTCWooCAb8 Subject: [pcp] review on draft-penno-pcp-mobile-qos X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 06:07:02 -0000 Hello Authors, I have reviewed the draft. The below is the comments. However, the Mobile Network may not trust the host (UE) to signal the correct flow characteristics permitted by the WebRTC server. => If you take look at TR23.701, 3GPP prefers WebRTC signalling function serving a AF to customize the policy. WebRTC signalling function entity is aware of the flow characteristics, afterwards the entity could direct correct network actions. So, I guess the sentence of "However" we could remove. For third party applications differentiated QoS services can be installed even if the UE is behind NAT provided by the Mobile Network. In contrast, other mechanisms struggle to install differentiated QOS if the UE is behind NAT. => Te scenario you indicated may worth to be clarified. You may indicate the case where there the bearer in PGW is identified by private 5 tuple and PCRF asks PGW to binding a Service Data Flow with public address. Looking at the architecture of TR23.701, it's may not happened at this time, because there is no NAT between PGW and WebRTC signalling function entity(AF). b. Mobile Network can authorize the differentiated service request from third party application because the proposed mechanism is compliant with the 3GPP's network-triggered QoS policy enforcement model. => AF(from third party) assigns particular policies to PCRF, which translate application specific language to 3GPP compliant. I guess there is no need to ask 3rd party app informs PCRF 3GPP specific language. 1. It is out of scope of this document to discuss the trade-offs between the proposed approach vs. deploying local WebRTC-IMS Gateways within the Mobile Network. => It's an important information. May I suggest elaborate this information in the main body. It also would be good to say what the relation of local WebRTC-IMS solution to the proposed solution. PCP success response would be sent without waiting for network-initiated bearer activation or modification to be complete: i.e., PCP success response would be sent based on the resource availability to setup or modify bearers. why not waiting for the completion of EPC bearer allocation? 3. The PDN-GW will communicate with the PCRF to trigger the appropriate Policy charging and control (PCC) decision based on which PDN-GW will initiate bearer activation or modification procedure. I can't understand the intention of PCRF selecting different PGWs. The process the draft described is more like ADC procedure. The PGW monitor the particular event (i.e. PCP request in this draft) and inform PCRF, after then PCRF only needs to permit the resource usage on the initiated PGW. BRs Gang