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: mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Sent: Freitag, 9. Januar 2015 11:21
> To: Juergen Quittek; Dave Thaler; Andreas Ripke; pcp@ietf.org
> 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:Quittek@neclab.eu]
> Envoyé : vendredi 9 janvier 2015 08:41
> À : BOUCADAIR Mohamed IMT/OLN; Dave Thaler; Andreas Ripke; pcp@ietf.org
> 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:pcp-bounces@ietf.org] On Behalf Of
> > mohamed.boucadair@orange.com
> > Sent: Freitag, 9. Januar 2015 07:57
> > To: Dave Thaler; Andreas Ripke; pcp@ietf.org
> > 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:dthaler@microsoft.com]
> > Envoyé : vendredi 9 janvier 2015 02:37
> > À : BOUCADAIR Mohamed IMT/OLN; Andreas Ripke; pcp@ietf.org
> > 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
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp