Subject: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised

From: Dave Thaler <[email-masked]>
Date: Fri, 30 Mar 2012 14:43:27 +0000

Based on the feedback received during the meeting and on this thread
from various people reporting they were blocked on THIRD_PARTY for
deploying PCP for the web portal case, I met with Stephen Farrell today
to report on the WG feedback and have a new proposal for the WG's
review, which Stephen would be okay with if worded properly.

The proposal is to split how we think about THIRD_PARTY into two
separate options with different Option Codes (though the rest of 
the option format may be identical), one in the base spec and one
moved out of it.  Specifically:

* One is for use cases where the PCP client and PCP server are owned
   and operated by the same entity and are placed on an entirely
   trusted network.   That is explicitly not a home network nor a typical
   enterprise network.   A PCP server intended for a home network
   MUST NOT support this option.    This option can appear in the
   pcp-base spec with the above restrictions and is intended to 
   unblock the deployments of the people who objected to the 
   "separate it out" proposal.   As noted below, we rename this option
   to something else (SAME_PARTY?) and use the term THIRD_PARTY
   for the next one.

* The second option would be separated out of the pcp-base spec,
   would mandate that it be protected via whatever advanced security
   mechanism we decide on, and be usable for more general cases
   where the PCP client and PCP server could even be owned by
   different entities and hence the term "THIRD_PARTY" is more
   appropriate to retain for this option.

With appropriate wordsmithing, is this approach something we
can quickly get consensus on?

-Dave

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Mar 2012 12:05:15 -0400

>>>>> "Dave" == Dave Thaler <[email-masked]> writes:

    Dave> * One is for use cases where the PCP client and PCP server are
    Dave> owned and operated by the same entity and are placed on an
    Dave> entirely trusted network.  That is explicitly not a home
    Dave> network nor a typical enterprise network.  A PCP server
    Dave> intended for a home network MUST NOT support this option.
    Dave> This option can appear in the pcp-base spec with the above
    Dave> restrictions and is intended to unblock the deployments of the
    Dave> people who objected to the "separate it out" proposal.  As
    Dave> noted below, we rename this option to something else
    Dave> (SAME_PARTY?) and use the term THIRD_PARTY for the next one.

I don't support this option in the base spec.  Any such trusted network
is an environment where it would be reasonably easy to share credentials
between the PCP server and a authorized party.  So, such an option is an
excellent candidate to be used along side a mandatory-to-implement
security mechanism.  (Mandatory-to-implement security mechanisms are not
mandatory-to-use. If you don't think it is worth credentialing and would
prefer to turn off security, that's fine.)

As a result I believe we would produce a higher-quality spec if we had
only one third-party option. This compromise produces a technically
inferior result simply to get the third party option specified 6-9
months earlier.

I prefer either 

1) Moving the third-party option to its own document

or
2) delaying the base spec

to this compromise option.

--Sam