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

"Alper Yegin" <alper.yegin@yegin.org> Fri, 24 June 2011 07:52 UTC

Return-Path: <alper.yegin@yegin.org>
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 3CE6C11E8090 for <pana@ietfa.amsl.com>; Fri, 24 Jun 2011 00:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.15
X-Spam-Level:
X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100]
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 djzXYECHkjwX for <pana@ietfa.amsl.com>; Fri, 24 Jun 2011 00:52:06 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id AFFE811E8089 for <pana@ietf.org>; Fri, 24 Jun 2011 00:52:06 -0700 (PDT)
Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MePod-1Qxtz02sN5-00QGEA; Fri, 24 Jun 2011 03:52:01 -0400
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Yoshihiro Ohba'" <yoshihiro.ohba@toshiba.co.jp>, <robert.cragie@gridmerge.com>
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> <4E03D65A.8030702@toshiba.co.jp>
In-Reply-To: <4E03D65A.8030702@toshiba.co.jp>
Date: Fri, 24 Jun 2011 10:51:37 +0300
Message-ID: <020f01cc3243$943f5d40$bcbe17c0$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwyA3EOkl19+AAZSdenRtjyRNiTTgAQBacw
Content-Language: en-us
X-Provags-ID: V02:K0:gQvUhpOuP/w/L5559n6Mj+haKG+2BDOLwY1M/r2+v0y dLpIDwmVlMf7rtPIFW92WyPoVH6BPCs7o+bu1CLQSnb/PTJFcY F/rDxKr9IjfILUyOlMJwLBjxXrNM92zSwBmIkKHUhhlKhgoYwX C6UYkq1U8yezWF/LWDyivGhtGFNUfcuIfWskeb/KeQf6mtCzuK 7+pWyWcgE5KDX9EFu+Bg23D994B9Dq65ZqIf5LQ8WQ=
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 07:52:07 -0000

Let's go with this.


> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp]
> Sent: Friday, June 24, 2011 3:12 AM
> To: robert.cragie@gridmerge.com
> Cc: Ralph Droms; Alper Yegin; int-ads@tools.ietf.org; pana@ietf.org;
> paduffy@cisco.com; samitac2@gmail.com; draft-ohba-pana-
> relay@tools.ietf.org; margaretw42@gmail.com
> 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
> 
> 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
> >>>
> >>