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> Sat, 11 June 2011 06:28 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 68F1111E8085 for <pana@ietfa.amsl.com>; Fri, 10 Jun 2011 23:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.245
X-Spam-Level:
X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_05=-1.11, 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 3vMYODgObBeU for <pana@ietfa.amsl.com>; Fri, 10 Jun 2011 23:28:46 -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 2595111E8083 for <pana@ietf.org>; Fri, 10 Jun 2011 23:28:45 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p5B6SicN028205; Sat, 11 Jun 2011 15:28:44 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id p5B6Si4d012232; Sat, 11 Jun 2011 15:28:44 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA12231; Sat, 11 Jun 2011 15:28:44 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p5B6ShUH011997; Sat, 11 Jun 2011 15:28:43 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p5B6ShkW018978; Sat, 11 Jun 2011 15:28:43 +0900 (JST)
Received: from [133.199.18.190] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LMM00IM44NVREL0@mail.po.toshiba.co.jp>; Sat, 11 Jun 2011 15:28:43 +0900 (JST)
Date: Sat, 11 Jun 2011 15:28:34 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <00f901cc2744$26bd95c0$7438c140$%yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4DF30B12.5010903@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> <00f901cc2744$26bd95c0$7438c140$%yegin@yegin.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
Cc: pana@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: Sat, 11 Jun 2011 06:28:47 -0000

Alper,

(2011/06/10 16:58), Alper Yegin wrote:
> I didn't understand why IANA assignment cares about the Req/Ans bit. 
> Is it really needed for IANA assignments?

I agree, Req/Ans distinction may not be needed for IANA assignments.

> 
> If we need to use it, one option is to put “not applicable for PCI and 
> PRY”.
> 
> 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.
> 

I agree to respond with IANA that Req/Ans distinction is not
applicable for PCI and PRY, with a back up plan of marking both PCI
and PRY as Req.

Thanks,
Yoshihiro Ohba


> Alper
> 
>  > -----Original Message-----
> 
>  > From: 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
> 
>  > 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>
> 
>  > Reply-To: drafts-lastcall@iana.org
> 
>  > CC: paduffy@cisco.com, samitac2@gmail.com,
> 
>  > robert.cragie@gridmerge.com, yoshihiro.ohba@toshiba.co.jp,
> 
>  > alper.yegin@yegin.org, 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 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 mailing lists by 2011-06-22. Exceptionally, comments
> 
>  > may be
> 
>  > > sent to 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
> 
>  > https://www.ietf.org/mailman/listinfo/pana
>