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> Thu, 23 June 2011 15:20 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 C4CE09E8055 for <pana@ietfa.amsl.com>; Thu, 23 Jun 2011 08:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level:
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[AWL=0.229, 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 73ZTtcrveFLa for <pana@ietfa.amsl.com>; Thu, 23 Jun 2011 08:20:34 -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 7E4E09E8058 for <pana@ietf.org>; Thu, 23 Jun 2011 08:20:34 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p5NFKM6B029352; Fri, 24 Jun 2011 00:20:22 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id p5NFKM42016451; Fri, 24 Jun 2011 00:20:22 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA16450; Fri, 24 Jun 2011 00:20:22 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p5NFKLj4007006; Fri, 24 Jun 2011 00:20:21 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p5NFKLai026252; Fri, 24 Jun 2011 00:20:21 +0900 (JST)
Received: from [133.199.17.57] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LN900A0Q19X6YD0@mail.po.toshiba.co.jp>; Fri, 24 Jun 2011 00:20:21 +0900 (JST)
Date: Fri, 24 Jun 2011 00:20:10 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <BANLkTinVZ2Bvd6A+znQTiB7X-P6XXh3Cow@mail.gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Message-id: <4E0359AA.9020008@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>
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, robert.cragie@gridmerge.com, samitac2@gmail.com, int-ads@tools.ietf.org, draft-ohba-pana-relay@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: Thu, 23 Jun 2011 15:20:35 -0000

I agree with Ralph's suggestion to rename "Req/Ans" to "R Message
Flag".   In that case, the value in the column shall be either '1' or
'0' (and no 'N/A').

Regards,
Yoshihiro Ohba


(2011/06/24 0:09), Ralph Droms wrote:
> 
> 
> On Fri, Jun 10, 2011 at 3:58 AM, Alper Yegin <alper.yegin@yegin.org 
> <mailto:alper.yegin@yegin.org>> wrote:
> 
>     __ __
> 
>     __ __
> 
>     I didn't understand why IANA assignment cares about the Req/Ans
>     bit. Is it really needed for IANA assignments?
> 
> 
> The Req/Ans column is needed to differentiate some of the messages, 
> e.g., PAR and PAN, which have different abbreviations but share the 
> same message code.
> 
>     ____
> 
>     __ __
> 
>     If we need to use it, one option is to put “not applicable for PCI
>     and PRY”.
> 
> 
> Reading RFC 5191 and the registry, I suggest that the Message Types 
> registry needs to be clarified a little, so that the column currently 
> labeled Req/Ans is tied directly to the 'R' Message Flag in the 
> Message Flags registry.  Giving the exact value for the 'R' flag in 
> that column seems more direct.  Perhaps rename "Req/Ans" to "R Message 
> Flag", with values in the column of '1', '0' or 'N/A' (the latter for 
> PCI and PRE messages; although PCI is a little tricky as its ABNF is 
> defined without "REQ" and I don't know if that ABNF implies the R 
> Message Flag MUST be 0 or if it's a "don't care").
> 
> - Ralph
> 
> 
> 
>     ____
> 
>     __ __
> 
>     And if that’s not acceptable/practical, then I’d say marking both
>     PCI and PRY with Req is OK. We could perceive them as requests
>     that do not expect answers. They are one-way messages. This is
>     more logical to me than to define an answer for which there is no
>     outstanding request.____
> 
>     __ __
> 
>     Alper____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>      > -----Original Message-----
> 
>      > From: pana-bounces@ietf.org <mailto:pana-bounces@ietf.org>
>     [mailto:pana-bounces@ietf.org <mailto:pana-bounces@ietf.org>] On
>     Behalf Of
> 
>      > Yoshihiro Ohba
> 
>      > Sent: Thursday, June 09, 2011 6:47 AM
> 
>      > To: pana@ietf.org <mailto:pana@ietf.org>
> 
>      > Subject: [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
> 
>      >
> 
>      > We have received the following question from IANA.
> 
>      >
> 
>      > Since the 'R' (Request) bit is not set for PANA-Relay, I think it
> 
>      > should be filled with "Ans" (not "Req").
> 
>      >
> 
>      > BTW, I've found that PCI, for which the 'R' (Request) bit is
>     not set,
> 
>      > is filled with "Req" in the IANA registry.  I think this should
>     have
> 
>      > been filled with "Ans" as well.
> 
>      >
> 
>      > Any opinions?
> 
>      >
> 
>      > Yoshihiro Ohba
> 
>      >
> 
>      > -------- Original Message --------
> 
>      > Subject: [IANA #454490] Last Call: <draft-ohba-pana-relay-03.txt>
> 
>      > (Protocol for Carrying Authentication for Network Access (PANA)
>     Relay
> 
>      > Element) to Proposed Standard
> 
>      > Date: Wed, 08 Jun 2011 20:37:04 +0000
> 
>      > From: Amanda Baber via RT <drafts-lastcall@iana.org
>     <mailto:drafts-lastcall@iana.org>>
> 
>      > Reply-To: drafts-lastcall@iana.org
>     <mailto:drafts-lastcall@iana.org>
> 
>      > CC: paduffy@cisco.com <mailto:paduffy@cisco.com>,
>     samitac2@gmail.com <mailto:samitac2@gmail.com>,
> 
>      > robert.cragie@gridmerge.com
>     <mailto:robert.cragie@gridmerge.com>, yoshihiro.ohba@toshiba.co.jp
>     <mailto:yoshihiro.ohba@toshiba.co.jp>,
> 
>      > alper.yegin@yegin.org <mailto:alper.yegin@yegin.org>,
>     iesg@ietf.org <mailto:iesg@ietf.org>
> 
>      >
> 
>      > IESG:
> 
>      >
> 
>      > IANA has reviewed draft-ohba-pana-relay-03.txt and has the
>     following
> 
>      > comments:
> 
>      >
> 
>      > IANA has questions about the IANA Actions in this document.
> 
>      >
> 
>      > IANA understands that, upon approval of this document, there
>     are two
> 
>      > IANA Actions that must be completed.
> 
>      >
> 
>      > First, in the Message Types registry in the Protocol for Carrying
> 
>      > Authentication for Network Access (PANA) Parameters registry
>     located
> 
>      > at:
> 
>      >
> 
>      > http://www.iana.org/assignments/pana-parameters/pana-parameters.xml
> 
>      >
> 
>      > a single, new message type will be added as follows:
> 
>      >
> 
>      > Value [ TBD ]
> 
>      > Name: PANA-Relay
> 
>      >
> 
>      > IANA QUESTION --> How should the following field in the registry be
> 
>      > filled in?
> 
>      > Req/Ans: [ ??? ]
> 
>      >
> 
>      > Abbrev: PRY
> 
>      > Reference: [ RFC-to-be ]
> 
>      >
> 
>      > IANA notes that the authors request the value "5" for the Value
>     of this
> 
>      > Message Type.
> 
>      >
> 
>      > Second, in the AVP Codes registry in the the Protocol for Carrying
> 
>      > Authentication for Network Access (PANA) Parameters registry
>     located
> 
>      > at:
> 
>      >
> 
>      > http://www.iana.org/assignments/pana-parameters/pana-parameters.xml
> 
>      >
> 
>      > two new AVP Codes will be added as follows:
> 
>      >
> 
>      > Code: [tbd2]
> 
>      > Attribute name: PaC-Information AVP
> 
>      > Reference: [ RFC-to-be ]
> 
>      >
> 
>      > Code: [tbd3]
> 
>      > Attribute name: Relayed-Message AVP
> 
>      > Reference: [ RFC-to-be ]
> 
>      >
> 
>      > IANA notes that the authors have requested codes "10" and "11" for
> 
>      > [tbd2] and [tbd3] respectively.
> 
>      >
> 
>      > IANA understands that these two actions are the only ones
>     required upon
> 
>      > approval of this document.
> 
>      >
> 
>      > Note:  The actions requested in this document will not be completed
> 
>      > until the document has been approved for publication as an RFC.
>     This
> 
>      > message is only to confirm what actions will be performed.
> 
>      >
> 
>      > Thanks,
> 
>      >
> 
>      > Amanda Baber
> 
>      > IANA
> 
>      >
> 
>      > On Wed May 25 13:37:06 2011, noreply@ietf.org
>     <mailto:noreply@ietf.org> wrote:
> 
>      > >
> 
>      > > The IESG has received a request from an individual submitter to
> 
>      > consider
> 
>      > > the following document:
> 
>      > > - 'Protocol for Carrying Authentication for Network Access (PANA)
> 
>      > Relay
> 
>      > >    Element'
> 
>      > > <draft-ohba-pana-relay-03.txt> as a Proposed Standard
> 
>      > >
> 
>      > > The IESG plans to make a decision in the next few weeks, and
>     solicits
> 
>      > > final comments on this action. Please send substantive
>     comments to
> 
>      > the
> 
>      > > ietf@ietf.org <mailto:ietf@ietf.org> mailing lists by
>     2011-06-22. Exceptionally, comments
> 
>      > may be
> 
>      > > sent to iesg@ietf.org <mailto:iesg@ietf.org> instead. In
>     either case, please retain the
> 
>      > > beginning of the Subject line to allow automated sorting.
> 
>      > >
> 
>      > > Abstract
> 
>      > >
> 
>      > >
> 
>      > > This document specifies Protocol for carrying Authentication for
> 
>      > > Network Access (PANA) Relay Element functionality which
>     enables PANA
> 
>      > > messaging between a PANA Client (PaC) and a PANA
>     Authentication Agent
> 
>      > > (PAA) where the two nodes cannot reach each other by means of
>     regular
> 
>      > > IP routing.
> 
>      > >
> 
>      > >
> 
>      > >
> 
>      > > The file can be obtained via
> 
>      > > http://datatracker.ietf.org/doc/draft-ohba-pana-relay/
> 
>      > >
> 
>      > > IESG discussion can be tracked via
> 
>      > > http://datatracker.ietf.org/doc/draft-ohba-pana-relay/
> 
>      > >
> 
>      > >
> 
>      > > No IPR declarations have been submitted directly on this I-D.
> 
>      > >
> 
>      > >
> 
>      >
> 
>      >
> 
>      >
> 
>      >
> 
>      > _______________________________________________
> 
>      > Pana mailing list
> 
>      > Pana@ietf.org <mailto:Pana@ietf.org>
> 
>      > https://www.ietf.org/mailman/listinfo/pana
> 
> 
>     _______________________________________________
>     Pana mailing list
>     Pana@ietf.org <mailto:Pana@ietf.org>
>     https://www.ietf.org/mailman/listinfo/pana
> 
>