Subject: [Pana] [issue148] Proposed text, solicitation for comments.

From: [email-masked]
Date: Mon, 29 Nov 2004 15:09:02 +0200

Solicitation for comments, if any.
- Dan

http://danforsberg.info:8080/pana-issues/issue148
Issue148: ABNF spec into the document 

Change from:

"
8.1  PANA Messages

   Figure 10 lists all PANA messages defined in this document.

                 Message          Direction: PaC---PAA
                 ----------------------------------------
                 PANA-PAA-Discover           -------->

                 PANA-Start-Request          <--------
                 PANA-Start-Answer           -------->

                 PANA-Auth-Request           <------->
                 PANA-Auth-Answer            <------->

                 PANA-Reauth-Request         -------->
                 PANA-Reauth-Answer          <--------

                 PANA-FirstAuth-End-Request  <--------
                 PANA-FirstAuth-End-Answer   -------->

                 PANA-Bind-Request           <--------
                 PANA-Bind-Answer            -------->

                 PANA-Ping-Request           <------->
                 PANA-Ping-Answer            <------->

                 PANA-Termination-Request    <------->
                 PANA-Termination-Answer     <------->

                 PANA-Update-Request         -------->
                 PANA-Update-Answer          <--------

                 PANA-Error-Request          <------->
                 PANA-Error-Answer           <------->

                    Figure 10: PANA Message Overview
"

To:

"
8.1  PANA Messages

   Each Request/Answer message pair is assigned a message ID, and the
   sub-type (i.e., request or answer) is identified via the 'R' bit in
   the Message Flags field of the PANA header.

   Every PANA message MUST contain a message ID in its header's
   Message-Id field, which is used to determine the action that is to
   be taken for a particular message.  Figure 10 lists all PANA
   messages defined in this document:

     Message-Name                Abbrev. ID    PaC<->PAA  Ref.
     -----------------------------------------------------------
     PANA-PAA-Discover           PDI     1     -------->  8.2.1
     PANA-Start-Request          PSR     2     <--------  8.2.2
     PANA-Start-Answer           PSA     2     -------->  8.2.3
     PANA-Auth-Request           PAR     3     <------->  8.2.4
     PANA-Auth-Answer            PAN     3     <------->  8.2.5
     PANA-Reauth-Request         PRAR    4     -------->  8.2.6
     PANA-Reauth-Answer          PRAA    4     <--------  8.2.7
     PANA-Bind-Request           PBR     5     <--------  8.2.8
     PANA-Bind-Answer            PBA     5     -------->  8.2.9
     PANA-Ping-Request           PPR     6     <------->  8.2.10
     PANA-Ping-Answer            PPA     6     <------->  8.2.11
     PANA-Termination-Request    PTR     7     <------->  8.2.12
     PANA-Termination-Answer     PTA     7     <------->  8.2.13
     PANA-Error-Request          PER     8     <------->  8.2.14
     PANA-Error-Answer           PEA     8     <------->  8.2.15
     PANA-FirstAuth-End-Request  PFER    9     <--------  8.2.16
     PANA-FirstAuth-End-Answer   PFEA    9     -------->  8.2.17
     PANA-Update-Request         PUR     10    -------->  8.2.18
     PANA-Update-Answer          PUA     10    <--------  8.2.19
     -----------------------------------------------------------

         Figure 10: Table of PANA Messages
"

-------------------------------------------------------------------------------
Change from:

"
8.2  Message Specifications

   Every PANA message MUST include a corresponding ABNF [RFC2234]
   specification found in [RFC3588].

   Example:

      message ::= < PANA-Header: <Message type>, [REQ] [SEP] >
                * [ AVP ]
"

To:

