From Andreas.Ripke@neclab.eu  Mon Feb  3 01:01:50 2014
Return-Path: <Andreas.Ripke@neclab.eu>
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 A0B351A0192 for <pcp@ietfa.amsl.com>; Mon,  3 Feb 2014 01:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.436
X-Spam-Level: 
X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, 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 kL3mRbSj7K8u for <pcp@ietfa.amsl.com>; Mon,  3 Feb 2014 01:01:48 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 44C921A0170 for <pcp@ietf.org>; Mon,  3 Feb 2014 01:01:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 41D9B106B03 for <pcp@ietf.org>; Mon,  3 Feb 2014 10:01:43 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29+Zu+y8GjTu for <pcp@ietf.org>; Mon,  3 Feb 2014 10:01:43 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 21A6A106AFD for <pcp@ietf.org>; Mon,  3 Feb 2014 10:01:38 +0100 (CET)
Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 3 Feb 2014 10:01:17 +0100
From: Andreas Ripke <Andreas.Ripke@neclab.eu>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: question on PCP proxy
Thread-Index: Ac8gvFDLhr31xMV/QN2urUMIZaUWWA==
Date: Mon, 3 Feb 2014 09:01:15 +0000
Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631C65CF@DAPHNIS.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.215]
Content-Type: multipart/alternative; boundary="_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_"
MIME-Version: 1.0
Subject: [pcp] question on PCP proxy
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 09:01:50 -0000

--_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I am writing to inquire about the status of draft-ietf-pcp-proxy that recen=
tly expired.
What are the pending issues with this draft and is there any intention to r=
evive it?

Thanks.

Best,

Andreas


NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End=
  Road, London, HA4 6QE, GB | Registered in England 2832014


--_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I am writing to inquire about the status of draft-ie=
tf-pcp-proxy that recently expired.<o:p></o:p></p>
<p class=3D"MsoNormal">What are the pending issues with this draft and is t=
here any intention to revive it?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Best,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Andreas<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">NEC Europe Ltd | Registered Office: Athene, Odyssey =
Business Park, West End &nbsp;Road, London, HA4 6QE, GB | Registered in Eng=
land 2832014<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_--

From tireddy@cisco.com  Mon Feb  3 06:07:25 2014
Return-Path: <tireddy@cisco.com>
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 36D4D1A00C7 for <pcp@ietfa.amsl.com>; Mon,  3 Feb 2014 06:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.436
X-Spam-Level: 
X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.535, 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 aBoqeAhql4-O for <pcp@ietfa.amsl.com>; Mon,  3 Feb 2014 06:07:20 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 285A81A01CF for <pcp@ietf.org>; Mon,  3 Feb 2014 06:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4923; q=dns/txt; s=iport; t=1391436291; x=1392645891; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=8pq/V6YQ9DUxr1STJAdmYRErqkfkJno6C3j3yOOjX8o=; b=B0ZLpFDmyXLSPPYuhLYLNggG36IS8WaSk/SR0MQeMs6gbVF6E/V8NEiV yiGkc8ep4Gb1qIxjcyKCRAQex1shmOBUCHgK6N575zJq1VREKtC64d9MM /32Z0ZjX5P1tSwcQeqagLH1ZMtyNxx/L0b16mKwjZ3RTUAnW1fzpx4joW 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0FAIqh71KtJXHA/2dsb2JhbABPCoMMOEsMvgiBCBZ0giUBAQEEeRIBCBEEAQELGT0dCQEEAQ0FCAGHfA3MQxeOLSsxgyuBFASJEZBLkG+Bb4E+gWgCHgIEHBE
X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="17525685"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 03 Feb 2014 14:04:50 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s13E4ook016409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Mon, 3 Feb 2014 14:04:51 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 08:04:50 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "Anca Zamfir (ancaz)" <ancaz@cisco.com>, "Reinaldo Penno (repenno)" <repenno@cisco.com>, "Dan Wing (dwing)" <dwing@cisco.com>, "Prashanth Patil (praspati)" <praspati@cisco.com>
Thread-Topic: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)
Thread-Index: Ac8g6OM9iZ7sffF+Q5SWt1ojcC5EYg==
Date: Mon, 3 Feb 2014 14:04:50 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A242A5956@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.51.29]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 14:07:25 -0000

Hi Anca,

Thanks for the review. Please see inline [TR]

From: Anca Zamfir (ancaz)=20
Sent: Wednesday, January 29, 2014 4:56 PM
To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing=
); Prashanth Patil (praspati)
Cc: pcp@ietf.org
Subject: [pcp] Comments on PCP Extension for Third Party Authorization (htt=
p://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)

Hi Tiru et al,
A few comments and questions on this draft.=A0

Section 4:
. Figure 1: could you identify the entities you mention in the text below i=
t? Like PCP Client (Alice box), Oauth 2.0 server (does it have to be the We=
bRTC or could it be separate?)

[TR]  Yes, updated.

. I don't understand the paragraph after bullet 4 and how is relevant to th=
is section/ draft? What do you mean by "This technique"?

[TR] Replaced "This technique" with " The technique proposed in the specifi=
cation".=20
The paragraph explains how this technique can be used with PCP-aware NAT to=
 permit MAP request after the client has got the token.=20

Section 5:

. Figure 3: Show a bidirectional Request/ Response on (1). Show a (5) arrow=
 with PCP Response so the loop is closed.

[TR]  Fixed.

. Same question as above. Does the Auth Server has to be the WebRTC Server =
(or app server in general)? Or is this figure just a possible scenario ?

[TR]  Yes,  The authorization server in this specific example has to be the=
 WebRTC server because only it will be aware of call termination details to=
 revoke the token.

. Create section 5.1 for the option detail and say something like "This spe=
cification defines the new PCP ACCESS_TOKEN Option."

[TR] ok.

. Option Length: Is this like any PCP option (i.e. length of Option Data, m=
ust be multiple of 4, etc). Maybe just refer to RFC6887 Section 7.3

[TR]  Yes and its variable length.

. "Reserved1": set to 0 by sender and ignored by the receiver?

[TR] Added
=20
Lifetime: Why does the PCP Client need to tell the PCP Server about the lif=
etime? Is this the expires_in value that the PCP Client got from the Auth S=
erver? Can this be "extended" later in a PCP Request by the PCP Client/ Ali=
ce or Mallory? And what would happen? I thought the PCP Server =A0must ensu=
re that the token has not expired by interacting with the authorization ser=
ver (e.g. on arrow (4) in your Figure 3, the Auth server would also include=
 the lifetime). I don't understand why it's needed in the PCP Option.

[TR] The PCP servers uses the lifetime field to do local validation before =
interacting with the Authorization Server for further checks. Yes, this is =
the expires_in value that the PCP Client got from the Authorization server.=
  Performing local validation is just a minor benefit and anyways the PCP S=
erver will ensure that the token has not expired by interacting with the au=
thorization server.

. Timestamp : This assumes some sort of synchronization, right? Then I don'=
t understand how the Timestamp on its own can prevent replay attacks. Maybe=
 you can elaborate on this a bit?

[TR] Sure.=20
Using the formula "Lifetime + Delta > abs(RDnew - TSnew)" defined in sectio=
n 7 of the draft, PCP server can find out if the Timestamp field in the ACC=
ESS_TOKEN option is too old when compared to the receipt of the PCP request=
.


. May appear in: response...I don't see any explanation on when PCP Server =
would include it in response and what is the PCP Client supposed to do/ che=
ck. Maybe you can say a few words about this in Sections 5.2 and 5.3=A0

[TR] If the token is valid then the PCP server generates a success PCP resp=
onse (it's the same as in RFC 6887, no changes)

. Probably out of scope but what happens on mapping refresh, PCP server res=
tart, etc? Will PCP Client get new token, reuse the old one, etc? Maybe giv=
e some hints on good practices?

[TR] It's covered in Section 7 "Security Considerations"

<snip>
A PCP server will delete explicit dynamic mappings after the lifetime of th=
e cryptographic token expires. The PCP client must obtain a new cryptograph=
ic token from the authorization server before the current token becomes inv=
alid or expires. The PCP client must propagate the new cryptographic token =
to the PCP server to refresh lifetime of mappings before the current token =
becomes invalid or expires
</snip>

Section 6:
. PCP Proxy question: What are the possible actions here wrt to the TOKEN o=
ption? Just forward or drop (e.g. if unknown and configured to drop unknown=
s)?=A0

[TR]  PCP Proxy will replay the ACCESS_TOKEN option because it's a mandator=
y-to-process option. For more information on the PCP proxy behavior w.r.t m=
andatory-to-process option please refer to section 7 in http://tools.ietf.o=
rg/html/draft-ietf-pcp-proxy-04#section-7=20

Cheers,
-Tiru.

thanks,
-anca

From simon.perreault@viagenie.ca  Mon Feb  3 07:44:32 2014
Return-Path: <simon.perreault@viagenie.ca>
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 5CE911A0155 for <pcp@ietfa.amsl.com>; Mon,  3 Feb 2014 07:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 sGm_mi4jKEPx for <pcp@ietfa.amsl.com>; Mon,  3 Feb 2014 07:44:29 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB371A0199 for <pcp@ietf.org>; Mon,  3 Feb 2014 07:44:29 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F370B40379 for <pcp@ietf.org>; Mon,  3 Feb 2014 10:44:28 -0500 (EST)
Message-ID: <52EFB95C.9080605@viagenie.ca>
Date: Mon, 03 Feb 2014 10:44:28 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: pcp@ietf.org
References: <2D2FFE4726FAF74285C45D69FDC30E79631C65CF@DAPHNIS.office.hd>
In-Reply-To: <2D2FFE4726FAF74285C45D69FDC30E79631C65CF@DAPHNIS.office.hd>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [pcp] question on PCP proxy
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 15:44:32 -0000

Le 2014-02-03 04:01, Andreas Ripke a écrit :
> I am writing to inquire about the status of draft-ietf-pcp-proxy that
> recently expired.
> 
> What are the pending issues with this draft and is there any intention
> to revive it?

A new revision should be posted very very very very soon... :)

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 rjsparks@nostrum.com  Mon Feb  3 15:06:30 2014
Return-Path: <rjsparks@nostrum.com>
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 5B0261A027B; Mon,  3 Feb 2014 15:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 ZBEVV-F5TbfS; Mon,  3 Feb 2014 15:06:29 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6253F1A0267; Mon,  3 Feb 2014 15:06:29 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s13N6Tco047547 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 3 Feb 2014 17:06:29 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52F020FE.6090904@nostrum.com>
Date: Mon, 03 Feb 2014 17:06:38 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, pcp@ietf.org, draft-ietf-pcp-nat64-prefix64@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Subject: [pcp] Gen-art LC review: draft-ietf-pcp-nat64-prefix64-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 23:06:30 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pcp-nat64-prefix64-04
Reviewer: Robert Sparks
Review Date: 3-Jan-2014
IETF LC End Date: 4-Jan-2014
IESG Telechat date: Unknown

Summary: Ready with Nits

Nits/editorial comments:

There are several references to expired drafts (some very expired).
If those are not going to progress, the details you wanted to call out 
would be better moved here.

It's not clear which of the results in nat64-experiments you are 
pointing to for support for this document.
Is the reference necessary? If so, can it be made more specific.

In section 4.1, you restate the allowed values for length from RFC6052. 
Consider making the statement
even clearer that these values are a consequence of RFC6052 and aren't 
being defined by this document.
Something like "The allowed values are specified in RFC6052 (currently 
4,5,6,7,8,12).
(I almost didn't include this since that set's not likely to change, but 
somebody might copy the style...)

RjS




From internet-drafts@ietf.org  Mon Feb  3 22:38:45 2014
Return-Path: <internet-drafts@ietf.org>
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 575931A037B; Mon,  3 Feb 2014 22:38:45 -0800 (PST)
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 8yQZGrJQjRwx; Mon,  3 Feb 2014 22:38:44 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE81A0371; Mon,  3 Feb 2014 22:38:44 -0800 (PST)
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.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140204063844.24004.20992.idtracker@ietfa.amsl.com>
Date: Mon, 03 Feb 2014 22:38:44 -0800
Cc: pcp@ietf.org
Subject: [pcp] I-D Action: draft-ietf-pcp-description-option-04.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 06:38:45 -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 Description Option
        Authors         : Mohamed Boucadair
                          Reinaldo Penno
                          Dan Wing
	Filename        : draft-ietf-pcp-description-option-04.txt
	Pages           : 6
	Date            : 2014-02-03

Abstract:
   This document extends Port Control Protocol (PCP) with the ability to
   associate a description with a PCP-instantiated mapping.  It does so
   by defining a new DESCRIPTION option.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-description-option-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-description-option-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Mon Feb  3 22:58:03 2014
Return-Path: <internet-drafts@ietf.org>
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 611411A038C; Mon,  3 Feb 2014 22:58:03 -0800 (PST)
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 wgESn-rudVYZ; Mon,  3 Feb 2014 22:58:01 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA261A0385; Mon,  3 Feb 2014 22:58:01 -0800 (PST)
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.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140204065801.26408.27074.idtracker@ietfa.amsl.com>
Date: Mon, 03 Feb 2014 22:58:01 -0800
Cc: pcp@ietf.org
Subject: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 06:58:03 -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           : Learning NAT64 PREFIX64s using Port Control Protocol (PCP)
        Author          : Mohamed Boucadair
	Filename        : draft-ietf-pcp-nat64-prefix64-05.txt
	Pages           : 17
	Date            : 2014-02-03

Abstract:
   This document defines a new Port Control Protocol (PCP) option to
   learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to
   build IPv4-converted IPv6 addresses.  This option is needed for
   successful communications when IPv4 addresses are used in referrals.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-nat64-prefix64-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Tue Feb  4 08:58:04 2014
Return-Path: <internet-drafts@ietf.org>
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 00C481A0135; Tue,  4 Feb 2014 08:58:04 -0800 (PST)
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 WV8sxLSyfhi5; Tue,  4 Feb 2014 08:58:02 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8121A019F; Tue,  4 Feb 2014 08:58:02 -0800 (PST)
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.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140204165802.24244.94984.idtracker@ietfa.amsl.com>
Date: Tue, 04 Feb 2014 08:58:02 -0800
Cc: pcp@ietf.org
Subject: [pcp] I-D Action: draft-ietf-pcp-proxy-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 16:58:04 -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           : Port Control Protocol (PCP) Proxy Function
        Authors         : Simon Perreault
                          Mohamed Boucadair
                          Reinaldo Penno
                          Dan Wing
                          Stuart Cheshire
	Filename        : draft-ietf-pcp-proxy-05.txt
	Pages           : 12
	Date            : 2014-01-29

Abstract:
   This document specifies a new PCP functional element denoted as a PCP
   Proxy.  The PCP Proxy relays PCP requests received from PCP clients
   to upstream PCP server(s).  A typical deployment usage of this
   function is to help establish successful PCP communications for PCP
   clients that can not be configured with the address of a PCP server
   located more than one hop away.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-proxy-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-proxy-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From simon.perreault@viagenie.ca  Tue Feb  4 09:05:29 2014
Return-Path: <simon.perreault@viagenie.ca>
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 00BAF1A020A for <pcp@ietfa.amsl.com>; Tue,  4 Feb 2014 09:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 blTkC64vwKQN for <pcp@ietfa.amsl.com>; Tue,  4 Feb 2014 09:05:27 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 347181A011D for <pcp@ietf.org>; Tue,  4 Feb 2014 09:05:27 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB4734037A for <pcp@ietf.org>; Tue,  4 Feb 2014 12:05:26 -0500 (EST)
Message-ID: <52F11DD6.2090004@viagenie.ca>
Date: Tue, 04 Feb 2014 12:05:26 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: pcp@ietf.org
References: <20140204165802.24244.94984.idtracker@ietfa.amsl.com>
In-Reply-To: <20140204165802.24244.94984.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [pcp] I-D Action: draft-ietf-pcp-proxy-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 17:05:29 -0000

All,

This new revision is a merge between -04 and
draft-cheshire-recursive-pcp. The general aim was to define the proxy as
a back-to-back server and client, while ensuring that unknown opcodes
were propagated upstream.

Discuss! :)

Simon

Le 2014-02-04 11:58, internet-drafts@ietf.org a écrit :
> 
> 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           : Port Control Protocol (PCP) Proxy Function
>         Authors         : Simon Perreault
>                           Mohamed Boucadair
>                           Reinaldo Penno
>                           Dan Wing
>                           Stuart Cheshire
> 	Filename        : draft-ietf-pcp-proxy-05.txt
> 	Pages           : 12
> 	Date            : 2014-01-29
> 
> Abstract:
>    This document specifies a new PCP functional element denoted as a PCP
>    Proxy.  The PCP Proxy relays PCP requests received from PCP clients
>    to upstream PCP server(s).  A typical deployment usage of this
>    function is to help establish successful PCP communications for PCP
>    clients that can not be configured with the address of a PCP server
>    located more than one hop away.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pcp-proxy-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-proxy-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
> 


-- 
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 tireddy@cisco.com  Wed Feb  5 05:49:07 2014
Return-Path: <tireddy@cisco.com>
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 EBD2A1A0149 for <pcp@ietfa.amsl.com>; Wed,  5 Feb 2014 05:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 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.535, 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 70JdrWdFaRjR for <pcp@ietfa.amsl.com>; Wed,  5 Feb 2014 05:49:06 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1852E1A012D for <pcp@ietf.org>; Wed,  5 Feb 2014 05:49:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2726; q=dns/txt; s=iport; t=1391608145; x=1392817745; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iiAn5gkL0sxwX5VoMsrxmp7NL9swzmgaeTDwwyBChXE=; b=QizhqQ+arfWZJf50d9iI28DPQtcdy6NBtzq5FI2UyVKO8+27NpkrlO4Y r0XSTNa3rUGNb4LxrzfWdwXJOOEAPZ9o9PN12q/7BdtVUMZO0tGM1KcLV zMylHCboldQBNF8WBTL6AwkwAwZZuTqkf9c9QlmiVK86+WYcQJ7CVcK2T Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjgFABFB8lKtJV2c/2dsb2JhbABZgww4UQaDAbtCGHcWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYd8CAWteqE0F4EpjRs4BoJpNYEUBJldkG+DLYIq
X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="301981051"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 05 Feb 2014 13:49:05 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s15Dn5XP012655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Wed, 5 Feb 2014 13:49:05 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 07:49:04 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: New Version Notification for draft-wing-pcp-third-party-authz-02.txt
Thread-Index: AQHPInihkrAT5A4qwUqSM0P2ssdBwpqmrOrw
Date: Wed, 5 Feb 2014 13:49:04 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A242A8343@xmb-rcd-x10.cisco.com>
References: <20140205134608.386.45135.idtracker@ietfa.amsl.com>
In-Reply-To: <20140205134608.386.45135.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.61.203]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-02.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 13:49:08 -0000

UmV2aXNlZCBkcmFmdC13aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMiBoYXMgYmVlbiBwdWJs
aXNoZWQuIFRoZSB1cGRhdGUgaW5jb3Jwb3JhdGVzIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9t
IHRoZSBXRy4gRnVydGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoN
ClRoYW5rcyBhbmQgUmVnYXJkcywNCi1BdXRob3JzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNzoxNiBQ
TQ0KVG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp
cmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0
aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5nKTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBEYW4g
V2luZyAoZHdpbmcpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykNClN1YmplY3Q6IE5ldyBWZXJz
aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHotMDIu
dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdpbmctcGNwLXRoaXJkLXBhcnR5
LWF1dGh6LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFs
ZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ
ZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHoNClJldmlzaW9uOgkwMg0KVGl0bGU6CQlQ
Q1AgRXh0ZW5zaW9uIGZvciBUaGlyZCBQYXJ0eSBBdXRob3JpemF0aW9uDQpEb2N1bWVudCBkYXRl
OgkyMDE0LTAyLTA1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNQ0K
VVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0
LXdpbmctcGNwLXRoaXJkLXBhcnR5LWF1dGh6LTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbmctcGNwLXRoaXJkLXBhcnR5LWF1
dGh6Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdp
bmctcGNwLXRoaXJkLXBhcnR5LWF1dGh6LTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5p
ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHotMDIN
Cg0KQWJzdHJhY3Q6DQogICBJdCBpcyBvZnRlbiBkZXNpcmFibGUgZm9yIGFuIGFwcGxpY2F0aW9u
IHNlcnZlciB0byBwZXJtaXQgYSBmbG93DQogICBhY3Jvc3MgYSBmaXJld2FsbCwgYXMgaGFwcGVu
cyB0b2RheSB3aGVuIGEgZmlyZXdhbGwgaW5jbHVkZXMgYW4NCiAgIEFwcGxpY2F0aW9uIExheWVy
IEdhdGV3YXkgKEFMRykgZnVuY3Rpb24uICBIb3dldmVyLCBhbiBBTEcgaGFzDQogICBzZXZlcmFs
IHdlYWtuZXNzZXMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY3J5cHRvZ3JhcGhp
YyB0ZWNobmlxdWUgZm9yIGFuIGFwcGxpY2F0aW9uDQogICBzZXJ2ZXIgdG8gcGVybWl0IGEgZmxv
dyBhY3Jvc3MgYSBmaXJld2FsbC4gIFRoaXMgdGVjaG5pcXVlIHVzZXMgT0F1dGgNCiAgIGFuZCBh
IG5ldyBQQ1Agb3B0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNl
IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg
b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh
aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=

From tireddy@cisco.com  Wed Feb  5 10:33:43 2014
Return-Path: <tireddy@cisco.com>
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 28EA91A0138 for <pcp@ietfa.amsl.com>; Wed,  5 Feb 2014 10:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 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.535, 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 Izhb5lIG4IpU for <pcp@ietfa.amsl.com>; Wed,  5 Feb 2014 10:33:41 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8B1A0132 for <pcp@ietf.org>; Wed,  5 Feb 2014 10:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7124; q=dns/txt; s=iport; t=1391625220; x=1392834820; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5BeROcLn1/28sy0RopCHhzIk3xTsNVHdegU4NKsikqw=; b=E4mvYXeHUJ2A3ETGXB4DmEN8Loy8TFg6SQe4md1Egg85wqWIiIfS+8mw kHBe660T47lq/kF3j9sjWCNGzohxofrLItIgAZzOTzDyY5ZtbX7QOovem ELmS9odZJXXTh5KxMH2YD+UTUekAzbqGm0IO3DZ1v2QwP9gvjZoY+YWxT E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMFAJqD8lKtJXG8/2dsb2JhbABPCoMMOFe+TIEQFnSCJQEBAQSBCwEIEQQBAQsdORQJCQEEARIIE4dqDc50F44UBQUKHINcgRQEiRGQTJBvgy2BaUE
X-IronPort-AV: E=Sophos;i="4.95,788,1384300800"; d="scan'208";a="18215611"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 05 Feb 2014 18:33:39 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s15IXd8U015728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 18:33:39 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 12:33:39 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Ben McCann <B.McCann@F5.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] Draft-wing-pcp-flowdata-000 Comments
Thread-Index: Ac8ioMUrjNvuc54eQby5psLfys81zA==
Date: Wed, 5 Feb 2014 18:33:38 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A242A86F8@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.34.133]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pcp] Draft-wing-pcp-flowdata-000 Comments
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 18:33:43 -0000

Hi Ben,

Thanks for the detailed review. Please see inline [TR]

From: Ben McCann [mailto:B.McCann@F5.com]=20
Sent: Wednesday, January 29, 2014 2:25 AM
To: pcp@ietf.org
Subject: [pcp] Draft-wing-pcp-flowdata-000 Comments

Hi Dan, Reinaldo, and Tiru,

I have a few comments and questions on your PCP flowdata draft. Overall, it=
 looks good.

To summarize, this PCP enhancement enables an application attached to an ac=
cess network to signal its resource (bandwidth, etc) requirements to the ne=
twork via a PCP server. The PCP server reserves none, some, or all of the r=
equested resources and returns a response describing that reservation.

. Section 1: Recursively forwarding PCP FlowData requests hop-by-hop throug=
h the access network is an elegant solution for reserving resources from th=
e application to the boundary between the access network and the Internet. =
That said, =A0does this introduce scaling problems ?

o Are there administrative scaling challenges for large access networks wit=
h many switches and routers? Do most of them have to be configured with PCP=
 servers for the reservation system to be effective?

[TR] Not all switches and routers in large access network need to be PCP-aw=
are. PCP server in the access network can convey the information to the SDN=
 controller (Policy Decision Point) which in turn installs flow in network =
devices. For more information refer to draft http://tools.ietf.org/html/dra=
ft-penno-pcp-asdn-00=20

o Can upstream PCP servers handle all of the individual reservation request=
s arriving from multiple downstream PCP servers? Is some kind of reservatio=
n aggregation mechanism required to scale to 1000's or 10000s of reservatio=
ns?


. Section 3.2 & Figure 3: Does the FlowData option in a MAP request define =
the aggregate resource requirements for all matching inbound flows going to=
 the application sending that MAP request or is the reservation per flow? B=
oth options have issues:

o If the reservation is for all flows, then the resource manager can easily=
 reserve resources (bandwidth, etc) in aggregate for that application. That=
 simplifies resource allocation but it is extremely inefficient because res=
ources are pre-allocated for flows that may never arrive.

o If the reservation is per flow, then how does the resource manager know h=
ow many resources to reserve? If the MAP request FlowData option only descr=
ibes the resource requirements for one flow, then how does the resource res=
ervation system know how many flows to expect?

IMHO, both of these options are broken. Instead, the FlowData option should=
:
o Describe the resource requirements per flow. The CGNAT/Firewall/Etc must =
reserve resources incrementally as clients connect to the mapped server. Th=
is provides some level of fairness across multiple servers using the MAP re=
quest.
o Define the maximum number of flows that are expected. The PCP server may =
return a smaller number in the MAP reply if this is excessive. The CGNAT ma=
y reject inbound connections that exceed this upper bound to ensure it has =
resources for other mapped servers.
o Define the behavior of the connection when resources (as defined in the M=
AP request) are unavailable. Should the CGNAT fall back to "best effort", d=
rop the SYN packet and let the client retry, send back something in ICMP, o=
r should it reject the connection request with a RST? (Examples are admitte=
dly TCP-centric).

In summary, FlowData should describe resources per flow, how many flows are=
 expected, and how to handle new inbound flows when resources are unavailab=
le.

Note that the CGNAT/Firewall handles resource reservation errors autonomous=
ly because, IMHO, sending PCP packets back to the client when resources are=
 low introduces unacceptable DoS attack vectors.

[TR] Good point. The reason for supporting FLOWDATA with MAP is to use it i=
n SIP/WebRTC calls where an endpoint with multiple interfaces (3G, Wifi etc=
) can use MAP with FLOWDATA on each available interface to find if any of t=
he networks can meet the requested flow characteristics,  so that the appli=
cation can prioritize the host candidates accordingly based on FLOWDATA res=
ponse.  In this case it would be only be one flow per MAP request. The scen=
ario you have mentioned would be typically used by servers and would use MA=
P for multiple flows.  we will define the behavior of FLOWDATA option with =
MAP opcode in the next revision.=20

. Section 6: Why do we need a separate authorization mechanism for FlowData=
? The client's identify is verified during PCP Authentication so why doesn'=
t the PCP server consult a policy server at that time to determine the clie=
nt's resource reservation privileges? We don't need a separate crypto-token=
 for FlowData because the whole PCP request is signed by the PCP Authentica=
tion Tag. We should also avoid authorizing individual FlowData requests to =
an external server because it won't scale.

[TR] PCP third party authorization is required only for some applications. =
For example in a scenario where access network has business agreement with =
Netflix, Hulu Plus etc. HTTP Adaptive Streaming client will send PCP reques=
t with access token option so that the access network can prioritize the on=
e-way streaming content. Usage of PCP third party authorization in Mobile n=
etworks is explained http://tools.ietf.org/search/draft-penno-pcp-mobile-qo=
s-00, where PCP requests with third party authorization will be mapped to Q=
CI values 1 to 4 and Bandwidth Minimum value in FLOWDATA option will be map=
ped to Guaranteed bit rate (GBR). PCP requests without third party authoriz=
ation will also be honored but mapped only to QCI values 6 to 8 (Non- GBR).=
=20

. (Other) Should the FlowData option define enforcement policies for non-co=
nformant flows that exceed their bandwidth reservation? For example, best e=
ffort, some flavor of random early discard, rate shaping, etc, etc.? The al=
ternative is that the reservation enforcement policy is statically defined =
per hop and that it is unaware of the best protocol-dependent method to enf=
orce bandwidth reservations.

[TR] Yes, FlowData option should enforce policies for flows which lie or mi=
sbehave. In section 3.3 this problem is discussed

<snip>

  A PCP server that processes the FLOWDATA option is likely to create
   state for that flow (e.g., for bandwidth counting so that the
   bandwidth is returned to the bandwidth pool when the flow lifetime
   expires).  Because Memory and other resources limit how much state
   can be created, the PCP server MUST implement a policy limit so that
   all state is not consumed by one host.  It MAY also implement other
   limits, such as rate limits.  The PCP server can implement its own
   policy to remove flows from its memory, such as FIFO.  If a host has
   exceeded its quota, the existing error USER_EX_QUOTA SHOULD be
   returned.

</snip>
=20
Cheers,
-Tiru.

Ben McCann,
F5 Networks

From repenno@cisco.com  Thu Feb  6 11:54:26 2014
Return-Path: <repenno@cisco.com>
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 D58031A044C for <pcp@ietfa.amsl.com>; Thu,  6 Feb 2014 11:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 mLmUOqaxchH3 for <pcp@ietfa.amsl.com>; Thu,  6 Feb 2014 11:54:25 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A27791A03ED for <pcp@ietf.org>; Thu,  6 Feb 2014 11:54:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1002; q=dns/txt; s=iport; t=1391716464; x=1392926064; h=from:to:subject:date:message-id:mime-version; bh=xpjEzAteabTnCEVL+zMNYR8q47N+v9gg4mB8RB+c6rA=; b=ivzgvFoYZvNopMEkKgv5G+HRDnGeK1p6I8RJYYJW57JN6591ognoQOgH TvAvV5M/EigRuxw3UpZFZlL+FeF842M8o2aMjdBc8uxSoGvsP9n7qijRP tX3dvqgcvRnCYguK+vujlKUbUakaRXUGng0L2Vs0pzwHfAMSzASoRCP/W I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFALfn81KtJXHB/2dsb2JhbABZgkhEgQ++aYEXFnSCLB1uAQsBAnInBIgYnQGwDheOJoUTBJgrkiGDLYIq
X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208,217";a="18545719"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 06 Feb 2014 19:54:24 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s16JsO42016252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Thu, 6 Feb 2014 19:54:24 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 13:54:24 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: PCP WG Call for Presentation - IETF London
Thread-Index: AQHPI3U71M6Y0T32I0K+YWkcpYErOQ==
Date: Thu, 6 Feb 2014 19:54:23 +0000
Message-ID: <CF19286E.8AFC%repenno@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.112.52]
Content-Type: multipart/alternative; boundary="_000_CF19286E8AFCrepennociscocom_"
MIME-Version: 1.0
Subject: [pcp] PCP WG Call for Presentation - IETF London
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 19:54:26 -0000

--_000_CF19286E8AFCrepennociscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If you would like to present, please send title, time needed, presenter and=
 pointer to draft (if exists).

Thanks,

Chairs

--_000_CF19286E8AFCrepennociscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <C69D3E55F6141542AB7B19B67DC1C0F1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif;">
<div>If you would like to present, please send title, time needed, presente=
r and pointer to draft (if exists).</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Chairs</div>
</body>
</html>

--_000_CF19286E8AFCrepennociscocom_--

From dthaler@microsoft.com  Fri Feb  7 18:35:09 2014
Return-Path: <dthaler@microsoft.com>
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 B2B2E1AD947 for <pcp@ietfa.amsl.com>; Fri,  7 Feb 2014 18:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level: 
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 N7BAHy4HdQjc for <pcp@ietfa.amsl.com>; Fri,  7 Feb 2014 18:35:07 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8371A046C for <pcp@ietf.org>; Fri,  7 Feb 2014 18:35:07 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.873.15; Sat, 8 Feb 2014 02:35:05 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Sat, 8 Feb 2014 02:35:05 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
Thread-Index: Ac8kdjJMiw3eyGvqT6mQAxskuNkKaQ==
Date: Sat, 8 Feb 2014 02:35:05 +0000
Message-ID: <8242767cd57c4b6c94759273739404b7@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ee31::3]
x-forefront-prvs: 01165471DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(13464003)(164054003)(377424004)(189002)(199002)(51704005)(479174003)(377454003)(83072002)(90146001)(56816005)(77982001)(85852003)(59766001)(76576001)(74876001)(76786001)(87266001)(19580405001)(94946001)(83322001)(19580395003)(86612001)(86362001)(94316002)(80976001)(93516002)(95416001)(54316002)(56776001)(47446002)(2656002)(85306002)(87936001)(76176001)(74502001)(74662001)(31966008)(76796001)(93136001)(33646001)(51856001)(81816001)(81686001)(15975445006)(46102001)(92566001)(65816001)(53806001)(76482001)(80022001)(74316001)(4396001)(54356001)(50986001)(47976001)(47736001)(49866001)(81342001)(79102001)(81542001)(74706001)(74366001)(69226001)(63696002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:2CE8FDDD.DF227C2.B5D6B3B7.50E9D9DC.20348; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2014 02:35:09 -0000

This email initiates a two-week Working Group Last Call on
draft-ietf-pcp-server-selection-02 to conclude on Friday, February 21st.
Please send comments to the list.

As a reminder, when responding to a WGLC, what we chairs are looking for is=
 a statement=20
about document quality (not really about whether the mechanism should move
forward).  That is, state whether you think the document is ready as is,
or if not, what issues you see.

Thanks,
-Dave

> -----Original Message-----
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil
> (praspati)
> Sent: Monday, January 6, 2014 8:52 AM
> To: pcp@ietf.org
> Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt
>=20
> Folks,
> Revised PCP server selection draft has been published. The update
> addresses comments received from Dave Thaler and the ones at IETF 88.
>=20
> -Prashanth
>=20
>=20
> On 1/6/14 10:19 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>=20
> >
> >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-02.txt
> >	Pages           : 11
> >	Date            : 2014-01-06
> >
> >Abstract:
> >   Multiple IP addresses may be configured on a PCP client in some
> >   deployment contexts such as multi-homing.  This document specifies
> >   the behavior to be followed by the 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-02
> >
> >A diff from the previous version is available at:
> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02
> >
> >
> >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
>=20
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

From internet-drafts@ietf.org  Sat Feb  8 01:36:11 2014
Return-Path: <internet-drafts@ietf.org>
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 6B3751ADF43; Sat,  8 Feb 2014 01:36:11 -0800 (PST)
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 jopyOqb30bs2; Sat,  8 Feb 2014 01:36:10 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A731ADF44; Sat,  8 Feb 2014 01:36:10 -0800 (PST)
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.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140208093609.19040.45724.idtracker@ietfa.amsl.com>
Date: Sat, 08 Feb 2014 01:36:09 -0800
Cc: pcp@ietf.org
Subject: [pcp] I-D Action: draft-ietf-pcp-authentication-03.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2014 09:36:11 -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           : Port Control Protocol (PCP) Authentication Mechanism
        Authors         : Margaret Wasserman
                          Sam Hartman
                          Dacheng Zhang
	Filename        : draft-ietf-pcp-authentication-03.txt
	Pages           : 23
	Date            : 2014-02-08

Abstract:
   An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
   flexibly manage the IP address and port mapping information on
   Network Address Translators (NATs) or firewalls, to facilitate
   communications with remote hosts.  However, the un-controlled
   generation or deletion of IP address mappings on such network devices
   may cause security risks and should be avoided.  In some cases the
   client may need to prove that it is authorized to modify, create or
   delete PCP mappings.  This document proposes an in-band
   authentication mechanism for PCP that can be used in those cases.
   The Extensible Authentication Protocol (EAP) is used to perform
   authentication between PCP devices.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-authentication-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-authentication-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 hassnaa.moustafa@intel.com  Tue Feb 11 13:16:02 2014
Return-Path: <hassnaa.moustafa@intel.com>
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 1B04F1A075E for <pcp@ietfa.amsl.com>; Tue, 11 Feb 2014 13:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level: 
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 RqHnPXaX2VO6 for <pcp@ietfa.amsl.com>; Tue, 11 Feb 2014 13:15:58 -0800 (PST)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9162D1A0764 for <pcp@ietf.org>; Tue, 11 Feb 2014 13:15:58 -0800 (PST)
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 11 Feb 2014 13:15:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.95,827,1384329600"; d="scan'208";a="473616687"
Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga001.fm.intel.com with ESMTP; 11 Feb 2014 13:15:57 -0800
Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 13:15:57 -0800
Received: from orsmsx102.amr.corp.intel.com ([169.254.1.111]) by ORSMSX155.amr.corp.intel.com ([169.254.7.248]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 13:15:57 -0800
From: "Moustafa, Hassnaa" <hassnaa.moustafa@intel.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: Comments For WGLC (draft-ietf-pcp-server-selection-02.txt)
Thread-Index: Ac8nbnAMPmCLz4feSSugkAOF9m9TDg==
Date: Tue, 11 Feb 2014 21:15:55 +0000
Message-ID: <F893BEC192403B489DBA38999068CF1905989BC0@ORSMSX102.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [pcp] Comments For WGLC (draft-ietf-pcp-server-selection-02.txt)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2014 21:16:02 -0000

Hi,

There are few editorial comments on draft (draft-ietf-pcp-server-selection-=
02) as follows:
1.	The term IP address family used in the draft needs more text clarificati=
on (to say for example IPv4 or IPv6 or maybe other points that the authors =
have in mind).
2.	The IP addresses used in the diagram (in the example of Section 5) is no=
t very consistent with the IP addresses mentioned in the text that explains=
 the diagram.


Regards,
Hassnaa

-----Original Message-----
From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Friday, February 07, 2014 6:35 PM
To: pcp@ietf.org
Subject: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by=
 FEB 21

This email initiates a two-week Working Group Last Call on
draft-ietf-pcp-server-selection-02 to conclude on Friday, February 21st.
Please send comments to the list.

As a reminder, when responding to a WGLC, what we chairs are looking for is=
 a statement about document quality (not really about whether the mechanism=
 should move forward).  That is, state whether you think the document is re=
ady as is, or if not, what issues you see.

Thanks,
-Dave

> -----Original Message-----
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil
> (praspati)
> Sent: Monday, January 6, 2014 8:52 AM
> To: pcp@ietf.org
> Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt
>=20
> Folks,
> Revised PCP server selection draft has been published. The update=20
> addresses comments received from Dave Thaler and the ones at IETF 88.
>=20
> -Prashanth
>=20
>=20
> On 1/6/14 10:19 PM, "internet-drafts@ietf.org"=20
> <internet-drafts@ietf.org>
> wrote:
>=20
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts=20
> >directories.
> > This draft is a work item of the Port Control Protocol Working Group=20
> >of the IETF.
> >
> >        Title           : PCP Server Selection
> >        Authors         : Mohamed Boucadair
> >                          Reinaldo Penno
> >                          Dan Wing
> >                          Prashanth Patil
> >                          Tirumaleswar Reddy
> >	Filename        : draft-ietf-pcp-server-selection-02.txt
> >	Pages           : 11
> >	Date            : 2014-01-06
> >
> >Abstract:
> >   Multiple IP addresses may be configured on a PCP client in some
> >   deployment contexts such as multi-homing.  This document specifies
> >   the behavior to be followed by the 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-02
> >
> >A diff from the previous version is available at:
> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02
> >
> >
> >Please note that it may take a couple of minutes from the time of=20
> >submission until the htmlized version and diff are available at=20
> >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
>=20
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
_______________________________________________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp


From simon.perreault@viagenie.ca  Wed Feb 12 14:20:26 2014
Return-Path: <simon.perreault@viagenie.ca>
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 8B2BA1A0002 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 14:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 8e0aRXkTOZJ4 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 14:20:22 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECA71A001B for <pcp@ietf.org>; Wed, 12 Feb 2014 14:20:21 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 22B0C403CB for <pcp@ietf.org>; Wed, 12 Feb 2014 17:20:20 -0500 (EST)
Message-ID: <52FBF3A3.2070009@viagenie.ca>
Date: Wed, 12 Feb 2014 17:20:19 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "pcp@ietf.org" <pcp@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 22:20:26 -0000

All,

Here's my review...

Summary: This draft contains major issues that need to be resolved
before being sent to IESG.

> 3.  IP Address Selection
> 
>    These steps specify the behavior to be followed by the PCP client to
>    contact a PCP server when the PCP client has multiple IP addresses
>    for a single PCP server.

How does the client know that those addresses belong to a single PCP server?

Does this work when there are multiple addresses that belong to multiple
PCP servers, or does it need to be a single server?

Are we assuming that there is always a single PCP server per interface,
and therefore all addresses can only belong to a single server by
definition?

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

This is wrong. You can't pick a source address based on the requested
external address family. You can only pick the address family. For
example, you can decide that you're going to use IPv6 to request an IPv6
external address, but that does not help decide which source IPv6
address you're going to use.

And this is even more fundamentally wrong. The address family of the PCP
request depends on your internal address family, not the suggested
external address family. If your server is listening on IPvX, you send
your PCP request over IPvX. Otherwise you have to play games with
THIRD_PARTY. The external address family has nothing to do with it.

In fact, the source address you're going to select has to be one your
server is listening on. Otherwise you'll have to play games with
THIRD_PARTY. Often servers just listen on the wildcard address, so that
does not help you pick one particular address, but if that's not the
case then you don't have a choice.

Finally, "Requested External IP Address" is not a PCP term. I think you
mean "Suggested External IP Address".

>    2.  Whenever communicating with a PCP server, the rules of Section 6
>        of [RFC6724] SHOULD be followed by using the source address
>        selected in the previous step as input to the destination address
>        selection algorithm.

Step 1 did not yield a particular source address. It yielded an address
family. You still need to pick a particular source address.

>    3.  The PCP client initializes its Maximum Retransmission Count (MRC)
>        to 4.
> 
>    4.  The PCP client sends its PCP message to the PCP server's IP
>        address following the retransmission procedure specified in
>        Section 8.1.1 of [RFC6887].  If no response is received after MRC
>        attempts, the PCP client re-tries the procedure excluding the
>        destination addresses which did not respond.  The PCP client
>        SHOULD ignore any response received from an IP address after
>        exhausting MRC attempts for that particular IP address.  If, when
>        sending PCP requests, the PCP client receives a hard ICMP error
>        [RFC1122] it SHOULD immediately try the next IP address from the
>        list of PCP server' IP addresses.
> 
>    5.  If the PCP client has exhausted all IP addresses configured for a
>        given PCP server, the procedure is repeated every fifteen minutes
>        until the PCP request is successfully answered.
> 
>    6.  Once the PCP client has successfully received a response from a
>        PCP server's IP address, it sends subsequent PCP requests to the
>        same server's IP address until that IP address becomes non-
>        responsive, which causes the PCP client to follow the steps above
>        to contact its PCP server.

Do we reset the destination address set then? That is, are addresses
that failed previously now potentially good again?

> 4.  Multiple Interfaces
> 
>    When an end host has multiple interfaces concurrently active (e.g.,
>    IEEE 802.11 and 3G), a PCP client would discover different PCP
>    servers over different interfaces.  A host may have multiple network
>    interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently.
>    Each PCP server learned MUST be associated with the interface via
>    which it was learned.  Particularly, the PCP client relies on the
>    source IP address of an outgoing PCP request to select which PCP
>    server(s) to use.

That last sentence would be wrong following my feedback to section 3.

> 5.  Example: Multiple PCP servers on a Single Interface
> 
>    Figure 1 depicts an example that is used to illustrate the server
>    selection procedure specified in Section 3.
> 
>                                ISP Network
>                              |              |
>        .........................................................
>                              |              |        Subscriber Network
>                      +-------+------+  +----+---------+
>                      | PCP-Server-A |  | PCP-Server-B |
>                      |              |  |              |
>                      +-------+------+  +----+---------+
>             192.0.2.1        |              |     198.51.100.1
>             2001:db8:2222::1 |              |     2001:db8:3333::1
>                              |              |
>                              |              |
>                       -------+--------------+-----------
>                                      |
>                                      |    203.0.113.0
>                                      |    2001:db8:1111::1
>                                  +---+---+
>                                  | Host  |
>                                  +-------+
> 
>                                  Figure 1

The PCP servers in this figure look like routers. To make things clearer:

- Remove the connection from each PCP server to the ISP network.

- Draw the "PCP-controlled device". That one would look like a router
and would be sitting on the border between the subscriber network and
the ISP network. Connect it to both PCP servers and the host. No need
for addresses.

Is there only one PCP-controlled device, or does each server control its
own device?

>    The PCP client sends two PCP requests at the same time,

Really? The algorithm from section 3 does not seem to allow parallel
requests. I'm lost.

>    the first to
>    192.0.2.1 (corresponding to PCP-Server-A) and the second to
>    198.51.100.1 (corresponding to PCP-Server-B).  The path to
>    198.51.100.1 is working so a PCP response is received.  Because the
>    path to 192.0.2.1 is broken, no PCP response is received.  The PCP
>    client retries 4 times to elicit a response from 192.0.2.1 and
>    finally gives up on that address and sends a PCP message to
>    2001::db8:1111:1.  That path is working, and a response is received.
>    Thereafter, the PCP client should continue using that responsive IP
>    address for PCP-Server-A (2001:db8:1111::1).  In this particular
>    case, it will have to use THIRD_PARTY option for IPv4 mappings.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca


From dwing@cisco.com  Wed Feb 12 17:02:17 2014
Return-Path: <dwing@cisco.com>
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 A45421A0081 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 17:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.76
X-Spam-Level: 
X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 H2zPeCypzHuD for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 17:02:15 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D38AB1A0079 for <pcp@ietf.org>; Wed, 12 Feb 2014 17:02:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1510; q=dns/txt; s=iport; t=1392253335; x=1393462935; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mOB3UyA+vM9XHwapYGPrnxE8rnjQ5WpWlcW/0d93TN0=; b=Do537mson3lwl6KRZvcPGpS93pFXpjMZG4D+Rucjj5vT0FYIDXdSu+8a xDFis6c5bKxJuh7ZgGK1dWv2glUOon18HJzpfQEy+g7hGQnA+yO2gsDo3 f91i6mvPFGO9/m1ax0frXuur7Fkk5pzGmHk43oP9wkA8VKXEC6oF6hexs A=;
X-IronPort-AV: E=Sophos;i="4.95,835,1384300800"; d="scan'208";a="105604150"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Feb 2014 01:02:15 +0000
Received: from [10.85.165.242] ([10.85.165.242]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1D12189013574; Thu, 13 Feb 2014 01:02:07 GMT
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com>
Date: Wed, 12 Feb 2014 17:02:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B12D7908-1773-4DC9-8474-90532F328E21@cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com>
To: "Zhangzhan (Channy)" <channy.zhang@huawei.com>
X-Mailer: Apple Mail (2.1510)
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 01:02:17 -0000

On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:

> "Indeed, it has been discussed."
>=20
> What's the final conclusion to the discussion?=20
>=20
> How PCP applies in the Dual-Egress NAT scene?
>=20
> Could you please share it?=20

I removed the RFC Editor from the thread.

PCP client needs to communicate to both of the NATs independently.  =
Which the same host (the PCP client) needs to know how to do anyway to =
send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to =
different networks, the host must have routing entries.  The PCP client =
can use those same routing entries to know there are two routers on the =
network, and send PCP messages to those two routers separately.

-d


>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13
> =CA=D5=BC=FE=C8=CB: Dan Wing
> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group
> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887)
>=20
> On Feb 12, 2014, at 10:15 AM, Dan Wing <dwing@cisco.com> wrote:
>> It seems appropriate to discuss this question on the PCP mailing =
list, pcp@ietf.org.
>=20
> Indeed, it has been discussed.   This isn't really an appropriate =
topic for an erratum.
>=20


From dwing@cisco.com  Wed Feb 12 18:22:49 2014
Return-Path: <dwing@cisco.com>
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 7940E1A00C9 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 18:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.76
X-Spam-Level: 
X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 Q9c9JlZKKvv2 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 18:22:46 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AC35C1A00CB for <pcp@ietf.org>; Wed, 12 Feb 2014 18:22:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3319; q=dns/txt; s=iport; t=1392258166; x=1393467766; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=27za/TbmOeOOom/RY+ZTVfQHInP490UBe+KfpG27TN0=; b=m5TuU02ryvuMugvAVo6SDfLjEAX5gbTeq1USnvVfD3ECfwndvYuMw9cG 6rKZZAaxvOgDPLJ35JUP1TyeFgVIjxCBKjEqCgEMw2XLubWYJVQA4ugT+ NVDvozgiWzI+7SAzRW8NjC9pZfz3T/5nLNxI6x0TkWDkqKaX63H1EOe81 k=;
X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="scan'208";a="102328145"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 02:22:45 +0000
Received: from [10.85.165.242] ([10.85.165.242]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1D2MgXP025702; Thu, 13 Feb 2014 02:22:43 GMT
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com>
Date: Wed, 12 Feb 2014 18:22:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com>
To: Zhangzhan (Channy) <channy.zhang@huawei.com>
X-Mailer: Apple Mail (2.1510)
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 02:22:49 -0000

On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) =
<channy.zhang@huawei.com> wrote:

> Maybe you misunderstand me.
> There is only one router for NAT and PCP.
> If the NAT gateway device (such as CGN) is PCP Server and has two or =
more out interfaces to internet were doing different nat conversion in =
the ISP.=20
> Maybe using NAT address pool A, B, C... And the routing entries to =
internet on NAT gateway is equivalent default route. In this case, the =
out interface is uncertain, fully in accordance with the equivalent =
route selection.
> If no PCP, service traffic can be selected out interface according to =
the destination address and do different NAT conversion.
> But the PCP message is in before the normal service traffic. And PCP =
MAP mode message does not include the destination address, the NAT =
gateway device how to choose the out interfaces and the different NAT =
address pools?=20
> Based on the current PCP protocol, I think that can't be solved. Or =
what I understand something wrong?

With such a network topology, you are correct that the current MAP =
opcode doesn't work.  We need something different.  Would =
http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution?

-d


>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02
> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical =
Errata Reported] RFC6887 (3887)
>=20
>=20
> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:
>=20
>> "Indeed, it has been discussed."
>>=20
>> What's the final conclusion to the discussion?=20
>>=20
>> How PCP applies in the Dual-Egress NAT scene?
>>=20
>> Could you please share it?=20
>=20
> I removed the RFC Editor from the thread.
>=20
> PCP client needs to communicate to both of the NATs independently.  =
Which the same host (the PCP client) needs to know how to do anyway to =
send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to =
different networks, the host must have routing entries.  The PCP client =
can use those same routing entries to know there are two routers on the =
network, and send PCP messages to those two routers separately.
>=20
> -d
>=20
>=20
>>=20
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13
>> =CA=D5=BC=FE=C8=CB: Dan Wing
>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group
>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887)
>>=20
>> On Feb 12, 2014, at 10:15 AM, Dan Wing <dwing@cisco.com> wrote:
>>> It seems appropriate to discuss this question on the PCP mailing =
list, pcp@ietf.org.
>>=20
>> Indeed, it has been discussed.   This isn't really an appropriate =
topic for an erratum.
>>=20
>=20


From dthaler@microsoft.com  Wed Feb 12 18:35:59 2014
Return-Path: <dthaler@microsoft.com>
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 4EAE31A00B6 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 18:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.652
X-Spam-Level: 
X-Spam-Status: No, score=-96.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 zKvNjDzqrB1s for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 18:35:57 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE11A00AB for <pcp@ietf.org>; Wed, 12 Feb 2014 18:35:56 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 02:35:47 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 02:35:47 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Dan Wing <dwing@cisco.com>, Zhangzhan <channy.zhang@huawei.com>
Thread-Topic: =?gb2312?B?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNobmljYWwg?= =?gb2312?Q?Errata_Reported]_RFC6887_(3887)?=
Thread-Index: AQHPJ6LKN4bC5yHBw0Cuo55Yoa2Q+pqxu0+AgAAQJoCAAJAjAIAAA4gAgAAHuwCAAA7RAIAAAsuw
Date: Thu, 13 Feb 2014 02:35:46 +0000
Message-ID: <df7903f4794646e3855dc40dd1a475d7@BY2PR03MB412.namprd03.prod.outlook.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com>
In-Reply-To: <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.135.4.20]
x-forefront-prvs: 0121F24F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(24454002)(189002)(199002)(377454003)(13464003)(51444003)(81816001)(76482001)(81686001)(33646001)(4396001)(53806001)(51856001)(46102001)(47976001)(49866001)(47736001)(74876001)(50986001)(95666001)(93136001)(94316002)(90146001)(56816005)(74706001)(86362001)(54356001)(19580395003)(2656002)(94946001)(87936001)(76786001)(83322001)(76576001)(95416001)(76796001)(86612001)(83072002)(77982001)(80976001)(224303002)(59766001)(19580405001)(85852003)(74366001)(79102001)(85306002)(66066001)(92566001)(65816001)(80022001)(87266001)(74316001)(56776001)(31966008)(74662001)(93516002)(47446002)(74502001)(81342001)(54316002)(69226001)(63696002)(81542001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:FC7CF1C5.2CF2CDA6.9F3DD7B.CED0D151.20300; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 02:35:59 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW4gV2luZyBbbWFpbHRvOmR3
aW5nQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCA2OjIz
IFBNDQo+IFRvOiBaaGFuZ3poYW4NCj4gQ2M6IFRlZCBMZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7
IFN0dWFydCBDaGVzaGlyZTsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRh
aXI7IFJlaW5hbGRvIFBlbm5vOw0KPiBwc2Vsa2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbjsg
RGF2ZSBUaGFsZXINCj4gU3ViamVjdDogUmU6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1c2lvbj+0
8Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0NCj4gUkZDNjg4NyAoMzg4NykNCj4gDQo+
IA0KPiBPbiBGZWIgMTIsIDIwMTQsIGF0IDU6MjkgUE0sIFpoYW5nemhhbiAoQ2hhbm55KQ0KPiA8
Y2hhbm55LnpoYW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPiBNYXliZSB5b3UgbWlzdW5k
ZXJzdGFuZCBtZS4NCj4gPiBUaGVyZSBpcyBvbmx5IG9uZSByb3V0ZXIgZm9yIE5BVCBhbmQgUENQ
Lg0KPiA+IElmIHRoZSBOQVQgZ2F0ZXdheSBkZXZpY2UgKHN1Y2ggYXMgQ0dOKSBpcyBQQ1AgU2Vy
dmVyIGFuZCBoYXMgdHdvIG9yIG1vcmUNCj4gb3V0IGludGVyZmFjZXMgdG8gaW50ZXJuZXQgd2Vy
ZSBkb2luZyBkaWZmZXJlbnQgbmF0IGNvbnZlcnNpb24gaW4gdGhlIElTUC4NCj4gPiBNYXliZSB1
c2luZyBOQVQgYWRkcmVzcyBwb29sIEEsIEIsIEMuLi4gQW5kIHRoZSByb3V0aW5nIGVudHJpZXMg
dG8gaW50ZXJuZXQNCj4gb24gTkFUIGdhdGV3YXkgaXMgZXF1aXZhbGVudCBkZWZhdWx0IHJvdXRl
LiBJbiB0aGlzIGNhc2UsIHRoZSBvdXQgaW50ZXJmYWNlIGlzDQo+IHVuY2VydGFpbiwgZnVsbHkg
aW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBlcXVpdmFsZW50IHJvdXRlIHNlbGVjdGlvbi4NCj4gPiBJ
ZiBubyBQQ1AsIHNlcnZpY2UgdHJhZmZpYyBjYW4gYmUgc2VsZWN0ZWQgb3V0IGludGVyZmFjZSBh
Y2NvcmRpbmcgdG8gdGhlDQo+IGRlc3RpbmF0aW9uIGFkZHJlc3MgYW5kIGRvIGRpZmZlcmVudCBO
QVQgY29udmVyc2lvbi4NCj4gPiBCdXQgdGhlIFBDUCBtZXNzYWdlIGlzIGluIGJlZm9yZSB0aGUg
bm9ybWFsIHNlcnZpY2UgdHJhZmZpYy4gQW5kIFBDUCBNQVANCj4gbW9kZSBtZXNzYWdlIGRvZXMg
bm90IGluY2x1ZGUgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MsIHRoZSBOQVQgZ2F0ZXdheQ0KPiBk
ZXZpY2UgaG93IHRvIGNob29zZSB0aGUgb3V0IGludGVyZmFjZXMgYW5kIHRoZSBkaWZmZXJlbnQg
TkFUIGFkZHJlc3MNCj4gcG9vbHM/DQo+ID4gQmFzZWQgb24gdGhlIGN1cnJlbnQgUENQIHByb3Rv
Y29sLCBJIHRoaW5rIHRoYXQgY2FuJ3QgYmUgc29sdmVkLiBPciB3aGF0IEkNCj4gdW5kZXJzdGFu
ZCBzb21ldGhpbmcgd3Jvbmc/DQo+IA0KPiBXaXRoIHN1Y2ggYSBuZXR3b3JrIHRvcG9sb2d5LCB5
b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudCBNQVAgb3Bjb2RlDQo+IGRvZXNuJ3Qgd29y
ay4NCg0KSSdtIG5vdCBzdXJlIGl0J3MgZmFpciB0byBzYXkgaXQgImRvZXNuJ3Qgd29yayIuICBJ
dCBqdXN0IG1lYW5zIHRoYXQgdGhlIE5BVCBwaWNrcw0Kb25lIHVzaW5nIGFueSBpbXBsZW1lbnRh
dGlvbi1zcGVjaWZpYyBtZWNoYW5pc20uICBJbiB0aGUgc3RhdGVkIGV4YW1wbGUgYWJvdmUsDQpi
b3RoIHBvc3NpYmxlIGFuc3dlcnMgZ28gdG8gdGhlIEludGVybmV0LCBzbyB3aGF0IHdvdWxkbid0
ICJ3b3JrIj8NCg0KT24gdGhlIHRvcGljIG9mIHRoZSBlcnJhdGEsIEkgYWdyZWUgd2l0aCBUZWQg
aXQgaXMgbm90IGFuIGVycmF0YS4gIEl0J3Mgc2ltcGx5IGFuDQppbXBsZW1lbnRhdGlvbiBkZXRh
aWwgdGhhdCB0aGUgUkZDIGRvZXNuJ3Qgc3BlY2lmeSwgc28gaXQncyB1cCB0byB0aGUgcmVhZGVy
Lg0KDQotRGF2ZQ0K


From dwing@cisco.com  Wed Feb 12 18:54:38 2014
Return-Path: <dwing@cisco.com>
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 848A91A004A for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 18:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level: 
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548, 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 Gheydz1eKNm5 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 18:54:36 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBFF1A0028 for <pcp@ietf.org>; Wed, 12 Feb 2014 18:54:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2431; q=dns/txt; s=iport; t=1392260075; x=1393469675; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=m4MqACOAFLlJFbjBeEv9okgGH8L9MA6FGEfkvtZbL+U=; b=Z7LUQznL4jMB7XooD+mVPDX75QbHxbAK1O+Mv2ZkGoIP0tT2FOPwc/zp qb27HAvMiy2RE2eumzbIep/+mgegyzvA7GXquVs2Z8GAA+B4sA2qEE7Tc abzOiHGZre2/H95OZtUekweQQApJmZGQTKo38Y2WDY7PmcU/2XEn9a7Uo U=;
X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="scan'208";a="20040490"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 13 Feb 2014 02:54:33 +0000
Received: from [10.85.165.242] ([10.85.165.242]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1D2sURp008344; Thu, 13 Feb 2014 02:54:31 GMT
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <df7903f4794646e3855dc40dd1a475d7@BY2PR03MB412.namprd03.prod.outlook.com>
Date: Wed, 12 Feb 2014 18:54:30 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <38C9F787-C766-47FF-835F-E224BFD47483@cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <df7903f4794646e3855dc40dd1a475d7@BY2PR03MB412.namprd03.prod.outlook.com>
To: Dave Thaler <dthaler@microsoft.com>
X-Mailer: Apple Mail (2.1510)
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, Zhangzhan <channy.zhang@huawei.com>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 02:54:38 -0000

On Feb 12, 2014, at 6:35 PM, Dave Thaler <dthaler@microsoft.com> wrote:

>> -----Original Message-----
>> From: Dan Wing [mailto:dwing@cisco.com]
>> Sent: Wednesday, February 12, 2014 6:23 PM
>> To: Zhangzhan
>> Cc: Ted Lemon; PCP Working Group; Stuart Cheshire;
>> mohamed.boucadair@orange.com Boucadair; Reinaldo Penno;
>> pselkirk@isc.org; Brian Haberman; Dave Thaler
>> Subject: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical =
Errata Reported]
>> RFC6887 (3887)
>>=20
>>=20
>> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy)
>> <channy.zhang@huawei.com> wrote:
>>=20
>>> Maybe you misunderstand me.
>>> There is only one router for NAT and PCP.
>>> If the NAT gateway device (such as CGN) is PCP Server and has two or =
more
>> out interfaces to internet were doing different nat conversion in the =
ISP.
>>> Maybe using NAT address pool A, B, C... And the routing entries to =
internet
>> on NAT gateway is equivalent default route. In this case, the out =
interface is
>> uncertain, fully in accordance with the equivalent route selection.
>>> If no PCP, service traffic can be selected out interface according =
to the
>> destination address and do different NAT conversion.
>>> But the PCP message is in before the normal service traffic. And PCP =
MAP
>> mode message does not include the destination address, the NAT =
gateway
>> device how to choose the out interfaces and the different NAT address
>> pools?
>>> Based on the current PCP protocol, I think that can't be solved. Or =
what I
>> understand something wrong?
>>=20
>> With such a network topology, you are correct that the current MAP =
opcode
>> doesn't work.
>=20
> I'm not sure it's fair to say it "doesn't work".  It just means that =
the NAT picks
> one using any implementation-specific mechanism.  In the stated =
example above,
> both possible answers go to the Internet, so what wouldn't "work"?

