Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

[Rolf Winter <[e-mail]>]

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:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Montag, 19. Januar 2015 11:00
> To: Andreas Ripke
> Cc: [e-mail]
> Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> comments on draft-ietf-pcp-third-party-id-option-00
> 
> Dear Andreas,
> 
> The explanation provided by Juergen for the point about including a
> recommended supported max length makes sense.
> 
> This version is much better. Below some comments about this version:
> 
> * You may consider adding some words about the lifetime of the errors
> (short/long) + a description text for each new result code.
> * Section 7:
>  (1) Cite the appropriate sections from RFC6887.
>  (2) I would update this sentence " The
>    THIRD_PARTY_ID option might carry privacy information like location
>    or profile information. " to for example: "The
>    THIRD_PARTY_ID option might carry privacy information like location
>    or profile information. Means to defend against such practice should
> be enabled."

I don't think this additional sentence makes sense. I think what you mean is something along these lines: "Means to protect unauthorized access to this information should be put in place."

Is that correct?

Best,

Rolf

> 
> Thank you.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : pcp [mailto:[e-mail]] De la part de Andreas Ripke
> Envoyé : vendredi 16 janvier 2015 12:00 À : [e-mail] Objet : Re:
> [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on
> draft-ietf-pcp-third-party-id-option-00
> 
> >From the proposed two technical modifications
> the recommended fixed maximum option length of 128 octets was not
> included into the new draft-ietf-pcp-third-party-id-option-01
> as argued below. The RFC 6887 limits already the overall option space
> and the future use of this identifier shouldn't be unnecessarily
> limited by currently used identifiers.
> 
> Using the THIRD_PARTY_ID option without the THIRD_PARTY option was
> adopted as deployment cases are already known.
> 
> Some of the Med's other editing comments were included as appropriate
> for the technical change.
> 
> Andreas
> 
> > -----Original Message-----
> > From: Juergen Quittek
> > Sent: Friday, January 09, 2015 3:11 PM
> > To: [e-mail]; Dave Thaler; Andreas Ripke;
> > [e-mail]
> > Subject: RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> > comments on draft-ietf-pcp-third-party-id-option-00
> >
> > Hi Med,
> >
> > I have a different view on the option length handling. The option is
> > used to managed entries in mapping tables. I would assume that when
> > you implement a server and its mapping tables you know which sizes of
> > THIRD_PARTY_IDs your table can support. If the server receives a
> > request with a not supported option length, it should return an error
> > message. It does not matter if the option length is too long or too
> short.
> >
> > Cheers,
> >     Juergen
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Freitag, 9. Januar 2015 11:21
> > > To: Juergen Quittek; Dave Thaler; Andreas Ripke; [e-mail]
> > > Subject: RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> > > comments on draft-ietf-pcp-third-party-id-option-00
> > >
> > > Re-,
> > >
> > > Thank you for the clarification.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > -----Message d'origine-----
> > > De : Juergen Quittek [mailto:[e-mail]] Envoyé : vendredi 9
> > > janvier 2015 08:41 À : BOUCADAIR Mohamed IMT/OLN; Dave Thaler;
> > Andreas
> > > Ripke; [e-mail] Objet : RE: [pcp] #74 (third-party-id-option):
> > > Mohamed Boucadair's comments on
> > > draft-ietf-pcp-third-party-id-option-00
> > >
> > > Hi Med,
> > >
> > > > -----Original Message-----
> > > > From: pcp [mailto:[e-mail]] On Behalf Of
> > > > [e-mail]
> > > > Sent: Freitag, 9. Januar 2015 07:57
> > > > To: Dave Thaler; Andreas Ripke; [e-mail]
> > > > Subject: Re: [pcp] #74 (third-party-id-option): Mohamed
> > > > Boucadair's
> > > comments
> > > > on draft-ietf-pcp-third-party-id-option-00
> > > >
> > > > Hi Dave,
> > > >
> > > > Hmm...but what will be the behavior of the server if it is not
> > > > designed to support a length included in the PCP request? Should
> > > > it truncate
> > the fiele?
> > >
> > > Hi Med. This case is pretty clear. Of course it should not truncate
> an ID.
> > > If a server cannot support an ID sent to it, the ID is obviously
> > > unsuited and it should return an error message.
> > >
> > > [Med] Agree. I'm expecting some text to call this out. A new result
> > > code is to be defined IMHO: e.g., UNSUPP_OPTION_LENGTH or something
> > similar.
> > >
> > > > Shouldn't this will lead to some side effects such as
> encountering
> > > > errors to
> > > send
> > > > a response or to validate the response at the client side because
> > > > the content
> > > of
> > > > the THIRD_PARTY_ID as included in the response does not match
> what
> > > > has been included in the response, etc.?
> > >
> > > If a server implements the THIRD_PARTY_ID, it needs to implement
> PCP
> > > variable length options and be able to return them in an error
> > > message.
> > >
> > > [Med] Agree about this. My point is I want to be sure no error is
> > > returned for a THIRD_PARTY_ID < 128 octets.
> > >
> > > > For these reasons and also to help the design of PCP server, I do
> > > > still think a max should be included as part of the specification.
> > > > 128 octets seems reasonable.
> > >
> > > The PCP protocol supports variable length options.
> > > Are you talking about PCP servers that do not support them?
> > >
> > > [Med] No. It is more about the dimensioning of the PCP server + be
> > > sure that schemes that are likely to be deployed are supported by
> > > servers with no risk to encounter errors because of an
> > > implementation choice. Getting an error won't help the client to
> get the service.
> > >
> > > Best regards,
> > >      Juergen
> > >
> > > > Cheers,
> > > > Med
> > > >
> > > > -----Message d'origine-----
> > > > De : Dave Thaler [mailto:[e-mail]] Envoyé : vendredi
> > > > 9 janvier 2015 02:37 À : BOUCADAIR Mohamed IMT/OLN; Andreas
> Ripke;
> > > > [e-mail] Objet : RE: [pcp] #74 (third-party-id-option):
> > > > Mohamed Boucadair's
> > > comments
> > > > on draft-ietf-pcp-third-party-id-option-00
> > > >
> > > > Andreas Ripke writes:
> > > > > Med's comments contain two technical modifications.
> > > > >
> > > > > 1. A recommended fixed maximum option length of 128 octets.
> > > > >
> > > > > Why should we (unnecessarily?) set an explicit limit to this
> option?
> > > > > The fixed option length (16 octets) was changed to a variable
> > > > > length with
> > > the
> > > > > current draft version.
> > > > > The maximum PCP packet size is 1100 octets and the client must
> > > > > ensure not
> > > > to
> > > > > cause an overrun according to RFC6887.
> > > > > But then, in RFC7220 the maximum variable length for the
> > > > > description
> > > option
> > > > is
> > > > > limited to 1016 octets.
> > > > > Is there any special reason to have an explicit maximum option
> > > > > length
> > > > defined?
> > > > >
> > > > > [Med] Fixing a maximum is required to help dimensioning the
> > > > > server and to avoid exhausting server's resources. Most of the
> > > > > identifiers I'm aware of
> > > > don't
> > > > > exceed 128 octets. Hence my recommendation to use that maximum.
> > > >
> > > > My personal opinion on the above is that the other limits Andreas
> > > > mentions are already sufficient and we don't need to specify a
> > > > shorter limit than what you naturally get.
> > > >
> > > > -Dave
> > > >
> > > > _______________________________________________
> > > > 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