IETF Logo Mail Archive

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

<mohamed.boucadair@orange.com> Fri, 09 January 2015 06:57 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39CA1A701E for <pcp@ietfa.amsl.com>; Thu, 8 Jan 2015 22:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfUN_xMQA9Uw for <pcp@ietfa.amsl.com>; Thu, 8 Jan 2015 22:57:26 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A38A1A0055 for <pcp@ietf.org>; Thu, 8 Jan 2015 22:57:26 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id B1815C06A4; Fri, 9 Jan 2015 07:57:23 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 9283C384098; Fri, 9 Jan 2015 07:57:23 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.125]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Fri, 9 Jan 2015 07:57:23 +0100
From: mohamed.boucadair@orange.com
To: Dave Thaler <dthaler@microsoft.com>, Andreas Ripke <Andreas.Ripke@neclab.eu>, "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00
Thread-Index: AQHQFYiv18dr0gAUwUu7AeZ+Ab+FRZyQ3I4AgADs44CAJWSr4IAAWA5Q
Date: Fri, 09 Jan 2015 06:57:23 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330048ED4C3@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <066.6faf9d8f2702d081360dcb658d129655@tools.ietf.org> <2D2FFE4726FAF74285C45D69FDC30E79912C7F0E@PALLENE.office.hd> <787AE7BB302AE849A7480A190F8B9330048D8C34@OPEXCLILM23.corporate.adroot.infra.ftgroup> <BY2PR03MB41284D2E1810D223695CD64A3440@BY2PR03MB412.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB41284D2E1810D223695CD64A3440@BY2PR03MB412.namprd03.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.23.1824
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/4HAwmdvZqgust95quYsFgejSEjk>
Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 06:57:29 -0000

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? 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.?

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.

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

v2.23.0 | Report a Bug | By Email