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

I didn't understand why IANA assignment cares about the Req/Ans bit. Is it
really 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.

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