Let's go with this.
> -----Original Message----- > From: Yoshihiro Ohba [mailto:yoshihiro.o...@toshiba.co.jp] > Sent: Friday, June 24, 2011 3:12 AM > To: robert.cra...@gridmerge.com > Cc: Ralph Droms; Alper Yegin; int-...@tools.ietf.org; pana@ietf.org; > padu...@cisco.com; samit...@gmail.com; draft-ohba-pana- > re...@tools.ietf.org; margaret...@gmail.com > 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 > > This table looks good to me. > > Thanks, > Yoshihiro Ohba > > > (2011/06/24 3:13), Robert Cragie wrote: > > Too hasty with the cut and paste (too many PTR/PTA). Revised table: > > > > Value | R flag | Abbrev | Name | > Reference | > > --------------------------------------------------------------------- > --- > > 0 | | | Reserved | > [RFC5191] | > > 1 | 0 | PCI | PANA-Client-Initiation | > [RFC5191] | > > 2 | 1 | PAR | PANA-Auth-Request | > [RFC5191] | > > 2 | 0 | PAN | PANA-Auth-Answer | > [RFC5191] | > > 3 | 1 | PTR | PANA-Termination-Request | > [RFC5191] | > > 3 | 0 | PTA | PANA-Termination-Answer | > [RFC5191] | > > 4 | 1 | PNR | PANA-Notification-Request | > [RFC5191] | > > 4 | 0 | PNA | PANA-Notification-Answer | > [RFC5191] | > > 5 | 0 | PRY | PANA-Relay | > [RFCxxxx] | > > 6-65519 | | | Unassigned | > [RFC5191] | > > 65520-65535 | | | Reserved (Experimental) | > [RFC5191] | > > > > On 23/06/2011 6:59 PM, Robert Cragie wrote: > >> As a follow up: as I read it in RFC 5191, the ABNF for PCI > >> explicitly sets the R flag to 0. In some respects, given the > >> definition of the R flag, this implies PCI is an answer, which is > >> not really true. I don't know how important that is; it is used > >> primarily for subclassifying a Message Type. > >> > >> On that basis, I think the table needs to look something like: > >> > >> Value | R flag | Abbrev | Name | > Reference | > >> -------------------------------------------------------------------- > ---- > >> 0 | | | Reserved | > [RFC5191] | > >> 1 | 0 | PCI | PANA-Client-Initiation | > [RFC5191] | > >> 2 | 1 | PAR | PANA-Auth-Request | > [RFC5191] | > >> 2 | 0 | PAN | PANA-Auth-Answer | > [RFC5191] | > >> 3 | 1 | PTR | PANA-Termination-Request | > [RFC5191] | > >> 3 | 0 | PTA | PANA-Termination-Answer | > [RFC5191] | > >> 4 | 1 | PTR | PANA-Notification-Request | > [RFC5191] | > >> 4 | 0 | PTA | PANA-Notification-Answer | > [RFC5191] | > >> 5 | 0 | PRY | PANA-Relay | > [RFCxxxx] | > >> 6-65519 | | | Unassigned | > [RFC5191] | > >> 65520-65535 | | | Reserved (Experimental) | > [RFC5191] | > >> > >> > >> Robert > >> > >> On 23/06/2011 6:26 PM, Robert Cragie wrote: > >>> Ralph, > >>> > >>> I like your suggestion for the Message Types registry. I guess > >>> there is an assumption if the field is not declared in the ABNF it > >>> becomes the same as reserved and thus follows the "set to zero and > >>> ignored on receipt" rule. Does this need to be explicitly stated > >>> anywhere? > >>> > >>> Robert > >>> > >> _______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
