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

Ralph Droms <rdroms.ietf@gmail.com> Thu, 23 June 2011 15:09 UTC

Return-Path: <rdroms.ietf@gmail.com>
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 0E44011E811A for <pana@ietfa.amsl.com>; Thu, 23 Jun 2011 08:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.223
X-Spam-Level:
X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 CbZKNfPg5Ozn for <pana@ietfa.amsl.com>; Thu, 23 Jun 2011 08:09:50 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E011E808D for <pana@ietf.org>; Thu, 23 Jun 2011 08:09:48 -0700 (PDT)
Received: by ewy19 with SMTP id 19so741765ewy.31 for <pana@ietf.org>; Thu, 23 Jun 2011 08:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X/5E6sTuuD2q+UzvNhgBwQoDrU7HGA1/nyAhtf3/xks=; b=MVJl/BbMj0Rn3AVGrjbn8UDQBoLkMPcLyKtFgeVA4mv6tabfh+kaqXcqi/ASI/MGTj +k0Ngyt5b/QzYNLdD0rN+ay2BQ/4oL6EDRkmlL/fBRj+Tsg2Wa+pxmrb/+ezASVIfs5h ZV8Uc6aO6L9DoSTT3NKHikDNnmCv5Wja3DnTM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kNJwJE1SpN7xfh4oS/z9xvyb7iaCoLFkLE2dxlU+R79jCVCrwewUa7Sv2HtUKigOxd Gkp3xk81ziZAxSgmvqjCjSo/JVv8r9TRREmuj947qULObe/UtmvtYoyhoaL03VFLOQpd UP5WUsOR5jzzKypw6w+hLHMvpeKwP2V3ekCFg=
MIME-Version: 1.0
Received: by 10.14.127.68 with SMTP id c44mr1549813eei.103.1308841787452; Thu, 23 Jun 2011 08:09:47 -0700 (PDT)
Received: by 10.213.105.77 with HTTP; Thu, 23 Jun 2011 08:09:47 -0700 (PDT)
In-Reply-To: <6491375641982933760@unknownmsgid>
References: <4DF04217.3080304@toshiba.co.jp> <6491375641982933760@unknownmsgid>
Date: Thu, 23 Jun 2011 11:09:47 -0400
Message-ID: <BANLkTinVZ2Bvd6A+znQTiB7X-P6XXh3Cow@mail.gmail.com>
From: Ralph Droms <rdroms.ietf@gmail.com>
To: Alper Yegin <alper.yegin@yegin.org>
Content-Type: multipart/alternative; boundary=90e6ba5bb945ceecfe04a662797d
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:09:53 -0000

On Fri, Jun 10, 2011 at 3:58 AM, Alper Yegin <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] 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
>
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www.ietf.org/mailman/listinfo/pana
>
>