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