"
8.2  PANA message ABNF specification

   Every PANA message defined MUST include a corresponding ABNF
   [RFC2234] specification, which is used to define the AVPs that MUST
   or MAY be present.  The following format is used in the definition:

   message-def      = Message-Name "::=" PANA-message

   message-name     = PANA-name

   PANA-name        = ALPHA *(ALPHA / DIGIT / "-")

   PANA-message     = header  [ *fixed] [ *required] [ *optional]
                      [ *fixed]

   header           = "< PANA-Header: " Message-Id
                      [r-bit] [s-bit] [n-bit] ">"

   Message-Id       = 1*DIGIT
                      ; The message code assigned to the message

   r-bit            = ", REQ"
                      ; If present, the 'R' bit in the Message
                      ; Flags is set, indicating that the message
                      ; is a request, as opposed to an answer.

   s-bit            = ", SEP"
                      ; If present, the 'S' bit in the Message
                      ; Flags is set, indicating support for 
                      ; separate NAP and ISP authentication.

   n-bit            = ", NAP"
                      ; If present, the 'N' bit in the Message
                      ; Flags is set, indicating that current
                      ; EAP authentication is for NAP authentication.

   fixed            = [qual] "<" avp-spec ">"
                      ; Defines the fixed position of an AVP

   required         = [qual] "{" avp-spec "}"
                      ; The AVP MUST be present and can appear
                      ; anywhere in the message.

   optional         = [qual] "[" avp-name "]"
                      ; The avp-name in the 'optional' rule cannot
                      ; evaluate to any AVP Name which is included
                      ; in a fixed or required rule.  The AVP can
                      ; appear anywhere in the message.

   qual             = [min] "*" [max]
                      ; See ABNF conventions, RFC 2234 Section 6.6.
                      ; The absence of any qualifiers depends on whether
                      ; it precedes a fixed, required, or optional
                      ; rule.  If a fixed or required rule has no
                      ; qualifier, then exactly one such AVP MUST
                      ; be present.  If an optional rule has no
                      ; qualifier, then 0 or 1 such AVP may be
                      ; present.
                      ;
                      ; NOTE:  "[" and "]" have a different meaning
                      ; than in ABNF (see the optional rule, above).
                      ; These braces cannot be used to express
                      ; optional fixed rules (such as an optional
                      ; ICV at the end).  To do this, the convention
                      ; is '0*1fixed'.

   min              = 1*DIGIT
                      ; The minimum number of times the element may
                      ; be present.  The default value is zero.

   max              = 1*DIGIT
                      ; The maximum number of times the element may
                      ; be present.  The default value is infinity.  A
                      ; value of zero implies the AVP MUST NOT be
                      ; present.

   avp-spec         = pana-name
                      ; The avp-spec has to be an AVP Name, defined
                      ; in the base PANA protocol specifications.

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary
                      ; AVP Name, which does not conflict with the
                      ; required or fixed position AVPs defined in
                      ; the message definition.

   Example-Request ::= < "PANA-Header: 9999999, REQ >
                       < Session-Id >
                       { Result-Code }
                    *  [ AVP ]
                   0*1 < MAC >
"
-------------------------------------------------------------------------------

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Avi Lior <[email-masked]>
Date: Mon, 29 Nov 2004 09:51:50 -0500

I don't have the spec infront of me now but do we conver the case if a
Mandatory AVP is missing altogether?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: November 29, 2004 8:03 AM
> To: [email-masked]
> Subject: [Pana] [issue112] Proposed text, solicitation for comments.
> 
> 
> http://danforsberg.info:8080/pana-issues/issue112
> Proposed text for issue112 ('M' flag clarification):
> 
> Change from (section 7.3 AVP Header):
> 
>       "M(andatory)
> 
>          The 'M' Bit, known as the Mandatory bit, indicates whether
>          support of the AVP is required.
> 
>       V(endor)
> 
>          The 'V' bit, known as the Vendor-Specific bit, indicates
>          whether the optional Vendor-Id field is present in the AVP
>          header."
> 
> To: 
> 
>       "M(andatory)
> 
>          The 'M' Bit, known as the Mandatory bit, indicates whether
>          support of the AVP is required.  
> 
>          If an AVP with the 'M' bit set is received by a PaC or PAA
>          and either the AVP or its value is unrecognized, the message
>          MUST be rejected and the receiver MUST send a PANA-Error
>          message. If the AVP was unrecognized the PANA-Error message
>          result code MUST be PANA_AVP_UNSUPPORTED.  If the AVP value
>          was unrecognized the The PANA-Error message result code MUST
>          be PANA_INVALID_AVP_VALUE.  In either case the PANA-Error
>          message MUST carry a Failed-AVP AVP containing the offending
>          mandatory AVP.
>  
>          AVPs with the 'M' bit cleared are informational only and a
>          receiver that receives a message with such an AVP that is not
>          supported, or whose value is not supported, MAY simply ignore
>          the AVP.
> 
>       V(endor)
> 
>          The 'V' bit, known as the Vendor-Specific bit, indicates
>          whether the optional Vendor-Id field is present in the AVP
>          header.  When set the AVP Code belongs to the specific
>          vendor code address space."
> 
> 
> Add to the end of section 7.3:
> 
>    "Unless otherwise noted, AVPs defined in this document 
> will have the
>    following default AVP Flags field settings:
> 
>          The 'M' bit MUST be set.  The 'V' bit MUST NOT be set."
>

---

From: [email-masked]
Date: Tue, 30 Nov 2004 09:50:21 +0200

Avi,

There are error result codes to be included in the Result-Code AVP of
the PANA-Error-Request message. PANA_MISSING_AVP can be used with the
Failed-AVP AVP to point out the missing AVP.

   PANA_AVP_UNSUPPORTED                    5001
   PANA_INVALID_AVP_VALUE                  5004
   PANA_MISSING_AVP                        5005
   PANA_CONTRADICTING_AVPS                 5007
   PANA_AVP_NOT_ALLOWED                    5008
   PANA_AVP_OCCURS_TOO_MANY_TIMES          5009
   PANA_INVALID_AVP_LENGTH                 5014

Br,
- Dan

> From: ext Avi Lior [mailto:[email-masked]]
> Sent: 29 November, 2004 16:52
> To: Forsberg Dan (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [Pana] [issue112] Proposed text, solicitation 
> for comments.
> 
>