Good point.  Same with a TCP SYN -- it gets assigned to one CGN, or the =
other -- it wouldn't be assigned to both.  I had figured that both don't =
really, really, go to the Internet, like what NTT does with their IPv6 =
default route in Japan (which doesn't go to the Internet).

-d


>=20
> On the topic of the errata, I agree with Ted it is not an errata.  =
It's simply an
> implementation detail that the RFC doesn't specify, so it's up to the =
reader.
>=20
> -Dave


From dthaler@microsoft.com  Wed Feb 12 19:03:12 2014
Return-Path: <dthaler@microsoft.com>
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 0235D1A00D3 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 19:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.952
X-Spam-Level: 
X-Spam-Status: No, score=-95.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 h3zU2GmLQy1y for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 19:03:09 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 48A081A0028 for <pcp@ietf.org>; Wed, 12 Feb 2014 19:03:09 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 03:03:06 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 03:03:06 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Dan Wing <dwing@cisco.com>
Thread-Topic: =?gb2312?B?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1?= =?gb2312?B?c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNjg4?= =?gb2312?Q?7_(3887))?=
Thread-Index: Ac8oZzWfW4x5PAEUTrq8YeFFYwPPGQ==
Date: Thu, 13 Feb 2014 03:03:03 +0000
Message-ID: <a3bde67a7aaf4a6bba0234a76ef06809@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.135.4.20]
x-forefront-prvs: 0121F24F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51444003)(377454003)(51704005)(24454002)(13464003)(85306002)(74876001)(19580395003)(19580405001)(83322001)(65816001)(80022001)(81816001)(90146001)(81686001)(66066001)(92566001)(56816005)(63696002)(76176001)(53806001)(85852003)(87936001)(87266001)(83072002)(76482001)(95416001)(33646001)(86612001)(56776001)(54316002)(2656002)(224303002)(80976001)(95666001)(79102001)(74316001)(59766001)(77982001)(74706001)(54356001)(74502001)(93516002)(47736001)(93136001)(51856001)(74662001)(94946001)(74366001)(86362001)(50986001)(47976001)(47446002)(69226001)(49866001)(94316002)(31966008)(46102001)(76576001)(76786001)(76796001)(81342001)(81542001)(4396001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:FC30F1E5.ACF2D5A6.CF17D7B.CED05D51.203FC; MLV:sfv; InfoNoRecordsA:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, Zhangzhan <channy.zhang@huawei.com>, PCP Working Group <pcp@ietf.org>
Subject: [pcp] =?gb2312?b?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmlu?= =?gb2312?b?YWwgY29uY2x1c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRl?= =?gb2312?b?ZF0gUkZDNjg4NyAoMzg4Nykp?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 03:03:12 -0000

VXBkYXRpbmcgc3ViamVjdCBsaW5lLg0KDQpNb3JlIGJlbG93Lg0KDQo+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+IEZyb206IERhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29tXQ0K
PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDY6NTUgUE0NCj4gVG86IERhdmUg
VGhhbGVyDQo+IENjOiBaaGFuZ3poYW47IFRlZCBMZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0
dWFydCBDaGVzaGlyZTsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7
IFJlaW5hbGRvIFBlbm5vOw0KPiBwc2Vsa2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbg0KPiBT
dWJqZWN0OiBSZTogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNobmljYWwg
RXJyYXRhIFJlcG9ydGVkXQ0KPiBSRkM2ODg3ICgzODg3KQ0KPiANCj4gDQo+IE9uIEZlYiAxMiwg
MjAxNCwgYXQgNjozNSBQTSwgRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4gd3Jv
dGU6DQo+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBEYW4g
V2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAxMiwgMjAxNCA2OjIzIFBNDQo+ID4+IFRvOiBaaGFuZ3poYW4NCj4gPj4gQ2M6IFRlZCBM
ZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj4gPj4gbW9oYW1lZC5i
b3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5vOw0KPiA+PiBwc2Vs
a2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbjsgRGF2ZSBUaGFsZXINCj4gPj4gU3ViamVjdDog
UmU6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YQ0K
PiA+PiBSZXBvcnRlZF0NCj4gPj4gUkZDNjg4NyAoMzg4NykNCj4gPj4NCj4gPj4NCj4gPj4gT24g
RmViIDEyLCAyMDE0LCBhdCA1OjI5IFBNLCBaaGFuZ3poYW4gKENoYW5ueSkNCj4gPj4gPGNoYW5u
eS56aGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4+IE1heWJlIHlvdSBtaXN1bmRl
cnN0YW5kIG1lLg0KPiA+Pj4gVGhlcmUgaXMgb25seSBvbmUgcm91dGVyIGZvciBOQVQgYW5kIFBD
UC4NCj4gPj4+IElmIHRoZSBOQVQgZ2F0ZXdheSBkZXZpY2UgKHN1Y2ggYXMgQ0dOKSBpcyBQQ1Ag
U2VydmVyIGFuZCBoYXMgdHdvIG9yDQo+ID4+PiBtb3JlDQo+ID4+IG91dCBpbnRlcmZhY2VzIHRv
IGludGVybmV0IHdlcmUgZG9pbmcgZGlmZmVyZW50IG5hdCBjb252ZXJzaW9uIGluIHRoZSBJU1Au
DQo+ID4+PiBNYXliZSB1c2luZyBOQVQgYWRkcmVzcyBwb29sIEEsIEIsIEMuLi4gQW5kIHRoZSBy
b3V0aW5nIGVudHJpZXMgdG8NCj4gPj4+IGludGVybmV0DQo+ID4+IG9uIE5BVCBnYXRld2F5IGlz
IGVxdWl2YWxlbnQgZGVmYXVsdCByb3V0ZS4gSW4gdGhpcyBjYXNlLCB0aGUgb3V0DQo+ID4+IGlu
dGVyZmFjZSBpcyB1bmNlcnRhaW4sIGZ1bGx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgZXF1aXZh
bGVudCByb3V0ZQ0KPiBzZWxlY3Rpb24uDQo+ID4+PiBJZiBubyBQQ1AsIHNlcnZpY2UgdHJhZmZp
YyBjYW4gYmUgc2VsZWN0ZWQgb3V0IGludGVyZmFjZSBhY2NvcmRpbmcNCj4gPj4+IHRvIHRoZQ0K
PiA+PiBkZXN0aW5hdGlvbiBhZGRyZXNzIGFuZCBkbyBkaWZmZXJlbnQgTkFUIGNvbnZlcnNpb24u
DQo+ID4+PiBCdXQgdGhlIFBDUCBtZXNzYWdlIGlzIGluIGJlZm9yZSB0aGUgbm9ybWFsIHNlcnZp
Y2UgdHJhZmZpYy4gQW5kIFBDUA0KPiA+Pj4gTUFQDQo+ID4+IG1vZGUgbWVzc2FnZSBkb2VzIG5v
dCBpbmNsdWRlIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLCB0aGUgTkFUDQo+ID4+IGdhdGV3YXkg
ZGV2aWNlIGhvdyB0byBjaG9vc2UgdGhlIG91dCBpbnRlcmZhY2VzIGFuZCB0aGUgZGlmZmVyZW50
IE5BVA0KPiA+PiBhZGRyZXNzIHBvb2xzPw0KPiA+Pj4gQmFzZWQgb24gdGhlIGN1cnJlbnQgUENQ
IHByb3RvY29sLCBJIHRoaW5rIHRoYXQgY2FuJ3QgYmUgc29sdmVkLiBPcg0KPiA+Pj4gd2hhdCBJ
DQo+ID4+IHVuZGVyc3RhbmQgc29tZXRoaW5nIHdyb25nPw0KPiA+Pg0KPiA+PiBXaXRoIHN1Y2gg
YSBuZXR3b3JrIHRvcG9sb2d5LCB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudCBNQVAN
Cj4gPj4gb3Bjb2RlIGRvZXNuJ3Qgd29yay4NCj4gPg0KPiA+IEknbSBub3Qgc3VyZSBpdCdzIGZh
aXIgdG8gc2F5IGl0ICJkb2Vzbid0IHdvcmsiLiAgSXQganVzdCBtZWFucyB0aGF0DQo+ID4gdGhl
IE5BVCBwaWNrcyBvbmUgdXNpbmcgYW55IGltcGxlbWVudGF0aW9uLXNwZWNpZmljIG1lY2hhbmlz
bS4gIEluIHRoZQ0KPiA+IHN0YXRlZCBleGFtcGxlIGFib3ZlLCBib3RoIHBvc3NpYmxlIGFuc3dl
cnMgZ28gdG8gdGhlIEludGVybmV0LCBzbyB3aGF0DQo+IHdvdWxkbid0ICJ3b3JrIj8NCj4gDQo+
IEdvb2QgcG9pbnQuICBTYW1lIHdpdGggYSBUQ1AgU1lOIC0tIGl0IGdldHMgYXNzaWduZWQgdG8g
b25lIENHTiwgb3IgdGhlIG90aGVyDQo+IC0tIGl0IHdvdWxkbid0IGJlIGFzc2lnbmVkIHRvIGJv
dGguICBJIGhhZCBmaWd1cmVkIHRoYXQgYm90aCBkb24ndCByZWFsbHksIHJlYWxseSwNCj4gZ28g
dG8gdGhlIEludGVybmV0LCBsaWtlIHdoYXQgTlRUIGRvZXMgd2l0aCB0aGVpciBJUHY2IGRlZmF1
bHQgcm91dGUgaW4gSmFwYW4NCj4gKHdoaWNoIGRvZXNuJ3QgZ28gdG8gdGhlIEludGVybmV0KS4N
Cg0KWWVzIHRoYXQncyBhbiBhbHRlcm5hdGUgZXhhbXBsZSB0aGF0J3MgZ29vZCB0byBkaXNjdXNz
IChoZW5jZSB0aGUgY2hhbmdlIGluIA0Kc3ViamVjdCBsaW5lKSwgd2hpY2ggZHJhZnQtcGVubm8t
cGNwLXpvbmVzIGRvZXMuICBJbiBhIG11bHRpLWhvbWVkIE5BVCBjYXNlLA0KSSdkIGV4cGVjdCB0
aGUgaW1wbGVtZW50YXRpb24gdG8gcHJlZmVyIHRoZSBvbmUgdGhhdCBhY3R1YWxseSBnb2VzIHRv
IHRoZSBJbnRlcm5ldC4NClRoYXQgaXMsIHNpbmNlIE1BUCB0cmllcyB0byBvcGVuIGEgcG9ydCBm
b3IgImFueW9uZSIsIHRoZW4gd2hlbiBtdWx0aXBsZSBjaG9pY2VzDQpleGlzdCB0aGF0IHN1cHBv
cnQgZGlmZmVyZW50IHNldHMgb2YgcmVtb3RlIHBlZXJzLCBvbmUgc2hvdWxkIGJ5IGRlZmF1bHQg
cHJlZmVyDQp0aGUgb25lIHdpdGggdGhlIGxhcmdlciBzZXQsIGFzIGJlaW5nIGNsb3NlciB0byB0
aGUgZGVzaXJlIG9mICJhbnlvbmUiLg0KDQpBbmQgb2YgY291cnNlIHRoZXJlIGNvdWxkIGJlIGlt
cGxlbWVudGF0aW9uLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gdG8gb3ZlcnJpZGUNCnRoZSBkZWZh
dWx0LCBvciBwcm90b2NvbCBzdXBwb3J0IGEgbGEgZHJhZnQtcGVubm8tcGNwLXpvbmVzIHRvIHNw
ZWNpZnkgbm9uLWRlZmF1bHQNCmJlaGF2aW9yLg0KDQotRGF2ZQ0KDQo+IA0KPiAtZA0KPiANCj4g
DQo+ID4NCj4gPiBPbiB0aGUgdG9waWMgb2YgdGhlIGVycmF0YSwgSSBhZ3JlZSB3aXRoIFRlZCBp
dCBpcyBub3QgYW4gZXJyYXRhLg0KPiA+IEl0J3Mgc2ltcGx5IGFuIGltcGxlbWVudGF0aW9uIGRl
dGFpbCB0aGF0IHRoZSBSRkMgZG9lc24ndCBzcGVjaWZ5LCBzbyBpdCdzIHVwDQo+IHRvIHRoZSBy
ZWFkZXIuDQo+ID4NCj4gPiAtRGF2ZQ0KDQo=


From dthaler@microsoft.com  Wed Feb 12 19:55:09 2014
Return-Path: <dthaler@microsoft.com>
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 0F0A71A00DD for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 19:55:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.313
X-Spam-Level: 
X-Spam-Status: No, score=-96.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 pImbNwsk_jHf for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 19:55:06 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 285131A00D8 for <pcp@ietf.org>; Wed, 12 Feb 2014 19:55:06 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 03:55:03 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 03:55:03 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "Zhangzhan (Channy)" <channy.zhang@huawei.com>, Dan Wing <dwing@cisco.com>
Thread-Topic: =?gb2312?B?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1?= =?gb2312?B?c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNjg4?= =?gb2312?Q?7_(3887))?=
Thread-Index: Ac8oZzWfW4x5PAEUTrq8YeFFYwPPGQABkIyAAABsuMA=
Date: Thu, 13 Feb 2014 03:55:03 +0000
Message-ID: <3881c4e57bf54bea836ca214c98c528f@BY2PR03MB412.namprd03.prod.outlook.com>
References: <a3bde67a7aaf4a6bba0234a76ef06809@BY2PR03MB412.namprd03.prod.outlook.com> <1DA8CEC3F3E989439069663C05A865D334F97B5A@nkgeml508-mbx.china.huawei.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B5A@nkgeml508-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.135.4.20]
x-forefront-prvs: 0121F24F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(13464003)(24454002)(51444003)(199002)(189002)(377454003)(94946001)(51856001)(74662001)(74366001)(93516002)(74502001)(47736001)(93136001)(81542001)(4396001)(69226001)(47446002)(31966008)(49866001)(94316002)(50986001)(47976001)(86362001)(81342001)(76796001)(76576001)(46102001)(76786001)(53806001)(63696002)(56816005)(92566001)(85852003)(87936001)(83322001)(19580405001)(19580395003)(81816001)(65816001)(80022001)(85306002)(74876001)(81686001)(66066001)(90146001)(2656002)(80976001)(224303002)(77982001)(59766001)(54356001)(74706001)(95666001)(74316001)(79102001)(76482001)(33646001)(95416001)(87266001)(83072002)(54316002)(56776001)(86612001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:FC20F0E5.ACF2DBA2.3CF171BB.8ED8DD51.20513; InfoNoRecordsA:1; MX:1; LANG:en;
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmlu?= =?gb2312?b?YWwgY29uY2x1c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRl?= =?gb2312?b?ZF0gUkZDNjg4NyAoMzg4Nykp?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 03:55:09 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBaaGFuZ3poYW4gKENoYW5ueSkg
W21haWx0bzpjaGFubnkuemhhbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJy
dWFyeSAxMiwgMjAxNCA3OjQ0IFBNDQo+IFRvOiBEYXZlIFRoYWxlcjsgRGFuIFdpbmcNCj4gQ2M6
IFRlZCBMZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj4gbW9oYW1l
ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5vOw0KPiBwc2Vs
a2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbg0KPiBTdWJqZWN0OiC08Li0OiBNdWx0aS1ob21l
ZCBOQVQgKHdhczogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6DQo+IFtUZWNobmlj
YWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KSkNCj4gDQo+IFRvIERhdmU6DQo+IA0K
PiBCYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIGZvciB5b3VyIG1lYW5pbmc6DQo+IEl0J3MgbW9y
ZSBhcHByb3ByaWF0ZSB0byBzZWxlY3QgYW4gb3B0aW1hbCBvbmUgaW5zdGVhZCBvZiBkZWZhdWx0
IGJlaGF2aW9yIGluDQo+IHRoaXMgc2NlbmUuDQo+IA0KPiBCdXQgaW4gc3VjaCBhIG5ldHdvcmsg
dG9wb2xvZ3k6DQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAsLS0tLS0uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAsJyAgICAgICBgLg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIC4oIElTUDEgKQ0KPiAgICAgICAgICAgICAgICwtLS0tLS0tLiAg
ICAgICAgICAgICAgICAgICAgIC4tJyAgYC4gICAgICAgLCcNCj4gICAgICAgICAgICAsLScgIElT
UDAgICBgLS4gICAgICAgICAgICAgICAgLicgICAgICAgYC0tLS0tJw0KPiAgICAgICAgIEhvc3Qg
ICAgICAgICAgICAgIFwgQ0dOICAgICAgICAuLScgICAgICAgICAgLC0tLS0tLS0uDQo+ICAgICAr
LS0tLSstLS0tLSsgICAgICAgKy0tLSstLS0tLS0rICAuJyAgICAgICAgICAgLCcgICAgICAgICBg
Lg0KPiAgICAgfFBDUCBDbGllbnR8LS0tLS0tLXxQQ1AgU2VydmVyfC4nLS0tLS0tLS0tLS0tKCBJ
U1AyKQ0KPiAgICAgKy0tLS0rLS0tLS0rICAgICAgICstLS0rLS0tLS0tKyBgLS4gICAgICAgICAg
IGAuICAgICAgICAgLCcNCj4gICAgICAgICAgIFwgICAgICAgICAgICAgICAvICAgICAgICAgICAg
YC4gICAgICAgICAgIGAtLS0tLS0tJw0KPiAgICAgICAgICAgIGAtLiAgICAgICAgICwtJyAgICAg
ICAgICAgICAgIGAtLiAgICAgICwtLS0tLS4NCj4gICAgICAgICAgICAgICBgLS0tLS0tLScgICAg
ICAgICAgICAgICAgICAgICBgLiAgIC8gICAgICAgXA0KPiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgYC0oIElTUDMgKQ0KPiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAvDQo+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYC0tLS0tJw0KPiANCj4gSWYgdXNl
cnMgaW4gSVNQMSB3YW50IHRvIHZpc2l0IHRoZSBob3N0IGluIElTUDAsIHN1cHBvc2UgdGhlIGds
b2JhbCBuYXQgYWRkcmVzcw0KPiBvZiBob3N0IGlzIElQIHBvb2wgMS4NCj4gTm9ybWFsbHksIGlm
IG5vIFBDUCwgaWYgdXNlcnMgaW4gSVNQMiB3YW50IHRvIHZpc2l0IHRoZSBob3N0LCB0aGUgZ2xv
YmFsIG5hdA0KPiBhZGRyZXNzIG9mIGhvc3QgaXMgSVAgcG9vbCAyLg0KPiBJUCBwb29sIDEgYW5k
IElQIHBvb2wgMiBhcmUgY2VydGFpbmx5IGRpZmZlcmVudCBhZGRyZXNzIHNlZ21lbnRzLCBhbmQN
Cj4gYmVsb25naW5nIHRvIGRpZmZlcmVudCBJU1AuDQo+IA0KPiBOb3cgUENQIGlzIHVzZWQgdG8g
bWFwcGluZyB0aGUgZ2xvYmFsIG5hdCBhZGRyZXNzLCBzdXBwb3NlIENHTiBzZWxlY3QgSVANCj4g
cG9vbCAxIGFzIHRoZSBvcHRpbWFsIG9uZS4gSWYgdXNlcnMgaW4gSVNQMiB3YW50IHRvIHZpc2l0
IHRoZSBob3N0LCBtdXN0IHZpc2l0IHRoZQ0KPiBJUCBwb29sIDEgdGhyb3VnaCBJU1AxJ3MgbmV0
d29yay4gQnV0IHVzdWFsbHkgdGhpcyBpcyBub3QgYWNjZXB0YWJsZSB0byBJUFMyLg0KDQpZZXMg
dGhhdCBkaWFncmFtIGlzIGEgZGlmZmVyZW50IHNjZW5hcmlvIHRoYW4gdGhlIG9uZSB5b3Ugb3Jp
Z2luYWxseSBtZW50aW9uZWQsDQp3aGVyZSBhbGwgY29ubmVjdCB0byB0aGUgSW50ZXJuZXQuICAo
VGhlcmUgaXMgbm8gSW50ZXJuZXQgaW4geW91ciBwaWN0dXJlIGhlcmUuKQ0KDQpUaGlzIGlzIHRo
ZSBzY2VuYXJpbyBEYW4gd2FzIHJlZmVycmluZyB0by4NCg0KLURhdmUNCiANCj4gLS0tLS3Tyrz+
1K28/i0tLS0tDQo+ILeivP7IyzogRGF2ZSBUaGFsZXIgW21haWx0bzpkdGhhbGVyQG1pY3Jvc29m
dC5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOoy1MIxM8jVIDExOjAzDQo+IMrVvP7IyzogRGFuIFdp
bmcNCj4gs63LzTogWmhhbmd6aGFuIChDaGFubnkpOyBUZWQgTGVtb247IFBDUCBXb3JraW5nIEdy
b3VwOyBTdHVhcnQNCj4gQ2hlc2hpcmU7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gQm91
Y2FkYWlyOyBSZWluYWxkbyBQZW5ubzsNCj4gcHNlbGtpcmtAaXNjLm9yZzsgQnJpYW4gSGFiZXJt
YW4NCj4g1vfM4jogTXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1
c2lvbj+08Li0OiBbVGVjaG5pY2FsDQo+IEVycmF0YSBSZXBvcnRlZF0gUkZDNjg4NyAoMzg4Nykp
DQo+IA0KPiBVcGRhdGluZyBzdWJqZWN0IGxpbmUuDQo+IA0KPiBNb3JlIGJlbG93Lg0KPiANCj4g
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhbiBXaW5nIFttYWlsdG86
ZHdpbmdAY2lzY28uY29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQg
Njo1NSBQTQ0KPiA+IFRvOiBEYXZlIFRoYWxlcg0KPiA+IENjOiBaaGFuZ3poYW47IFRlZCBMZW1v
bjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj4gPiBtb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tIEJvdWNhZGFpcjsgUmVpbmFsZG8gUGVubm87DQo+ID4gcHNlbGtpcmtA
aXNjLm9yZzsgQnJpYW4gSGFiZXJtYW4NCj4gPiBTdWJqZWN0OiBSZTogV2hhdCdzIHRoZSBmaW5h
bCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNobmljYWwgRXJyYXRhDQo+ID4gUmVwb3J0ZWRdDQo+ID4g
UkZDNjg4NyAoMzg4NykNCj4gPg0KPiA+DQo+ID4gT24gRmViIDEyLCAyMDE0LCBhdCA2OjM1IFBN
LCBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gPg0KPiA+ID4+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogRGFuIFdpbmcgW21haWx0
bzpkd2luZ0BjaXNjby5jb21dDQo+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwg
MjAxNCA2OjIzIFBNDQo+ID4gPj4gVG86IFpoYW5nemhhbg0KPiA+ID4+IENjOiBUZWQgTGVtb247
IFBDUCBXb3JraW5nIEdyb3VwOyBTdHVhcnQgQ2hlc2hpcmU7DQo+ID4gPj4gbW9oYW1lZC5ib3Vj
YWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5vOw0KPiA+ID4+IHBzZWxr
aXJrQGlzYy5vcmc7IEJyaWFuIEhhYmVybWFuOyBEYXZlIFRoYWxlcg0KPiA+ID4+IFN1YmplY3Q6
IFJlOiBXaGF0J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tPC4tDogW1RlY2huaWNhbCBFcnJhdGEN
Cj4gPiA+PiBSZXBvcnRlZF0NCj4gPiA+PiBSRkM2ODg3ICgzODg3KQ0KPiA+ID4+DQo+ID4gPj4N
Cj4gPiA+PiBPbiBGZWIgMTIsIDIwMTQsIGF0IDU6MjkgUE0sIFpoYW5nemhhbiAoQ2hhbm55KQ0K
PiA+ID4+IDxjaGFubnkuemhhbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPj4NCj4gPiA+Pj4g
TWF5YmUgeW91IG1pc3VuZGVyc3RhbmQgbWUuDQo+ID4gPj4+IFRoZXJlIGlzIG9ubHkgb25lIHJv
dXRlciBmb3IgTkFUIGFuZCBQQ1AuDQo+ID4gPj4+IElmIHRoZSBOQVQgZ2F0ZXdheSBkZXZpY2Ug
KHN1Y2ggYXMgQ0dOKSBpcyBQQ1AgU2VydmVyIGFuZCBoYXMgdHdvDQo+ID4gPj4+IG9yIG1vcmUN
Cj4gPiA+PiBvdXQgaW50ZXJmYWNlcyB0byBpbnRlcm5ldCB3ZXJlIGRvaW5nIGRpZmZlcmVudCBu
YXQgY29udmVyc2lvbiBpbiB0aGUNCj4gSVNQLg0KPiA+ID4+PiBNYXliZSB1c2luZyBOQVQgYWRk
cmVzcyBwb29sIEEsIEIsIEMuLi4gQW5kIHRoZSByb3V0aW5nIGVudHJpZXMgdG8NCj4gPiA+Pj4g
aW50ZXJuZXQNCj4gPiA+PiBvbiBOQVQgZ2F0ZXdheSBpcyBlcXVpdmFsZW50IGRlZmF1bHQgcm91
dGUuIEluIHRoaXMgY2FzZSwgdGhlIG91dA0KPiA+ID4+IGludGVyZmFjZSBpcyB1bmNlcnRhaW4s
IGZ1bGx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgZXF1aXZhbGVudA0KPiA+ID4+IHJvdXRlDQo+
ID4gc2VsZWN0aW9uLg0KPiA+ID4+PiBJZiBubyBQQ1AsIHNlcnZpY2UgdHJhZmZpYyBjYW4gYmUg
c2VsZWN0ZWQgb3V0IGludGVyZmFjZSBhY2NvcmRpbmcNCj4gPiA+Pj4gdG8gdGhlDQo+ID4gPj4g
ZGVzdGluYXRpb24gYWRkcmVzcyBhbmQgZG8gZGlmZmVyZW50IE5BVCBjb252ZXJzaW9uLg0KPiA+
ID4+PiBCdXQgdGhlIFBDUCBtZXNzYWdlIGlzIGluIGJlZm9yZSB0aGUgbm9ybWFsIHNlcnZpY2Ug
dHJhZmZpYy4gQW5kDQo+ID4gPj4+IFBDUCBNQVANCj4gPiA+PiBtb2RlIG1lc3NhZ2UgZG9lcyBu
b3QgaW5jbHVkZSB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywgdGhlIE5BVA0KPiA+ID4+IGdhdGV3
YXkgZGV2aWNlIGhvdyB0byBjaG9vc2UgdGhlIG91dCBpbnRlcmZhY2VzIGFuZCB0aGUgZGlmZmVy
ZW50DQo+ID4gPj4gTkFUIGFkZHJlc3MgcG9vbHM/DQo+ID4gPj4+IEJhc2VkIG9uIHRoZSBjdXJy
ZW50IFBDUCBwcm90b2NvbCwgSSB0aGluayB0aGF0IGNhbid0IGJlIHNvbHZlZC4NCj4gPiA+Pj4g
T3Igd2hhdCBJDQo+ID4gPj4gdW5kZXJzdGFuZCBzb21ldGhpbmcgd3Jvbmc/DQo+ID4gPj4NCj4g
PiA+PiBXaXRoIHN1Y2ggYSBuZXR3b3JrIHRvcG9sb2d5LCB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0
aGUgY3VycmVudCBNQVANCj4gPiA+PiBvcGNvZGUgZG9lc24ndCB3b3JrLg0KPiA+ID4NCj4gPiA+
IEknbSBub3Qgc3VyZSBpdCdzIGZhaXIgdG8gc2F5IGl0ICJkb2Vzbid0IHdvcmsiLiAgSXQganVz
dCBtZWFucyB0aGF0DQo+ID4gPiB0aGUgTkFUIHBpY2tzIG9uZSB1c2luZyBhbnkgaW1wbGVtZW50
YXRpb24tc3BlY2lmaWMgbWVjaGFuaXNtLiAgSW4NCj4gPiA+IHRoZSBzdGF0ZWQgZXhhbXBsZSBh
Ym92ZSwgYm90aCBwb3NzaWJsZSBhbnN3ZXJzIGdvIHRvIHRoZSBJbnRlcm5ldCwNCj4gPiA+IHNv
IHdoYXQNCj4gPiB3b3VsZG4ndCAid29yayI/DQo+ID4NCj4gPiBHb29kIHBvaW50LiAgU2FtZSB3
aXRoIGEgVENQIFNZTiAtLSBpdCBnZXRzIGFzc2lnbmVkIHRvIG9uZSBDR04sIG9yDQo+ID4gdGhl
IG90aGVyDQo+ID4gLS0gaXQgd291bGRuJ3QgYmUgYXNzaWduZWQgdG8gYm90aC4gIEkgaGFkIGZp
Z3VyZWQgdGhhdCBib3RoIGRvbid0DQo+ID4gcmVhbGx5LCByZWFsbHksIGdvIHRvIHRoZSBJbnRl
cm5ldCwgbGlrZSB3aGF0IE5UVCBkb2VzIHdpdGggdGhlaXIgSVB2Ng0KPiA+IGRlZmF1bHQgcm91
dGUgaW4gSmFwYW4gKHdoaWNoIGRvZXNuJ3QgZ28gdG8gdGhlIEludGVybmV0KS4NCj4gDQo+IFll
cyB0aGF0J3MgYW4gYWx0ZXJuYXRlIGV4YW1wbGUgdGhhdCdzIGdvb2QgdG8gZGlzY3VzcyAoaGVu
Y2UgdGhlIGNoYW5nZSBpbg0KPiBzdWJqZWN0IGxpbmUpLCB3aGljaCBkcmFmdC1wZW5uby1wY3At
em9uZXMgZG9lcy4gIEluIGEgbXVsdGktaG9tZWQgTkFUDQo+IGNhc2UsIEknZCBleHBlY3QgdGhl
IGltcGxlbWVudGF0aW9uIHRvIHByZWZlciB0aGUgb25lIHRoYXQgYWN0dWFsbHkgZ29lcyB0bw0K
PiB0aGUgSW50ZXJuZXQuDQo+IFRoYXQgaXMsIHNpbmNlIE1BUCB0cmllcyB0byBvcGVuIGEgcG9y
dCBmb3IgImFueW9uZSIsIHRoZW4gd2hlbiBtdWx0aXBsZQ0KPiBjaG9pY2VzIGV4aXN0IHRoYXQg
c3VwcG9ydCBkaWZmZXJlbnQgc2V0cyBvZiByZW1vdGUgcGVlcnMsIG9uZSBzaG91bGQgYnkNCj4g
ZGVmYXVsdCBwcmVmZXIgdGhlIG9uZSB3aXRoIHRoZSBsYXJnZXIgc2V0LCBhcyBiZWluZyBjbG9z
ZXIgdG8gdGhlIGRlc2lyZSBvZg0KPiAiYW55b25lIi4NCj4gDQo+IEFuZCBvZiBjb3Vyc2UgdGhl
cmUgY291bGQgYmUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgY29uZmlndXJhdGlvbiB0bw0KPiBv
dmVycmlkZSB0aGUgZGVmYXVsdCwgb3IgcHJvdG9jb2wgc3VwcG9ydCBhIGxhIGRyYWZ0LXBlbm5v
LXBjcC16b25lcyB0bw0KPiBzcGVjaWZ5IG5vbi1kZWZhdWx0IGJlaGF2aW9yLg0KPiANCj4gLURh
dmUNCj4gDQo+ID4NCj4gPiAtZA0KPiA+DQo+ID4NCj4gPiA+DQo+ID4gPiBPbiB0aGUgdG9waWMg
b2YgdGhlIGVycmF0YSwgSSBhZ3JlZSB3aXRoIFRlZCBpdCBpcyBub3QgYW4gZXJyYXRhLg0KPiA+
ID4gSXQncyBzaW1wbHkgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIHRoYXQgdGhlIFJGQyBkb2Vz
bid0IHNwZWNpZnksDQo+ID4gPiBzbyBpdCdzIHVwDQo+ID4gdG8gdGhlIHJlYWRlci4NCj4gPiA+
DQo+ID4gPiAtRGF2ZQ0KDQo=


From dwing@cisco.com  Wed Feb 12 22:22:20 2014
Return-Path: <dwing@cisco.com>
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 DB72F1A0111 for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 22:22:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.76
X-Spam-Level: 
X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 Eej9_pc0NasU for <pcp@ietfa.amsl.com>; Wed, 12 Feb 2014 22:22:18 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 390281A00F5 for <pcp@ietf.org>; Wed, 12 Feb 2014 22:22:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4869; q=dns/txt; s=iport; t=1392272537; x=1393482137; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lX6iNO4R4Aw/kGvZgZgmQmwbS7HH48A0X50EoPw75Bw=; b=PJ1fjJjDBS9Ix0JXS13PcY/tWJjn5ZaVIutmwzMaGad3+WhFagkPyyew zmNYFR5wKr5tbZuGDLl4C0SLNi17uPez0TIYrCTGdcL2OzERjltpKmiB1 8TUNXQ/aLj9NyxWJX5qnQHQSJZXSutOV+HQGjAdjcfwKVu+VrCCX7Yrol w=;
X-IronPort-AV: E=Sophos;i="4.95,837,1384300800"; d="scan'208";a="303830458"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 13 Feb 2014 06:22:17 +0000
Received: from [10.85.165.74] ([10.85.165.74]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1D6MEFf009564; Thu, 13 Feb 2014 06:22:15 GMT
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com>
Date: Wed, 12 Feb 2014 22:22:14 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com>
To: "Zhangzhan (Channy)" <channy.zhang@huawei.com>
X-Mailer: Apple Mail (2.1510)
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 06:22:21 -0000

On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:

> This draft is proposed in 2011, but has expired, no refresh or =
replacement?

That's right.

> The PEER mode include remote address maybe can be selected correct =
zone.
>=20
> The MAP mode only through the filter option to identify, if contains =
more than one filter in one PCP message, and these filters maybe belong =
to different zones.=20
> And an address pool may contain a number of different segments address =
blocks, the filter maybe not be able to identify zones.
>=20
> The ZONEID option should be a good solution, but the client to get the =
zones information is a very difficult thing, because zones in CGN is =
hidden for a client and no business relations. Zones maybe be changed, =
how to keep the synchronization is a problem.

That problem needs to be solved anyway, no matter if it's called ZONEID =
or called something else.

-d


>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 10:23
> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical =
Errata Reported] RFC6887 (3887)
>=20
>=20
> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) =
<channy.zhang@huawei.com> wrote:
>=20
>> Maybe you misunderstand me.
>> There is only one router for NAT and PCP.
>> If the NAT gateway device (such as CGN) is PCP Server and has two or =
more out interfaces to internet were doing different nat conversion in =
the ISP.=20
>> Maybe using NAT address pool A, B, C... And the routing entries to =
internet on NAT gateway is equivalent default route. In this case, the =
out interface is uncertain, fully in accordance with the equivalent =
route selection.
>> If no PCP, service traffic can be selected out interface according to =
the destination address and do different NAT conversion.
>> But the PCP message is in before the normal service traffic. And PCP =
MAP mode message does not include the destination address, the NAT =
gateway device how to choose the out interfaces and the different NAT =
address pools?=20
>> Based on the current PCP protocol, I think that can't be solved. Or =
what I understand something wrong?
>=20
> With such a network topology, you are correct that the current MAP =
opcode doesn't work.  We need something different.  Would =
http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution?
>=20
> -d
>=20
>=20
>>=20
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02
>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: =
[Technical Errata Reported] RFC6887 (3887)
>>=20
>>=20
>> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:
>>=20
>>> "Indeed, it has been discussed."
>>>=20
>>> What's the final conclusion to the discussion?=20
>>>=20
>>> How PCP applies in the Dual-Egress NAT scene?
>>>=20
>>> Could you please share it?=20
>>=20
>> I removed the RFC Editor from the thread.
>>=20
>> PCP client needs to communicate to both of the NATs independently.  =
Which the same host (the PCP client) needs to know how to do anyway to =
send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to =
different networks, the host must have routing entries.  The PCP client =
can use those same routing entries to know there are two routers on the =
network, and send PCP messages to those two routers separately.
>>=20
>> -d
>>=20
>>=20
>>>=20
>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13
>>> =CA=D5=BC=FE=C8=CB: Dan Wing
>>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart =
Cheshire; mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group
>>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887)
>>>=20
>>> On Feb 12, 2014, at 10:15 AM, Dan Wing <dwing@cisco.com> wrote:
>>>> It seems appropriate to discuss this question on the PCP mailing =
list, pcp@ietf.org.
>>>=20
>>> Indeed, it has been discussed.   This isn't really an appropriate =
topic for an erratum.
>>>=20
>>=20
>=20


From Ted.Lemon@nominum.com  Thu Feb 13 05:59:38 2014
Return-Path: <Ted.Lemon@nominum.com>
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 6346C1A0105 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 05:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.502
X-Spam-Level: ***
X-Spam-Status: No, score=3.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548] 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 SBi8WgicjJwE for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 05:59:36 -0800 (PST)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D78011A0008 for <pcp@ietf.org>; Thu, 13 Feb 2014 05:59:36 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0C7201B82A4 for <pcp@ietf.org>; Thu, 13 Feb 2014 05:59:36 -0800 (PST)
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 EE17B190052; Thu, 13 Feb 2014 05:59:35 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 05:59:35 -0800
Content-Type: text/plain; charset="gb18030"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com>
Date: Thu, 13 Feb 2014 08:59:30 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <BCB60015-852E-4B41-B55A-CAF8CFC11142@nominum.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.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>
To: Dan Wing <dwing@cisco.com>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, "Zhangzhan \(Channy\)" <channy.zhang@huawei.com>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb18030?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6?= =?gb18030?q?_=5BTechnical_Errata_Reported=5D_RFC6887_=283887=29?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 13:59:38 -0000

On Feb 13, 2014, at 1:22 AM, Dan Wing <dwing@cisco.com> wrote:
>> This draft is proposed in 2011, but has expired, no refresh or =
replacement?
> That's right.

Yes, this is why it's so important to discuss it in the working =
group=A1=AAso that progress can resume!   :)


From repenno@cisco.com  Thu Feb 13 06:08:09 2014
Return-Path: <repenno@cisco.com>
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 CCCA71A0186 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 06:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.549
X-Spam-Level: 
X-Spam-Status: No, score=-11.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 e7fmf_geNOt4 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 06:08:08 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A18BA1A0292 for <pcp@ietf.org>; Thu, 13 Feb 2014 06:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1114; q=dns/txt; s=iport; t=1392300472; x=1393510072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tNnjuomByn+BgMK1mXfEK6udP6p1wlPDnJLoCJsQQqA=; b=d0yTVPm+iYkq+eRO6Z9oRyzipYdZm11rXSEk0axjYocfykdrvAugeHuF 3DTDwgel+1NA1WrNe/04V1GCNRVQgiqtHurl5jNJ0Fu+IY3mH3KPNLeC/ Z3RctWpJqmAMMBhynZvs8gcjdezUWOLPk+3HaWadokkMLRoLkdkhFJdVq Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMFAGDQ/FKtJV2c/2dsb2JhbABZgwaBD4MAvEwYfhZ0giUBAQEENEUQAgEIEQQBAQEEBiICAjAaAwgCBAENBQiHfYl/m3MOoiUXgSCNKDEHgmY+gRQBA6pPgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="303790397"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2014 14:07:51 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DE7pxt028103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:07:51 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:07:50 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: Ted Lemon <ted.lemon@nominum.com>, "Dan Wing (dwing)" <dwing@cisco.com>
Thread-Topic: =?big5?B?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtUZWNobmljYWwgRXJy?= =?big5?Q?ata_Reported]_RFC6887_(3887)?=
Thread-Index: AQHPJ6LPzMjxlXlS/USHNBsyymSwU5qxNTOAgAAQJoCAARNEUIAAaxgAgAAHuwCAAA7RAIAAQNAAgAACHQCAAH/CAP//nVfc
Date: Thu, 13 Feb 2014 14:07:50 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B7A5F2E@xmb-rcd-x04.cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.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>, <BCB60015-852E-4B41-B55A-CAF8CFC11142@nominum.com>
In-Reply-To: <BCB60015-852E-4B41-B55A-CAF8CFC11142@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.113.31]
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, "Zhangzhan \(Channy\)" <channy.zhang@huawei.com>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?big5?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtU?= =?big5?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 14:08:10 -0000

SSBiZWxpZXZlIGF0IHRoYXQgdGltZSB3ZSBoYWQgYmlnZ2VyIGZpc2ggdG8gZnJ5IHN1Y2ggYXMg
Y29tcGxldGluZyB0aGUgbWFpbiBzcGVjLiBJZiB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgdGhp
cyB3b3JrIGNvdWxkIGJlIHJlc3VtZWQuIAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpGcm9tOiBUZWQgTGVtb24gW3RlZC5sZW1vbkBub21pbnVtLmNvbV0KU2VudDog
VGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDU6NTkgQU0KVG86IERhbiBXaW5nIChkd2luZykK
Q2M6IFpoYW5nemhhbiAoQ2hhbm55KTsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGly
ZTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5v
IChyZXBlbm5vKTsgcHNlbGtpcmtAaXNjLm9yZzsgQnJpYW4gSGFiZXJtYW47IERhdmUgVGhhbGVy
ClN1YmplY3Q6IFJlOiBXaGF0J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tarOYDogW1RlY2huaWNh
bCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzY4ODcgKDM4ODcpCgpPbiBGZWIgMTMsIDIwMTQsIGF0IDE6
MjIgQU0sIERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb20+IHdyb3RlOgo+PiBUaGlzIGRyYWZ0IGlz
IHByb3Bvc2VkIGluIDIwMTEsIGJ1dCBoYXMgZXhwaXJlZCwgbm8gcmVmcmVzaCBvciByZXBsYWNl
bWVudD8KPiBUaGF0J3MgcmlnaHQuCgpZZXMsIHRoaXMgaXMgd2h5IGl0J3Mgc28gaW1wb3J0YW50
IHRvIGRpc2N1c3MgaXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXChWHNvIHRoYXQgcHJvZ3Jlc3MgY2Fu
IHJlc3VtZSEgICA6KQoK


From repenno@cisco.com  Thu Feb 13 09:14:19 2014
Return-Path: <repenno@cisco.com>
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 6E3F21A0370 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 09:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.549
X-Spam-Level: 
X-Spam-Status: No, score=-11.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 8O1uGM8h9o9D for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 09:14:17 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD41A036B for <pcp@ietf.org>; Thu, 13 Feb 2014 09:14:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1610; q=dns/txt; s=iport; t=1392311656; x=1393521256; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AmVDLSMO3XTuzSqnin/+ETEj2AR5zeWuSs7f/DH8SnI=; b=KdmaxewIlyvHIf2lfuq95UiYd4GUuUuh2aGwbN/r+32GJZf75s0VEMHN adlK1DqnpzgHooCjPBZQEPm4jPROljLc2uDInRz33K2Q2w0pVVoxC4Hmt U27T6pG2akyR3tADWq60P3s76+aK4Q44LoaffjHIxZm6pwEZfCHAbSNZK 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoMFACv9/FKtJXG8/2dsb2JhbABZgwaBD4MAvEwYgQAWdIIlAQEBBDRFEgEIEQQBAQEEKAQwGgMIAgQOBRmHbIlmm3MOoiEXgSCNJjMHgmaBUgEDmCySI4Mtgio
X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="303864357"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 13 Feb 2014 17:14:16 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DHEGxY032614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 17:14:16 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 11:14:16 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Zhangzhan (Channy)" <channy.zhang@huawei.com>
Thread-Topic: =?big5?B?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtUZWNobmljYWwgRXJy?= =?big5?Q?ata_Reported]_RFC6887_(3887)?=
Thread-Index: AQHPJ6LPzMjxlXlS/USHNBsyymSwU5qxNTOAgAAQJoCAARNEUIAAaxgAgAAHuwCAAA7RAIAAQNAAgAACHQCAAH/CAP//nVfcgAAS9QA=
Date: Thu, 13 Feb 2014 17:14:15 +0000
Message-ID: <CF223CD0.908A%repenno@cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B7A5F2E@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.102.89]
Content-Type: text/plain; charset="big5"
Content-ID: <F1B705532B68B64890B53E843A912A44@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?big5?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtU?= =?big5?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 17:14:19 -0000

Wmhhbmd6aGFuLA0KDQpXb3VsZCB5b3UgY2FyZSB0byBwcmVzZW50IHlvdXIgdXNlLWNhc2UgYW5k
IHByb2JsZW0gc3RhdGVtZW50IGF0IHRoZSBuZXh0DQpJRVRGPyANCg0KQXMgSSBzYWlkLCBJIHBy
ZXNlbnRlZCB0aGlzIHByb3Bvc2FsIGJlZm9yZSBidXQgbWF5YmUgaXQgd2FzIHRvbyBlYXJseSBv
bg0KV0cgbGlmZSBmb3Igb3RoZXJzIHRvIGRlZGljYXRlZCB0aW1lLg0KDQpUaGFua3MsDQoNClJl
aW5hbGRvDQoNCk9uIDIvMTMvMTQsIDY6MDcgQU0sICJSZWluYWxkbyBQZW5ubyAocmVwZW5ubyki
IDxyZXBlbm5vQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5JIGJlbGlldmUgYXQgdGhhdCB0aW1lIHdl
IGhhZCBiaWdnZXIgZmlzaCB0byBmcnkgc3VjaCBhcyBjb21wbGV0aW5nIHRoZQ0KPm1haW4gc3Bl
Yy4gSWYgdGhlcmUgaXMgZW5vdWdoIGludGVyZXN0IHRoaXMgd29yayBjb3VsZCBiZSByZXN1bWVk
Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBU
ZWQgTGVtb24gW3RlZC5sZW1vbkBub21pbnVtLmNvbV0NCj5TZW50OiBUaHVyc2RheSwgRmVicnVh
cnkgMTMsIDIwMTQgNTo1OSBBTQ0KPlRvOiBEYW4gV2luZyAoZHdpbmcpDQo+Q2M6IFpoYW5nemhh
biAoQ2hhbm55KTsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj5tb2hhbWVk
LmJvdWNhZGFpckBvcmFuZ2UuY29tIEJvdWNhZGFpcjsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8p
Ow0KPnBzZWxraXJrQGlzYy5vcmc7IEJyaWFuIEhhYmVybWFuOyBEYXZlIFRoYWxlcg0KPlN1Ympl
Y3Q6IFJlOiBXaGF0J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tarOYDogW1RlY2huaWNhbCBFcnJh
dGEgUmVwb3J0ZWRdDQo+UkZDNjg4NyAoMzg4NykNCj4NCj5PbiBGZWIgMTMsIDIwMTQsIGF0IDE6
MjIgQU0sIERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb20+IHdyb3RlOg0KPj4+IFRoaXMgZHJhZnQg
aXMgcHJvcG9zZWQgaW4gMjAxMSwgYnV0IGhhcyBleHBpcmVkLCBubyByZWZyZXNoIG9yDQo+Pj5y
ZXBsYWNlbWVudD8NCj4+IFRoYXQncyByaWdodC4NCj4NCj5ZZXMsIHRoaXMgaXMgd2h5IGl0J3Mg
c28gaW1wb3J0YW50IHRvIGRpc2N1c3MgaXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXChWHNvDQo+dGhh
dCBwcm9ncmVzcyBjYW4gcmVzdW1lISAgIDopDQo+DQoNCg==


From nobody Thu Feb 13 09:45:33 2014
Return-Path: <dwing@cisco.com>
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 B7FE81A036E for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 09:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.76
X-Spam-Level: 
X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 093mnyWz2sui for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 09:45:27 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3681A02B9 for <pcp@ietf.org>; Thu, 13 Feb 2014 09:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8061; q=dns/txt; s=iport; t=1392313526; x=1393523126; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1zIYyGF9+vaZtBV3gyG1I3I8OpJxiUjQmnvzJ8ui/E0=; b=OTQ9MiC+kgVfhfkbQfJxCbdlqt4C72p3645cqG7LzsZrMXsu3zdEECmP Am/p+TRJHw07W4Vf+aM5QkjvG1zNqIUL7UF5GwBwmmWUpEQZzLVIl1SMe uQ8BZDm7SD3s1nwio1ey/7YRg4fwfd8jI9M4g0mkL0lXFcBpNwLRVmiSG s=;
X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="102390557"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 17:45:26 +0000
Received: from [10.85.165.74] ([10.85.165.74]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DHjBhN025817; Thu, 13 Feb 2014 17:45:14 GMT
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B88@nkgeml508-mbx.china.huawei.com>
Date: Thu, 13 Feb 2014 09:45:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <80955F6E-204D-4B6B-BE45-9C1A0F0DD072@cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.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>
To: Zhangzhan (Channy) <channy.zhang@huawei.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/sqUU-WEm2Jbf_lJmJrEdfsXykME
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?VGhpcyBzb2x1dGlvbiBpcyBmZWFzaWJsZT+08Li0OiBXaGF0?= =?gb2312?b?J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tPC4tDogW1RlY2huaWNhbCBFcnJh?= =?gb2312?b?dGEgUmVwb3J0ZWRdIFJGQzY4ODcgKDM4ODcp?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 17:45:31 -0000

On Feb 12, 2014, at 11:06 PM, Zhangzhan (Channy) =
<channy.zhang@huawei.com> wrote:

> This solution is feasible?
>=20
> We define a new result code, such as MULTIPLE_ZONES, and define a new =
Opcode, such as GET_ZONE.
> If the PCP server have more than one ZONE, reply a MULTIPLE_ZONES =
result code message when receiving any PCP requests.
> The client receives the result code, must send a GET_ZONE Opcode =
request message.
> The PCP server must replay a message which contains the list of all =
ZONE ID information.
> Then the client get the ZONE ID information, sends request messages =
(PEER or MAP) which include ZONEID option. If there are N zones, client =
must send N request messages.
> Finally The PCP server can be selected the different address pools =
according to the ZONEID information and create multiple different =
mapping tables.
> If the zone information is changed in PCP server, mapping tables must =
be deleted and create new mapping table when receiving renewing messages =
from clients.

Seems like a good first cut, but I don't like breaking backwards =
compatibility with existing PCP clients.  Backwards compatibility is =
broken in that second step (the step starting with "If the PCP server =
have more than one ZONE ...").  Better would be if the PCP client tries =
to do zone discovery when it sends its first MAP (such as an PCP =
option), as that doesn't change state machine much.   Here is what I am =
thinking (view with fixed-width font):

PCP Client    	      	           PCP	Server=09
----------    	      	           ----------
    |                                   |
    |---MAP w/LEARN_ZONES option------->|
    |                                   |
    |                   (one mapping is created)
    |                                   |
    |<--mapped to zone=3D1, total zones=3D3-|
    |                                   |
    |--GET_ZONE 1 details-------------->|
    |<--zone 1 details------------------|
    |                                   |
    |--GET_ZONE 2 details-------------->|
    |<--zone 2 details------------------|
    |                                   |
    |--GET_ZONE 3 details-------------->|
    |<--zone 3 details------------------|
    |                                   |
    |--MAP, ZONE=3D2--------------------->|
    |<-ok-------------------------------|
    |                                   |
    |--MAP, ZONE=3D3--------------------->|
    |<-ok-------------------------------|
    |                                   |


-d


>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 14:22
> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical =
Errata Reported] RFC6887 (3887)
>=20
>=20
> On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:
>=20
>> This draft is proposed in 2011, but has expired, no refresh or =
replacement?
>=20
> That's right.
>=20
>> The PEER mode include remote address maybe can be selected correct =
zone.
>>=20
>> The MAP mode only through the filter option to identify, if contains =
more than one filter in one PCP message, and these filters maybe belong =
to different zones.=20
>> And an address pool may contain a number of different segments =
address blocks, the filter maybe not be able to identify zones.
>>=20
>> The ZONEID option should be a good solution, but the client to get =
the zones information is a very difficult thing, because zones in CGN is =
hidden for a client and no business relations. Zones maybe be changed, =
how to keep the synchronization is a problem.
>=20
> That problem needs to be solved anyway, no matter if it's called =
ZONEID or called something else.
>=20
> -d
>=20
>=20
>>=20
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 10:23
>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: =
[Technical Errata Reported] RFC6887 (3887)
>>=20
>>=20
>> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) =
<channy.zhang@huawei.com> wrote:
>>=20
>>> Maybe you misunderstand me.
>>> There is only one router for NAT and PCP.
>>> If the NAT gateway device (such as CGN) is PCP Server and has two or =
more out interfaces to internet were doing different nat conversion in =
the ISP.=20
>>> Maybe using NAT address pool A, B, C... And the routing entries to =
internet on NAT gateway is equivalent default route. In this case, the =
out interface is uncertain, fully in accordance with the equivalent =
route selection.
>>> If no PCP, service traffic can be selected out interface according =
to the destination address and do different NAT conversion.
>>> But the PCP message is in before the normal service traffic. And PCP =
MAP mode message does not include the destination address, the NAT =
gateway device how to choose the out interfaces and the different NAT =
address pools?=20
>>> Based on the current PCP protocol, I think that can't be solved. Or =
what I understand something wrong?
>>=20
>> With such a network topology, you are correct that the current MAP =
opcode doesn't work.  We need something different.  Would =
http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution?
>>=20
>> -d
>>=20
>>=20
>>>=20
>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02
>>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
>>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
>>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: =
[Technical Errata Reported] RFC6887 (3887)
>>>=20
>>>=20
>>> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:
>>>=20
>>>> "Indeed, it has been discussed."
>>>>=20
>>>> What's the final conclusion to the discussion?=20
>>>>=20
>>>> How PCP applies in the Dual-Egress NAT scene?
>>>>=20
>>>> Could you please share it?=20
>>>=20
>>> I removed the RFC Editor from the thread.
>>>=20
>>> PCP client needs to communicate to both of the NATs independently.  =
Which the same host (the PCP client) needs to know how to do anyway to =
send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to =
different networks, the host must have routing entries.  The PCP client =
can use those same routing entries to know there are two routers on the =
network, and send PCP messages to those two routers separately.
>>>=20
>>> -d
>>>=20
>>>=20
>>>>=20
>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20
>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13
>>>> =CA=D5=BC=FE=C8=CB: Dan Wing
>>>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart =
Cheshire; mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group
>>>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887)
>>>>=20
>>>> On Feb 12, 2014, at 10:15 AM, Dan Wing <dwing@cisco.com> wrote:
>>>>> It seems appropriate to discuss this question on the PCP mailing =
list, pcp@ietf.org.
>>>>=20
>>>> Indeed, it has been discussed.   This isn't really an appropriate =
topic for an erratum.
>>>>=20
>>>=20
>>=20
>=20


