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

[Andreas Ripke <[e-mail]>]

The new draft-ietf-pcp-third-party-id-option-01 addresses these comments.
See inline.

Andreas

> -----Original Message-----
> From: pcp [mailto:[e-mail]] On Behalf Of Dave Thaler
> Sent: Thursday, January 08, 2015 9:30 PM
> To: 🔓Dan Wing; pcp issue tracker
> Cc: [e-mail]; [e-mail]
> Subject: 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:[e-mail]]
> > Sent: Thursday, January 8, 2015 8:21 AM
> > To: pcp issue tracker
> > Cc: [e-mail]; Dave Thaler;
> > [e-mail]
> > 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 <[e-mail]> 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.

Some were changed but there are still places mentioning a "tunnel"
because the described scenarios use tunnels. It is mentioned in
section 3.3 that other identifiers can be used as well.

> > > 2) Need to explicitly state the assumption that the same PCP-IWF
> > > serves multiple subscribers.
> > >     (It was implicit currently, but should be explicit.)

This is now mentioned in section 3.

"For
this purpose the PCP IWF contains a PCP client serving multiple 
subscribers and the CGN is co-located with a PCP server."

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

This is now mentioned in the last paragraph of section 4.

"The identifier field can contain any deployment specific value the
PCP client and the PCP server agree on.  How this agreement is
reached if both PCP server and client are not administered by the
same entity is beyond the scope of this document."

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

The success case is added to section 5.2.

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

Reporting an error is kept in the text.
Without reporting an error we wouldn't need a diversity of error codes
because the PCP client can't recover from using a wrong identifier on its own
and most probably must be re-configured manually by the subscriber.

> > > --
> > > -------------------------+------------------------------------------
> > > -------------------------+--
> > > -------------------------+-----
> > > Reporter:               |      Owner:  draft-ietf-pcp-third-party-id-
> > >  [e-mail]  |  [e-mail]
> > >     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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp