Re: [Pana] Fwd: [IANA #454490] Last Call: <draft-ohba-pana-relay-03.txt> (Protocol for Carrying Authentication for Network Access (PANA) Relay Element) to Proposed Standard

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Fri, 24 June 2011 00:12 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: pana@ietfa.amsl.com
Delivered-To: pana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F911E8084 for <pana@ietfa.amsl.com>; Thu, 23 Jun 2011 17:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level:
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[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 jQ9MPWBAIqj7 for <pana@ietfa.amsl.com>; Thu, 23 Jun 2011 17:12:33 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id B20A611E807C for <pana@ietf.org>; Thu, 23 Jun 2011 17:12:32 -0700 (PDT)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id p5O0CMTc017245; Fri, 24 Jun 2011 09:12:22 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id p5O0CMbx007146; Fri, 24 Jun 2011 09:12:22 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id KAA07143; Fri, 24 Jun 2011 09:12:22 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id p5O0CLTa013959; Fri, 24 Jun 2011 09:12:22 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p5O0CLDI014264; Fri, 24 Jun 2011 09:12:21 +0900 (JST)
Received: from [133.196.17.93] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LN900AGDPWL6XJ0@mail.po.toshiba.co.jp>; Fri, 24 Jun 2011 09:12:21 +0900 (JST)
Date: Fri, 24 Jun 2011 09:12:10 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <4E038264.1080602@gridmerge.com>
To: robert.cragie@gridmerge.com
Message-id: <4E03D65A.8030702@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-2022-JP
Content-transfer-encoding: 7bit
References: <4DF04217.3080304@toshiba.co.jp> <6491375641982933760@unknownmsgid> <BANLkTinVZ2Bvd6A+znQTiB7X-P6XXh3Cow@mail.gmail.com> <4E037743.2060602@gridmerge.com> <4E037F0D.3060508@gridmerge.com> <4E038264.1080602@gridmerge.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
Cc: pana@ietf.org, draft-ohba-pana-relay@tools.ietf.org, Ralph Droms <rdroms.ietf@gmail.com>, samitac2@gmail.com, int-ads@tools.ietf.org
Subject: Re: [Pana] Fwd: [IANA #454490] Last Call: <draft-ohba-pana-relay-03.txt> (Protocol for Carrying Authentication for Network Access (PANA) Relay Element) to Proposed Standard
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pana>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2011 00:12:34 -0000

This table looks good to me.

Thanks,
Yoshihiro Ohba


(2011/06/24 3:13), Robert Cragie wrote:
> Too hasty with the cut and paste (too many PTR/PTA). Revised table:
> 
> Value        | R flag | Abbrev | Name                      | Reference |
> ------------------------------------------------------------------------
>   0           |        |        | Reserved                  | [RFC5191] |
>   1           | 0      | PCI    | PANA-Client-Initiation    | [RFC5191] |
>   2           | 1      | PAR    | PANA-Auth-Request         | [RFC5191] |
>   2           | 0      | PAN    | PANA-Auth-Answer          | [RFC5191] |
>   3           | 1      | PTR    | PANA-Termination-Request  | [RFC5191] |
>   3           | 0      | PTA    | PANA-Termination-Answer   | [RFC5191] |
>   4           | 1      | PNR    | PANA-Notification-Request | [RFC5191] |
>   4           | 0      | PNA    | PANA-Notification-Answer  | [RFC5191] |
>   5           | 0      | PRY    | PANA-Relay                | [RFCxxxx] |
>   6-65519     |        |        | Unassigned                | [RFC5191] |
>   65520-65535 |        |        | Reserved (Experimental)   | [RFC5191] |
> 
> On 23/06/2011 6:59 PM, Robert Cragie wrote:
>> As a follow up: as I read it in RFC 5191, the ABNF for PCI 
>> explicitly sets the R flag to 0. In some respects, given the 
>> definition of the R flag, this implies PCI is an answer, which is 
>> not really true. I don't know how important that is; it is used 
>> primarily for subclassifying a Message Type.
>>
>> On that basis, I think the table needs to look something like:
>>
>> Value        | R flag | Abbrev | Name                      | Reference |
>> ------------------------------------------------------------------------
>>  0           |        |        | Reserved                  | [RFC5191] |
>>  1           | 0      | PCI    | PANA-Client-Initiation    | [RFC5191] |
>>  2           | 1      | PAR    | PANA-Auth-Request         | [RFC5191] |
>>  2           | 0      | PAN    | PANA-Auth-Answer          | [RFC5191] |
>>  3           | 1      | PTR    | PANA-Termination-Request  | [RFC5191] |
>>  3           | 0      | PTA    | PANA-Termination-Answer   | [RFC5191] |
>>  4           | 1      | PTR    | PANA-Notification-Request | [RFC5191] |
>>  4           | 0      | PTA    | PANA-Notification-Answer  | [RFC5191] |
>>  5           | 0      | PRY    | PANA-Relay                | [RFCxxxx] |
>>  6-65519     |        |        | Unassigned                | [RFC5191] |
>>  65520-65535 |        |        | Reserved (Experimental)   | [RFC5191] |
>>
>>
>> Robert
>>
>> On 23/06/2011 6:26 PM, Robert Cragie wrote:
>>> Ralph,
>>>
>>> I like your suggestion for the Message Types registry. I guess 
>>> there is an assumption if the field is not declared in the ABNF it 
>>> becomes the same as reserved and thus follows the "set to zero and 
>>> ignored on receipt" rule. Does this need to be explicitly stated 
>>> anywhere?
>>>
>>> Robert
>>>
>>