IETF Logo Mail Archive

Re: [pcp] Capability discovery

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Fri, 05 October 2012 06:57 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729A621F85A2 for <pcp@ietfa.amsl.com>; Thu, 4 Oct 2012 23:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.34
X-Spam-Level:
X-Spam-Status: No, score=-5.34 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BAjebdgIwu6 for <pcp@ietfa.amsl.com>; Thu, 4 Oct 2012 23:57:23 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9646821F85A4 for <pcp@ietf.org>; Thu, 4 Oct 2012 23:57:23 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q956vMnK019875; Fri, 5 Oct 2012 15:57:22 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id q956vLVt004332; Fri, 5 Oct 2012 15:57:21 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA04331; Fri, 5 Oct 2012 15:57:21 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q956vL28016633; Fri, 5 Oct 2012 15:57:21 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q956vLre024221; Fri, 5 Oct 2012 15:57:21 +0900 (JST)
Received: from [133.196.20.203] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBE0067HRBL3KM0@mail.po.toshiba.co.jp>; Fri, 05 Oct 2012 15:57:21 +0900 (JST)
Date: Fri, 05 Oct 2012 15:57:25 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <94C682931C08B048B7A8645303FDC9F36E5F75BE63@PUEXCB1B.nanterre.francetelecom.fr>
To: mohamed.boucadair@orange.com
Message-id: <506E84D5.2050502@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 8bit
References: <506E4E07.3000807@toshiba.co.jp> <94C682931C08B048B7A8645303FDC9F36E5F75BE63@PUEXCB1B.nanterre.francetelecom.fr>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] Capability discovery
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Oct 2012 06:57:24 -0000

So there are two ways for capability discovery:

- Use a PCP Opcode
- Use a PCP Option

If the WG has not decided which way to use for capability discovery,
I would have to mention the two ways in the two PANA I-Ds I am working on.

Is this OK?

Yoshihiro Ohba

(2012/10/05 14:56), mohamed.boucadair@orange.com wrote:
> Dear Yoshihiro,
>
> FYI, this document proposes an option to retrieve the capabilities of the PCP-controlled device:
> http://tools.ietf.org/html/draft-boucadair-pcp-capability-00
>
> The current version does only describe whether the controlled device is NAT44, NAT46, NAT64, IPv4 FW, IPv6 FW, Port Range Router.
>
> This feature is defined as an option but can be elected to be defined as standalone OpCode. The capabilities set format can be modified to support new capabilities: e.g., authentication support, list of supported opcodes, etc.
>
> Saying that, IMHO we need further analyze what are the gains and the impacts on the PCP server to support such feature:
>
> * Is it reducing exchanged messages?
> * Does it harm if we try an opcode no matter if the PCP server supports it or not?
> * Reduce delay before establishing a session?
> * Be a trigger to decide whether all available PCP Servers need to be contacted in // or select only one?
>
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la
>> part de Yoshihiro Ohba
>> Envoyé : vendredi 5 octobre 2012 05:04
>> À : pcp@ietf.org
>> Objet : [pcp] Capability discovery
>>
>> There has been a question on what to do when PCP client supports PCP
>> authentication
>> while PCP server does not, and vise versa. The same issue will
>> exist for
>> future PCP extensions.
>>
>> I would like to hear opinions whether defining a capability discovery
>> exchange
>> in PCP base specification ever makes sense, where the capability
>> discovery exchange is
>> expected to happen prior to any other PCP opcodes.
>>
>> Best Regards,
>> Yoshihiro Ohba
>>
>>
>>
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>>

v2.23.0 | Report a Bug | By Email