From nobody Thu Feb 13 19:24:23 2014
Return-Path: <dwing@cisco.com>
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 5166A1A00B8 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 19:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.76
X-Spam-Level: 
X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 FCtMJTDND8I0 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 19:24:13 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39BEA1A003B for <pcp@ietf.org>; Thu, 13 Feb 2014 19:24:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14739; q=dns/txt; s=iport; t=1392348252; x=1393557852; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=i/vqcI4a+4HfR+O4WzyffTuJcnbHnwzhhax/UuFB7x8=; b=Rr2GwHYXF/j9s4AN5yAfBiqBdddry7EzfCE9cPgpi9xrIo4yKn4rR1YK AaQxaiiG0aXA2WwJQ3EFRCwvZwKAsYnNEviVqzURkJO/BRIoY1U5EnZFj b/xGd82DXqFcObjRcGn56upTT3vHm4xzbqlKzwE1hI59qpEySvOUlRkqN Y=;
X-IronPort-AV: E=Sophos;i="4.95,842,1384300800"; d="scan'208";a="102424989"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 14 Feb 2014 03:24:12 +0000
Received: from sjc-vpn5-1629.cisco.com (sjc-vpn5-1629.cisco.com [10.21.94.93]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1E3O7Mu016498;  Fri, 14 Feb 2014 03:24:08 GMT
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97BCE@nkgeml508-mbx.china.huawei.com>
Date: Thu, 13 Feb 2014 19:24:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D388899F-B28D-465D-8AEB-AAE0BC3E3F11@cisco.com>
References: <20140212033032.D4F0A7FC395@rfc-editor.org> <B5316AA3-9CFD-4E25-822B-401F9DE36765@cisco.com> <F8F3C26A-FC50-486A-8EFF-DA2C08178524@nominum.com> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <B12D7908-1773-4DC9-8474-90532F328E21@cisco.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> <1DA8CEC3F3E989439069663C05A865D334F97BCE@nkgeml508-mbx.china.huawei.com>
To: "Zhangzhan (Channy)" <channy.zhang@huawei.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/at-KfWE0uqKjf31jZDK3sooaKV8
Cc: Stuart Cheshire <cheshire@apple.com>, Brian Haberman <brian@innovationslab.net>, PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?VGhpcyBzb2x1dGlvbiBpcyBmZWFzaWJsZT+08Li0OiBXaGF0?= =?gb2312?b?J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tPC4tDogW1RlY2huaWNhbCBFcnJh?= =?gb2312?b?dGEgUmVwb3J0ZWRdIFJGQzY4ODcgKDM4ODcp?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 03:24:20 -0000

On Feb 13, 2014, at 5:56 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:

> PCP Client    	      	           PCP	Server=09
> ----------    	      	           ----------
>    |                                   |
>    |---MAP w/LEARN_ZONES option------->|
>    |                                   |
>    |                   (one mapping is created)
>    |                                   |
>    |<--mapped to zone=3D1, total zones=3D3-|
>    |                                   |
>    |--GET_ZONE 1 details-------------->|
>    |<--zone 1 details------------------|
>    |                                   |
>    |--GET_ZONE 2 details-------------->|
>    |<--zone 2 details------------------|
>    |                                   |
>    |--GET_ZONE 3 details-------------->|
>    |<--zone 3 details------------------|
>    |                                   |
>    |--MAP, ZONE=3D2--------------------->|
>    |<-ok-------------------------------|
>    |                                   |
>    |--MAP, ZONE=3D3--------------------->|
>    |<-ok-------------------------------|
>    |                                   |
>=20
> I think this solution has one problem.
> Based on RFC6887, we add a new LEARN_ZONES option, and client send =
this option message firstly to get zone number of PCP server.=20
> It seems that pcp client know the server has more than one ZONEs in =
advance.

No, it doesn't.  LEARN_ZONE would be in the optional-to-process range, =
so the PCP client can safely send that option with any MAP request.  If =
the PCP server understands LEARN_ZONE, it includes LEARN_ZONE =
information in the response.  I show that the LEARN_ZONE information =
would merely indicate the number of zones supported.  If the PCP server =
does not understand LEARN_ZONE, the PCP server omits the LEARN_ZONE =
option from the response, but otherwise creates the requested MAP =
normally (that is, the PCP server behaves as if the optional-to-process =
LEARN_ZONE was not in the request at all).

This gives good backwards and forwards compatibility.


> But in actual network pcp client how to get this information?=20
> I think that supplementing on the basis of the existing is a better =
way for protocol compatibility.
>=20
> Refer to your idea chart, my idea chart is as follows:
>=20
> PCP Client    	      	           PCP	Server=09
> ----------    	      	           ----------
>    |                                   |
>    |---MAP/PEER request--------------->|
>    |                                   |
>    |                 (have more than one ZONEs)
>    |                                   |
>    |<-----MULTIPLE_ZONES resultcode----|
>    |                                   |
>    |--GET_ZONE Opcode----------------->|
>    |<--------------all zones detail----|
>    |                                   |
>    |--MAP/PEER zone 1----------------->|
>    |                                   |
>    |                       (mapping to zone 1)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 2----------------->|
>    |                                   |
>    |                       (mapping to zone 2)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 3----------------->|
>    |                                   |
>    |                       (mapping to zone 3)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>=20
>=20
> Based on your idea, my idea to make the following change:
>=20
> PCP Client    	      	           PCP	Server=09
> ----------    	      	           ----------
>    |                                   |
>    |---MAP/PEER request--------------->|
>    |                                   |
>    |                 (have more than one ZONEs)
>    |                                   |
>    |<----MULTIPLE_ZONES resultcode
>          ZONES_NUM option(zones=3D3)-----|

So, that is an error message.    Existing PCP clients will be unable to =
create any sort of mapping.  That seems undesirable, as it forces PCP =
clients to understand how to handle zones, or else they cannot function. =
 If that is the desire, it is better to create an entirely new opcode =
instead of overloading MAP as I proposed.  I don't think such a failure =
is desirable.  Why force zone-unaware PCP clients to fail?

-d


>    |                                   |
>    |--GET_ZONE 1 details-------------->|
>    |<--zone 1 details------------------|
>    |                                   |
>    |--GET_ZONE 2 details-------------->|
>    |<--zone 2 details------------------|
>    |                                   |
>    |--GET_ZONE 3 details-------------->|
>    |<--zone 3 details------------------|
>    |                                   |
>    |--MAP/PEER zone 1----------------->|
>    |                                   |
>    |                       (mapping to zone 1)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 2----------------->|
>    |                                   |
>    |                       (mapping to zone 2)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>    |--MAP/PEER zone 3----------------->|
>    |                                   |
>    |                       (mapping to zone 3)
>    |                                   |
>    |<--ok------------------------------|
>    |                                   |
>=20
> The coupling degree of this idea is smaller, or not?
>=20
>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C214=C8=D5 1:45
> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
> =D6=F7=CC=E2: Re: This solution is feasible?=B4=F0=B8=B4: What's the =
final conclusion?=B4=F0=B8=B4: [Technical Errata Reported] RFC6887 =
(3887)
>=20
>=20
> On Feb 12, 2014, at 11:06 PM, Zhangzhan (Channy) =
<channy.zhang@huawei.com> wrote:
>=20
>> This solution is feasible?
>>=20
>> We define a new result code, such as MULTIPLE_ZONES, and define a new =
Opcode, such as GET_ZONE.
>> If the PCP server have more than one ZONE, reply a MULTIPLE_ZONES =
result code message when receiving any PCP requests.
>> The client receives the result code, must send a GET_ZONE Opcode =
request message.
>> The PCP server must replay a message which contains the list of all =
ZONE ID information.
>> Then the client get the ZONE ID information, sends request messages =
(PEER or MAP) which include ZONEID option. If there are N zones, client =
must send N request messages.
>> Finally The PCP server can be selected the different address pools =
according to the ZONEID information and create multiple different =
mapping tables.
>> If the zone information is changed in PCP server, mapping tables must =
be deleted and create new mapping table when receiving renewing messages =
from clients.
>=20
> Seems like a good first cut, but I don't like breaking backwards =
compatibility with existing PCP clients.  Backwards compatibility is =
broken in that second step (the step starting with "If the PCP server =
have more than one ZONE ...").  Better would be if the PCP client tries =
to do zone discovery when it sends its first MAP (such as an PCP =
option), as that doesn't change state machine much.   Here is what I am =
thinking (view with fixed-width font):
>=20
> PCP Client    	      	           PCP	Server=09
> ----------    	      	           ----------
>    |                                   |
>    |---MAP w/LEARN_ZONES option------->|
>    |                                   |
>    |                   (one mapping is created)
>    |                                   |
>    |<--mapped to zone=3D1, total zones=3D3-|
>    |                                   |
>    |--GET_ZONE 1 details-------------->|
>    |<--zone 1 details------------------|
>    |                                   |
>    |--GET_ZONE 2 details-------------->|
>    |<--zone 2 details------------------|
>    |                                   |
>    |--GET_ZONE 3 details-------------->|
>    |<--zone 3 details------------------|
>    |                                   |
>    |--MAP, ZONE=3D2--------------------->|
>    |<-ok-------------------------------|
>    |                                   |
>    |--MAP, ZONE=3D3--------------------->|
>    |<-ok-------------------------------|
>    |                                   |
>=20
>=20
> -d
>=20
>=20
>>=20
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 14:22
>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: =
[Technical Errata Reported] RFC6887 (3887)
>>=20
>>=20
>> On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:
>>=20
>>> This draft is proposed in 2011, but has expired, no refresh or =
replacement?
>>=20
>> That's right.
>>=20
>>> The PEER mode include remote address maybe can be selected correct =
zone.
>>>=20
>>> The MAP mode only through the filter option to identify, if contains =
more than one filter in one PCP message, and these filters maybe belong =
to different zones.=20
>>> And an address pool may contain a number of different segments =
address blocks, the filter maybe not be able to identify zones.
>>>=20
>>> The ZONEID option should be a good solution, but the client to get =
the zones information is a very difficult thing, because zones in CGN is =
hidden for a client and no business relations. Zones maybe be changed, =
how to keep the synchronization is a problem.
>>=20
>> That problem needs to be solved anyway, no matter if it's called =
ZONEID or called something else.
>>=20
>> -d
>>=20
>>=20
>>>=20
>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 10:23
>>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
>>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
>>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: =
[Technical Errata Reported] RFC6887 (3887)
>>>=20
>>>=20
>>> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) =
<channy.zhang@huawei.com> wrote:
>>>=20
>>>> Maybe you misunderstand me.
>>>> There is only one router for NAT and PCP.
>>>> If the NAT gateway device (such as CGN) is PCP Server and has two =
or more out interfaces to internet were doing different nat conversion =
in the ISP.=20
>>>> Maybe using NAT address pool A, B, C... And the routing entries to =
internet on NAT gateway is equivalent default route. In this case, the =
out interface is uncertain, fully in accordance with the equivalent =
route selection.
>>>> If no PCP, service traffic can be selected out interface according =
to the destination address and do different NAT conversion.
>>>> But the PCP message is in before the normal service traffic. And =
PCP MAP mode message does not include the destination address, the NAT =
gateway device how to choose the out interfaces and the different NAT =
address pools?=20
>>>> Based on the current PCP protocol, I think that can't be solved. Or =
what I understand something wrong?
>>>=20
>>> With such a network topology, you are correct that the current MAP =
opcode doesn't work.  We need something different.  Would =
http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution?
>>>=20
>>> -d
>>>=20
>>>=20
>>>>=20
>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20
>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02
>>>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy)
>>>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; =
mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler
>>>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: =
[Technical Errata Reported] RFC6887 (3887)
>>>>=20
>>>>=20
>>>> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" =
<channy.zhang@huawei.com> wrote:
>>>>=20
>>>>> "Indeed, it has been discussed."
>>>>>=20
>>>>> What's the final conclusion to the discussion?=20
>>>>>=20
>>>>> How PCP applies in the Dual-Egress NAT scene?
>>>>>=20
>>>>> Could you please share it?=20
>>>>=20
>>>> I removed the RFC Editor from the thread.
>>>>=20
>>>> PCP client needs to communicate to both of the NATs independently.  =
Which the same host (the PCP client) needs to know how to do anyway to =
send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to =
different networks, the host must have routing entries.  The PCP client =
can use those same routing entries to know there are two routers on the =
network, and send PCP messages to those two routers separately.
>>>>=20
>>>> -d
>>>>=20
>>>>=20
>>>>>=20
>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20
>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13
>>>>> =CA=D5=BC=FE=C8=CB: Dan Wing
>>>>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart =
Cheshire; mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; =
pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group
>>>>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887)
>>>>>=20
>>>>> On Feb 12, 2014, at 10:15 AM, Dan Wing <dwing@cisco.com> wrote:
>>>>>> It seems appropriate to discuss this question on the PCP mailing =
list, pcp@ietf.org.
>>>>>=20
>>>>> Indeed, it has been discussed.   This isn't really an appropriate =
topic for an erratum.
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


From nobody Thu Feb 13 19:24:43 2014
Return-Path: <repenno@cisco.com>
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 2C0311A00D1 for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 19:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.76
X-Spam-Level: 
X-Spam-Status: No, score=-3.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548, 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 ya1rjYT1v2Oj for <pcp@ietfa.amsl.com>; Thu, 13 Feb 2014 19:24:23 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id E6EDE1A003B for <pcp@ietf.org>; Thu, 13 Feb 2014 19:24:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2440; q=dns/txt; s=iport; t=1392348262; x=1393557862; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vLNbhaOyXsDWnV4VgxiSoavxq+zYKshMzc6Lq7IrKS4=; b=lllgtFv8Rg2Vn6u/sEvQgRrpYzV9a6m1iscRmkUh/VGHC3HdJ2HdKhMx NkcEWpjvdTcVbp16nAIW/PXS9B00SRb3qEeYKb3/43aoquOZ9WVqw7hdq iRVygoBGdbKdeMQBaIVP/N6lgliU0IMATx4Kt6XCRwMdgCpZX8JsSa2Lp w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FAOiL/VKtJV2d/2dsb2JhbABZgwaBD4MCvFcYgQEWdIIlAQEBBDRFEgEGAhEEAQEBBCMFBDAUBgMIAgQOBRkCh2qKZZt5CKFyF4EljTkbB4JrgU0BA5gskiOBb4E+gio
X-IronPort-AV: E=Sophos;i="4.95,842,1384300800"; d="scan'208";a="20367430"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 14 Feb 2014 03:24:21 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1E3OLW3015066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 03:24:21 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 21:24:20 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "Zhangzhan (Channy)" <channy.zhang@huawei.com>
Thread-Topic: =?gb2312?B?tPC4tDogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNo?= =?gb2312?Q?nical_Errata_Reported]_RFC6887_(3887)?=
Thread-Index: AQHPJ6LPzMjxlXlS/USHNBsyymSwU5qxNTOAgAAQJoCAARNEUIAAaxgAgAAHuwCAAA7RAIAAQNAAgAACHQCAAH/CAP//nVfcgAAS9QCAARv7AP//jnkA
Date: Fri, 14 Feb 2014 03:24:20 +0000
Message-ID: <CF22CC2C.918B%repenno@cisco.com>
In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97BE1@nkgeml508-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.155.66.4]
Content-Type: text/plain; charset="gb2312"
Content-ID: <0542A4F6508457439A4A6086705467E3@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/xu04IDEY2Ol56Pv6PqR-M_sXrn0
Cc: PCP Working Group <pcp@ietf.org>
Subject: Re: [pcp] =?gb2312?b?tPC4tDogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7Tw?= =?gb2312?b?uLQ6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3?= =?gb2312?b?KQ==?=
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 03:24:25 -0000

SnVzdCBwdXQgYSBwb3dlcnBvaW50IHByZXNlbnRhdGlvbiB0b2dldGhlciBkZXNjcmliaW5nIHlv
dXIgaXNzdWUsDQpwcm9wb3NlZCBzb2x1dGlvbiwgd2hhdG5vdC4NCg0KQW5kIHRlbGwgdXMgaG93
IG11Y2ggdGltZSB5b3UgbmVlZC4NCg0KT24gMi8xMy8xNCwgNjoxMCBQTSwgIlpoYW5nemhhbiAo
Q2hhbm55KSIgPGNoYW5ueS56aGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkl0J3MgbXkgcGxl
YXN1cmUuDQo+DQo+Q291bGQgeW91IHRlbGwgbWUgaG93IHRvIHByZXNlbnQ/IEFueSBlbnRyYW5j
ZSBvciBndWlkZT8NCj4NCj4NCj4tLS0tLdPKvP7Urbz+LS0tLS0NCj63orz+yMs6IFJlaW5hbGRv
IFBlbm5vIChyZXBlbm5vKSBbbWFpbHRvOnJlcGVubm9AY2lzY28uY29tXQ0KPreiy83KsbzkOiAy
MDE0xOoy1MIxNMjVIDE6MTQNCj7K1bz+yMs6IFpoYW5nemhhbiAoQ2hhbm55KQ0KPrOty806IFBD
UCBXb3JraW5nIEdyb3VwDQo+1vfM4jogUmU6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1c2lvbj+0
8Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0NCj5SRkM2ODg3ICgzODg3KQ0KPg0KPlpo
YW5nemhhbiwNCj4NCj5Xb3VsZCB5b3UgY2FyZSB0byBwcmVzZW50IHlvdXIgdXNlLWNhc2UgYW5k
IHByb2JsZW0gc3RhdGVtZW50IGF0IHRoZSBuZXh0DQo+SUVURj8gDQo+DQo+QXMgSSBzYWlkLCBJ
IHByZXNlbnRlZCB0aGlzIHByb3Bvc2FsIGJlZm9yZSBidXQgbWF5YmUgaXQgd2FzIHRvbyBlYXJs
eSBvbg0KPldHIGxpZmUgZm9yIG90aGVycyB0byBkZWRpY2F0ZWQgdGltZS4NCj4NCj5UaGFua3Ms
DQo+DQo+UmVpbmFsZG8NCj4NCj5PbiAyLzEzLzE0LCA2OjA3IEFNLCAiUmVpbmFsZG8gUGVubm8g
KHJlcGVubm8pIiA8cmVwZW5ub0BjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5JIGJlbGlldmUgYXQg
dGhhdCB0aW1lIHdlIGhhZCBiaWdnZXIgZmlzaCB0byBmcnkgc3VjaCBhcyBjb21wbGV0aW5nIHRo
ZQ0KPj5tYWluIHNwZWMuIElmIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCB0aGlzIHdvcmsgY291
bGQgYmUgcmVzdW1lZC4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+RnJvbTogVGVkIExlbW9uIFt0ZWQubGVtb25Abm9taW51bS5jb21dDQo+PlNlbnQ6
IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCA1OjU5IEFNDQo+PlRvOiBEYW4gV2luZyAoZHdp
bmcpDQo+PkNjOiBaaGFuZ3poYW4gKENoYW5ueSk7IFBDUCBXb3JraW5nIEdyb3VwOyBTdHVhcnQg
Q2hlc2hpcmU7DQo+Pm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gQm91Y2FkYWlyOyBSZWlu
YWxkbyBQZW5ubyAocmVwZW5ubyk7DQo+PnBzZWxraXJrQGlzYy5vcmc7IEJyaWFuIEhhYmVybWFu
OyBEYXZlIFRoYWxlcg0KPj5TdWJqZWN0OiBSZTogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9u
P7TwuLQ6IFtUZWNobmljYWwgRXJyYXRhDQo+PlJlcG9ydGVkXQ0KPj5SRkM2ODg3ICgzODg3KQ0K
Pj4NCj4+T24gRmViIDEzLCAyMDE0LCBhdCAxOjIyIEFNLCBEYW4gV2luZyA8ZHdpbmdAY2lzY28u
Y29tPiB3cm90ZToNCj4+Pj4gVGhpcyBkcmFmdCBpcyBwcm9wb3NlZCBpbiAyMDExLCBidXQgaGFz
IGV4cGlyZWQsIG5vIHJlZnJlc2ggb3INCj4+Pj5yZXBsYWNlbWVudD8NCj4+PiBUaGF0J3Mgcmln
aHQuDQo+Pg0KPj5ZZXMsIHRoaXMgaXMgd2h5IGl0J3Mgc28gaW1wb3J0YW50IHRvIGRpc2N1c3Mg
aXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXChqnNvDQo+PnRoYXQgcHJvZ3Jlc3MgY2FuIHJlc3VtZSEg
ICA6KQ0KPj4NCj4NCg0K


From nobody Fri Feb 14 01:07:45 2014
Return-Path: <Andreas.Ripke@neclab.eu>
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 B60331A01B3 for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 01:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.15
X-Spam-Level: 
X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, 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 9FH6-DVnxDui for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 01:07:38 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E47D11A01F4 for <pcp@ietf.org>; Fri, 14 Feb 2014 01:07:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4D905106CCB for <pcp@ietf.org>; Fri, 14 Feb 2014 10:07:17 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUE6KIMjhNMs for <pcp@ietf.org>; Fri, 14 Feb 2014 10:07:17 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 281A7106CCA for <pcp@ietf.org>; Fri, 14 Feb 2014 10:07:12 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 14 Feb 2014 10:07:12 +0100
From: Andreas Ripke <Andreas.Ripke@neclab.eu>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
Thread-Index: AQHPKNN183BuJolhBUq4sUpr4CoLq5q0dB4Q
Date: Fri, 14 Feb 2014 09:07:11 +0000
Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd>
References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com>
In-Reply-To: <20140213155106.26257.47053.idtracker@ietfa.amsl.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/fUbdxFos3cUYYUO6AGrV9a195VM
Subject: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 09:07:42 -0000

SGksDQoNClRoZSBiZWxvdyBkcmFmdCBkZXNjcmliZXMgYSBzY2VuYXJpbyBpbiB0aGF0DQogICgx
KSB0aGUgc3Vic2NyaWJlcnMgYmVoaW5kIGEgQ0dOIGNhbiBmcmVlbHkgY2hvb3NlIHRoZWlyIGlu
dGVybmFsIElQIGFkZHJlc3Nlcw0KICAgICAgICh3aGljaCBwb3RlbnRpYWxseSBsZWFkcyB0byBv
dmVybGFwcGluZyBJUCBhZGRyZXNzIHNwYWNlcykNCiAgKDIpIGEgY2VudHJhbCBQQ1AgY2xpZW50
IGlzIHVzZWQgZm9yIHBvcnQgbWFwcGluZyByZXF1ZXN0cy4NClRoZSBDR04sIGFjdGluZyBhcyBQ
Q1Agc2VydmVyLCBjYW5ub3QgaWRlbnRpZnkgdGhlIHN1YnNjcmliZXIganVzdCBieSB0aGUgaW50
ZXJuYWwgSVAgYWRkcmVzcyBwcm92aWRlZCB3aXRoIHRoZSBUSElSRF9QQVJUWSBvcHRpb24uDQpU
aGVyZWZvcmUsIGFuIGFkZGl0aW9uYWwgaWRlbnRpZmllciAodGhlIHN1YnNjcmliZXLigJlzIHR1
bm5lbCBJRCkgdG8gdGhlIFBDUCBtYXBwaW5nIHJlcXVlc3QgaXMgbmVlZGVkLg0KDQpJZiB5b3Ug
aGF2ZSBhbnkgY29tbWVudHMgb24gdGhpcyBkcmFmdCBwbGVhc2UgbGV0IHVzIGtub3cuIFRoYW5r
cy4NCg0KQmVzdCwNCg0KQW5kcmVhcw0KDQoNCk5FQyBFdXJvcGUgTHRkIHwgUmVnaXN0ZXJlZCBP
ZmZpY2U6IEF0aGVuZSwgT2R5c3NleSBCdXNpbmVzcyBQYXJrLCBXZXN0IEVuZCAgUm9hZCwgTG9u
ZG9uLCBIQTQgNlFFLCBHQiB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQoNCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBG
ZWJydWFyeSAxMywgMjAxNCA0OjUxIFBNDQo+IFRvOiBBbmRyZWFzIFJpcGtlOyBSYWZhZWwgTG9w
ZXogZGEgU2lsdmE7IFJhZmFlbCBMb3BleiBkYSBTaWx2YTsgVGhvbWFzIERpZXR6Ow0KPiBKdWVy
Z2VuIFF1aXR0ZWs7IEp1ZXJnZW4gUXVpdHRlazsgVGhvbWFzIERpZXR6OyBBbmRyZWFzIFJpcGtl
DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmlwa2UtcGNw
LXR1bm5lbC1pZC1vcHRpb24tMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs
IGRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQtb3B0aW9uLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNj
ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFuZHJlYXMgUmlwa2UgYW5kIHBvc3RlZCB0byB0aGUgSUVU
Rg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQt
b3B0aW9uDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVBDUCBUdW5uZWwtSUQgT3B0aW9uDQo+
IERvY3VtZW50IGRhdGU6CTIwMTQtMDItMTMNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np
b24NCj4gUGFnZXM6CQk4DQo+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1yaXBrZS1wY3AtdHVubmVsLWlkLQ0KPiBvcHRpb24tMDAudHh0
DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1yaXBrZS1wY3AtdHVubmVsLWlkLW9wdGlvbi8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQtb3B0aW9uLTAwDQo+
IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbmV3IFBv
cnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSBvcHRpb24NCj4gICAgY2FsbGVkIFRVTk5FTF9JRC4g
IEl0IHNlcnZlcyBmb3IgaWRlbnRpZnlpbmcgYSBUaGlyZCBQYXJ0eSBpbg0KPiAgICBhZGRpdGlv
biB0byB0aGUgbWVhbnMgdGhhdCBQQ1AncyBUSElSRF9QQVJUWSBvcHRpb24gYWxyZWFkeSBwcm92
aWRlcw0KPiAgICBmb3IgdGhhdCBwdXJwb3NlLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5v
dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg
c3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh
aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K


From nobody Fri Feb 14 07:08:44 2014
Return-Path: <simon.perreault@viagenie.ca>
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 BF6CA1A02BB for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 07:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 aYhb3sDhYCs8 for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 07:08:36 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6781A02A2 for <pcp@ietf.org>; Fri, 14 Feb 2014 07:08:32 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 97E2640222 for <pcp@ietf.org>; Fri, 14 Feb 2014 10:08:30 -0500 (EST)
Message-ID: <52FE316E.7000708@viagenie.ca>
Date: Fri, 14 Feb 2014 10:08:30 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: pcp@ietf.org
References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd>
In-Reply-To: <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/aBb01pjI2PQRjHV7O8DHBORBj-8
Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 15:08:41 -0000

Le 2014-02-14 04:07, Andreas Ripke a écrit :
> The below draft describes a scenario in that
>   (1) the subscribers behind a CGN can freely choose their internal IP addresses
>        (which potentially leads to overlapping IP address spaces)
>   (2) a central PCP client is used for port mapping requests.
> The CGN, acting as PCP server, cannot identify the subscriber just by the internal IP address provided with the THIRD_PARTY option.
> Therefore, an additional identifier (the subscriber’s tunnel ID) to the PCP mapping request is needed.

Eerily similar to draft-ietf-pcp-dslite...

Why not send the PCP request inside the tunnel?

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 Fri Feb 14 08:09:34 2014
Return-Path: <Andreas.Ripke@neclab.eu>
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 DC2611A0242 for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 08:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.15
X-Spam-Level: 
X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, 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 vQL96DdF6RRx for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 08:09:28 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1AD1A02FB for <pcp@ietf.org>; Fri, 14 Feb 2014 08:09:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5204C106CD5; Fri, 14 Feb 2014 17:09:21 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZHrxDnrvoKj; Fri, 14 Feb 2014 17:09:21 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 37EC3106CDD; Fri, 14 Feb 2014 17:09:11 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 14 Feb 2014 17:09:11 +0100
From: Andreas Ripke <Andreas.Ripke@neclab.eu>
To: Simon Perreault <simon.perreault@viagenie.ca>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
Thread-Index: AQHPKNN183BuJolhBUq4sUpr4CoLq5q0dB4QgABWtACAAB34wA==
Date: Fri, 14 Feb 2014 16:09:11 +0000
Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631D69FE@PALLENE.office.hd>
References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> <52FE316E.7000708@viagenie.ca>
In-Reply-To: <52FE316E.7000708@viagenie.ca>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/0k1rYqZR0AJFBjAqrMvO15d35Cs
Cc: Rolf Winter <Rolf.Winter@neclab.eu>, Thomas Dietz <Thomas.Dietz@neclab.eu>
Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 16:09:31 -0000

SGkgU2ltb24sDQoNClRoZSB1c2UtY2FzZSBpbiBkcmFmdC1pZXRmLXBjcC1kc2xpdGUgaXMgYSBk
aWZmZXJlbnQgb25lLg0KVGhlcmUsIHRoZSBQQ1AgcHJveHkgb3IgY2xpZW50IGlzIGxvY2F0ZWQg
aW4gdGhlIGN1c3RvbWVyJ3MgcmVhbG0uDQpXaGF0IHdlIGRlc2NyaWJlIGlzIGEgc2NlbmFyaW8g
d2l0aCBvbmUgY2VudHJhbCBQQ1AgY2xpZW50IGxvY2F0ZWQgb24gYSB3ZWIgcG9ydGFsIHNlcnZp
bmcgYWxsIGN1c3RvbWVycy4NClRoZXJlZm9yZSwgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyIGlz
IG5lZWRlZCBieSB0aGUgUENQIHNlcnZlciB0byBhc3NvY2lhdGUgdGhlIGNvbm5lY3Rpb24gdG8g
YmUgbWFwcGVkIHdpdGggdGhlIGN1c3RvbWVyJ3MgdHVubmVsLg0KDQpCZXN0LA0KDQpBbmRyZWFz
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGNwIFttYWlsdG86cGNw
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaW1vbiBQZXJyZWF1bHQNCj4gU2VudDog
RnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA0OjA5IFBNDQo+IFRvOiBwY3BAaWV0Zi5vcmcNCj4g
U3ViamVjdDogUmU6IFtwY3BdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0
LXJpcGtlLXBjcC10dW5uZWwtaWQtDQo+IG9wdGlvbi0wMC50eHQNCj4gDQo+IExlIDIwMTQtMDIt
MTQgMDQ6MDcsIEFuZHJlYXMgUmlwa2UgYSDDqWNyaXQgOg0KPiA+IFRoZSBiZWxvdyBkcmFmdCBk
ZXNjcmliZXMgYSBzY2VuYXJpbyBpbiB0aGF0DQo+ID4gICAoMSkgdGhlIHN1YnNjcmliZXJzIGJl
aGluZCBhIENHTiBjYW4gZnJlZWx5IGNob29zZSB0aGVpciBpbnRlcm5hbCBJUA0KPiBhZGRyZXNz
ZXMNCj4gPiAgICAgICAgKHdoaWNoIHBvdGVudGlhbGx5IGxlYWRzIHRvIG92ZXJsYXBwaW5nIElQ
IGFkZHJlc3Mgc3BhY2VzKQ0KPiA+ICAgKDIpIGEgY2VudHJhbCBQQ1AgY2xpZW50IGlzIHVzZWQg
Zm9yIHBvcnQgbWFwcGluZyByZXF1ZXN0cy4NCj4gPiBUaGUgQ0dOLCBhY3RpbmcgYXMgUENQIHNl
cnZlciwgY2Fubm90IGlkZW50aWZ5IHRoZSBzdWJzY3JpYmVyIGp1c3QgYnkgdGhlDQo+IGludGVy
bmFsIElQIGFkZHJlc3MgcHJvdmlkZWQgd2l0aCB0aGUgVEhJUkRfUEFSVFkgb3B0aW9uLg0KPiA+
IFRoZXJlZm9yZSwgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyICh0aGUgc3Vic2NyaWJlcuKAmXMg
dHVubmVsIElEKSB0byB0aGUgUENQDQo+IG1hcHBpbmcgcmVxdWVzdCBpcyBuZWVkZWQuDQo+IA0K
PiBFZXJpbHkgc2ltaWxhciB0byBkcmFmdC1pZXRmLXBjcC1kc2xpdGUuLi4NCj4gDQo+IFdoeSBu
b3Qgc2VuZCB0aGUgUENQIHJlcXVlc3QgaW5zaWRlIHRoZSB0dW5uZWw/DQo+IA0KPiBTaW1vbg0K
PiAtLQ0KPiBEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxs
YXRpb24udmlhZ2VuaWUuY2ENCj4gTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0tPiBo
dHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYQ0KPiBTVFVOL1RVUk4gc2VydmVyICAgICAgICAgICAg
ICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwY3AgbWFpbGluZyBsaXN0DQo+IHBjcEBp
ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0K


From nobody Fri Feb 14 10:51:04 2014
Return-Path: <internet-drafts@ietf.org>
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 28F0B1A0341; Fri, 14 Feb 2014 10:51:01 -0800 (PST)
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 o0KecmQjCD5m; Fri, 14 Feb 2014 10:50:59 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352511A02D0; Fri, 14 Feb 2014 10:50:59 -0800 (PST)
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.0.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140214185059.6512.98492.idtracker@ietfa.amsl.com>
Date: Fri, 14 Feb 2014 10:50:59 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/FZ89i_tPInKxTPO2Z0lnfWXQbpI
Cc: pcp@ietf.org
Subject: [pcp] I-D Action: draft-ietf-pcp-anycast-01.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 18:51:01 -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 Anycast Address
        Authors         : Sebastian Kiesel
                          Reinaldo Penno
                          Stuart Cheshire
	Filename        : draft-ietf-pcp-anycast-01.txt
	Pages           : 16
	Date            : 2014-02-14

Abstract:
   The Port Control Protocol (PCP) Anycast Address enables PCP clients
   to transmit signaling messages to their closest on-path NAT,
   Firewall, or other middlebox, without having to learn the IP address
   of that middlebox via some external channel.  This document
   establishes one well-known IPv4 address and one well-known IPv6
   address to be used as PCP Anycast Address.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-anycast-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-anycast-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Feb 14 11:04:39 2014
Return-Path: <sebi@gw01.ehlo.wurstkaes.de>
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 72D571A0045 for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 11:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] 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 IKduFi1uzvhv for <pcp@ietfa.amsl.com>; Fri, 14 Feb 2014 11:04:33 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id E80C41A02A3 for <pcp@ietf.org>; Fri, 14 Feb 2014 11:04:32 -0800 (PST)
Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1WEO3p-00017R-Hn for pcp@ietf.org; Fri, 14 Feb 2014 20:04:29 +0100
Date: Fri, 14 Feb 2014 20:04:29 +0100
From: Sebastian Kiesel <ietf-pcp@skiesel.de>
To: pcp@ietf.org
Message-ID: <20140214190429.GA3221@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/ldcMMPZOBi-jNeqyzyn-vplx95A
Subject: [pcp] FWD: I-D Action: draft-ietf-pcp-anycast-01.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 19:04:36 -0000

Dear all,

this version of the draft has a dramatically shortened deployment
considerations section.  All discussion of possible mechanisms to
deal with multiple PCP servers and asymetric routing removed, 
keeping just a statement that this is beyond the scope of this document.

Your reviews/comments/suggestions are appreciated.

Thanks
Sebastian

----- Forwarded message from internet-drafts@ietf.org -----

