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

Hi,

see inline.

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

> -----Original Message-----
> From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of ??Dan Wing
> Sent: Donnerstag, 8. Januar 2015 17:21
> To: pcp issue tracker
> Cc: draft-ietf-pcp-third-party-id-option@tools.ietf.org; pcp@ietf.org
> Subject: 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?

The option would be unkown to the server and as per 6887 an UNSUPP_OPTION error should be generated. Which is desired and correct and independent of whether there is THIRD_PARTY option additionally in the packet or not. 

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

Well, it seems from the current discussion, that there might be cases, when the THIRD_PARTY option is not needed and we might need to update the draft accordingly. In that case there is some text missing to explain when the option might not be needed and potentially an error to signal to the client, that the THIRD_PARTY option is expected.

Rolf

> 
> -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
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp