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

From: "pcp issue tracker" <[email-masked]>
Date: Wed, 07 Jan 2015 22:42:46 -0000

#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.
     And I believe that behavior changes the basic rules in RFC 6887 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-
  [email-masked]  |  [email-masked]
     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/>

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 8 Jan 2015 08:21:12 -0800

> 4) Section 5.2 on processing a request needs to cover the success 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
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Rolf Winter <[email-masked]>
Date: Thu, 8 Jan 2015 16:34:19 +0000

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:[email-masked]] On Behalf Of ??Dan Wing
> Sent: Donnerstag, 8. Januar 2015 17:21
> To: pcp issue tracker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] #75 (third-party-id-option): Dave Thaler's comments
> on draft-ietf-pcp-third-party-id-option-00
> 
> 
> > 1) Too many places are still worded to be about "tunnel ID" rather
> > than "third party ID".
> > 2) Need to explicitly state the assumption that the same PCP-IWF
> > serves multiple subscribers.
> >     out-of-band mechanism to agree on what to put in the
> > THIRD_PARTY_ID field.
> > 4) Section 5.2 on processing a request needs to cover the success
> > case, not just the error case.
> 
> 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
> > -------------------------+-------------------------------------------
> -
> > -------------------------+-----
> > -------------------------+-------------------------------------------
> -
> > -------------------------+-----
> >

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Jan 2015 20:30:00 +0000

> From: 🔓Dan Wing [mailto:[email-masked]]
> Sent: Thursday, January 8, 2015 8:21 AM
> To: pcp issue tracker
> Cc: [email-masked]; Dave Thaler;
> [email-masked]
> Subject: Re: [pcp] #75 (third-party-id-option): Dave Thaler's comments on
> draft-ietf-pcp-third-party-id-option-00
> 
> 
> 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
> > -------------------------+--------------------------------------------
> > -------------------------+--------------------------------------------

---

From: Andreas Ripke <[email-masked]>
Date: Fri, 16 Jan 2015 11:01:03 +0000

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

Andreas

> From: pcp [mailto:[email-masked]] On Behalf Of Dave Thaler
> Sent: Thursday, January 08, 2015 9:30 PM
> To: 🔓Dan Wing; pcp issue tracker
> Subject: Re: [pcp] #75 (third-party-id-option): Dave Thaler's comments on draft-
> ietf-pcp-third-party-id-option-00
> 

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.

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

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

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

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"
> > >     either way, but not sure why this specific error response would
> > > be special in terms

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.

> > > --
> > > -------------------------+------------------------------------------
> > > -------------------------+--
> > > -------------------------+------------------------------------------
> > > -------------------------+--

---

From: Rolf Winter <[email-masked]>
Date: Mon, 26 Jan 2015 09:31:12 +0000

Question to the people who have commented on the draft before (thanks for thorough review). We believe we have addressed all previous comments in this version, would you agree or do you think further changes are needed to address you previous comments?

Thanks,

Rolf

> From: pcp [mailto:[email-masked]] On Behalf Of Andreas Ripke
> Sent: Freitag, 16. Januar 2015 12:01
> To: [email-masked]
> > > Cc: [email-masked]; Dave
> > > Thaler; [email-masked]
> > > > http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-
> party-
> > > > id
> > > > -
> > > > option-00.pdf
> > > >
> > > > Summary:
> because the described scenarios use tunnels. It is mentioned in section
> 3.3 that other identifiers can be used as well.
> 
> "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."
> 
> > > 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?
> >
> > 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:
> > That's halfway there.  Now 5.2 just needs text that says how that
> > affect MAP/PEER processing when the id is received.
> >
> > mapping table, whenever RFC 6887 would access a mapping with a given
> internal address".
> >
> > >
> > > 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
> > > >     either way, but not sure why this specific error response
> > > > would be special in terms
> 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.
> 
> > > > --
> > > > -------------------------+---------------------------------------
> -
> > > > -------------------------+---------------------------------------
> -