Date: Fri, 14 Feb 2014 10:50:59 -0800
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: pcp@ietf.org
Subject: [pcp] I-D Action: draft-ietf-pcp-anycast-01.txt


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 Anycast Address
        Authors         : Sebastian Kiesel
                          Reinaldo Penno
                          Stuart Cheshire
	Filename        : draft-ietf-pcp-anycast-01.txt
	Pages           : 16
	Date            : 2014-02-14

Abstract:
   The Port Control Protocol (PCP) Anycast Address enables PCP clients
   to transmit signaling messages to their closest on-path NAT,
   Firewall, or other middlebox, without having to learn the IP address
   of that middlebox via some external channel.  This document
   establishes one well-known IPv4 address and one well-known IPv6
   address to be used as PCP Anycast Address.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-anycast-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-anycast-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

----- End forwarded message -----


From nobody Sat Feb 15 10:47:21 2014
Return-Path: <Quittek@neclab.eu>
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 1BBD11A027A for <pcp@ietfa.amsl.com>; Sat, 15 Feb 2014 10:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.15
X-Spam-Level: 
X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, 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 p6RLcFCh_eyG for <pcp@ietfa.amsl.com>; Sat, 15 Feb 2014 10:47:17 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 03F941A026D for <pcp@ietf.org>; Sat, 15 Feb 2014 10:47:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8AA22106CC6; Sat, 15 Feb 2014 19:47:14 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOFgzUo-QBT2; Sat, 15 Feb 2014 19:47:14 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 6BEA51068B5; Sat, 15 Feb 2014 19:46:59 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sat, 15 Feb 2014 19:46:38 +0100
From: Juergen Quittek <Quittek@neclab.eu>
To: Andreas Ripke <Andreas.Ripke@neclab.eu>, Simon Perreault <simon.perreault@viagenie.ca>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
Thread-Index: AQHPKNN1JE4TS3eChESgjCh6CKOftJq0Zd+AgABk8wCAABD1gIABzLKg
Date: Sat, 15 Feb 2014 18:46:37 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A5A617@PALLENE.office.hd>
References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> <52FE316E.7000708@viagenie.ca> <2D2FFE4726FAF74285C45D69FDC30E79631D69FE@PALLENE.office.hd>
In-Reply-To: <2D2FFE4726FAF74285C45D69FDC30E79631D69FE@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.7.0.202]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/4ae_8i65n6bSeKtb_r5GZPmuAME
Cc: "ralds@tid.es" <ralds@tid.es>, Rolf Winter <Rolf.Winter@neclab.eu>, Thomas Dietz <Thomas.Dietz@neclab.eu>
Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Feb 2014 18:47:20 -0000

RGVhciBhbGwsDQoNClllcywgdGhhdCBpcyB0aGUgZGlmZmVyZW5jZS4NCg0KSW4gdGhlIHBjcC1k
c2xpdGUgc2NlbmFyaW8sIHRoZSBQQ1AgcHJveHkgc2VuZHMgUENQIHJlcXVlc3RzIHdpdGhpbiB0
aGUgRFNsaXRlIHR1bm5lbC4gVGhlIHJlY2VpdmluZyBQQ1AgU2VydmVyL05BVCBjYW4gbWFwIHRo
ZSByZXF1ZXN0IHRvIGEgRFNsaXRlIHR1bm5lbCwgYmVjYXVzZSBpdCBjYW4gb2JzZXJ2ZSBmcm9t
IHdoaWNoIHR1bm5lbCB0aGUgcmVxdWVzdCBjb21lcy4gDQoNCkluIHRoZSBzY2VuYXJpbyBvZiBw
Y3AtdHVubmVsLWlkLCB0aGUgcmVxdWVzdCBjb21lcyBmcm9tIG91dHNpZGUgdGhlIHR1bm5lbCwg
ZnJvbSBhIHBvcnRhbCBvZiB0aGUgTkFUIG9wZXJhdG9yIHdoZXJlIGNsaWVudHMgY2FuIGNvbmZp
Z3VyZSB0aGVpciBzZXJ2aWNlcy4gSGVyZSwgdGhlIFBDUCBjbGllbnQgaGFzIHRvIHVzZSB0aGUg
VEhJUkRfUEFSVFkgb3B0aW9uIHRvIGlkZW50aWZ5IHRoZSBJbnRlcm5hbCBIb3N0LiBJZiB0aGUg
SW50ZXJuYWwgSG9zdCBpcyB1c2luZyBwcml2YXRlIGFkZHJlc3NlcywgaXQgbmVlZHMgZnVydGhl
ciBpZGVudGlmaWNhdGlvbi4gVGhpcyBpcyB3aGF0IHRoZSBUVU5ORUxfSUQgb3B0aW9uIGlzIHBy
b3Bvc2VkIHRvIGJlIHVzZWQgZm9yLg0KDQpDaGVlcnMsDQogICAgSnVlcmdlbg0KIA0KPiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZWFzIFJpcGtlDQo+IFNlbnQ6IEZy
ZWl0YWcsIDE0LiBGZWJydWFyIDIwMTQgMTc6MDkNCj4gVG86IFNpbW9uIFBlcnJlYXVsdDsgcGNw
QGlldGYub3JnDQo+IENjOiBKdWVyZ2VuIFF1aXR0ZWs7IFRob21hcyBEaWV0ejsgUm9sZiBXaW50
ZXINCj4gU3ViamVjdDogUkU6IFtwY3BdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y
IGRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtDQo+IGlkLW9wdGlvbi0wMC50eHQNCj4gDQo+IEhpIFNp
bW9uLA0KPiANCj4gVGhlIHVzZS1jYXNlIGluIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZSBpcyBhIGRp
ZmZlcmVudCBvbmUuDQo+IFRoZXJlLCB0aGUgUENQIHByb3h5IG9yIGNsaWVudCBpcyBsb2NhdGVk
IGluIHRoZSBjdXN0b21lcidzIHJlYWxtLg0KPiBXaGF0IHdlIGRlc2NyaWJlIGlzIGEgc2NlbmFy
aW8gd2l0aCBvbmUgY2VudHJhbCBQQ1AgY2xpZW50IGxvY2F0ZWQgb24gYSB3ZWINCj4gcG9ydGFs
IHNlcnZpbmcgYWxsIGN1c3RvbWVycy4NCj4gVGhlcmVmb3JlLCBhbiBhZGRpdGlvbmFsIGlkZW50
aWZpZXIgaXMgbmVlZGVkIGJ5IHRoZSBQQ1Agc2VydmVyIHRvIGFzc29jaWF0ZQ0KPiB0aGUgY29u
bmVjdGlvbiB0byBiZSBtYXBwZWQgd2l0aCB0aGUgY3VzdG9tZXIncyB0dW5uZWwuDQo+IA0KPiBC
ZXN0LA0KPiANCj4gQW5kcmVhcw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+IEZyb206IHBjcCBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
U2ltb24gUGVycmVhdWx0DQo+ID4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA0OjA5
IFBNDQo+ID4gVG86IHBjcEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbcGNwXSBGVzogTmV3
IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQt
IG9wdGlvbi0wMC50eHQNCj4gPg0KPiA+IExlIDIwMTQtMDItMTQgMDQ6MDcsIEFuZHJlYXMgUmlw
a2UgYSDDqWNyaXQgOg0KPiA+ID4gVGhlIGJlbG93IGRyYWZ0IGRlc2NyaWJlcyBhIHNjZW5hcmlv
IGluIHRoYXQNCj4gPiA+ICAgKDEpIHRoZSBzdWJzY3JpYmVycyBiZWhpbmQgYSBDR04gY2FuIGZy
ZWVseSBjaG9vc2UgdGhlaXIgaW50ZXJuYWwNCj4gPiA+IElQDQo+ID4gYWRkcmVzc2VzDQo+ID4g
PiAgICAgICAgKHdoaWNoIHBvdGVudGlhbGx5IGxlYWRzIHRvIG92ZXJsYXBwaW5nIElQIGFkZHJl
c3Mgc3BhY2VzKQ0KPiA+ID4gICAoMikgYSBjZW50cmFsIFBDUCBjbGllbnQgaXMgdXNlZCBmb3Ig
cG9ydCBtYXBwaW5nIHJlcXVlc3RzLg0KPiA+ID4gVGhlIENHTiwgYWN0aW5nIGFzIFBDUCBzZXJ2
ZXIsIGNhbm5vdCBpZGVudGlmeSB0aGUgc3Vic2NyaWJlciBqdXN0DQo+ID4gPiBieSB0aGUNCj4g
PiBpbnRlcm5hbCBJUCBhZGRyZXNzIHByb3ZpZGVkIHdpdGggdGhlIFRISVJEX1BBUlRZIG9wdGlv
bi4NCj4gPiA+IFRoZXJlZm9yZSwgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyICh0aGUgc3Vic2Ny
aWJlcuKAmXMgdHVubmVsIElEKSB0bw0KPiA+ID4gdGhlIFBDUA0KPiA+IG1hcHBpbmcgcmVxdWVz
dCBpcyBuZWVkZWQuDQo+ID4NCj4gPiBFZXJpbHkgc2ltaWxhciB0byBkcmFmdC1pZXRmLXBjcC1k
c2xpdGUuLi4NCj4gPg0KPiA+IFdoeSBub3Qgc2VuZCB0aGUgUENQIHJlcXVlc3QgaW5zaWRlIHRo
ZSB0dW5uZWw/DQo+ID4NCj4gPiBTaW1vbg0KPiA+IC0tDQo+ID4gRFROIG1hZGUgZWFzeSwgbGVh
biwgYW5kIHNtYXJ0IC0tPiBodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhDQo+ID4gTkFU
NjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5j
YQ0KPiA+IFNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlh
Z2VuaWUuY2ENCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+ID4gcGNwIG1haWxpbmcgbGlzdA0KPiA+IHBjcEBpZXRmLm9yZw0KPiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwDQo=


From nobody Mon Feb 17 15:48:13 2014
Return-Path: <eckelcu@cisco.com>
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 6BE1B1A05B8 for <pcp@ietfa.amsl.com>; Mon, 17 Feb 2014 15:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level: 
X-Spam-Status: No, score=-10.049 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.548, 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 b8_bD1DQiXk7 for <pcp@ietfa.amsl.com>; Mon, 17 Feb 2014 15:48:05 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id E00C61A043D for <pcp@ietf.org>; Mon, 17 Feb 2014 15:48:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1209; q=dns/txt; s=iport; t=1392680880; x=1393890480; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KXG305Kj5jQaOxAp8NVuOrtOSaKTaFxOc13vquhBMQI=; b=MHXSJsq4xW/Bv3+DlJVJeyFwsZ+LvQI1eb2xW6U5dqjOue6YSk4dz97+ rESXtOgLVu3yd9ciodHrh9UaiVTAngNje0Q3to8SsNWVkr8geGX+SckNp lG9VSqYtSgUcB4e8ZlmC3qKt9RGAvplEyBWR4F0Me+mYMj5k8QyByy4/n Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAMyeAlOtJXG9/2dsb2JhbABZgwY4V8BgFnSCJQEBAQQBAQFrHQEIOzILGwEGBQQTiAUNmUGwfReOLYUTBIkQjxyBMpBxgW+BPoIq
X-IronPort-AV: E=Sophos;i="4.95,863,1384300800"; d="scan'208";a="21133020"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 17 Feb 2014 23:47:59 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1HNlxKY026106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Mon, 17 Feb 2014 23:47:59 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 17:47:58 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19
Thread-Index: AQHPLDqvmtNJ9L8wukKWAsGpI1Inkg==
Date: Mon, 17 Feb 2014 23:47:58 +0000
Message-ID: <CF27DD2B.1F2CD%eckelcu@cisco.com>
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.79.36]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7793D31DFAA7E244914273E19A1A0DC2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/KsT9k5MKEyOt2k4BSOifnlwcpek
Subject: [pcp] FW: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 23:48:07 -0000

FYI, if you had interested in the concepts introduced in "PCP Flowdata
Option=B2, draft-wing-pcp-flowdata-00
(http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), which was
presented in this WG at a pervious IETF, you may also be interested in
subscribing to the AEON list and attending the AEON meeting announced in
the forwarded e-mail.

Cheers,
Charles


On 2/17/14, 10:12 AM, "Charles Eckel (eckelcu)" <eckelcu@cisco.com> wrote:

>AEON list members and other interested parties,
>
>We plan to reserve an IESG breakout room to have an AEON meeting at IETF
>89 in London.
>Please indicate which of the potential time slots work for you no later
>than Wednesday, Feb 19.
>All time slots are 1 hour in duration.
>The actual location and time will be announced on the AEON list.
>
>
>Preliminary agenda is as follows:
>1) problem statement draft
>2) draft charter
>
>The agenda will be finalized via a separate thread on the AEON list as
>well.
>Here is the link to the poll:
>http://www.doodle.com/fb8k5hyqap4iqyye
>
>
>Cheers,
>Charles
>
>_______________________________________________
>Aeon mailing list
>Aeon@ietf.org
>https://www.ietf.org/mailman/listinfo/aeon


From nobody Tue Feb 18 00:54:12 2014
Return-Path: <Andreas.Ripke@neclab.eu>
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 347FB1A009E for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 00:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level: 
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, 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 jW7mhTj49qyk for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 00:54:07 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A19B31A012B for <pcp@ietf.org>; Tue, 18 Feb 2014 00:54:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7A001106D29 for <pcp@ietf.org>; Tue, 18 Feb 2014 09:54:04 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLNDk11ak9OL for <pcp@ietf.org>; Tue, 18 Feb 2014 09:54:04 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 5D326106D28 for <pcp@ietf.org>; Tue, 18 Feb 2014 09:53:59 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 18 Feb 2014 09:54:00 +0100
From: Andreas Ripke <Andreas.Ripke@neclab.eu>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: PCP WG Call for Presentation - IETF London
Thread-Index: AQHPI3U71M6Y0T32I0K+YWkcpYErOZq0x1VggAX+hWA=
Date: Tue, 18 Feb 2014 08:53:58 +0000
Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631D6D8C@PALLENE.office.hd>
References: <CF19286E.8AFC%repenno@cisco.com> 
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.6.215]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Yj1_aGS3FWBkkf8ffjGhoAzwqC0
Subject: [pcp] FW: PCP WG Call for Presentation - IETF London
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 08:54:10 -0000

> Hi,
>=20
> We would like to have a slot for presenting draft-ripke-pcp-tunnel-id-opt=
ion-
> 00.txt
> (http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-00).
> Most likely Rolf Winter will be presenting.
> Duration: 10mins.
>=20
> Thanks.
>=20
> Best,
>=20
> Andreas
>=20
>=20
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West
> End =A0Road, London, HA4 6QE, GB | Registered in England 2832014
>=20
>=20
>=20
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Reinaldo Penno
> (repenno)
> Sent: Thursday, February 06, 2014 8:54 PM
> To: pcp@ietf.org
> Subject: [pcp] PCP WG Call for Presentation - IETF London
>=20
> If you would like to present, please send title, time needed, presenter a=
nd
> pointer to draft (if exists).
>=20
> Thanks,
>=20
> Chairs


From nobody Tue Feb 18 06:20:54 2014
Return-Path: <praspati@cisco.com>
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 A2B231A04D5 for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 06:20:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.449
X-Spam-Level: 
X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.548, 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 HZourSUJQi2s for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 06:20:48 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FF1A01CB for <pcp@ietf.org>; Tue, 18 Feb 2014 06:20:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9621; q=dns/txt; s=iport; t=1392733245; x=1393942845; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xQ23iiDG0ciKiivaJwjPsjs5lf10KKzGEII43Aj22wY=; b=XccMWrqe56SwBLWQtrRSesavU73VivkImACpBPm/vNRWrLaXh97NvTPJ tlTmo6lC7m6KWqH6nkr4Lu+lsQiaKo/UzjQMlBdpw2nboyik9D55bTAnR gEJjSWcYabFe7ouo2XxaiuLz3gPkpOF3Fw+kuRnSue+Y6Ymjeg6dP/Hdc o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFACtrA1OtJXG9/2dsb2JhbABZgwY4V79QgRUWdIIlAQEBAwEBAQEkEzQbAgEINhAnCyUCBAESh30IDcttF44eaoQ4BJgsgTKQcYMtgio
X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="21264576"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 18 Feb 2014 14:20:44 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IEKixM031528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 14:20:44 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 08:20:44 -0600
From: "Prashanth Patil (praspati)" <praspati@cisco.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
Thread-Index: AQHPLLSbX79HGCj/7kO9PWHLSSzZLw==
Date: Tue, 18 Feb 2014 14:20:44 +0000
Message-ID: <CF2967C9.1DF0B%praspati@cisco.com>
References: <52FBF3A3.2070009@viagenie.ca>
In-Reply-To: <52FBF3A3.2070009@viagenie.ca>
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.65.47.252]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0E9E905B52A17646BAD60F88F764B48E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/xgC_5hCWMIZdFAeSDPI5Y7MILeQ
Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 14:20:52 -0000

Hi,

On 2/13/14 3:50 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:

>All,
>
>Here's my review...
>
>Summary: This draft contains major issues that need to be resolved
>before being sent to IESG.
>
>> 3.  IP Address Selection
>>=20
>>    These steps specify the behavior to be followed by the PCP client to
>>    contact a PCP server when the PCP client has multiple IP addresses
>>    for a single PCP server.
>
>How does the client know that those addresses belong to a single PCP
>server?

A PCP client, via DHCP for example, can learn a list of IP addresses for
the same PCP server and a list of unique PCP servers.
https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5


>
>Does this work when there are multiple addresses that belong to multiple
>PCP servers, or does it need to be a single server?

It works in both cases.

The draft first describes how a PCP client goes about contacting a PCP
server that has multiple addresses. The same steps are to be followed for
each unique PCP server learnt (each of which may again have multiple
addresses).

>From the draft:
"If several PCP servers are configured, each with multiple IP addresses,
the PCP client contacts all PCP servers in parallel following the steps
described above."


>
>Are we assuming that there is always a single PCP server per interface,
>and therefore all addresses can only belong to a single server by
>definition?

No, we're not making that assumption.


>
>>    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).
>
>This is wrong. You can't pick a source address based on the requested
>external address family. You can only pick the address family. For
>example, you can decide that you're going to use IPv6 to request an IPv6
>external address, but that does not help decide which source IPv6
>address you're going to use.

Agreed. What is currently described addresses PEER and MAP+FILTER cases
where source and destination IP addresses are known.
In case of MAP, what you say is right. For MAP, based on the address
family the client intends to listen on, the client makes an appropriate
request to each distinct server. We'll have to fix this.


>
>And this is even more fundamentally wrong. The address family of the PCP
>request depends on your internal address family, not the suggested
>external address family. If your server is listening on IPvX, you send
>your PCP request over IPvX. Otherwise you have to play games with
>THIRD_PARTY. The external address family has nothing to do with it.
>
>In fact, the source address you're going to select has to be one your
>server is listening on. Otherwise you'll have to play games with
>THIRD_PARTY. Often servers just listen on the wildcard address, so that
>does not help you pick one particular address, but if that's not the
>case then you don't have a choice.
>
>Finally, "Requested External IP Address" is not a PCP term. I think you
>mean "Suggested External IP Address".

Ok.

>
>>    2.  Whenever communicating with a PCP server, the rules of Section 6
>>        of [RFC6724] SHOULD be followed by using the source address
>>        selected in the previous step as input to the destination address
>>        selection algorithm.
>
>Step 1 did not yield a particular source address. It yielded an address
>family. You still need to pick a particular source address.
>
>>    3.  The PCP client initializes its Maximum Retransmission Count (MRC)
>>        to 4.
>>=20
>>    4.  The PCP client sends its PCP message to the PCP server's IP
>>        address following the retransmission procedure specified in
>>        Section 8.1.1 of [RFC6887].  If no response is received after MRC
>>        attempts, the PCP client re-tries the procedure excluding the
>>        destination addresses which did not respond.  The PCP client
>>        SHOULD ignore any response received from an IP address after
>>        exhausting MRC attempts for that particular IP address.  If, when
>>        sending PCP requests, the PCP client receives a hard ICMP error
>>        [RFC1122] it SHOULD immediately try the next IP address from the
>>        list of PCP server' IP addresses.
>>=20
>>    5.  If the PCP client has exhausted all IP addresses configured for a
>>        given PCP server, the procedure is repeated every fifteen minutes
>>        until the PCP request is successfully answered.
>>=20
>>    6.  Once the PCP client has successfully received a response from a
>>        PCP server's IP address, it sends subsequent PCP requests to the
>>        same server's IP address until that IP address becomes non-
>>        responsive, which causes the PCP client to follow the steps above
>>        to contact its PCP server.
>
>Do we reset the destination address set then? That is, are addresses
>that failed previously now potentially good again?

Yes, the client has to attempt contacting the servers again.


>
>> 4.  Multiple Interfaces
>>=20
>>    When an end host has multiple interfaces concurrently active (e.g.,
>>    IEEE 802.11 and 3G), a PCP client would discover different PCP
>>    servers over different interfaces.  A host may have multiple network
>>    interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently.
>>    Each PCP server learned MUST be associated with the interface via
>>    which it was learned.  Particularly, the PCP client relies on the
>>    source IP address of an outgoing PCP request to select which PCP
>>    server(s) to use.
>
>That last sentence would be wrong following my feedback to section 3.
>
>> 5.  Example: Multiple PCP servers on a Single Interface
>>=20
>>    Figure 1 depicts an example that is used to illustrate the server
>>    selection procedure specified in Section 3.
>>=20
>>                                ISP Network
>>                              |              |
>>        .........................................................
>>                              |              |        Subscriber Network
>>                      +-------+------+  +----+---------+
>>                      | PCP-Server-A |  | PCP-Server-B |
>>                      |              |  |              |
>>                      +-------+------+  +----+---------+
>>             192.0.2.1        |              |     198.51.100.1
>>             2001:db8:2222::1 |              |     2001:db8:3333::1
>>                              |              |
>>                              |              |
>>                       -------+--------------+-----------
>>                                      |
>>                                      |    203.0.113.0
>>                                      |    2001:db8:1111::1
>>                                  +---+---+
>>                                  | Host  |
>>                                  +-------+
>>=20
>>                                  Figure 1
>
>The PCP servers in this figure look like routers. To make things clearer:
>
>- Remove the connection from each PCP server to the ISP network.
>
>- Draw the "PCP-controlled device". That one would look like a router
>and would be sitting on the border between the subscriber network and
>the ISP network. Connect it to both PCP servers and the host. No need
>for addresses.
>
>Is there only one PCP-controlled device, or does each server control its
>own device?

Each server controls its own device. With this clarification, do you still
think the figure needs to be updated? The text below the figure
illustrates how the client goes about contacting the two distinct servers.


>
>>    The PCP client sends two PCP requests at the same time,
>
>Really? The algorithm from section 3 does not seem to allow parallel
>requests. I'm lost.

It does, as described in an earlier comment and the last paragraph of
http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3.
There are two potential scenarios. A single server having multiple
addresses AND multiple PCP servers itself. The draft tries to address both
scenarios. If this is unclear, we'll have to see how to re-organize to
make it more obvious.

-Prashanth


>
>>    the first to
>>    192.0.2.1 (corresponding to PCP-Server-A) and the second to
>>    198.51.100.1 (corresponding to PCP-Server-B).  The path to
>>    198.51.100.1 is working so a PCP response is received.  Because the
>>    path to 192.0.2.1 is broken, no PCP response is received.  The PCP
>>    client retries 4 times to elicit a response from 192.0.2.1 and
>>    finally gives up on that address and sends a PCP message to
>>    2001::db8:1111:1.  That path is working, and a response is received.
>>    Thereafter, the PCP client should continue using that responsive IP
>>    address for PCP-Server-A (2001:db8:1111::1).  In this particular
>>    case, it will have to use THIRD_PARTY option for IPv4 mappings.
>
>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 Tue Feb 18 06:28:17 2014
Return-Path: <simon.perreault@viagenie.ca>
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 F3B3D1A01D4 for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 06:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 Zrw55XJGAuOe for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 06:28:12 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD93A1A060E for <pcp@ietf.org>; Tue, 18 Feb 2014 06:28:11 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A46C94040D; Tue, 18 Feb 2014 09:28:08 -0500 (EST)
Message-ID: <53036DF8.9050003@viagenie.ca>
Date: Tue, 18 Feb 2014 09:28:08 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Prashanth Patil (praspati)" <praspati@cisco.com>,  "pcp@ietf.org" <pcp@ietf.org>
References: <52FBF3A3.2070009@viagenie.ca> <CF2967C9.1DF0B%praspati@cisco.com>
In-Reply-To: <CF2967C9.1DF0B%praspati@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/PwzDTo65MM-c-0TMCqXixjeHeME
Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 14:28:17 -0000

Le 2014-02-18 09:20, Prashanth Patil (praspati) a écrit :
>> How does the client know that those addresses belong to a single PCP
>> server?
> 
> A PCP client, via DHCP for example, can learn a list of IP addresses for
> the same PCP server and a list of unique PCP servers.
> https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5
> 
> 
>>
>> Does this work when there are multiple addresses that belong to multiple
>> PCP servers, or does it need to be a single server?
> 
> It works in both cases.
> 
> The draft first describes how a PCP client goes about contacting a PCP
> server that has multiple addresses. The same steps are to be followed for
> each unique PCP server learnt (each of which may again have multiple
> addresses).
> 
> From the draft:
> "If several PCP servers are configured, each with multiple IP addresses,
> the PCP client contacts all PCP servers in parallel following the steps
> described above."

Good. That makes sense.

>>>    6.  Once the PCP client has successfully received a response from a
>>>        PCP server's IP address, it sends subsequent PCP requests to the
>>>        same server's IP address until that IP address becomes non-
>>>        responsive, which causes the PCP client to follow the steps above
>>>        to contact its PCP server.
>>
>> Do we reset the destination address set then? That is, are addresses
>> that failed previously now potentially good again?
> 
> Yes, the client has to attempt contacting the servers again.

Ok. It would be nice to mention it explicitly.

>>> 5.  Example: Multiple PCP servers on a Single Interface
>>>
>>>    Figure 1 depicts an example that is used to illustrate the server
>>>    selection procedure specified in Section 3.
>>>
>>>                                ISP Network
>>>                              |              |
>>>        .........................................................
>>>                              |              |        Subscriber Network
>>>                      +-------+------+  +----+---------+
>>>                      | PCP-Server-A |  | PCP-Server-B |
>>>                      |              |  |              |
>>>                      +-------+------+  +----+---------+
>>>             192.0.2.1        |              |     198.51.100.1
>>>             2001:db8:2222::1 |              |     2001:db8:3333::1
>>>                              |              |
>>>                              |              |
>>>                       -------+--------------+-----------
>>>                                      |
>>>                                      |    203.0.113.0
>>>                                      |    2001:db8:1111::1
>>>                                  +---+---+
>>>                                  | Host  |
>>>                                  +-------+
>>>
>>>                                  Figure 1
>>
>> The PCP servers in this figure look like routers. To make things clearer:
>>
>> - Remove the connection from each PCP server to the ISP network.
>>
>> - Draw the "PCP-controlled device". That one would look like a router
>> and would be sitting on the border between the subscriber network and
>> the ISP network. Connect it to both PCP servers and the host. No need
>> for addresses.
>>
>> Is there only one PCP-controlled device, or does each server control its
>> own device?
> 
> Each server controls its own device. With this clarification, do you still
> think the figure needs to be updated?

Yes.

>>>    The PCP client sends two PCP requests at the same time,
>>
>> Really? The algorithm from section 3 does not seem to allow parallel
>> requests. I'm lost.
> 
> It does, as described in an earlier comment and the last paragraph of
> http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3.
> There are two potential scenarios. A single server having multiple
> addresses AND multiple PCP servers itself. The draft tries to address both
> scenarios. If this is unclear, we'll have to see how to re-organize to
> make it more obvious.

I think that would be necessary.

Thanks,
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 Tue Feb 18 08:40:20 2014
Return-Path: <repenno@cisco.com>
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 032E51A04D4 for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 08:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.049
X-Spam-Level: 
X-Spam-Status: No, score=-15.049 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.548, 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 x3xou1j29dhU for <pcp@ietfa.amsl.com>; Tue, 18 Feb 2014 08:40:17 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D41A0504 for <pcp@ietf.org>; Tue, 18 Feb 2014 08:40:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=732; q=dns/txt; s=iport; t=1392741614; x=1393951214; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mlKSC3AKUVD5YaXsnakN1ORsJm9foCEJYG7eELS1HT0=; b=CSQT08umTX9oAaD/XXiwTcz/ybAyY6XksncXGI1CVMZbT5XhCs4B/8Wv 4bITTxSQqjBfaDCEmWnOGiRHXMMUA+dGVkDs0Gr80DJyYF9x6K06Tmww7 1AkDx6iuMNmw4RK4B+wHtEagXrsmg/8sHOCT3Xhcreq1/ONcUY4CwpIO9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAHiMA1OtJXG8/2dsb2JhbABZgwY4V8BqFnSCLIELAYEAJwSIGA2ac7EdF5NABIkQjxyBMpBxgy2CKg
X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="304855417"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 18 Feb 2014 16:40:14 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGeEOG016970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Tue, 18 Feb 2014 16:40:14 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 10:40:14 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: PCP Working Group <pcp@ietf.org>
Thread-Topic: PCP Presentation Slots so far
Thread-Index: AQHPLMgYyqPqIEtprkClBlORpGNshw==
Date: Tue, 18 Feb 2014 16:40:13 +0000
Message-ID: <CF222CFB.904A%repenno@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.89.179]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <F31F47D2B3C08B4BA90E36279A291E21@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/1MtBDQBj6URcU6qPAomONH11piA
Subject: [pcp] PCP Presentation Slots so far
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 16:40:19 -0000

PCP Proxy =AD 20 minutes - Simon
http://tools.ietf.org/html/draft-ietf-pcp-proxy-05

PCP Authentication =AD 20 minutes =AD Dacheng
http://tools.ietf.org/html/draft-ietf-pcp-authentication-03

PCP Anycast =AD 10 minutes - Sebastian
http://tools.ietf.org/html/draft-ietf-pcp-anycast-01

PCP Extension for Third Party Authorization =AD 10min -Tiru
http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-02

PCP Tunnel ID Option =AD 10min =AD Rolf Winter
http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-00.

PCP Support for Multi-Homing/Egress NATs - 15mins - Zhangzhan (Channy)
No draft, but refer to:
http://tools.ietf.org/id/draft-penno-pcp-zones-01.txt
Also presentation sent to list on Feb 13th





From nobody Fri Feb 21 09:10:38 2014
Return-Path: <Internet-Drafts@ietf.org>
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 6DF461A0483; Fri, 21 Feb 2014 09:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] 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 EXdb24WG5p1H; Fri, 21 Feb 2014 09:10:34 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A85C1A02D0; Fri, 21 Feb 2014 09:10:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140221171034.15533.45654.idtracker@ietfa.amsl.com>
Date: Fri, 21 Feb 2014 09:10:34 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5LtSrLkwqd_3s2eeZbQPXtZ6-yo
Cc: pcp@ietf.org
Subject: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 17:10:36 -0000

--NextPart

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 Description Option
    Author(s)     : M. Boucadair, et al
    Filename      : draft-ietf-pcp-description-option
    Pages         : 6 
    Date          : 2014-02-21 
    
This document extends Port Control Protocol (PCP) with the ability to
   associate a description with a PCP-instantiated mapping.  It does so
   by defining a new DESCRIPTION option.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-description-option-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-pcp-description-option";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-02-21091034.I-D@ietf.org>


--NextPart--


From nobody Fri Feb 21 09:13:08 2014
Return-Path: <Internet-Drafts@ietf.org>
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 A51681A047E; Fri, 21 Feb 2014 09:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] 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 sqJA0nx2X8GX; Fri, 21 Feb 2014 09:13:03 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3E11A01BF; Fri, 21 Feb 2014 09:13:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140221171303.15533.4406.idtracker@ietfa.amsl.com>
Date: Fri, 21 Feb 2014 09:13:03 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/bTN4MP_iduOUpJky_DcXklHjt_o
Cc: pcp@ietf.org
Subject: [pcp] I-D ACTION:draft-ietf-pcp-nat64-prefix64-06.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 17:13:05 -0000

--NextPart

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         : Learning NAT64 PREFIX64s using Port Control Protocol (PCP)
    Author(s)     : M. Boucadair
    Filename      : draft-ietf-pcp-nat64-prefix64
    Pages         : 17 
    Date          : 2014-02-21 
    
   This document defines a new Port Control Protocol (PCP) option to
   learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to
   build IPv4-converted IPv6 addresses.  This option is needed for
   successful communications when IPv4 addresses are used in referrals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-nat64-prefix64-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-pcp-nat64-prefix64";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-02-21091303.I-D@ietf.org>


--NextPart--


From nobody Mon Feb 24 13:56:12 2014
Return-Path: <dthaler@microsoft.com>
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 6C8191A02BF for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 13:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level: 
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 aQ2GghL8Yos7 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 13:56:07 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC31A030A for <pcp@ietf.org>; Mon, 24 Feb 2014 13:56:06 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB596.namprd03.prod.outlook.com (10.255.93.36) with Microsoft SMTP Server (TLS) id 15.0.883.10; Mon, 24 Feb 2014 21:56:04 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Mon, 24 Feb 2014 21:56:04 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by	FEB 21
Thread-Index: Ac8kdjJMiw3eyGvqT6mQAxskuNkKaQNM833A
Date: Mon, 24 Feb 2014 21:56:03 +0000
Message-ID: <22358639d9584ae591dd272472d24993@BY2PR03MB412.namprd03.prod.outlook.com>
References: <8242767cd57c4b6c94759273739404b7@BY2PR03MB412.namprd03.prod.outlook.com>
In-Reply-To: <8242767cd57c4b6c94759273739404b7@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ee31::2]
x-forefront-prvs: 0132C558ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(51704005)(164054003)(479174003)(24454002)(377454003)(243025003)(13464003)(377424004)(74366001)(74316001)(93136001)(76786001)(76796001)(76576001)(74876001)(74706001)(95666003)(15202345003)(81542001)(81342001)(86362001)(94946001)(94316002)(93516002)(92566001)(80022001)(95416001)(86612001)(69226001)(33646001)(85306002)(15975445006)(87936001)(224313003)(224303002)(2656002)(87266001)(80976001)(19580405001)(19580395003)(83322001)(85852003)(81816001)(90146001)(56816005)(81686001)(79102001)(83072002)(47446002)(63696002)(4396001)(54356001)(76482001)(77982001)(59766001)(53806001)(54316002)(56776001)(51856001)(65816001)(46102001)(74502001)(50986001)(47976001)(49866001)(31966008)(74662001)(47736001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB596; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/1a6m0EO3Lu6C6fJ1fq3-3GsP-UI
Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by	FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 21:56:10 -0000

My comments are in the marked up copy at
http://research.microsoft.com/~dthaler/draft-ietf-pcp-server-selection-02.p=
df
Much of it is editorial-only.  A summary of the top technical feedback is b=
elow.

1) Relationship to RFC 6724 is confusing.  For a given server should be
     I) Construct set of *Candidate* Source Addresses based on app input an=
d
         constraints in the PCP base spec (e.g., for a PEER it should just =
contain the
         app session's source address).
     II) Sort list of destination addresses per RFC 6724 section 6

2) Should provide more guidance about when to use one vs multiple servers.
     I believe the best answer is that by default, the client needs to use =
all PCP
     servers that configure firewalls (i.e. external IP =3D=3D internal IP =
in mapping).
     When NATs are involved, then it is implementation specific... if the a=
pp can
     deal with multiple IPs then it can use multiple servers that return di=
fferent
     external IPs.

-Dave

> -----Original Message-----
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler
> Sent: Friday, February 7, 2014 6:35 PM
> To: pcp@ietf.org
> Subject: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due
> by FEB 21
>=20
> This email initiates a two-week Working Group Last Call on
> draft-ietf-pcp-server-selection-02 to conclude on Friday, February 21st.
> Please send comments to the list.
>=20
> As a reminder, when responding to a WGLC, what we chairs are looking for =
is
> a statement about document quality (not really about whether the
> mechanism should move forward).  That is, state whether you think the
> document is ready as is, or if not, what issues you see.
>=20
> Thanks,
> -Dave
>=20
> > -----Original Message-----
> > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil
> > (praspati)
> > Sent: Monday, January 6, 2014 8:52 AM
> > To: pcp@ietf.org
> > Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt
> >
> > Folks,
> > Revised PCP server selection draft has been published. The update
> > addresses comments received from Dave Thaler and the ones at IETF 88.
> >
> > -Prashanth
> >
> >
> > On 1/6/14 10:19 PM, "internet-drafts@ietf.org"
> > <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-02.txt
> > >	Pages           : 11
> > >	Date            : 2014-01-06
> > >
> > >Abstract:
> > >   Multiple IP addresses may be configured on a PCP client in some
> > >   deployment contexts such as multi-homing.  This document specifies
> > >   the behavior to be followed by the PCP client to contact its PCP
> > >   server(s) when one or several PCP server IP addresses are configure=
d.
> > >
> > >   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-02
> > >
> > >A diff from the previous version is available at:
> > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02
> > >
> > >
> > >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
> >
> > _______________________________________________
> > pcp mailing list
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp


From nobody Mon Feb 24 14:13:12 2014
Return-Path: <trac@tools.ietf.org>
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 427811A02C7 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 14:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 buIkDwWJoCzy for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 14:13:09 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 452FF1A028B for <pcp@ietf.org>; Mon, 24 Feb 2014 14:13:09 -0800 (PST)
Received: from localhost ([127.0.0.1]:57271 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI3lk-00082S-Au; Mon, 24 Feb 2014 23:13:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-server-selection@tools.ietf.org, hassnaa.moustafa@intel.com
X-Trac-Project: pcp
Date: Mon, 24 Feb 2014 22:13:00 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/66
Message-ID: <064.7b3a3e19faa89c6a5e8c0ab56fb13946@tools.ietf.org>
X-Trac-Ticket-ID: 66
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-server-selection@tools.ietf.org, hassnaa.moustafa@intel.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
Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, praspati@cisco.com,  repenno@cisco.com, tireddy@cisco.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/XYk5txXyVsgowNtH8q_IYCAYmjI
Cc: pcp@ietf.org
Subject: [pcp]  #66: server-selection comments from Hassnaa Moustafa
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 22:13:11 -0000

#66: server-selection comments from Hassnaa Moustafa

 There are few editorial comments on draft (draft-ietf-pcp-server-
 selection-02) as follows:
 1. The term IP address family used in the draft needs more text
 clarification (to say for example IPv4 or IPv6 or maybe other points that
 the authors have in mind).
 2. The IP addresses used in the diagram (in the example of Section 5) is
 not very consistent with the IP addresses mentioned in the text that
 explains the diagram.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-pcp-server-
  hassnaa.moustafa@intel.com         |  selection@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:  milestone1
Component:  server-selection         |    Version:  1.0
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/66>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 14:17:35 2014
Return-Path: <trac@tools.ietf.org>
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 56D2B1A02E1 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 14:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level: 
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] 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 o--ZpS4Oyhbt for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 14:17:32 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B95951A02D8 for <pcp@ietf.org>; Mon, 24 Feb 2014 14:17:31 -0800 (PST)
Received: from localhost ([127.0.0.1]:57568 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI3q2-0002oE-5J; Mon, 24 Feb 2014 23:17:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-server-selection@tools.ietf.org, simon.perreault@viagenie.ca
X-Trac-Project: pcp
Date: Mon, 24 Feb 2014 22:17:26 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/67
Message-ID: <065.afb63ecc150bcf708a7b04d61f012f95@tools.ietf.org>
X-Trac-Ticket-ID: 67
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-server-selection@tools.ietf.org, simon.perreault@viagenie.ca, 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
Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, praspati@cisco.com,  repenno@cisco.com, tireddy@cisco.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5Cq6uMMMtiXgBV0DVG0Bl4_NfyE
Cc: pcp@ietf.org
Subject: [pcp]  #67: Server selection feedback from Simon Perreault
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 22:17:34 -0000

#67: Server selection feedback from Simon Perreault

 > 3.  IP Address Selection
 >
 >    These steps specify the behavior to be followed by the PCP client to
 >    contact a PCP server when the PCP client has multiple IP addresses
 >    for a single PCP server.

 How does the client know that those addresses belong to a single PCP
 server?

 Does this work when there are multiple addresses that belong to multiple
 PCP servers, or does it need to be a single server?

 Are we assuming that there is always a single PCP server per interface,
 and therefore all addresses can only belong to a single server by
 definition?

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

 This is wrong. You can't pick a source address based on the requested
 external address family. You can only pick the address family. For
 example, you can decide that you're going to use IPv6 to request an IPv6
 external address, but that does not help decide which source IPv6 address
 you're going to use.

 And this is even more fundamentally wrong. The address family of the PCP
 request depends on your internal address family, not the suggested
 external address family. If your server is listening on IPvX, you send
 your PCP request over IPvX. Otherwise you have to play games with
 THIRD_PARTY. The external address family has nothing to do with it.

 In fact, the source address you're going to select has to be one your
 server is listening on. Otherwise you'll have to play games with
 THIRD_PARTY. Often servers just listen on the wildcard address, so that
 does not help you pick one particular address, but if that's not the case
 then you don't have a choice.

 Finally, "Requested External IP Address" is not a PCP term. I think you
 mean "Suggested External IP Address".

 >    2.  Whenever communicating with a PCP server, the rules of Section 6
 >        of [RFC6724] SHOULD be followed by using the source address
 >        selected in the previous step as input to the destination address
 >        selection algorithm.

 Step 1 did not yield a particular source address. It yielded an address
 family. You still need to pick a particular source address.

 >    3.  The PCP client initializes its Maximum Retransmission Count (MRC)
 >        to 4.
 >
 >    4.  The PCP client sends its PCP message to the PCP server's IP
 >        address following the retransmission procedure specified in
 >        Section 8.1.1 of [RFC6887].  If no response is received after MRC
 >        attempts, the PCP client re-tries the procedure excluding the
 >        destination addresses which did not respond.  The PCP client
 >        SHOULD ignore any response received from an IP address after
 >        exhausting MRC attempts for that particular IP address.  If, when
 >        sending PCP requests, the PCP client receives a hard ICMP error
 >        [RFC1122] it SHOULD immediately try the next IP address from the
 >        list of PCP server' IP addresses.
 >
 >    5.  If the PCP client has exhausted all IP addresses configured for a
 >        given PCP server, the procedure is repeated every fifteen minutes
 >        until the PCP request is successfully answered.
 >
 >    6.  Once the PCP client has successfully received a response from a
 >        PCP server's IP address, it sends subsequent PCP requests to the
 >        same server's IP address until that IP address becomes non-
 >        responsive, which causes the PCP client to follow the steps above
 >        to contact its PCP server.

 Do we reset the destination address set then? That is, are addresses that
 failed previously now potentially good again?

 > 4.  Multiple Interfaces
 >
 >    When an end host has multiple interfaces concurrently active (e.g.,
 >    IEEE 802.11 and 3G), a PCP client would discover different PCP
 >    servers over different interfaces.  A host may have multiple network
 >    interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently.
 >    Each PCP server learned MUST be associated with the interface via
 >    which it was learned.  Particularly, the PCP client relies on the
 >    source IP address of an outgoing PCP request to select which PCP
 >    server(s) to use.

 That last sentence would be wrong following my feedback to section 3.

 {{{
 > 5.  Example: Multiple PCP servers on a Single Interface
 >
 >    Figure 1 depicts an example that is used to illustrate the server
 >    selection procedure specified in Section 3.
 >
 >                                ISP Network
 >                              |              |
 >        .........................................................
 >                              |              |        Subscriber Network
 >                      +-------+------+  +----+---------+
 >                      | PCP-Server-A |  | PCP-Server-B |
 >                      |              |  |              |
 >                      +-------+------+  +----+---------+
 >             192.0.2.1        |              |     198.51.100.1
 >             2001:db8:2222::1 |              |     2001:db8:3333::1
 >                              |              |
 >                              |              |
 >                       -------+--------------+-----------
 >                                      |
 >                                      |    203.0.113.0
 >                                      |    2001:db8:1111::1
 >                                  +---+---+
 >                                  | Host  |
 >                                  +-------+
 >
 >                                  Figure 1
 }}}

 The PCP servers in this figure look like routers. To make things clearer:

 - Remove the connection from each PCP server to the ISP network.

 - Draw the "PCP-controlled device". That one would look like a router and
 would be sitting on the border between the subscriber network and the ISP
 network. Connect it to both PCP servers and the host. No need for
 addresses.

 Is there only one PCP-controlled device, or does each server control its
 own device?

 >    The PCP client sends two PCP requests at the same time,

 Really? The algorithm from section 3 does not seem to allow parallel
 requests. I'm lost.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-pcp-server-
  simon.perreault@viagenie.ca        |  selection@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  server-selection         |    Version:  1.0
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/67>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 14:19:58 2014
Return-Path: <trac@tools.ietf.org>
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 7D0A41A02E1 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 14:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 wW6pC7jmD7Tp for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 14:19:56 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F23211A02D8 for <pcp@ietf.org>; Mon, 24 Feb 2014 14:19:55 -0800 (PST)
Received: from localhost ([127.0.0.1]:57743 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI3sN-0004gY-Tr; Mon, 24 Feb 2014 23:19:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-server-selection@tools.ietf.org, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Mon, 24 Feb 2014 22:19:51 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/68
Message-ID: <059.8c54e37692f360ec6114d97c4ee4c134@tools.ietf.org>
X-Trac-Ticket-ID: 68
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-server-selection@tools.ietf.org, dthaler@microsoft.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
Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, praspati@cisco.com,  repenno@cisco.com, tireddy@cisco.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/WlXAfcg3MtxF6zt-pMSD7VhNj2Q
Cc: pcp@ietf.org
Subject: [pcp]  #68: Server selection feedback from Dave Thaler
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 22:19:57 -0000

#68: Server selection feedback from Dave Thaler

 My comments are in the marked up copy at
 http://research.microsoft.com/~dthaler/draft-ietf-pcp-server-
 selection-02.pdf
 Much of it is editorial-only.  A summary of the top technical feedback is
 below.

 1) Relationship to RFC 6724 is confusing.  For a given server should be
      I) Construct set of *Candidate* Source Addresses based on app input
 and constraints in the PCP base spec (e.g., for a PEER it should just
 contain the app session's source address).
      II) Sort list of destination addresses per RFC 6724 section 6

 2) Should provide more guidance about when to use one vs multiple servers.
      I believe the best answer is that by default, the client needs to use
 all PCP
      servers that configure firewalls (i.e. external IP == internal IP in
 mapping).
      When NATs are involved, then it is implementation specific... if the
 app can
      deal with multiple IPs then it can use multiple servers that return
 different
      external IPs.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-server-
  dthaler@microsoft.com  |  selection@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:  milestone1
Component:  server-      |    Version:  1.0
  selection              |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/68>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 17:51:37 2014
Return-Path: <dthaler@microsoft.com>
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 120EC1A0235 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 17:51:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.703
X-Spam-Level: 
X-Spam-Status: No, score=-100.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 6gaDUFvNMr3N for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 17:51:32 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 014891A0393 for <pcp@ietf.org>; Mon, 24 Feb 2014 17:51:31 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB596.namprd03.prod.outlook.com (10.255.93.36) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 01:51:23 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 01:51:23 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: Comments on draft-ietf-pcp-port-set-04.txt
Thread-Index: Ac8xy+Mq/8nkmFJKT/e9FgA8BKMzaA==
Date: Tue, 25 Feb 2014 01:51:12 +0000
Message-ID: <8c6c79ff7a7a4886bca7e9b5e2ed4bce@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ed43::2]
x-forefront-prvs: 01334458E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(51704005)(24454002)(377424004)(74366001)(74316001)(93136001)(76786001)(76796001)(76576001)(76176001)(74876001)(74706001)(86362001)(81542001)(81342001)(93516002)(94946001)(94316002)(92566001)(80022001)(95416001)(86612001)(69226001)(33646001)(85306002)(87936001)(2656002)(87266001)(81816001)(80976001)(83322001)(85852003)(56816005)(90146001)(81686001)(79102001)(83072002)(47446002)(63696002)(4396001)(54356001)(76482001)(77982001)(59766001)(53806001)(54316002)(56776001)(51856001)(65816001)(46102001)(74502001)(50986001)(47976001)(49866001)(31966008)(74662001)(47736001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB596; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:EE21D0D5.9AC253D5.F0D2317B.5EE4D141.20692; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="windows-1257"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Wuqf3VelAAe59MtjyH4rIsQrkRA
Subject: [pcp] Comments on draft-ietf-pcp-port-set-04.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 01:51:35 -0000

Reviewing -04 and comparing it with the thread below... see inline.

Simon Perreault wrote:
> Thanks a lot for the review! I'll be sure to incorporate your comments in=
to a
> new revision shortly after the gates reopen.
>=20
> Le 2013-10-30 18:33, Dave Thaler a =E9crit :
> > 1) The claim that a port set makes code simpler needs an explanation to
> justify it.
> > E.g., if an app really needs 16 ports, and it fails to get 16 back in
> > its first request, it still has to handle that and say make multiple se=
parate
> requests.
>=20
> Two observations:
>=20
> - Wouldn't that behaviour be a tiny bit evil? It reminds me of applicatio=
ns that
> create multiple flows in an attempt to trick an SFQ-based QoS into alloca=
ting
> them more bandwidth.
>=20
> - Often, apps that ask for N ports don't really need N ports. Ideally the=
y
> would like to get N ports, but they can live with <N ports. No need for s=
ingle-
> port fallback in that case.
>=20
> > So if it already has to have
> > code to deal with multiple separate requests, why is it simpler to add
> > port set functionality to and implement both?  This seems counter-intui=
tive
> to a reader.
>=20
> That would only apply to apps that absolutely need N ports to function, a=
nd
> don't need them to be contiguous. Those apps need to fall back on single-
> port requests as you describe. But I would argue that these apps are real=
ly
> quite rare.
>=20
> We can add text describing these concerns in the next revision.

Sure, but the claim in section 2 is that the client side logic *is* simpler=
.
Not "often" simpler, or "may be simpler".   You can=92t assert this when=20
sections 6.4 and 6.3 both leave some major questions up to the=20
implementation.  So it might be more complicated not simpler.  Suggest=20
just deleting the "Client-side simplicity" bullet.

The text added in section 6.4 looks fine to me, except for one editorial
suggestion on this text:
> Suppose a PCP client asks for 16 ports and receives 8.  What should
>   it do?  Should it consider this a final answer?  Should it try a
>   second request, asking for 8 more ports?  Should it fall back to 8
>   individual MAP requests?  This document does not try to answer those
>   questions , but describes issues to be considered when doing so.

Suggest changing last sentence to
"This document leaves the answers to be implementation-specific,
but describes issues to be considered when answering them."

That is, it answers them by saying it's implementation-specific.


> > 2) Text on overlapping ranges needs more detail.  Is it legal for a
> > client to send requests for overlapping ranges in parallel or not?  I
> > ask because this was an attack vector for IP reassembly so can imagine
> > we need the precision here to avoid similar attacks.  This might have a=
n
> impact on the Security Considerations section.
>=20
> Hmmm... interesting. I see now that those requests would not be
> idempotent, contrary to single-port MAP requests. The first one to be
> processed by the server would "win". Responses to each request would
> depend on which one has won.
>=20
> I don't see an attack here, but the lack of idempotence bugs me. I don't =
quite
> know what action to take here except describe the situation in the next
> revision.

Yes, Section 6.3 now looks fine to me, except for a typo:
> which port set mapping requests would be arbitrated,  Alternatively,

Change first comma to period.

> > 3) The unstated assumption in section 5.3 seems to be that the client
> > can reuse the same mapping nonce in all independent requests that it
> wants to refresh as a block, is that right?
>=20
> Right.
>=20
> > Let's say internal port 100 and 110 both have the same mapping nonce,
> > and internal port 105 has a different mapping nonce (e.g., from a diffe=
rent
> PCP client on the same host).
> > If the first PCP client sends a refresh for port 100, Port Set Size =3D
> > 11, what would the effect be at the PCP server?
>=20
> Assuming the request nonce matches the nonce of the mapping at port 100,
> then:
>=20
> - The mapping at port 100 would be refreshed.
>=20
> - The mapping at port 110 would not be refreshed, but its remaining lifet=
ime
> would be returned by the server, as described in draft-cheshire-pcp-unsup=
p-
> family. The response's nonce would be copied from the request's nonce.
>=20
> If you agree that this is how it should be, I'll add this to the example =
section.
> However, that would depend on keeping the normative reference to
> unsupp-family (see point 5 below).

We agreed to not have a normative reference to unsupp-family, but I don't
want this to get lost.  Was any change to the port-set document made?
Should there be an example in the unsupp-family draft, or what?


> > 4) Section 4.1 says if the response does not include a PORT_SET, in a
> > response it assumes the server doesn't support it, and sends individual
> MAP requests for the rest of the ports it needs.
> > But section 4.2 says if the server does support PORT_SET but can only
> > return 1 in its first response, It must omit the PORT_SET option.  I th=
ink
> that's wrong since it will confuse the client as noted above.
> > If it's included with a Port Set Size of 1, the client knows it can
> > keep trying using PORT_SET for subsequent blocks, which might get more
> than 1 port in each response.
>=20
> Agreed. I'll modify the draft accordingly unless others disagree.

I expected the draft to be modified accordingly as I didn't see any disagre=
ement
on the list or in the meeting notes (let me know if I missed something).
However a different change was made to the draft which I think isn't as goo=
d.

Specifically, per the "Agreed" above, I expected it to say the server will
return a port set option with size of 1, and the client then knows the serv=
er
supports port-sets and can choose to ask for another port-set if it wants.
And if the response has no port-set option, then it knows the server doesn'=
t
support it and can send other requests accordingly.

Instead, -04 changed to keep the statement:
>   If the PCP server ends up mapping only a single port, for any reason,
>   the PORT_SET option MUST NOT be present in the response.

And instead added this text:
> If no PORT_SET option is present in the response, the PCP client
>   cannot conclude that the PCP server does not support the PORT_SET
>   option.  It may just be that the PCP server does support PORT_SET but
>   decided to allocate only a single port, for reasons that are its own.
>   If the client wishes to obtain more ports, it MAY send additional MAP
>   requests (see Section 6.4),

I didn't see it explained why this is better than what I thought we agreed
to on the list.

=20
> > 5) If we want this to go to RFC soon, we need to remove normative
> > references to non-RFCs (and this is easy, I suggested text), but I
> > think we should also remove informative references to individual
> > drafts (i.e., drafts that aren't currently WG drafts in any WG), and in=
stead
> only reference in the reverse direction; those other drafts should refere=
nce
> this one instead of the other way around.
>=20
> AFAIK, informative references don't prevent publishing as an RFC. So I'll
> focus on normative references.
>=20
> I'll remove the reference to draft-boucadair-pcp-failure unless others
> disagree.
>=20
> About draft-cheshire-pcp-unsupp-family: we could remove the reference
> and let the document stand on its own. The new example showing the effect
> of nonce checking multiple mappings with differing nonces would be added
> to draft-cheshire.
>=20
> As an aside: the example in section "5.2 Stateless Mapping Discovery" is =
not
> specific to draft-tsou-stateless-nat44. It is intended to illustrate how
> discovery is done generically without the client knowing the kind of stat=
eless
> NAT it is speaking to. In fact, if the NAT in that example had been one
> implementing draft-tsou, the numbers would have been different.
> Therefore I suggest keeping the example.

I'm fine with that part, thanks.

-Dave


From nobody Mon Feb 24 18:00:23 2014
Return-Path: <dthaler@microsoft.com>
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 9FE3C1A02F2 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level: 
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Q8ESo5kl0e-M for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:00:19 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id D36731A0236 for <pcp@ietf.org>; Mon, 24 Feb 2014 18:00:18 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 02:00:16 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 02:00:13 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "draft-ietf-pcp-port-set@tools.ietf.org" <draft-ietf-pcp-port-set@tools.ietf.org>
Thread-Topic: IETF 88 notes for draft-ietf-pcp-port-set-04
Thread-Index: Ac8xzUhiSfXY0tZASTK1+6aFvdMunQ==
Date: Tue, 25 Feb 2014 02:00:07 +0000
Message-ID: <c27dba04300d4f0cb9f6c0b467839ad0@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ed43::2]
x-forefront-prvs: 01334458E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(54316002)(76482001)(15975445006)(81686001)(56776001)(85306002)(81816001)(74706001)(74876001)(76796001)(81542001)(80976001)(95416001)(80022001)(54356001)(86362001)(46102001)(53806001)(51856001)(83072002)(85852003)(92566001)(94946001)(56816005)(19580395003)(83322001)(90146001)(74366001)(94316002)(74316001)(76786001)(79102001)(65816001)(2656002)(74662001)(93516002)(87936001)(77982001)(59766001)(4396001)(81342001)(31966008)(76176001)(33646001)(86612001)(93136001)(47976001)(50986001)(49866001)(47736001)(15202345003)(76576001)(69226001)(63696002)(74502001)(87266001)(47446002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:7E3AD1D4.8C2065CF.49F2517D.84E91959.201DE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/4ieTgKUjtpGcv50cBS37L9_5kyI
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: [pcp] IETF 88 notes for draft-ietf-pcp-port-set-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:00:21 -0000

>From the IETF 88 meeting notes (http://www.ietf.org/proceedings/88/minutes/=
minutes-88-pcp)

[...]
> Dave Thaler suggested that if port-set capability is added (or removed),
> the PCP server can reset its Epoch to zero, which causes PCP client to=20
> re-try using PORT_SET. New text is needed in the document for those thing=
s.
> [See also discussion in the Jabber log.]

I don't see this in draft -04.

[...]
> Simon: Possible to get multiple responses to a single request.
> Dan: Add to Security Considerations.
> Dan: If I'm missing one response out of the set, have to re-send request.
> Dave: Need to know nonce, so this can still be an on-path attack.

I don't see this in draft -04.

[...]
> Dan: Server can be upgraded/changed to support/not support PORT_SET.
>     Is there any harm to always request PORT_SET?
> Dave: If I get an indication that the server doesn't currently support
>      PORT_SET, I'll send multiple requests in parallel.

This is related to the issue in the other thread (the follow-up to -03).
The text to address that should just keep the above in mind.

-Dave


From nobody Mon Feb 24 18:34:52 2014
Return-Path: <dthaler@microsoft.com>
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 1E45E1A039B for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level: 
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 cWuc4RO6BTRF for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:34:46 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id 864D41A0389 for <pcp@ietf.org>; Mon, 24 Feb 2014 18:34:46 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB597.namprd03.prod.outlook.com (10.255.93.37) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 02:34:43 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 02:34:44 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: 1 week last call on draft-ietf-pcp-dhcp-09
Thread-Index: Ac8x0W0A6P90LzsJSXOKAFBdPQrjcw==
Date: Tue, 25 Feb 2014 02:34:43 +0000
Message-ID: <a97532a3e6964630ab6cb9e92091e5a8@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 01334458E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(92566001)(87936001)(95416001)(86612001)(83322001)(19580395003)(56816005)(80976001)(83072002)(85852003)(94946001)(90146001)(93516002)(93136001)(65816001)(94316002)(49866001)(47736001)(47976001)(50986001)(54316002)(56776001)(76482001)(31966008)(81686001)(81816001)(2656002)(74662001)(87266001)(74502001)(47446002)(54356001)(51856001)(53806001)(4396001)(46102001)(85306002)(15975445006)(63696002)(77982001)(59766001)(74876001)(79102001)(74706001)(76176001)(76576001)(76786001)(19300405004)(76796001)(69226001)(81542001)(81342001)(80022001)(86362001)(33646001)(74316001)(16236675002)(74366001)(15202345003)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB597; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:B6CB7EB2.9D1087EB.715D7FEB.84E9DEB9.201B1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/7ywJ79LJmHUr1c-0lk2U3mKzfPo
Subject: [pcp] 1 week last call on draft-ietf-pcp-dhcp-09
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:34:51 -0000

--_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As we reported in the IETF 88 meeting, the DHCP document previously
went through 2 WGLCs, with -08 being the version that was updated to
reflect WG consensus and AD feedback.  The document shepherd (me)
reviewed -08 and agreed that all technical issues had been addressed and
found only editorial issues, which resulted in -09 posted shortly before
the PCP meeting at IETF 88.  Per the meeting notes there were no
objections to starting a short WGLC to let anyone else review -09 before
submitting to the IESG.

Hence this email is a notice that we intend to submit draft-ietf-pcp-dhcp-0=
9
to the IESG for publication as a Proposed Standard in approximately
1 week from today (i.e., before the PCP meeting on the Wednesday
of IETF) unless we hear any objections by end of day Monday March 3rd.

-Dave

--_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">As we reported in the IETF 88 meeting, the DHCP docu=
ment previously<o:p></o:p></p>
<p class=3D"MsoNormal">went through 2 WGLCs, with -08 being the version tha=
t was updated to<o:p></o:p></p>
<p class=3D"MsoNormal">reflect WG consensus and AD feedback.&nbsp; The docu=
ment shepherd (me)<o:p></o:p></p>
<p class=3D"MsoNormal">reviewed -08 and agreed that all technical issues ha=
d been addressed and<o:p></o:p></p>
<p class=3D"MsoNormal">found only editorial issues, which resulted in -09 p=
osted shortly before<o:p></o:p></p>
<p class=3D"MsoNormal">the PCP meeting at IETF 88.&nbsp; Per the meeting no=
tes there were no
<o:p></o:p></p>
<p class=3D"MsoNormal">objections to starting a short WGLC to let anyone el=
se review -09 before<o:p></o:p></p>
<p class=3D"MsoNormal">submitting to the IESG.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hence this email is a notice that we intend to submi=
t draft-ietf-pcp-dhcp-09<o:p></o:p></p>
<p class=3D"MsoNormal">to the IESG for publication as a Proposed Standard i=
n approximately<o:p></o:p></p>
<p class=3D"MsoNormal">1 week from today (i.e., before the PCP meeting on t=
he Wednesday<o:p></o:p></p>
<p class=3D"MsoNormal">of IETF) unless we hear any objections by end of day=
 Monday March 3<sup>rd</sup>.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">-Dave<o:p></o:p></p>
</div>
</body>
</html>

--_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_--


From nobody Mon Feb 24 18:42:28 2014
Return-Path: <trac@tools.ietf.org>
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 17D281A022A for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 k1Ou7dTfj1p0 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:42:24 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 633451A0221 for <pcp@ietf.org>; Mon, 24 Feb 2014 18:42:24 -0800 (PST)
Received: from localhost ([127.0.0.1]:40928 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI7yF-0006XK-HQ; Tue, 25 Feb 2014 03:42:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 02:42:11 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/69
Message-ID: <059.3374a8816348b43c84919b7b9ca03a7f@tools.ietf.org>
X-Trac-Ticket-ID: 69
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.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
Resent-To: cathy.zhou@huawei.com, mohamed.boucadair@orange.com, simon.perreault@viagenie.ca, ssenthil@cisco.com, sunqiong@ctbri.com.cn, tina.tsou.zouting@huawei.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/alRIpjZmxj-rV28GdECorg_6gWc
Cc: pcp@ietf.org
Subject: [pcp]  #69: Dave Thaler comments on draft-ietf-pcp-port-set-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:42:27 -0000

#69: Dave Thaler comments on draft-ietf-pcp-port-set-04

 > Le 2013-10-30 18:33, Dave Thaler a écrit :
 > > 1) The claim that a port set makes code simpler needs an explanation
 > > to
 > justify it.
 > > E.g., if an app really needs 16 ports, and it fails to get 16 back
 > > in its first request, it still has to handle that and say make
 > > multiple separate
 > requests.
 >
 > Two observations:
 >
 > - Wouldn't that behaviour be a tiny bit evil? It reminds me of
 > applications that create multiple flows in an attempt to trick an
 > SFQ-based QoS into allocating them more bandwidth.
 >
 > - Often, apps that ask for N ports don't really need N ports. Ideally
 > they would like to get N ports, but they can live with <N ports. No
 > need for single- port fallback in that case.
 >
 > > So if it already has to have
 > > code to deal with multiple separate requests, why is it simpler to
 > > add port set functionality to and implement both?  This seems
 > > counter-intuitive
 > to a reader.
 >
 > That would only apply to apps that absolutely need N ports to
 > function, and don't need them to be contiguous. Those apps need to
 > fall back on single- port requests as you describe. But I would argue
 > that these apps are really quite rare.
 >
 > We can add text describing these concerns in the next revision.

 Sure, but the claim in section 2 is that the client side logic *is*
 simpler.
 Not "often" simpler, or "may be simpler".   You can’t assert this when
 sections 6.4 and 6.3 both leave some major questions up to the
 implementation.  So it might be more complicated not simpler.  Suggest
 just deleting the "Client-side simplicity" bullet.

 The text added in section 6.4 looks fine to me, except for one editorial
 suggestion on this text:
 > Suppose a PCP client asks for 16 ports and receives 8.  What should
 >   it do?  Should it consider this a final answer?  Should it try a
 >   second request, asking for 8 more ports?  Should it fall back to 8
 >   individual MAP requests?  This document does not try to answer those
 >   questions , but describes issues to be considered when doing so.

 Suggest changing last sentence to
 "This document leaves the answers to be implementation-specific, but
 describes issues to be considered when answering them."

 That is, it answers them by saying it's implementation-specific.

 [...]
 Section 6.3 now looks fine to me, except for a typo:
 > which port set mapping requests would be arbitrated,  Alternatively,

 Change first comma to period.


 > > 4) Section 4.1 says if the response does not include a PORT_SET, in
 > > a response it assumes the server doesn't support it, and sends
 > > individual
 > MAP requests for the rest of the ports it needs.
 > > But section 4.2 says if the server does support PORT_SET but can
 > > only return 1 in its first response, It must omit the PORT_SET
 > > option.  I think
 > that's wrong since it will confuse the client as noted above.
 > > If it's included with a Port Set Size of 1, the client knows it can
 > > keep trying using PORT_SET for subsequent blocks, which might get
 > > more
 > than 1 port in each response.
 >
 > Agreed. I'll modify the draft accordingly unless others disagree.

 I expected the draft to be modified accordingly as I didn't see any
 disagreement on the list or in the meeting notes (let me know if I missed
 something).
 However a different change was made to the draft which I think isn't as
 good.

 Specifically, per the "Agreed" above, I expected it to say the server will
 return a port set option with size of 1, and the client then knows the
 server supports port-sets and can choose to ask for another port-set if it
 wants.
 And if the response has no port-set option, then it knows the server
 doesn't support it and can send other requests accordingly.

 Instead, -04 changed to keep the statement:
 >   If the PCP server ends up mapping only a single port, for any reason,
 >   the PORT_SET option MUST NOT be present in the response.

 And instead added this text:
 > If no PORT_SET option is present in the response, the PCP client
 >   cannot conclude that the PCP server does not support the PORT_SET
 >   option.  It may just be that the PCP server does support PORT_SET but
 >   decided to allocate only a single port, for reasons that are its own.
 >   If the client wishes to obtain more ports, it MAY send additional MAP
 >   requests (see Section 6.4),

 I didn't see it explained why this is better than what I thought we agreed
 to on the list.

 Also related to the above is the following from IETF 88 meeting minutes:
 > Dan: Server can be upgraded/changed to support/not support PORT_SET.
 >     Is there any harm to always request PORT_SET?
 > Dave: If I get an indication that the server doesn't currently support
 >      PORT_SET, I'll send multiple requests in parallel.

 Just keep the above in mind when addressing the earlier issue.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-port-
  dthaler@microsoft.com  |  set@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:  milestone1
