I agree with Ralph's suggestion to rename "Req/Ans" to "R Message Flag". In that case, the value in the column shall be either '1' or '0' (and no 'N/A').
Regards, Yoshihiro Ohba (2011/06/24 0:09), Ralph Droms wrote: > > > On Fri, Jun 10, 2011 at 3:58 AM, Alper Yegin <alper.ye...@yegin.org > <mailto:alper.ye...@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-boun...@ietf.org <mailto:pana-boun...@ietf.org> > [mailto:pana-boun...@ietf.org <mailto:pana-boun...@ietf.org>] On > Behalf Of > > > Yoshihiro Ohba > > > Sent: Thursday, June 09, 2011 6:47 AM > > > To: pana@ietf.org <mailto: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-lastc...@iana.org > <mailto:drafts-lastc...@iana.org>> > > > Reply-To: drafts-lastc...@iana.org > <mailto:drafts-lastc...@iana.org> > > > CC: padu...@cisco.com <mailto:padu...@cisco.com>, > samit...@gmail.com <mailto:samit...@gmail.com>, > > > robert.cra...@gridmerge.com > <mailto:robert.cra...@gridmerge.com>, yoshihiro.o...@toshiba.co.jp > <mailto:yoshihiro.o...@toshiba.co.jp>, > > > alper.ye...@yegin.org <mailto:alper.ye...@yegin.org>, > i...@ietf.org <mailto:i...@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, nore...@ietf.org > <mailto:nore...@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 > > > > i...@ietf.org <mailto:i...@ietf.org> mailing lists by > 2011-06-22. Exceptionally, comments > > > may be > > > > sent to i...@ietf.org <mailto:i...@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 <mailto:Pana@ietf.org> > > > https://www.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org <mailto:Pana@ietf.org> > https://www.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
