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

> -----Original Message-----
> From: 🔓Dan Wing [mailto:dwing@cisco.com]
> Sent: Thursday, January 8, 2015 8:21 AM
> To: pcp issue tracker
> Cc: draft-ietf-pcp-third-party-id-option@tools.ietf.org; Dave Thaler;
> 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?

Yes.  6887's use of a mapping table says nothing about any third party ID.
So there needs to be at least a sentence or two to say that the third party ID
is used when doing a lookup or creation in the mapping table, for instance.
Such text belongs in this section, which is about what to do when you get this
option.

Section 2 already says:
"Unlike a standard NAT, it
   includes a subscriber identifier in addition to the source IP address
   in entries of the NAT mapping table."

That's halfway there.  Now 5.2 just needs text that says how that affect
MAP/PEER processing when the id is received.

RFC 6887 section 11.3 states:
"   If the internal port, protocol, and internal address match an
   existing static mapping (which will have no nonce), then a PCP reply
   is sent giving the external address and port of that static mapping,
   using the nonce from the PCP request."

That's an example of a sentence that's Updated.  So we could just say
something along the lines of "If the id is legal, then the message is
processed as specified in RFC 6887, except that the third party id is
always used in addition to the internal address when accessing a
mapping table, whenever RFC 6887 would access a mapping with
a given internal address".

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