Component:  port-set     |    Version:  1.0
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/69>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 18:43:17 2014
Return-Path: <trac@tools.ietf.org>
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 0E4941A0221 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 tEH5YnX0M1og for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:43:14 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 789B31A022A for <pcp@ietf.org>; Mon, 24 Feb 2014 18:43:14 -0800 (PST)
Received: from localhost ([127.0.0.1]:40948 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI7z8-0001mu-4S; Tue, 25 Feb 2014 03:43:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 02:43:06 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/70
Message-ID: <059.9c890c190a530694044ddc4e563b8d72@tools.ietf.org>
X-Trac-Ticket-ID: 70
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.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
Resent-To: cathy.zhou@huawei.com, mohamed.boucadair@orange.com, simon.perreault@viagenie.ca, ssenthil@cisco.com, sunqiong@ctbri.com.cn, tina.tsou.zouting@huawei.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/wDpKTZH7dyNR6nfgyfdomxuuWBY
Cc: pcp@ietf.org
Subject: [pcp] #70: IETF 88 meeting feedback on draft-ietf-pcp-port-set-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:43:16 -0000

#70: IETF 88 meeting feedback on draft-ietf-pcp-port-set-04

 From the IETF 88 meeting notes
 (http://www.ietf.org/proceedings/88/minutes/minutes-88-pcp)

 [...]
 > Dave Thaler suggested that if port-set capability is added (or
 > removed), the PCP server can reset its Epoch to zero, which causes PCP
 > client to re-try using PORT_SET. New text is needed in the document for
 those things.
 > [See also discussion in the Jabber log.]

 I don't see this in draft -04.

 [...]
 > Simon: Possible to get multiple responses to a single request.
 > Dan: Add to Security Considerations.
 > Dan: If I'm missing one response out of the set, have to re-send
 request.
 > Dave: Need to know nonce, so this can still be an on-path attack.

 I don't see this in draft -04.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-port-
  dthaler@microsoft.com  |  set@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:  milestone1
Component:  port-set     |    Version:  1.0
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/70>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 18:50:22 2014
Return-Path: <trac@tools.ietf.org>
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 6ED071A025D for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 6upE3lS4F4Nm for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:50:18 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F21161A024C for <pcp@ietf.org>; Mon, 24 Feb 2014 18:50:17 -0800 (PST)
Received: from localhost ([127.0.0.1]:41228 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI862-0002Yf-C2; Tue, 25 Feb 2014 03:50:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: dwing@cisco.com, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 02:50:14 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/26#comment:2
Message-ID: <106.547968bb11cef77fd6e80e0207e20c7f@tools.ietf.org>
References: <091.f83f0cafe2719b6da7df8493705ab75f@tools.ietf.org>
X-Trac-Ticket-ID: 26
In-Reply-To: <091.f83f0cafe2719b6da7df8493705ab75f@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.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/Yjd-B2MFbycCFqdxwYFHXIe4Ais
Cc: pcp@ietf.org
Subject: Re: [pcp] #26: Firewall detection
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:50:19 -0000

#26: Firewall detection

Changes (by dthaler@microsoft.com):

 * component:  PCP server discovery => Extensions


-- 
-------------------------------------------------+-------------------------
 Reporter:  mohamed.boucadair@orange-            |       Owner:
  ftgroup.com; dwing@cisco.com                   |      Status:  new
     Type:  enhancement                          |   Milestone:
 Priority:  major                                |     Version:
Component:  Extensions                           |  Resolution:
 Severity:  Active WG Document                   |
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/26#comment:2>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 18:53:17 2014
Return-Path: <trac@tools.ietf.org>
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 D79241A025E for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:53:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 jH14nG4ChOvj for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:53:14 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3456D1A025D for <pcp@ietf.org>; Mon, 24 Feb 2014 18:53:14 -0800 (PST)
Received: from localhost ([127.0.0.1]:41891 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI88l-0003DZ-2X; Tue, 25 Feb 2014 03:53:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com, cheshire@apple.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 02:53:02 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:7
Message-ID: <074.0665c2dd32c6f8eb09aeda462f9408fe@tools.ietf.org>
References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org>
X-Trac-Ticket-ID: 49
In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com,  cheshire@apple.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
Resent-To: cheshire@apple.com, dwing@cisco.com, mohamed.boucadair@orange.com,  pselkirk@isc.org, repenno@cisco.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5lasA8cX0IznNgNHBxKprTmQmiE
Cc: pcp@ietf.org
Subject: Re: [pcp] #49: Multihoming confusion
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:53:16 -0000

#49: Multihoming confusion

Changes (by dthaler@microsoft.com):

 * component:  base => server-selection


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-pcp-base@tools.ietf.org
  dthaler@microsoft.com  |      Status:  reopened
     Type:  defect       |   Milestone:
 Priority:  major        |     Version:
Component:  server-      |  Resolution:
  selection              |
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:7>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 18:53:37 2014
Return-Path: <trac@tools.ietf.org>
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 647401A024C for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 cS_UTJUdjWI2 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:53:35 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 198281A03BE for <pcp@ietf.org>; Mon, 24 Feb 2014 18:53:35 -0800 (PST)
Received: from localhost ([127.0.0.1]:41919 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI89C-0003Pe-5i; Tue, 25 Feb 2014 03:53:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: dwing@cisco.com, dthaler@microsoft.com, tena@huawei.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 02:53:30 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/13#comment:5
Message-ID: <068.e1892b18ac74380890c8391664064e3b@tools.ietf.org>
References: <053.a0bcfe3bfc790d5de6e2861c6c3677b6@tools.ietf.org>
X-Trac-Ticket-ID: 13
In-Reply-To: <053.a0bcfe3bfc790d5de6e2861c6c3677b6@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, tena@huawei.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/n1SfR18PxeM1G1zB4tp1kAaCH68
Cc: pcp@ietf.org
Subject: Re: [pcp] #13: DS-lite interaction
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:53:36 -0000

#13: DS-lite interaction

Changes (by dthaler@microsoft.com):

 * component:  base => dslite


-- 
--------------------------------+------------------
 Reporter:  dwing@cisco.com     |       Owner:
     Type:  enhancement         |      Status:  new
 Priority:  major               |   Milestone:
Component:  dslite              |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/13#comment:5>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 18:59:21 2014
Return-Path: <trac@tools.ietf.org>
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 C69C21A03D6 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 m-RXoe2AuQJv for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 18:59:16 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5091A03E9 for <pcp@ietf.org>; Mon, 24 Feb 2014 18:59:12 -0800 (PST)
Received: from localhost ([127.0.0.1]:42456 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI8Ee-0002Dy-4C; Tue, 25 Feb 2014 03:59:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: dwing@cisco.com, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 02:59:07 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4
Message-ID: <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org>
References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org>
X-Trac-Ticket-ID: 34
In-Reply-To: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.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/S2CeUCO0ZG1WZmdbnnuvmY6NX4E
Cc: pcp@ietf.org
Subject: Re: [pcp] #34: notify NAT WAN address changed
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 02:59:18 -0000

#34: notify NAT WAN address changed

Changes (by dthaler@microsoft.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This was addressed in RFC 6887.  Section 14.2 begins:
 > 14.2.  PCP Mapping Update
 >
 >   This rapid recovery mechanism is used when the PCP server remembers
 >   its state and determines its existing mappings are invalid (e.g., IP
 >   renumbering changes the external IP address of a PCP-controlled NAT).

-- 
--------------------------------------------------+---------------------
 Reporter:  mohamed.boucadair@orange-ftgroup.com  |       Owner:
     Type:  enhancement                           |      Status:  closed
 Priority:  minor                                 |   Milestone:
Component:  Extensions                            |     Version:
 Severity:  -                                     |  Resolution:  fixed
 Keywords:                                        |
--------------------------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 19:01:09 2014
Return-Path: <trac@tools.ietf.org>
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 235F31A03CC for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 19:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 75MMxD6MgMxz for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 19:01:05 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6E1A02E3 for <pcp@ietf.org>; Mon, 24 Feb 2014 19:01:05 -0800 (PST)
Received: from localhost ([127.0.0.1]:42535 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI8GV-0002kD-9n; Tue, 25 Feb 2014 04:01:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 03:01:03 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/36#comment:1
Message-ID: <068.3e310a7a0983b1338abd375c9e6f856c@tools.ietf.org>
References: <053.58320c0d7e5437ce095c55c69e6bd448@tools.ietf.org>
X-Trac-Ticket-ID: 36
In-Reply-To: <053.58320c0d7e5437ce095c55c69e6bd448@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: dthaler@microsoft.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/gSxYdy4kpccEGUYU3WUy7WUefZc
Cc: pcp@ietf.org
Subject: Re: [pcp] #36: error on renewal for interworking function
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 03:01:07 -0000

#36: error on renewal for interworking function

Changes (by dthaler@microsoft.com):

 * status:  new => closed
 * resolution:   => fixed
 * component:  UPnP interop => upnp-igd-interworking


Comment:

 This was addressed in RFC 6970 section 5.9.

-- 
-----------------------------------+---------------------
 Reporter:  dwing@cisco.com        |       Owner:
     Type:  enhancement            |      Status:  closed
 Priority:  minor                  |   Milestone:
Component:  upnp-igd-interworking  |     Version:
 Severity:  -                      |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/36#comment:1>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 19:03:16 2014
Return-Path: <trac@tools.ietf.org>
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 62CC01A03E2 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 19:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 F90GC9PfPr1E for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 19:03:13 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 17C851A03CC for <pcp@ietf.org>; Mon, 24 Feb 2014 19:03:13 -0800 (PST)
Received: from localhost ([127.0.0.1]:42595 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI8IX-00034f-CP; Tue, 25 Feb 2014 04:03:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 03:03:09 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/30#comment:3
Message-ID: <089.ca62926dc2989897b7ec47723d728cf0@tools.ietf.org>
References: <074.7aee1ae9c8079cffdef45063f8ecdbfb@tools.ietf.org>
X-Trac-Ticket-ID: 30
In-Reply-To: <074.7aee1ae9c8079cffdef45063f8ecdbfb@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: dthaler@microsoft.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/SD6Pzdm10pAloZoHeuJAUdqKHZk
Cc: pcp@ietf.org
Subject: Re: [pcp] #30: GetExternalIP capability?
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 03:03:14 -0000

#30: GetExternalIP capability?

Changes (by dthaler@microsoft.com):

 * status:  new => closed
 * resolution:   => fixed
 * component:  UPnP interop => upnp-igd-interworking
 * severity:  Active WG Document => Submitted WG Document


Comment:

 GetExternalIPAddress() support was addressed in RFC 6970 section 4.2.

-- 
--------------------------------------------------+---------------------
 Reporter:  mohamed.boucadair@orange-ftgroup.com  |       Owner:
     Type:  enhancement                           |      Status:  closed
 Priority:  minor                                 |   Milestone:
Component:  upnp-igd-interworking                 |     Version:
 Severity:  Submitted WG Document                 |  Resolution:  fixed
 Keywords:                                        |
--------------------------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/30#comment:3>
pcp <http://tools.ietf.org/pcp/>


From nobody Mon Feb 24 19:07:48 2014
Return-Path: <trac@tools.ietf.org>
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 CEB8F1A03E0 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 19:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 cmvpaOtbqB71 for <pcp@ietfa.amsl.com>; Mon, 24 Feb 2014 19:07:43 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4A1A03CC for <pcp@ietf.org>; Mon, 24 Feb 2014 19:07:42 -0800 (PST)
Received: from localhost ([127.0.0.1]:42737 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WI8M6-0004QT-0h; Tue, 25 Feb 2014 04:06:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: tena@huawei.com, cheshire@apple.com, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Tue, 25 Feb 2014 03:06:48 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/16#comment:4
Message-ID: <074.f1740c3eea6f2d6c12bb754369f307d5@tools.ietf.org>
References: <059.b8e7df1bdcf8430f3c4de0aadc733008@tools.ietf.org>
X-Trac-Ticket-ID: 16
In-Reply-To: <059.b8e7df1bdcf8430f3c4de0aadc733008@tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: tena@huawei.com, cheshire@apple.com, dthaler@microsoft.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/EkE1aJcx2_OcmFbI_u6eCEvJPvQ
Cc: pcp@ietf.org
Subject: Re: [pcp] #16: PCP lifetime expiration with active traffic
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 03:07:46 -0000

#16: PCP lifetime expiration with active traffic

Changes (by dthaler@microsoft.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 WG consensus is what was put in RFC 6887 section 15:
 > In particular, it is implementation-dependent if outgoing traffic
 > extends the lifetime of such mappings beyond the PCP-assigned
 > lifetime.  PCP clients MUST NOT depend on this behavior to keep
 > mappings active, and MUST explicitly renew their mappings as required
 > by the Lifetime field in PCP response messages.

-- 
-----------------------------------+---------------------
 Reporter:  dthaler@microsoft.com  |       Owner:
     Type:  enhancement            |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  base                   |     Version:
 Severity:  Active WG Document     |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/16#comment:4>
pcp <http://tools.ietf.org/pcp/>


From nobody Tue Feb 25 03:52:46 2014
Return-Path: <matt@bodgit-n-scarper.com>
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 2C4A81A06B8 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 03:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 UiKF7Omg-H-0 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 03:52:42 -0800 (PST)
Received: from mail.bodgit-n-scarper.com (simulant.bodgit-n-scarper.com [IPv6:2600:3c03::f03c:91ff:fe96:1bcb]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E21A06B6 for <pcp@ietf.org>; Tue, 25 Feb 2014 03:52:42 -0800 (PST)
Received: by mail.bodgit-n-scarper.com (Postfix, from userid 2000) id 552C37F15; Tue, 25 Feb 2014 06:53:13 -0500 (EST)
Date: Tue, 25 Feb 2014 06:53:13 -0500
From: Matt Dainty <matt@bodgit-n-scarper.com>
To: pcp@ietf.org
Message-ID: <20140225115313.GS2245@simulant.bodgit-n-scarper.com>
References: <20140221171034.15533.45654.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140221171034.15533.45654.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.4.2.2i
X-Operating-System: Linux 2.6.18-348.3.1.el5xen on x86_64 SMP (simulant.bodgit-n-scarper.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/VOMqSQ0i9j_ErclRFpxDU4lyj98
Subject: Re: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 11:52:44 -0000

Section 3 of this draft seems to hint at different forms of option
processing compared to what is defined in RFC 6887.

If the PCP client includes the DESCRIPTION option and marks it as
mandatory the PCP server should return UNSUPP_OPTION if it does not
support it, rather than ignore it. In fact, if it truly doesn't
understand this option, that's what it will do anyway; you would have
to teach the server about this option to then make it ignore it. RFC
6887 defines the method of marking options as optional so clients
should use that if they don't want the option to potentially trigger an
error response from the server.

If the PCP client includes malformed UTF-8 content then the PCP server
should return MALFORMED_OPTION as per the standard option processing
rather than just ignore the option/request.

Matt

* Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> [2014-02-21 12:10:39]:
> 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 Description Option
>     Author(s)     : M. Boucadair, et al
>     Filename      : draft-ietf-pcp-description-option
>     Pages         : 6 
>     Date          : 2014-02-21 
>     
> This document extends Port Control Protocol (PCP) with the ability to
>    associate a description with a PCP-instantiated mapping.  It does so
>    by defining a new DESCRIPTION option.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pcp-description-option-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.


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


From nobody Tue Feb 25 04:33:22 2014
Return-Path: <mohamed.boucadair@orange.com>
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 A68EC1A06D0 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 04:33:20 -0800 (PST)
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 N6Bov2Ypb2GH for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 04:33:18 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0F01A06C2 for <pcp@ietf.org>; Tue, 25 Feb 2014 04:33:18 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 36FFD18C338; Tue, 25 Feb 2014 13:33:17 +0100 (CET)
Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1D4D427C0CE; Tue, 25 Feb 2014 13:33:17 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 25 Feb 2014 13:33:17 +0100
From: <mohamed.boucadair@orange.com>
To: Matt Dainty <matt@bodgit-n-scarper.com>, "pcp@ietf.org" <pcp@ietf.org>
Date: Tue, 25 Feb 2014 13:33:12 +0100
Thread-Topic: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt
Thread-Index: Ac8yIBr+P+7Pj9xvQze4K/GIWOilTgAAyRHA
Message-ID: <94C682931C08B048B7A8645303FDC9F36F4E4D7909@PUEXCB1B.nanterre.francetelecom.fr>
References: <20140221171034.15533.45654.idtracker@ietfa.amsl.com> <20140225115313.GS2245@simulant.bodgit-n-scarper.com>
In-Reply-To: <20140225115313.GS2245@simulant.bodgit-n-scarper.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: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/YEwtllicI2fxeL1hMY7-dFsj1XA
Subject: Re: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 12:33:20 -0000

Dear Matt,

This option is defined in the optional to process range (see IANA section).=
=20

The draft follows the behavior in RFC6887, particularly this part:

   If the overall option structure of a request is valid, then how each
   individual option is handled is determined by the most significant
   bit in the option code.  If the most significant bit is set, handling
   this option is optional, and a PCP server MAY process or ignore this
   option, entirely at its discretion.  If the most significant bit is
   clear, handling this option is mandatory, and a PCP server MUST
   return the error MALFORMED_OPTION if the option contents are
   malformed, or UNSUPP_OPTION if the option is unrecognized,
   unimplemented, or disabled, or if the client is not authorized to use
   the option.  In error responses, all options are returned.  In
   success responses, all processed options are included and unprocessed
   options are not included.

Cheers,
Med

>-----Message d'origine-----
>De=A0: pcp [mailto:pcp-bounces@ietf.org] De la part de Matt Dainty
>Envoy=E9=A0: mardi 25 f=E9vrier 2014 12:53
>=C0=A0: pcp@ietf.org
>Objet=A0: Re: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt
>
>Section 3 of this draft seems to hint at different forms of option
>processing compared to what is defined in RFC 6887.
>
>If the PCP client includes the DESCRIPTION option and marks it as
>mandatory the PCP server should return UNSUPP_OPTION if it does not
>support it, rather than ignore it. In fact, if it truly doesn't
>understand this option, that's what it will do anyway; you would have
>to teach the server about this option to then make it ignore it. RFC
>6887 defines the method of marking options as optional so clients
>should use that if they don't want the option to potentially trigger an
>error response from the server.
>
>If the PCP client includes malformed UTF-8 content then the PCP server
>should return MALFORMED_OPTION as per the standard option processing
>rather than just ignore the option/request.
>
>Matt
>
>* Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> [2014-02-21
>12:10:39]:
>> 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 Description Option
>>     Author(s)     : M. Boucadair, et al
>>     Filename      : draft-ietf-pcp-description-option
>>     Pages         : 6
>>     Date          : 2014-02-21
>>
>> This document extends Port Control Protocol (PCP) with the ability to
>>    associate a description with a PCP-instantiated mapping.  It does so
>>    by defining a new DESCRIPTION option.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pcp-description-option-
>05.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>
>
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp


From nobody Tue Feb 25 06:50:52 2014
Return-Path: <simon.perreault@viagenie.ca>
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 697DD1A0476 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 06:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 F491DorC53C3 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 06:50:47 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66FC91A00B2 for <pcp@ietf.org>; Tue, 25 Feb 2014 06:50:47 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6BE23403F7 for <pcp@ietf.org>; Tue, 25 Feb 2014 09:50:46 -0500 (EST)
Message-ID: <530CADC6.104@viagenie.ca>
Date: Tue, 25 Feb 2014 09:50:46 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: pcp@ietf.org
References: <c27dba04300d4f0cb9f6c0b467839ad0@BY2PR03MB412.namprd03.prod.outlook.com>
In-Reply-To: <c27dba04300d4f0cb9f6c0b467839ad0@BY2PR03MB412.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/j53WtT2ArHRHUHF4bKi36DdqQKg
Subject: Re: [pcp] IETF 88 notes for draft-ietf-pcp-port-set-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 14:50:49 -0000

You're right. I wonder how I missed those. I'll bake a new revision.

Simon

Le 2014-02-24 21:00, Dave Thaler a écrit :
>>From the IETF 88 meeting notes (http://www.ietf.org/proceedings/88/minutes/minutes-88-pcp)
> 
> [...]
>> Dave Thaler suggested that if port-set capability is added (or removed),
>> the PCP server can reset its Epoch to zero, which causes PCP client to 
>> re-try using PORT_SET. New text is needed in the document for those things.
>> [See also discussion in the Jabber log.]
> 
> I don't see this in draft -04.
> 
> [...]
>> Simon: Possible to get multiple responses to a single request.
>> Dan: Add to Security Considerations.
>> Dan: If I'm missing one response out of the set, have to re-send request.
>> Dave: Need to know nonce, so this can still be an on-path attack.
> 
> I don't see this in draft -04.
> 
> [...]
>> Dan: Server can be upgraded/changed to support/not support PORT_SET.
>>     Is there any harm to always request PORT_SET?
>> Dave: If I get an indication that the server doesn't currently support
>>      PORT_SET, I'll send multiple requests in parallel.
> 
> This is related to the issue in the other thread (the follow-up to -03).
> The text to address that should just keep the above in mind.
> 
> -Dave
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
> 


-- 
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 Tue Feb 25 19:08:42 2014
Return-Path: <tireddy@cisco.com>
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 F38651A0845 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 19:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level: 
X-Spam-Status: No, score=-15.048 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.547, 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 TrTsRUa6rKR5 for <pcp@ietfa.amsl.com>; Tue, 25 Feb 2014 19:08:39 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 115491A03B1 for <pcp@ietf.org>; Tue, 25 Feb 2014 19:08:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4991; q=dns/txt; s=iport; t=1393384117; x=1394593717; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BEJpyMCcWlVz8QJMTrTB5gxXnCdJeFj7genoKMCVdRs=; b=RikVVvM7ywSwXRtK1BUH38Ufis3SatiRJXfb/H1eSASCfnmfintxhikj quqTMLKlAwxH3je95ZjJIRI38M//d7m02WsBF6NifywnbHJj2ImyMS+k2 pvMz5okfHkigL5I71kafcoTkJg1c1sOyFnT8xRZH7cxkxqF+b5cCj6o/L 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAB9aDVOtJXHA/2dsb2JhbABYgwY7V8EDgRcWdIIlAQEBBCdeBgEIEQQBAQsdORQJCQEEARIIh30NyFAXjW0yCzODHoEUBIkRkFeQdoMtgio
X-IronPort-AV: E=Sophos;i="4.97,544,1389744000"; d="scan'208";a="306526055"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 26 Feb 2014 03:08:36 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q38asO019697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 03:08:36 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 21:08:36 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, "Prashanth Patil (praspati)" <praspati@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
Thread-Index: Ac8yoAclbfYgfWYkTaiF3WBTb2QENQ==
Date: Wed, 26 Feb 2014 03:08:36 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A242C5B0B@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.77.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5Kmnm8abn8ZUvtX0rgYYNDlUdyc
Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 03:08:41 -0000

> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault@viagenie.ca]
> Sent: Tuesday, February 18, 2014 7:58 PM
> To: Prashanth Patil (praspati); pcp@ietf.org
> Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments =
due
> by FEB 21
>=20
> Le 2014-02-18 09:20, Prashanth Patil (praspati) a =E9crit :
> >> How does the client know that those addresses belong to a single PCP
> >> server?
> >
> > A PCP client, via DHCP for example, can learn a list of IP addresses
> > for the same PCP server and a list of unique PCP servers.
> > https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5
> >
> >
> >>
> >> Does this work when there are multiple addresses that belong to
> >> multiple PCP servers, or does it need to be a single server?
> >
> > It works in both cases.
> >
> > The draft first describes how a PCP client goes about contacting a PCP
> > server that has multiple addresses. The same steps are to be followed
> > for each unique PCP server learnt (each of which may again have
> > multiple addresses).
> >
> > From the draft:
> > "If several PCP servers are configured, each with multiple IP
> > addresses, the PCP client contacts all PCP servers in parallel
> > following the steps described above."
>=20
> Good. That makes sense.
>=20
> >>>    6.  Once the PCP client has successfully received a response from =
a
> >>>        PCP server's IP address, it sends subsequent PCP requests to t=
he
> >>>        same server's IP address until that IP address becomes non-
> >>>        responsive, which causes the PCP client to follow the steps ab=
ove
> >>>        to contact its PCP server.
> >>
> >> Do we reset the destination address set then? That is, are addresses
> >> that failed previously now potentially good again?
> >
> > Yes, the client has to attempt contacting the servers again.
>=20
> Ok. It would be nice to mention it explicitly.
>=20
> >>> 5.  Example: Multiple PCP servers on a Single Interface
> >>>
> >>>    Figure 1 depicts an example that is used to illustrate the server
> >>>    selection procedure specified in Section 3.
> >>>
> >>>                                ISP Network
> >>>                              |              |
> >>>        .........................................................
> >>>                              |              |        Subscriber Netwo=
rk
> >>>                      +-------+------+  +----+---------+
> >>>                      | PCP-Server-A |  | PCP-Server-B |
> >>>                      |              |  |              |
> >>>                      +-------+------+  +----+---------+
> >>>             192.0.2.1        |              |     198.51.100.1
> >>>             2001:db8:2222::1 |              |     2001:db8:3333::1
> >>>                              |              |
> >>>                              |              |
> >>>                       -------+--------------+-----------
> >>>                                      |
> >>>                                      |    203.0.113.0
> >>>                                      |    2001:db8:1111::1
> >>>                                  +---+---+
> >>>                                  | Host  |
> >>>                                  +-------+
> >>>
> >>>                                  Figure 1
> >>
> >> The PCP servers in this figure look like routers. To make things clear=
er:
> >>
> >> - Remove the connection from each PCP server to the ISP network.
> >>
> >> - Draw the "PCP-controlled device". That one would look like a router
> >> and would be sitting on the border between the subscriber network and
> >> the ISP network. Connect it to both PCP servers and the host. No need
> >> for addresses.
> >>
> >> Is there only one PCP-controlled device, or does each server control
> >> its own device?
> >
> > Each server controls its own device. With this clarification, do you
> > still think the figure needs to be updated?
>=20
> Yes.

Can you please provide more details why this figure needs to be updated ?

-Tiru

>=20
> >>>    The PCP client sends two PCP requests at the same time,
> >>
> >> Really? The algorithm from section 3 does not seem to allow parallel
> >> requests. I'm lost.
> >
> > It does, as described in an earlier comment and the last paragraph of
> > http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3=
.
> > There are two potential scenarios. A single server having multiple
> > addresses AND multiple PCP servers itself. The draft tries to address
> > both scenarios. If this is unclear, we'll have to see how to
> > re-organize to make it more obvious.
>=20
> I think that would be necessary.
>=20
> Thanks,
> 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
>=20


From nobody Wed Feb 26 01:11:35 2014
Return-Path: <mohamed.boucadair@orange.com>
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 85AC41A002F for <pcp@ietfa.amsl.com>; Wed, 26 Feb 2014 01:11:29 -0800 (PST)
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 HU01jPKL1JtN for <pcp@ietfa.amsl.com>; Wed, 26 Feb 2014 01:11:22 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1861A016A for <pcp@ietf.org>; Wed, 26 Feb 2014 01:11:22 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7840D324063; Wed, 26 Feb 2014 10:11:20 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4D71927C0B6; Wed, 26 Feb 2014 10:11:20 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 26 Feb 2014 10:11:20 +0100
From: <mohamed.boucadair@orange.com>
To: pcp issue tracker <trac@tools.ietf.org>, "dwing@cisco.com" <dwing@cisco.com>, "dthaler@microsoft.com" <dthaler@microsoft.com>
Date: Wed, 26 Feb 2014 10:11:18 +0100
Thread-Topic: [pcp] #34: notify NAT WAN address changed
Thread-Index: Ac8x1ZsNomlq7CMaTFqv1wt/Mk7JagA+28DA
Message-ID: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr>
References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org>
In-Reply-To: <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org>
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.2.25.93015
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/X0zcgewJdMV12XtQtuEzPjt6Q1g
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] #34: notify NAT WAN address changed
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 09:11:29 -0000

Hi Dave, all,

I agree most of the issues captured in this ticket are solved, but still th=
ere is one remaining issue.=20

As a reminder, the ticket refers to this text:

=3D=3D=3D=3D=3D=3D
2.5. Change of the CPE WAN IP Address

   The change of the IP address of the WAN interface of the CPE would
   have an impact on the accuracy of the mappings instantiated in the
   PCP Server:

   o  For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new
      IPv6 address is used by the B4 element when encapsulating IPv4
      packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP
      Client is embedded in the B4, the refresh operation is triggered
      by the change of the B4 IPv6 address.  This would be more
      complicated when the PCP Client is located in a device behind the
      B4.

         [Ed.  Note: how an IPv4 host behind a DS-Lite CPE is aware that
         a new IPv6 address is used by the B4?]

   o  For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any
      change of the assigned IPv6 prefix delegated to the CPE will be
      detected by the PCP Client (because this leads to the allocation
      of a new IPv6 address).  The PCP Client has to undertake the
      operation described in Section 2.4.
=3D=3D=3D=3D=3D=3D=3D=3D

An issue is still unsolved in the DS-Lite case where the PCP client is not =
co-located with B4. This issue is not solved in the base PCP spec, but is a=
ddressed in this individual draft: http://tools.ietf.org/search/draft-vinap=
amula-softwire-dslite-prefix-binding-01=20

The recommendation in http://tools.ietf.org/search/draft-vinapamula-softwir=
e-dslite-prefix-binding-01 covers the PCP case, in particular these two rec=
ommendations:

   3.  In the event a new IPv6 address is assigned to B4, the AFTR
       SHOULD migrate existing state to be bound to the new B4's IP
       address.  This ensures the traffic destined to the previous IPv6
       address will redirected to the new IPv6 address.  The destination
       address for tunneling return traffic SHOULD be the last seen
       address from the CPE.  The source address of the tunnel would
       remain same as AFTR.

   4.  In the event of change of the CPE WAN IPv6 prefix, unsolicited
       PCP ANNOUNCE messages SHOULD be sent by the B4 element to
       internal hosts to update their mappings.

Cheers,
Med

>-----Message d'origine-----
>De=A0: pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker
>Envoy=E9=A0: mardi 25 f=E9vrier 2014 03:59
>=C0=A0: dwing@cisco.com; dthaler@microsoft.com
>Cc=A0: pcp@ietf.org
>Objet=A0: Re: [pcp] #34: notify NAT WAN address changed
>
>#34: notify NAT WAN address changed
>
>Changes (by dthaler@microsoft.com):
>
> * status:  new =3D> closed
> * resolution:   =3D> fixed
>
>
>Comment:
>
> This was addressed in RFC 6887.  Section 14.2 begins:
> > 14.2.  PCP Mapping Update
> >
> >   This rapid recovery mechanism is used when the PCP server remembers
> >   its state and determines its existing mappings are invalid (e.g., IP
> >   renumbering changes the external IP address of a PCP-controlled NAT).
>
>--
>--------------------------------------------------+---------------------
> Reporter:  mohamed.boucadair@orange-ftgroup.com  |       Owner:
>     Type:  enhancement                           |      Status:  closed
> Priority:  minor                                 |   Milestone:
>Component:  Extensions                            |     Version:
> Severity:  -                                     |  Resolution:  fixed
> Keywords:                                        |
>--------------------------------------------------+---------------------
>
>Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4>
>pcp <http://tools.ietf.org/pcp/>
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp


From nobody Wed Feb 26 05:20:23 2014
Return-Path: <simon.perreault@viagenie.ca>
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 5C7491A02E4 for <pcp@ietfa.amsl.com>; Wed, 26 Feb 2014 05:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 uTqE6hRhCfgR for <pcp@ietfa.amsl.com>; Wed, 26 Feb 2014 05:20:13 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 200B41A007F for <pcp@ietf.org>; Wed, 26 Feb 2014 05:20:13 -0800 (PST)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C561246907; Wed, 26 Feb 2014 08:20:11 -0500 (EST)
Message-ID: <530DEA0B.9010800@viagenie.ca>
Date: Wed, 26 Feb 2014 08:20:11 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>,  "Prashanth Patil (praspati)" <praspati@cisco.com>, "pcp@ietf.org" <pcp@ietf.org>
References: <913383AAA69FF945B8F946018B75898A242C5B0B@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A242C5B0B@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/zUGPNuoU4Yb9EiKS_XdmOOkZ5_E
Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 13:20:20 -0000

Le 2014-02-25 22:08, Tirumaleswar Reddy (tireddy) a écrit :
>>>>> 5.  Example: Multiple PCP servers on a Single Interface
>>>>>
>>>>>    Figure 1 depicts an example that is used to illustrate the server
>>>>>    selection procedure specified in Section 3.
>>>>>
>>>>>                                ISP Network
>>>>>                              |              |
>>>>>        .........................................................
>>>>>                              |              |        Subscriber Network
>>>>>                      +-------+------+  +----+---------+
>>>>>                      | PCP-Server-A |  | PCP-Server-B |
>>>>>                      |              |  |              |
>>>>>                      +-------+------+  +----+---------+
>>>>>             192.0.2.1        |              |     198.51.100.1
>>>>>             2001:db8:2222::1 |              |     2001:db8:3333::1
>>>>>                              |              |
>>>>>                              |              |
>>>>>                       -------+--------------+-----------
>>>>>                                      |
>>>>>                                      |    203.0.113.0
>>>>>                                      |    2001:db8:1111::1
>>>>>                                  +---+---+
>>>>>                                  | Host  |
>>>>>                                  +-------+
>>>>>
>>>>>                                  Figure 1
> 
> Can you please provide more details why this figure needs to be updated ?

Because:

1. The PCP servers look like routers. They should not be connected at
the top.

2. The PCP-controlled device(s) is/are not shown. We don't know whether
there are two PCP servers controlling a single device or two PCP servers
each controlling its own device.

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 Wed Feb 26 10:44:03 2014
Return-Path: <iesg-secretary@ietf.org>
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 8C0391A0802; Wed, 26 Feb 2014 10:43:58 -0800 (PST)
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 OtF6ttXbERki; Wed, 26 Feb 2014 10:43:54 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A41A0732; Wed, 26 Feb 2014 10:43:47 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140226184347.14989.14128.idtracker@ietfa.amsl.com>
Date: Wed, 26 Feb 2014 10:43:47 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/voueZ1llu4KQCskkLXBFV36PQZU
Cc: pcp mailing list <pcp@ietf.org>, pcp chair <pcp-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [pcp] Protocol Action: 'PCP Description Option' to Proposed Standard (draft-ietf-pcp-description-option-05.txt)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 18:43:58 -0000

The IESG has approved the following document:
- 'PCP Description Option'
  (draft-ietf-pcp-description-option-05.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-description-option/




Technical Summary

  This document extends Port Control Protocol (PCP) with the ability to
  associate a description with a PCP-instantiated mapping.  It does so
  by defining a new DESCRIPTION option.

Working Group Summary

Was there anything in WG process that is worth noting? For 
example, was there controversy about particular points or 
were there decisions where the consensus was particularly 
rough?

  Nothing controversial.

Document Quality

  It is expected that any implementation of RFC 6970 (PCP/UPnP-IGD
  interop) would want this extension.  One known implementation is
  reported in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.1.

  Other than the document editor, the following people reviewed the document
  during WGLC and all concluded the document had no substantive issues:
      1) Dave Thaler (document shepherd, WG co-chair)
      2) Tiru Reddy
      3) Simon Perreault
      4) Paul Selkirk
      5) Reinaldo Penno (WG co-chair, co-author)

Personnel

  Document Shepherd: Dave Thaler <dthaler@microsoft.com>
  Responsible Area Director: Ted Lemon <ted.lemon@nominum.com>

RFC Editor Note:

Please replace paragraphs 4 and 5 of section three with the following new text.

OLD (in -05):
   Because of the UDP payload limit of 1100 octets [RFC6887], the
   configured maximum length MUST NOT exceed 1016 octets.  The suggested
   maximum length is 128 octets.  If a PCP client includes a DESCRIPTION
   option with a length exceeding the maximum length supported by the
   PCP server, only the portion of the Description field fitting that
   maximum length is stored by the PCP server and returned to the PCP
   client in the response.
 
   If the PCP server receives a DESCRIPTION option having a length which
   does not exceed the maximum value configured, the PCP server MUST
   record the complete sequence of the description text and MUST send
   back to the PCP client the same DESCRIPTION option as the one
   included in the request.

NEW:
  A PCP server SHOULD be able to store at least 128 bytes for a description.
   When the PCP server receives a DESCRIPTION option, it first stores
   the value of the received Description field, truncating it if it cannot store
   the entire value.  The server MUST then send the stored value back to
   the PCP client in the DESCRIPTION option in the response. 


From nobody Wed Feb 26 10:58:14 2014
Return-Path: <iesg-secretary@ietf.org>
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 E03BB1A07D3; Wed, 26 Feb 2014 10:58:06 -0800 (PST)
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 yEl6ybi1VR-4; Wed, 26 Feb 2014 10:58:05 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A01A074A; Wed, 26 Feb 2014 10:58:00 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140226185800.17844.42509.idtracker@ietfa.amsl.com>
Date: Wed, 26 Feb 2014 10:58:00 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/_c13dhziqyBsESlIwubARuBYRkc
Cc: pcp mailing list <pcp@ietf.org>, pcp chair <pcp-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [pcp] Protocol Action: 'Learning NAT64 PREFIX64s using Port Control Protocol (PCP)' to Proposed Standard (draft-ietf-pcp-nat64-prefix64-06.txt)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 18:58:07 -0000

The IESG has approved the following document:
- 'Learning NAT64 PREFIX64s using Port Control Protocol (PCP)'
  (draft-ietf-pcp-nat64-prefix64-06.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-nat64-prefix64/




Technical Summary

  This document defines a new PCP extension to learn the IPv6
  prefix(es) used by a PCP-controlled NAT64 device to build
  IPv4-converted IPv6 addresses.  This extension is needed for
  successful communications when IPv4 addresses are used in referrals.

Working Group Summary

  The WG easily got consensus.

Document Quality

  It is unknown whether there are existing implementations.

  A large number of people (named in section 8 of the doc) reviewed it
  and contributed to it. The individuals who provided reviews during WGLC were:
     Dave Thaler
     Teemu Savolainen
     Senthil Sivakumar
     Simon Perreault
     Iljitsch van Beijnum 

Personnel

  Document Shepherd: Dave Thaler <dthaler@microsoft.com>
  Responsible AD: Ted Lemon <ted.lemon@nominum.com>


From nobody Thu Feb 27 12:18:24 2014
Return-Path: <sureshk@juniper.net>
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 3FE871A0552 for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 12:18:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 O08c4Gf-gcwH for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 12:18:19 -0800 (PST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1991A0643 for <pcp@ietf.org>; Thu, 27 Feb 2014 12:18:18 -0800 (PST)
Received: from mail100-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.22; Thu, 27 Feb 2014 20:18:16 +0000
Received: from mail100-am1 (localhost [127.0.0.1])	by mail100-am1-R.bigfish.com (Postfix) with ESMTP id 6482136078D;	Thu, 27 Feb 2014 20:18:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -73
X-BigFish: VPS-73(z551bizbb2dI98dI9371Ic89bh1432I15caKJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz97hdchz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h)
Received-SPF: pass (mail100-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(479174003)(189002)(24454002)(55784002)(199002)(76482001)(94946001)(31966008)(74662001)(74502001)(19580405001)(83072002)(2656002)(51856001)(94316002)(47446002)(54356001)(54316002)(86362001)(95416001)(79102001)(36756003)(92566001)(2201001)(92726001)(95666003)(83322001)(19580395003)(81686001)(83506001)(87266001)(80976001)(85852003)(59766001)(74706001)(53806001)(50986001)(47736001)(47976001)(49866001)(93136001)(81342001)(65816001)(66066001)(80022001)(69226001)(76796001)(1511001)(90146001)(56776001)(56816005)(87936001)(74366001)(46102001)(85306002)(81816001)(81542001)(4396001)(76786001)(76176001)(93516002)(74876001)(77982001)(63696002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB719; H:DM2PR05MB288.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:FCFEFD0D.AFFA17E9.F5C170BC.4EEEF74B.20411; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail100-am1 (localhost.localdomain [127.0.0.1]) by mail100-am1 (MessageSwitch) id 1393532293283994_6427; Thu, 27 Feb 2014 20:18:13 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.229])	by mail100-am1.bigfish.com (Postfix) with ESMTP id 3ADF724009D; Thu, 27 Feb 2014 20:18:13 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 27 Feb 2014 20:18:11 +0000
Received: from DM2PR05MB719.namprd05.prod.outlook.com (10.141.177.151) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 27 Feb 2014 20:18:10 +0000
Received: from DM2PR05MB288.namprd05.prod.outlook.com (10.141.101.11) by DM2PR05MB719.namprd05.prod.outlook.com (10.141.177.151) with Microsoft SMTP Server (TLS) id 15.0.883.10; Thu, 27 Feb 2014 20:18:08 +0000
Received: from DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) by DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) with mapi id 15.00.0888.003; Thu, 27 Feb 2014 20:18:08 +0000
From: Suresh Kumar Vinapamula Venkata <sureshk@juniper.net>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, pcp issue tracker <trac@tools.ietf.org>, "dwing@cisco.com" <dwing@cisco.com>, "dthaler@microsoft.com" <dthaler@microsoft.com>
Thread-Topic: [pcp] #34: notify NAT WAN address changed
Thread-Index: AQHPMdWeDQOTA82BA0m4bjbUYzmRWprHQb4AgAHGg4A=
Date: Thu, 27 Feb 2014 20:18:08 +0000
Message-ID: <CF34CA8D.307F7%sureshk@juniper.net>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@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.2.130206
x-originating-ip: [66.129.239.14]
x-forefront-prvs: 013568035E
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9B0A26BCB4460D42A66AB8DD41A8046D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/clv5VfdgQCafAXZtrq5kk9Cm6bo
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] #34: notify NAT WAN address changed
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 20:18:22 -0000

Hi Dave,=20

Section 14.2 of RFC6887 addresses change in external IP address of PCP
controlled NAT, and it doesn=B9t address change in CPE WAN IP address. This
draft is addressing the change in CPE WAN IP address and suggests
recommendations.=20

Thanks
Suresh

On 2/26/14 1:11 AM, "mohamed.boucadair@orange.com"
<mohamed.boucadair@orange.com> wrote:

>Hi Dave, all,
>
>I agree most of the issues captured in this ticket are solved, but still
>there is one remaining issue.
>
>As a reminder, the ticket refers to this text:
>
>=3D=3D=3D=3D=3D=3D
>2.5. Change of the CPE WAN IP Address
>
>   The change of the IP address of the WAN interface of the CPE would
>   have an impact on the accuracy of the mappings instantiated in the
>   PCP Server:
>
>   o  For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new
>      IPv6 address is used by the B4 element when encapsulating IPv4
>      packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP
>      Client is embedded in the B4, the refresh operation is triggered
>      by the change of the B4 IPv6 address.  This would be more
>      complicated when the PCP Client is located in a device behind the
>      B4.
>
>         [Ed.  Note: how an IPv4 host behind a DS-Lite CPE is aware that
>         a new IPv6 address is used by the B4?]
>
>   o  For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any
>      change of the assigned IPv6 prefix delegated to the CPE will be
>      detected by the PCP Client (because this leads to the allocation
>      of a new IPv6 address).  The PCP Client has to undertake the
>      operation described in Section 2.4.
>=3D=3D=3D=3D=3D=3D=3D=3D
>
>An issue is still unsolved in the DS-Lite case where the PCP client is
>not co-located with B4. This issue is not solved in the base PCP spec,
>but is addressed in this individual draft:
>http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bindi
>ng-01=20
>
>The recommendation in
>http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bindi
>ng-01 covers the PCP case, in particular these two recommendations:
>
>   3.  In the event a new IPv6 address is assigned to B4, the AFTR
>       SHOULD migrate existing state to be bound to the new B4's IP
>       address.  This ensures the traffic destined to the previous IPv6
>       address will redirected to the new IPv6 address.  The destination
>       address for tunneling return traffic SHOULD be the last seen
>       address from the CPE.  The source address of the tunnel would
>       remain same as AFTR.
>
>   4.  In the event of change of the CPE WAN IPv6 prefix, unsolicited
>       PCP ANNOUNCE messages SHOULD be sent by the B4 element to
>       internal hosts to update their mappings.
>
>Cheers,
>Med
>
>>-----Message d'origine-----
>>De : pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker
>>Envoy=E9 : mardi 25 f=E9vrier 2014 03:59
>>=C0 : dwing@cisco.com; dthaler@microsoft.com
>>Cc : pcp@ietf.org
>>Objet : Re: [pcp] #34: notify NAT WAN address changed
>>
>>#34: notify NAT WAN address changed
>>
>>Changes (by dthaler@microsoft.com):
>>
>> * status:  new =3D> closed
>> * resolution:   =3D> fixed
>>
>>
>>Comment:
>>
>> This was addressed in RFC 6887.  Section 14.2 begins:
>> > 14.2.  PCP Mapping Update
>> >
>> >   This rapid recovery mechanism is used when the PCP server remembers
>> >   its state and determines its existing mappings are invalid (e.g., IP
>> >   renumbering changes the external IP address of a PCP-controlled
>>NAT).
>>
>>--
>>--------------------------------------------------+---------------------
>> Reporter:  mohamed.boucadair@orange-ftgroup.com  |       Owner:
>>     Type:  enhancement                           |      Status:  closed
>> Priority:  minor                                 |   Milestone:
>>Component:  Extensions                            |     Version:
>> Severity:  -                                     |  Resolution:  fixed
>> Keywords:                                        |
>>--------------------------------------------------+---------------------
>>
>>Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4>
>>pcp <http://tools.ietf.org/pcp/>
>>
>>_______________________________________________
>>pcp mailing list
>>pcp@ietf.org
>>https://www.ietf.org/mailman/listinfo/pcp
>
>



From nobody Thu Feb 27 14:41:04 2014
Return-Path: <dthaler@microsoft.com>
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 A3C321A024A for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 14:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 9oC6jJv5Iacf for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 14:40:58 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id C04811A028E for <pcp@ietf.org>; Thu, 27 Feb 2014 14:40:57 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB597.namprd03.prod.outlook.com (10.255.93.37) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 27 Feb 2014 22:40:54 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 22:40:54 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Suresh Kumar Vinapamula Venkata <sureshk@juniper.net>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "pcp issue tracker" <trac@tools.ietf.org>, "dwing@cisco.com" <dwing@cisco.com>
Thread-Topic: [pcp] #34: notify NAT WAN address changed
Thread-Index: AQHPMdWQIS2flFFrkUulCiX4MJkHkprHQb8AgAJMpACAACd50A==
Date: Thu, 27 Feb 2014 22:40:53 +0000
Message-ID: <2db04f60e1c749b7abcddec705c31e14@BY2PR03MB412.namprd03.prod.outlook.com>
References: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr> <CF34CA8D.307F7%sureshk@juniper.net>
In-Reply-To: <CF34CA8D.307F7%sureshk@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.108.71.45]
x-forefront-prvs: 013568035E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(479174003)(51704005)(189002)(199002)(377454003)(56776001)(93516002)(93136001)(54316002)(76482001)(74316001)(49866001)(90146001)(47736001)(94316002)(74706001)(74366001)(4396001)(33646001)(46102001)(92566001)(54356001)(86362001)(53806001)(56816005)(83072002)(50986001)(47976001)(66066001)(80022001)(85852003)(85306002)(65816001)(80976001)(83322001)(19580395003)(19580405001)(81686001)(94946001)(77982001)(59766001)(74662001)(47446002)(81542001)(74502001)(31966008)(63696002)(69226001)(79102001)(87936001)(81816001)(76796001)(76786001)(76576001)(95666003)(95416001)(86612001)(87266001)(74876001)(2656002)(81342001)(24736002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB597; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:199.108.71.45; FPR:FCFEFD1D.AFFA17E9.F4C170BC.4EE2774F.20464; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/412JW493YtpRQW_xrCbfewscD1o
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] #34: notify NAT WAN address changed
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 22:41:01 -0000

I don't follow.  If the PCP server controls the NAT in the CPE,=20
then the CPE WAN IP address *is* the external IP address of=20
the PCP controlled NAT.

-Dave

> -----Original Message-----
> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]
> Sent: Thursday, February 27, 2014 12:18 PM
> To: mohamed.boucadair@orange.com; pcp issue tracker; dwing@cisco.com;
> Dave Thaler
> Cc: pcp@ietf.org
> Subject: Re: [pcp] #34: notify NAT WAN address changed
>=20
> Hi Dave,
>=20
> Section 14.2 of RFC6887 addresses change in external IP address of PCP
> controlled NAT, and it doesn=B9t address change in CPE WAN IP address. Th=
is
> draft is addressing the change in CPE WAN IP address and suggests
> recommendations.
>=20
> Thanks
> Suresh
>=20
> On 2/26/14 1:11 AM, "mohamed.boucadair@orange.com"
> <mohamed.boucadair@orange.com> wrote:
>=20
> >Hi Dave, all,
> >
> >I agree most of the issues captured in this ticket are solved, but
> >still there is one remaining issue.
> >
> >As a reminder, the ticket refers to this text:
> >
> >=3D=3D=3D=3D=3D=3D
> >2.5. Change of the CPE WAN IP Address
> >
> >   The change of the IP address of the WAN interface of the CPE would
> >   have an impact on the accuracy of the mappings instantiated in the
> >   PCP Server:
> >
> >   o  For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new
> >      IPv6 address is used by the B4 element when encapsulating IPv4
> >      packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP
> >      Client is embedded in the B4, the refresh operation is triggered
> >      by the change of the B4 IPv6 address.  This would be more
> >      complicated when the PCP Client is located in a device behind the
> >      B4.
> >
> >         [Ed.  Note: how an IPv4 host behind a DS-Lite CPE is aware that
> >         a new IPv6 address is used by the B4?]
> >
> >   o  For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any
> >      change of the assigned IPv6 prefix delegated to the CPE will be
> >      detected by the PCP Client (because this leads to the allocation
> >      of a new IPv6 address).  The PCP Client has to undertake the
> >      operation described in Section 2.4.
> >=3D=3D=3D=3D=3D=3D=3D=3D
> >
> >An issue is still unsolved in the DS-Lite case where the PCP client is
> >not co-located with B4. This issue is not solved in the base PCP spec,
> >but is addressed in this individual draft:
> >http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bi
> >ndi
> >ng-01
> >
> >The recommendation in
> >http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bi
> >ndi
> >ng-01 covers the PCP case, in particular these two recommendations:
> >
> >   3.  In the event a new IPv6 address is assigned to B4, the AFTR
> >       SHOULD migrate existing state to be bound to the new B4's IP
> >       address.  This ensures the traffic destined to the previous IPv6
> >       address will redirected to the new IPv6 address.  The destination
> >       address for tunneling return traffic SHOULD be the last seen
> >       address from the CPE.  The source address of the tunnel would
> >       remain same as AFTR.
> >
> >   4.  In the event of change of the CPE WAN IPv6 prefix, unsolicited
> >       PCP ANNOUNCE messages SHOULD be sent by the B4 element to
> >       internal hosts to update their mappings.
> >
> >Cheers,
> >Med
> >
> >>-----Message d'origine-----
> >>De : pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker
> >>Envoy=E9 : mardi 25 f=E9vrier 2014 03:59 =C0 : dwing@cisco.com;
> >>dthaler@microsoft.com Cc : pcp@ietf.org Objet : Re: [pcp] #34: notify
> >>NAT WAN address changed
> >>
> >>#34: notify NAT WAN address changed
> >>
> >>Changes (by dthaler@microsoft.com):
> >>
> >> * status:  new =3D> closed
> >> * resolution:   =3D> fixed
> >>
> >>
> >>Comment:
> >>
> >> This was addressed in RFC 6887.  Section 14.2 begins:
> >> > 14.2.  PCP Mapping Update
> >> >
> >> >   This rapid recovery mechanism is used when the PCP server
> remembers
> >> >   its state and determines its existing mappings are invalid (e.g., =
IP
> >> >   renumbering changes the external IP address of a PCP-controlled
> >>NAT).
> >>
> >>--
> >>--------------------------------------------------+-------------------
> >>--------------------------------------------------+--
> >> Reporter:  mohamed.boucadair@orange-ftgroup.com  |       Owner:
> >>     Type:  enhancement                           |      Status:  close=
d
> >> Priority:  minor                                 |   Milestone:
> >>Component:  Extensions                            |     Version:
> >> Severity:  -                                     |  Resolution:  fixed
> >> Keywords:                                        |
> >>--------------------------------------------------+-------------------
> >>--------------------------------------------------+--
> >>
> >>Ticket URL:
> >><http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4>
> >>pcp <http://tools.ietf.org/pcp/>
> >>
> >>_______________________________________________
> >>pcp mailing list
> >>pcp@ietf.org
> >>https://www.ietf.org/mailman/listinfo/pcp
> >
> >
>=20


From nobody Thu Feb 27 14:43:00 2014
Return-Path: <dthaler@microsoft.com>
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 56A031A015E for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 14:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level: 
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FQyaCvo9Q03k for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 14:42:54 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 248F21A0131 for <pcp@ietf.org>; Thu, 27 Feb 2014 14:42:53 -0800 (PST)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 27 Feb 2014 22:42:50 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 22:42:50 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "pcp issue tracker" <trac@tools.ietf.org>, "dwing@cisco.com" <dwing@cisco.com>
Thread-Topic: [pcp] #34: notify NAT WAN address changed
Thread-Index: AQHPMdWQIS2flFFrkUulCiX4MJkHkprHQb8AgAJ0U7A=
Date: Thu, 27 Feb 2014 22:42:49 +0000
Message-ID: <c75185cf4b8841e88b43ddeeb238070d@BY2PR03MB412.namprd03.prod.outlook.com>
References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.108.71.45]
x-forefront-prvs: 013568035E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(377454003)(13464003)(86362001)(94946001)(79102001)(94316002)(19580405001)(83322001)(63696002)(80976001)(76576001)(76786001)(76796001)(74706001)(95666003)(74876001)(87266001)(69226001)(90146001)(81542001)(19580395003)(33646001)(93136001)(86612001)(81686001)(59766001)(77982001)(95416001)(74366001)(74316001)(93516002)(81342001)(53806001)(56776001)(31966008)(81816001)(54316002)(76482001)(65816001)(50986001)(47976001)(66066001)(80022001)(92566001)(47446002)(4396001)(74502001)(74662001)(49866001)(47736001)(15975445006)(87936001)(54356001)(56816005)(85852003)(83072002)(85306002)(46102001)(2656002)(15202345003)(24736002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:199.108.71.45; FPR:FCFCFDDD.AFFA17E9.F0C170B8.46EEF74F.20436; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/7iPOyZHXQbX6UbI9yEqmqwS2XUA
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] #34: notify NAT WAN address changed
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 22:42:57 -0000

The DSlite case needs to be treated as a separate issue because it's
a separate doc.   I'll open a separate ticket to track that.

-Dave

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Sent: Wednesday, February 26, 2014 1:11 AM
> To: pcp issue tracker; dwing@cisco.com; Dave Thaler
> Cc: pcp@ietf.org; Suresh Kumar Vinapamula Venkata
> Subject: RE: [pcp] #34: notify NAT WAN address changed
>=20
> Hi Dave, all,
>=20
> I agree most of the issues captured in this ticket are solved, but still =
there is
> one remaining issue.
>=20
> As a reminder, the ticket refers to this text:
>=20
> =3D=3D=3D=3D=3D=3D
> 2.5. Change of the CPE WAN IP Address
>=20
>    The change of the IP address of the WAN interface of the CPE would
>    have an impact on the accuracy of the mappings instantiated in the
>    PCP Server:
>=20
>    o  For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new
>       IPv6 address is used by the B4 element when encapsulating IPv4
>       packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP
>       Client is embedded in the B4, the refresh operation is triggered
>       by the change of the B4 IPv6 address.  This would be more
>       complicated when the PCP Client is located in a device behind the
>       B4.
>=20
>          [Ed.  Note: how an IPv4 host behind a DS-Lite CPE is aware that
>          a new IPv6 address is used by the B4?]
>=20
>    o  For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any
>       change of the assigned IPv6 prefix delegated to the CPE will be
>       detected by the PCP Client (because this leads to the allocation
>       of a new IPv6 address).  The PCP Client has to undertake the
>       operation described in Section 2.4.
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> An issue is still unsolved in the DS-Lite case where the PCP client is no=
t co-
> located with B4. This issue is not solved in the base PCP spec, but is
> addressed in this individual draft: http://tools.ietf.org/search/draft-
> vinapamula-softwire-dslite-prefix-binding-01
>=20
> The recommendation in http://tools.ietf.org/search/draft-vinapamula-
> softwire-dslite-prefix-binding-01 covers the PCP case, in particular thes=
e two
> recommendations:
>=20
>    3.  In the event a new IPv6 address is assigned to B4, the AFTR
>        SHOULD migrate existing state to be bound to the new B4's IP
>        address.  This ensures the traffic destined to the previous IPv6
>        address will redirected to the new IPv6 address.  The destination
>        address for tunneling return traffic SHOULD be the last seen
>        address from the CPE.  The source address of the tunnel would
>        remain same as AFTR.
>=20
>    4.  In the event of change of the CPE WAN IPv6 prefix, unsolicited
>        PCP ANNOUNCE messages SHOULD be sent by the B4 element to
>        internal hosts to update their mappings.
>=20
> Cheers,
> Med
>=20
> >-----Message d'origine-----
> >De=A0: pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker
> >Envoy=E9=A0: mardi 25 f=E9vrier 2014 03:59 =C0=A0: dwing@cisco.com;
> >dthaler@microsoft.com Cc=A0: pcp@ietf.org Objet=A0: Re: [pcp] #34: notif=
y
> >NAT WAN address changed
> >
> >#34: notify NAT WAN address changed
> >
> >Changes (by dthaler@microsoft.com):
> >
> > * status:  new =3D> closed
> > * resolution:   =3D> fixed
> >
> >
> >Comment:
> >
> > This was addressed in RFC 6887.  Section 14.2 begins:
> > > 14.2.  PCP Mapping Update
> > >
> > >   This rapid recovery mechanism is used when the PCP server remembers
> > >   its state and determines its existing mappings are invalid (e.g., I=
P
> > >   renumbering changes the external IP address of a PCP-controlled NAT=
).
> >
> >--
> >--------------------------------------------------+--------------------
> >--------------------------------------------------+-
> > Reporter:  mohamed.boucadair@orange-ftgroup.com  |       Owner:
> >     Type:  enhancement                           |      Status:  closed
> > Priority:  minor                                 |   Milestone:
> >Component:  Extensions                            |     Version:
> > Severity:  -                                     |  Resolution:  fixed
> > Keywords:                                        |
> >--------------------------------------------------+--------------------
> >--------------------------------------------------+-
> >
> >Ticket URL:
> ><http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4>
> >pcp <http://tools.ietf.org/pcp/>
> >
> >_______________________________________________
> >pcp mailing list
> >pcp@ietf.org
> >https://www.ietf.org/mailman/listinfo/pcp


From nobody Thu Feb 27 14:46:13 2014
Return-Path: <trac@tools.ietf.org>
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 2C6DB1A0131 for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 14:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 ThY28_pycIEy for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 14:46:08 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 830F11A00ED for <pcp@ietf.org>; Thu, 27 Feb 2014 14:46:08 -0800 (PST)
Received: from localhost ([127.0.0.1]:39433 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac@tools.ietf.org>) id 1WJ9iB-0003YH-Bw; Thu, 27 Feb 2014 23:45:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-dslite@tools.ietf.org, mohamed.boucadair@orange.com
X-Trac-Project: pcp
Date: Thu, 27 Feb 2014 22:45:51 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/pcp/trac/ticket/71
Message-ID: <066.da9f39acbb4f0e726165162172cd1c41@tools.ietf.org>
X-Trac-Ticket-ID: 71
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-dslite@tools.ietf.org, 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
Resent-To: fdupont@isc.org, jacni@jacni.com, mrw@painless-security.com, tina.tsou.zouting@huawei.com, zhangdacheng@huawei.com
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/IHQU5qnoxYTpM0O-3Ld0LdM3PHU
Cc: pcp@ietf.org
Subject: [pcp]  #71 (dslite): Handling change of B4's IPv6 address
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 22:46:11 -0000

#71: Handling change of B4's IPv6 address

 [DSlite portion of ticket #34 moved to this ticket]

 ======
 2.5. Change of the CPE WAN IP Address

    The change of the IP address of the WAN interface of the CPE would
    have an impact on the accuracy of the mappings instantiated in the
    PCP Server:

    o  For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new
       IPv6 address is used by the B4 element when encapsulating IPv4
       packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP
       Client is embedded in the B4, the refresh operation is triggered
       by the change of the B4 IPv6 address.  This would be more
       complicated when the PCP Client is located in a device behind the
       B4.

          [Ed.  Note: how an IPv4 host behind a DS-Lite CPE is aware that
          a new IPv6 address is used by the B4?]

    o  For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any
       change of the assigned IPv6 prefix delegated to the CPE will be
       detected by the PCP Client (because this leads to the allocation
       of a new IPv6 address).  The PCP Client has to undertake the
       operation described in Section 2.4.
 ========

 An issue is still unsolved in the DS-Lite case where the PCP client is not
 co-located with B4. This issue is not solved in the base PCP spec, but is
 addressed in this individual draft: http://tools.ietf.org/search/draft-
 vinapamula-softwire-dslite-prefix-binding-01

 The recommendation in http://tools.ietf.org/search/draft-vinapamula-
 softwire-dslite-prefix-binding-01 covers the PCP case, in particular these
 two recommendations:

    3.  In the event a new IPv6 address is assigned to B4, the AFTR
        SHOULD migrate existing state to be bound to the new B4's IP
        address.  This ensures the traffic destined to the previous IPv6
        address will redirected to the new IPv6 address.  The destination
        address for tunneling return traffic SHOULD be the last seen
        address from the CPE.  The source address of the tunnel would
        remain same as AFTR.

    4.  In the event of change of the CPE WAN IPv6 prefix, unsolicited
        PCP ANNOUNCE messages SHOULD be sent by the B4 element to
        internal hosts to update their mappings.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-pcp-
  mohamed.boucadair@orange.com       |  dslite@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  dslite                   |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/pcp/trac/ticket/71>
pcp <http://tools.ietf.org/pcp/>


From nobody Thu Feb 27 16:33:04 2014
Return-Path: <sureshk@juniper.net>
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 0D0861A069B for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 16:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 TJWvGutOw5cb for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 16:32:57 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id A3D921A068F for <pcp@ietf.org>; Thu, 27 Feb 2014 16:32:57 -0800 (PST)
Received: from mail224-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Feb 2014 00:32:55 +0000
Received: from mail224-tx2 (localhost [127.0.0.1])	by mail224-tx2-R.bigfish.com (Postfix) with ESMTP id C87ADA00173;	Fri, 28 Feb 2014 00:32:55 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -74
X-BigFish: VPS-74(z551bizbb2dI98dI9371Ic89bh542I1432I15caKJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz97hz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h)
Received-SPF: pass (mail224-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(55784002)(377454003)(479174003)(51704005)(13464003)(189002)(199002)(24454002)(94316002)(74502001)(74662001)(63696002)(74366001)(47446002)(50986001)(76176001)(47736001)(49866001)(86362001)(93516002)(94946001)(81686001)(31966008)(4396001)(51856001)(95666003)(90146001)(85306002)(79102001)(80976001)(92566001)(56816005)(80022001)(76786001)(46102001)(66066001)(76796001)(47976001)(65816001)(83322001)(92726001)(1511001)(19580395003)(95416001)(74706001)(19580405001)(83072002)(53806001)(87266001)(59766001)(77982001)(87936001)(81816001)(2656002)(76482001)(69226001)(93136001)(83506001)(54356001)(36756003)(85852003)(74876001)(54316002)(81342001)(56776001)(81542001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB706; H:CO1PR05MB284.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:FCFEFD1D.AFFA17E9.F4C170BC.4EE2774F.204A3; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2 (MessageSwitch) id 139354757453359_19425; Fri, 28 Feb 2014 00:32:54 +0000 (UTC)
Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.247])	by mail224-tx2.bigfish.com (Postfix) with ESMTP id F2FBFA0060;	Fri, 28 Feb 2014 00:32:53 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 00:32:53 +0000
Received: from BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 00:32:52 +0000
Received: from CO1PR05MB284.namprd05.prod.outlook.com (10.141.70.144) by BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 28 Feb 2014 00:32:51 +0000
Received: from CO1PR05MB284.namprd05.prod.outlook.com ([10.141.70.144]) by CO1PR05MB284.namprd05.prod.outlook.com ([10.141.70.144]) with mapi id 15.00.0883.010; Fri, 28 Feb 2014 00:32:50 +0000
From: Suresh Kumar Vinapamula Venkata <sureshk@juniper.net>
To: Dave Thaler <dthaler@microsoft.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, pcp issue tracker <trac@tools.ietf.org>, "dwing@cisco.com" <dwing@cisco.com>
Thread-Topic: [pcp] #34: notify NAT WAN address changed
Thread-Index: AQHPMdWeDQOTA82BA0m4bjbUYzmRWprHQb4AgAHGg4CAAK4EgP//mSYA
Date: Fri, 28 Feb 2014 00:32:50 +0000
Message-ID: <CF350713.30872%sureshk@juniper.net>
In-Reply-To: <2db04f60e1c749b7abcddec705c31e14@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [66.129.239.14]
x-forefront-prvs: 0136C1DDA4
Content-Type: text/plain; charset="utf-8"
Content-ID: <B4D5BB4FF835D44C9A6ECC76AB02F381@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Fd5fkP6VA90P50KSsPWfgOnKFQU
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] #34: notify NAT WAN address changed
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 00:33:02 -0000

SGkgRGF2ZSwgDQoNCkkgd2FzIHRhbGtpbmcgaW4gdGhlIGNvbnRleHQgb2YgRFMtTGl0ZSwgd2hh
dCBJIG1lYW50IGJ5IENQRSBXQU4gSVAgaXMgdGhlDQpCNCBhZGRyZXNzIG9mIHRoZSBDUEUuIENo
YW5nZSBvZiB0aGF0IGFkZHJlc3MgY291bGQgcmVzdWx0IGluIGluYWNjdXJhY3kNCm9mIHRoYXQg
ZXhpc3RpbmcgbWFwcGluZ3Mgb2YgYm90aCBQQ1AgYW5kIG5vbiBQQ1AuIFRoaXMgZHJhZnQgaXMN
CmFkZHJlc3NpbmcgdGhvc2UgaXNzdWVzLiBNYXkgYmUgIklQIiBhZGRyZXNzLCBtaWdodCBoYXZl
IGNvbmZ1c2VkIHlvdS4NCg0KLVN1cmVzaA0KDQpPbiAyLzI3LzE0IDI6NDAgUE0sICJEYXZlIFRo
YWxlciIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCj5JIGRvbid0IGZvbGxvdy4g
IElmIHRoZSBQQ1Agc2VydmVyIGNvbnRyb2xzIHRoZSBOQVQgaW4gdGhlIENQRSwNCj50aGVuIHRo
ZSBDUEUgV0FOIElQIGFkZHJlc3MgKmlzKiB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcyBvZg0KPnRo
ZSBQQ1AgY29udHJvbGxlZCBOQVQuDQo+DQo+LURhdmUNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+PiBGcm9tOiBTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhIFttYWls
dG86c3VyZXNoa0BqdW5pcGVyLm5ldF0NCj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNywg
MjAxNCAxMjoxOCBQTQ0KPj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHBjcCBp
c3N1ZSB0cmFja2VyOyBkd2luZ0BjaXNjby5jb207DQo+PiBEYXZlIFRoYWxlcg0KPj4gQ2M6IHBj
cEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtwY3BdICMzNDogbm90aWZ5IE5BVCBXQU4gYWRk
cmVzcyBjaGFuZ2VkDQo+PiANCj4+IEhpIERhdmUsDQo+PiANCj4+IFNlY3Rpb24gMTQuMiBvZiBS
RkM2ODg3IGFkZHJlc3NlcyBjaGFuZ2UgaW4gZXh0ZXJuYWwgSVAgYWRkcmVzcyBvZiBQQ1ANCj4+
IGNvbnRyb2xsZWQgTkFULCBhbmQgaXQgZG9lc27CuXQgYWRkcmVzcyBjaGFuZ2UgaW4gQ1BFIFdB
TiBJUCBhZGRyZXNzLg0KPj5UaGlzDQo+PiBkcmFmdCBpcyBhZGRyZXNzaW5nIHRoZSBjaGFuZ2Ug
aW4gQ1BFIFdBTiBJUCBhZGRyZXNzIGFuZCBzdWdnZXN0cw0KPj4gcmVjb21tZW5kYXRpb25zLg0K
Pj4gDQo+PiBUaGFua3MNCj4+IFN1cmVzaA0KPj4gDQo+PiBPbiAyLzI2LzE0IDE6MTEgQU0sICJt
b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n
ZS5jb20+IHdyb3RlOg0KPj4gDQo+PiA+SGkgRGF2ZSwgYWxsLA0KPj4gPg0KPj4gPkkgYWdyZWUg
bW9zdCBvZiB0aGUgaXNzdWVzIGNhcHR1cmVkIGluIHRoaXMgdGlja2V0IGFyZSBzb2x2ZWQsIGJ1
dA0KPj4gPnN0aWxsIHRoZXJlIGlzIG9uZSByZW1haW5pbmcgaXNzdWUuDQo+PiA+DQo+PiA+QXMg
YSByZW1pbmRlciwgdGhlIHRpY2tldCByZWZlcnMgdG8gdGhpcyB0ZXh0Og0KPj4gPg0KPj4gPj09
PT09PQ0KPj4gPjIuNS4gQ2hhbmdlIG9mIHRoZSBDUEUgV0FOIElQIEFkZHJlc3MNCj4+ID4NCj4+
ID4gICBUaGUgY2hhbmdlIG9mIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBXQU4gaW50ZXJmYWNlIG9m
IHRoZSBDUEUgd291bGQNCj4+ID4gICBoYXZlIGFuIGltcGFjdCBvbiB0aGUgYWNjdXJhY3kgb2Yg
dGhlIG1hcHBpbmdzIGluc3RhbnRpYXRlZCBpbiB0aGUNCj4+ID4gICBQQ1AgU2VydmVyOg0KPj4g
Pg0KPj4gPiAgIG8gIEZvciB0aGUgRFMtTGl0ZSBjYXNlIFtJLUQuaWV0Zi1zb2Z0d2lyZS1kdWFs
LXN0YWNrLWxpdGVdOiBpZiBhDQo+Pm5ldw0KPj4gPiAgICAgIElQdjYgYWRkcmVzcyBpcyB1c2Vk
IGJ5IHRoZSBCNCBlbGVtZW50IHdoZW4gZW5jYXBzdWxhdGluZyBJUHY0DQo+PiA+ICAgICAgcGFj
a2V0cyBpbiBJUHY2IG9uZXMsIHRoZSBtYXBwaW5ncyBTSE9VTEQgYmUgcmVmcmVzaGVkOiBJZiB0
aGUNCj4+UENQDQo+PiA+ICAgICAgQ2xpZW50IGlzIGVtYmVkZGVkIGluIHRoZSBCNCwgdGhlIHJl
ZnJlc2ggb3BlcmF0aW9uIGlzIHRyaWdnZXJlZA0KPj4gPiAgICAgIGJ5IHRoZSBjaGFuZ2Ugb2Yg
dGhlIEI0IElQdjYgYWRkcmVzcy4gIFRoaXMgd291bGQgYmUgbW9yZQ0KPj4gPiAgICAgIGNvbXBs
aWNhdGVkIHdoZW4gdGhlIFBDUCBDbGllbnQgaXMgbG9jYXRlZCBpbiBhIGRldmljZSBiZWhpbmQg
dGhlDQo+PiA+ICAgICAgQjQuDQo+PiA+DQo+PiA+ICAgICAgICAgW0VkLiAgTm90ZTogaG93IGFu
IElQdjQgaG9zdCBiZWhpbmQgYSBEUy1MaXRlIENQRSBpcyBhd2FyZQ0KPj50aGF0DQo+PiA+ICAg
ICAgICAgYSBuZXcgSVB2NiBhZGRyZXNzIGlzIHVzZWQgYnkgdGhlIEI0P10NCj4+ID4NCj4+ID4g
ICBvICBGb3IgdGhlIE5BVDY0IGNhc2UgW0ktRC5pZXRmLWJlaGF2ZS12NnY0LXhsYXRlLXN0YXRl
ZnVsXSwgYW55DQo+PiA+ICAgICAgY2hhbmdlIG9mIHRoZSBhc3NpZ25lZCBJUHY2IHByZWZpeCBk
ZWxlZ2F0ZWQgdG8gdGhlIENQRSB3aWxsIGJlDQo+PiA+ICAgICAgZGV0ZWN0ZWQgYnkgdGhlIFBD
UCBDbGllbnQgKGJlY2F1c2UgdGhpcyBsZWFkcyB0byB0aGUgYWxsb2NhdGlvbg0KPj4gPiAgICAg
IG9mIGEgbmV3IElQdjYgYWRkcmVzcykuICBUaGUgUENQIENsaWVudCBoYXMgdG8gdW5kZXJ0YWtl
IHRoZQ0KPj4gPiAgICAgIG9wZXJhdGlvbiBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjQuDQo+PiA+
PT09PT09PT0NCj4+ID4NCj4+ID5BbiBpc3N1ZSBpcyBzdGlsbCB1bnNvbHZlZCBpbiB0aGUgRFMt
TGl0ZSBjYXNlIHdoZXJlIHRoZSBQQ1AgY2xpZW50IGlzDQo+PiA+bm90IGNvLWxvY2F0ZWQgd2l0
aCBCNC4gVGhpcyBpc3N1ZSBpcyBub3Qgc29sdmVkIGluIHRoZSBiYXNlIFBDUCBzcGVjLA0KPj4g
PmJ1dCBpcyBhZGRyZXNzZWQgaW4gdGhpcyBpbmRpdmlkdWFsIGRyYWZ0Og0KPj4gPmh0dHA6Ly90
b29scy5pZXRmLm9yZy9zZWFyY2gvZHJhZnQtdmluYXBhbXVsYS1zb2Z0d2lyZS1kc2xpdGUtcHJl
Zml4LWJpDQo+PiA+bmRpDQo+PiA+bmctMDENCj4+ID4NCj4+ID5UaGUgcmVjb21tZW5kYXRpb24g
aW4NCj4+ID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvc2VhcmNoL2RyYWZ0LXZpbmFwYW11bGEtc29m
dHdpcmUtZHNsaXRlLXByZWZpeC1iaQ0KPj4gPm5kaQ0KPj4gPm5nLTAxIGNvdmVycyB0aGUgUENQ
IGNhc2UsIGluIHBhcnRpY3VsYXIgdGhlc2UgdHdvIHJlY29tbWVuZGF0aW9uczoNCj4+ID4NCj4+
ID4gICAzLiAgSW4gdGhlIGV2ZW50IGEgbmV3IElQdjYgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byBC
NCwgdGhlIEFGVFINCj4+ID4gICAgICAgU0hPVUxEIG1pZ3JhdGUgZXhpc3Rpbmcgc3RhdGUgdG8g
YmUgYm91bmQgdG8gdGhlIG5ldyBCNCdzIElQDQo+PiA+ICAgICAgIGFkZHJlc3MuICBUaGlzIGVu
c3VyZXMgdGhlIHRyYWZmaWMgZGVzdGluZWQgdG8gdGhlIHByZXZpb3VzIElQdjYNCj4+ID4gICAg
ICAgYWRkcmVzcyB3aWxsIHJlZGlyZWN0ZWQgdG8gdGhlIG5ldyBJUHY2IGFkZHJlc3MuICBUaGUN
Cj4+ZGVzdGluYXRpb24NCj4+ID4gICAgICAgYWRkcmVzcyBmb3IgdHVubmVsaW5nIHJldHVybiB0
cmFmZmljIFNIT1VMRCBiZSB0aGUgbGFzdCBzZWVuDQo+PiA+ICAgICAgIGFkZHJlc3MgZnJvbSB0
aGUgQ1BFLiAgVGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSB0dW5uZWwgd291bGQNCj4+ID4gICAg
ICAgcmVtYWluIHNhbWUgYXMgQUZUUi4NCj4+ID4NCj4+ID4gICA0LiAgSW4gdGhlIGV2ZW50IG9m
IGNoYW5nZSBvZiB0aGUgQ1BFIFdBTiBJUHY2IHByZWZpeCwgdW5zb2xpY2l0ZWQNCj4+ID4gICAg
ICAgUENQIEFOTk9VTkNFIG1lc3NhZ2VzIFNIT1VMRCBiZSBzZW50IGJ5IHRoZSBCNCBlbGVtZW50
IHRvDQo+PiA+ICAgICAgIGludGVybmFsIGhvc3RzIHRvIHVwZGF0ZSB0aGVpciBtYXBwaW5ncy4N
Cj4+ID4NCj4+ID5DaGVlcnMsDQo+PiA+TWVkDQo+PiA+DQo+PiA+Pi0tLS0tTWVzc2FnZSBkJ29y
aWdpbmUtLS0tLQ0KPj4gPj5EZSA6IHBjcCBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXSBE
ZSBsYSBwYXJ0IGRlIHBjcCBpc3N1ZSB0cmFja2VyDQo+PiA+PkVudm95w6kgOiBtYXJkaSAyNSBm
w6l2cmllciAyMDE0IDAzOjU5IMOAIDogZHdpbmdAY2lzY28uY29tOw0KPj4gPj5kdGhhbGVyQG1p
Y3Jvc29mdC5jb20gQ2MgOiBwY3BAaWV0Zi5vcmcgT2JqZXQgOiBSZTogW3BjcF0gIzM0OiBub3Rp
ZnkNCj4+ID4+TkFUIFdBTiBhZGRyZXNzIGNoYW5nZWQNCj4+ID4+DQo+PiA+PiMzNDogbm90aWZ5
IE5BVCBXQU4gYWRkcmVzcyBjaGFuZ2VkDQo+PiA+Pg0KPj4gPj5DaGFuZ2VzIChieSBkdGhhbGVy
QG1pY3Jvc29mdC5jb20pOg0KPj4gPj4NCj4+ID4+ICogc3RhdHVzOiAgbmV3ID0+IGNsb3NlZA0K
Pj4gPj4gKiByZXNvbHV0aW9uOiAgID0+IGZpeGVkDQo+PiA+Pg0KPj4gPj4NCj4+ID4+Q29tbWVu
dDoNCj4+ID4+DQo+PiA+PiBUaGlzIHdhcyBhZGRyZXNzZWQgaW4gUkZDIDY4ODcuICBTZWN0aW9u
IDE0LjIgYmVnaW5zOg0KPj4gPj4gPiAxNC4yLiAgUENQIE1hcHBpbmcgVXBkYXRlDQo+PiA+PiA+
DQo+PiA+PiA+ICAgVGhpcyByYXBpZCByZWNvdmVyeSBtZWNoYW5pc20gaXMgdXNlZCB3aGVuIHRo
ZSBQQ1Agc2VydmVyDQo+PiByZW1lbWJlcnMNCj4+ID4+ID4gICBpdHMgc3RhdGUgYW5kIGRldGVy
bWluZXMgaXRzIGV4aXN0aW5nIG1hcHBpbmdzIGFyZSBpbnZhbGlkDQo+PihlLmcuLCBJUA0KPj4g
Pj4gPiAgIHJlbnVtYmVyaW5nIGNoYW5nZXMgdGhlIGV4dGVybmFsIElQIGFkZHJlc3Mgb2YgYSBQ
Q1AtY29udHJvbGxlZA0KPj4gPj5OQVQpLg0KPj4gPj4NCj4+ID4+LS0NCj4+ID4+LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KPj4gPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSstLQ0KPj4gPj4gUmVwb3J0ZXI6ICBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UtZnRncm91
cC5jb20gIHwgICAgICAgT3duZXI6DQo+PiA+PiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czoNCj4+Y2xvc2VkDQo+PiA+PiBQcmlv
cml0eTogIG1pbm9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9u
ZToNCj4+ID4+Q29tcG9uZW50OiAgRXh0ZW5zaW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICBWZXJzaW9uOg0KPj4gPj4gU2V2ZXJpdHk6ICAtICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgIFJlc29sdXRpb246DQo+PmZpeGVkDQo+PiA+PiBLZXl3b3Jkczog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gPj4tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t
LS0tDQo+PiA+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tKy0tDQo+PiA+Pg0KPj4gPj5UaWNrZXQgVVJMOg0KPj4gPj48aHR0cDovL3RyYWMudG9vbHMu
aWV0Zi5vcmcvd2cvcGNwL3RyYWMvdGlja2V0LzM0I2NvbW1lbnQ6ND4NCj4+ID4+cGNwIDxodHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvcGNwLz4NCj4+ID4+DQo+PiA+Pl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PnBjcCBtYWlsaW5nIGxpc3QNCj4+ID4+
cGNwQGlldGYub3JnDQo+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
cGNwDQo+PiA+DQo+PiA+DQo+PiANCj4NCj4NCj4NCg0K


From nobody Thu Feb 27 20:37:14 2014
Return-Path: <repenno@cisco.com>
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 C84961A06FA for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 20:37:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level: 
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 8QicJfoHWxkZ for <pcp@ietfa.amsl.com>; Thu, 27 Feb 2014 20:37:08 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 18CD21A06DF for <pcp@ietf.org>; Thu, 27 Feb 2014 20:37:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1393562227; x=1394771827; h=from:to:subject:date:message-id:mime-version; bh=+5Lk0wsZ8y1zI1b/xpacX5yO6MMqBhGx/ZjO7MMwjM0=; b=B+QjLTCtXKEv73Urs+/KHiAbflqozyTcyXUFoUH++epseRpWPXnZ7+Z/ M0ss9EZw537QUpeL12cfDKJkkfVJNmXSIPFtEQgWwNvNA4XJDmgf3bNnH DA17CUdvYdu5agytkXgLo6C+yvyhRSHnbmQugmn4LHdv3VKHHL6k2/z1S I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar4IAEwREFOtJXG//2dsb2JhbABagkJEO1eEIbQniVwWdIIcDgKBCwELAXQnBByHcA2bMLAAF5MTBJg4kiqDLYIq
X-IronPort-AV: E=Sophos;i="4.97,559,1389744000";  d="scan'208,217";a="307139376"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 28 Feb 2014 04:37:06 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1S4b6Os023766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Fri, 28 Feb 2014 04:37:06 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.98]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 22:37:06 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: PCP Working Group <pcp@ietf.org>
Thread-Topic: PCP Interop Report - Apple Airport Extreme
Thread-Index: AQHPND67RvotjnUmr0m5xviztcGU1w==
Date: Fri, 28 Feb 2014 04:37:05 +0000
Message-ID: <CF35521C.9CA1%repenno@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.77.147]
Content-Type: multipart/alternative; boundary="_000_CF35521C9CA1repennociscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/gdssOqPCTk5MU81wG8gpGDXPOYo
Subject: [pcp] PCP Interop Report - Apple Airport Extreme
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2014 04:37:10 -0000

--_000_CF35521C9CA1repennociscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If there is time and interest at next meeting I can go through the slides.

For reference, slides are here:

http://www.ietf.org/proceedings/89/slides/slides-89-pcp-1.pdf

New versions will be committed to Github

Regards,

Reinaldo

--_000_CF35521C9CA1repennociscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <A5E5568060F09C41B21E188083574855@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif;">
<div>If there is time and interest at next meeting I can go through the sli=
des.</div>
<div><br>
</div>
<div>For reference, slides are here:</div>
<div><br>
</div>
<div><a href=3D"http://www.ietf.org/proceedings/89/slides/slides-89-pcp-1.p=
df">http://www.ietf.org/proceedings/89/slides/slides-89-pcp-1.pdf</a></div>
<div><br>
</div>
<div>New versions will be committed to Github</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Reinaldo</div>
</body>
</html>

--_000_CF35521C9CA1repennociscocom_--