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 <at> ietf.org
[mailto:pana-bounces <at> ietf.org] On Behalf Of
> Yoshihiro Ohba
> Sent: Thursday, June 09, 2011 6:47 AM
> To: pana <at> 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 <at> iana.org>
> Reply-To: drafts-lastcall <at> iana.org
> CC: paduffy <at> cisco.com, samitac2 <at> gmail.com,
> robert.cragie <at> gridmerge.com,
yoshihiro.ohba <at> toshiba.co.jp,
> alper.yegin <at> yegin.org, iesg <at> 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 <at> 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 <at> ietf.org mailing lists by 2011-06-22.
Exceptionally, comments
> may be
> > sent to iesg <at> 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 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pana
RSS Feed