Re: [pcp] #75 (third-party-id-option): Dave Thaler's comments on draft-ietf-pcp-third-party-id-option-00

On Jan 7, 2015, at 2:42 PM, pcp issue tracker <trac@tools.ietf.org> wrote:

> #75: Dave Thaler's comments on draft-ietf-pcp-third-party-id-option-00
> 
> A copy with my comments inline is now at
> http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-party-id-
> option-00.pdf
> 
> Summary:
> 1) Too many places are still worded to be about "tunnel ID" rather than
> "third party ID".
>    This draft shouldn't assume tunnels, that's just one example case.
> 2) Need to explicitly state the assumption that the same PCP-IWF serves
> multiple subscribers.
>     (It was implicit currently, but should be explicit.)
> 3) Need to explicitly state the assumption that the PCP client and PCP
> server have some
>     out-of-band mechanism to agree on what to put in the THIRD_PARTY_ID
> field.
>     (Again it was implicit, but should be explicit.)
> 4) Section 5.2 on processing a request needs to cover the success case,
> not just the error case.

Yes.  Section 5 is very short, and provides little-to-no guidance 

>     And I believe that behavior changes the basic rules in RFC 6887

Yes, draft-ietf-pcp-third-party-id-option-00 requires that if THIRD_PARTY_ID is present, then THIRD_PARTY must also be present.  I'm not sure if that qualifies as an Update to RFC6887, though.  Are there other changes to 6887's basic rules?  

Certainly, the I-D should be much clearer that presence of THIRD_PARTY_ID means that THIRD_PARTY must also be present.  Existing wording in 5.1 is not sufficiently clear to make that point obvious when generating a request (needs a MUST and at least sentence restructuring).

-d

> and
> hence this document
>     should Update 6887.  I.e. you cannot simply implement this as a layer
> on top of an
>     unmodified 6887-compliant PCP implementation.
> 5) Section 5.3 on processing a response has a new requirement "SHOULD
> report an error"
>      which is not in RFC 6887 section 11.4 or 12.4.   Is this really a
> requirement?  I'm ok
>     either way, but not sure why this specific error response would be
> special in terms
>     of what should be reported to somewhere.
> 
> -- 
> -------------------------+-------------------------------------------------
> Reporter:               |      Owner:  draft-ietf-pcp-third-party-id-
>  dthaler@microsoft.com  |  option@tools.ietf.org
>     Type:  defect       |     Status:  new
> Priority:  major        |  Milestone:  milestone1
> Component:  third-       |    Version:  1.0
>  party-id-option        |   Keywords:
> Severity:  In WG Last   |
>  Call                   |
> -------------------------+-------------------------------------------------
> 
> Ticket URL: <http://tools.ietf.org/wg/pcp/trac/ticket/75>
> pcp <http://tools.ietf.org/pcp/>
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp