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

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