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

[Andreas Ripke <[e-mail]>]

>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