Re: [pcp] Confirming consensus from WG meetings

[Margaret Wasserman <[e-mail]>]

Hi Wim,

As I said in my response to Christian, we do not have the option of publishing the Base Specification now with the THIRD_PARTY option in it and no mandatory-to-implement security mechanism.  We either need to add a normative reference to a security mechanism to the Base Spec (and wait for the security mechanism to be approved before we publish the Base Spec), or break the THIRD_PARTY option out in to a separate document (that will normatively reference a security mechanism), so that we can get the rest of the Base Spec published now.

Could you please read my response to Christian (my previous message to PCP), and let me know which of the two choices listed in that message you would actually prefer?

Thanks,
Margaret


On Mar 29, 2012, at 10:30 AM, Henderickx, Wim (Wim) wrote:

> +1
> 
> Cheers,
> Wim
> _________________
> sent from blackberry
> 
> ----- Original Message -----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, March 29, 2012 10:29 AM
> To: BOUCADAIR Mohamed OLNC/NAD/TIP <[e-mail]>; Dave Thaler <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: [pcp] Confirming consensus from WG meetings
> 
> Dave, all,
> 
> I'd like to second Med's comment. 
> 
> I'm too opposed to motion #1 below, especially in light of the need for the THIRD_PARTY option for DS-Lite deployments that will start in a couple of months from now as far as some service providers are concerned. The security concerns that have been raised so far do not apply to DS-Lite scenarios, as reminded by Med below.
> 
> I think the -24 is in a sufficiently good shape to be published as is, whereas DS-Lite scenarios remain one of the most straightforward use cases for PCP applicability, and was actually a key driver for the initial base spec effort back in 2010.
> 
> Simply ignoring what becomes a fact in the very short term because of security considerations that do not apply to such use case is not a good enough reason for me to defer the standardization of the THIRD PARTY at who-knows-when.
> 
> Cheers,
> 
> Christian.
> 
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
> Envoyé : jeudi 29 mars 2012 10:15
> À : Dave Thaler; [e-mail]
> Objet : Re: [pcp] Confirming consensus from WG meetings
> 
> Dear Dave, all,
> 
> I was one of the 2 who objected to remove the THIRD_PARTY Option from the base spec. I maintain my objection because I see THIRD_PARTY as an important feature: allow to instruct mappings for non pcp compliant hosts/applications.   
> 
> Adding a normative ref to draft-wasserman for the THIRD_PARTY is too strong IMHO. The major scenarios which driven so far the development of PCP do not require authenticated PCP communications: why doing this for explicit mapping while this is not required for implicit mappings!
> 
> I do not want to slow down the progress of PCP base spec but cutting the important features from the base spec won't help too. 
> 
> Cheers,
> Med 
> 
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]] De la part de 
>> Dave Thaler Envoyé : jeudi 29 mars 2012 10:00 À : [e-mail] Objet : 
>> [pcp] Confirming consensus from WG meetings
>> 
>> We got consensus among those at the meetings on the following, and want 
>> to confirm WG consensus on the list, in case there are new objections 
>> raised or folks who were not present in the room at the time.
>> 
>> 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2 
>> against)
>> 	This would resolve Stephen Farrell's discuss, allowing the base spec
>> 	to be published quickly.   The alternative would likely 
>> take a lot more
>> 	time to address, especially given that we already moved DS-lite
>> 	discussion out of the base spec, and the DS-lite scenario was a key
>> 	motivation for THIRD_PARTY.
>> 
>> 2) Add a client-specified per-mapping nonce (no strong objections)
>> 	Belief is this is needed to resolve the transaction ID discuss's.
>> 	WG will not add a transaction id, but will add a per-mapping
>> 	nonce instead.
>> 
>> 3) Without having resolved the question of inline vs PANA first, adopt 
>> draft-wasserman-pcp-authentication as a working group document
>> (12 in favor, 3 against)
>> 	This would be the basis of the pcp security document.  Belief is
>> 	that much of the current document is independent of the 
>> 	unresolved question on the table, and the WG draft should
>> 	be agnostic on that question.
>> 
>> 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus
>> 	among those who've read it)
>> 
>> Barring new objections that were not raised at the meeting, we plan to 
>> go forward with the above consensus items.
>> 
>> -Dave
>> 
>> _______________________________________________
>> pcp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pcp
>> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp