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 <[e-mail]>]

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