IETF Logo Mail Archive

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

Andreas Ripke <Andreas.Ripke@neclab.eu> Mon, 15 December 2014 16:26 UTC

Return-Path: <Andreas.Ripke@neclab.eu>
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 A9C5B1A86DE for <pcp@ietfa.amsl.com>; Mon, 15 Dec 2014 08:26:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level:
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ymj9BZwPACt3 for <pcp@ietfa.amsl.com>; Mon, 15 Dec 2014 08:26:04 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB761A8549 for <pcp@ietf.org>; Mon, 15 Dec 2014 08:26:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D99AD108E27 for <pcp@ietf.org>; Mon, 15 Dec 2014 17:26:02 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GULTXlTUdz8q for <pcp@ietf.org>; Mon, 15 Dec 2014 17:26:02 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id BB651108E26 for <pcp@ietf.org>; Mon, 15 Dec 2014 17:26:00 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Mon, 15 Dec 2014 17:26:00 +0100
From: Andreas Ripke <Andreas.Ripke@neclab.eu>
To: "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: AQHQFYirSgKSGY/ESEq7Nep0KP29ApyQdWUA
Date: Mon, 15 Dec 2014 16:26:00 +0000
Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79912C7F0E@PALLENE.office.hd>
References: <066.6faf9d8f2702d081360dcb658d129655@tools.ietf.org>
In-Reply-To: <066.6faf9d8f2702d081360dcb658d129655@tools.ietf.org>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.6.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/tVNzsa3RSHzTN2E-h3I6BW7Y0v0
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: Mon, 15 Dec 2014 16:26:10 -0000

Hi,

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?

2. The newly specified THIRD_PARTY_ID option can be used alone without the THIRD_PARTY option.

The THIRD_PARTY_ID option is defined as an extension to the THIRD_PARTY option in case the THIRD_PARTY address is not sufficient.
Using the THIRD_PARTY_ID alone  seems to be a very special use case.
Is there a practical application to it?

Andreas


> -----Original Message-----
> From: pcp issue tracker [mailto:trac@tools.ietf.org]
> Sent: Thursday, December 11, 2014 10:23 PM
> To: draft-ietf-pcp-third-party-id-option@tools.ietf.org;
> mohamed.boucadair@orange.com
> Cc: pcp@ietf.org
> Subject: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on
> draft-ietf-pcp-third-party-id-option-00
> 
> #74: Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-
> 00
> 
>  Comments inline in PDF copy currently at
>  http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-party-id-
>  option-00-Med.pdf
> 
> --
> -------------------------------------+-------------------------------------
>  Reporter:                           |      Owner:  draft-ietf-pcp-third-
>   mohamed.boucadair@orange.com       |  party-id-option@tools.ietf.org
>      Type:  defect                   |     Status:  new
>  Priority:  major                    |  Milestone:  milestone1
> Component:  third-party-id-option    |    Version:  1.0
>  Severity:  In WG Last Call          |   Keywords:
> -------------------------------------+-------------------------------------
> 
> Ticket URL: <https://tools.ietf.org/wg/pcp/trac/ticket/74>
> pcp <http://tools.ietf.org/pcp/>

v2.23.0 | Report a Bug | By Email