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

[Rolf Winter <[e-mail]>]

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

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:[e-mail]] On Behalf Of Andreas Ripke
> Sent: Freitag, 16. Januar 2015 12:01
> To: [e-mail]
> Subject: Re: [pcp] #75 (third-party-id-option): Dave Thaler's comments
> on draft-ietf-pcp-third-party-id-option-00
> 
> 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
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp