Subject: [AAA-WG]: Issue 119: E bit, P bit, and proxy-info

From: Pat Calhoun <[email-masked]>
Date: Tue, 21 Aug 2001 13:37:41 -0700

> A diameter error packet with an 'E' bit set MUST have the
> required AVPS listed in section 6.2, "Diameter Answer 
> Processing". 
>
> Modify section 6.2 to state that these requirements are valid
> even if the 'E' bit is set. 
>
> Modify section 7.2 to list the answer-message as
>::= < Diameter Header: code, ERR [PXY] > 
> and state that the 'P' bit will be set the same as the 'P' 
> bit in the request. 
>
> I'm not certain if we need to modify section 6.1.7. It will be
> technically correct with the requested changes, but probably 
> could be made more clear.

Ok, added a sentence to the end of section 6.2, and modified section 7.2. 
I really don't think that section 6.1.7 needs any changes.

<proposed text>

6.2  Diameter Answer Processing

[...]

   Note that the error messages (see section 7.2) are also subjected
   to the above processing rules.

[...]

7.2  Error Bit

   The 'E' (Error Bit) in the Diameter header is set when the
   request caused a protocol-related error (see section 7.1.3).
   Note that a message with the 'E' bit set is still subjected
   to the processing rules defined in section 6.2. When set, the
   answer message will not conform to the ABNF specification for
   the command, and will instead conform to the following ABNF:

   Message Format

      <answer-message> ::= < Diameter Header: code, ERR [PXY] >
                           < Session-Id >
                           { Origin-Host }
                           { Origin-Realm }
                           { Result-Code }
                           [ Origin-State-Id ]
                           [ Error-Reporting-Host ]
                           [ Proxy-Info ]
                         * [ AVP ]

   Note that the code used in the header is the same that the one
   found in the request message, but with the 'R' bit cleared and
   the 'E' bit set. The 'P' bit in the header is set to the same 
   value as the one found in the request message.
</proposed text>

PatC

---

From: Mark Eklund <[email-masked]>
Date: Tue, 21 Aug 2001 16:52:51 -0400 (EDT)

Works for me.
-mark

---

From: "Kevin Purser" <[email-masked]>
Date: Tue, 21 Aug 2001 16:36:59 -0700

Submitter name: Kevin Purser
Submitter email address: [email-masked]
Date first submitted: August 21, 2001
Reference: none
Document: NASREQ-07
Comment type: 'E'ditorial
Priority: 'S' Must fix
Section: 3.0
Rationale/Explanation of issue:
The last paragraph of this section describes the possibility for a AAA
server to "issue an unsolicited re-authentication and/or re-authorization by
issueing an AA-Challenge-Ind message to the NAS."

First and foremost, this kind of message no longer exists.  Additionally,
submitted issue #32 handles the technical issues regarding the removal of
such messages.

Requested change:
Remove the last paragraph of section 3.0

Kev

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 22 Aug 2001 09:20:47 -0700

> Remove the last paragraph of section 3.0

Actually, removing the paragraph is the wrong
fix. The correct fix is to replace AA-Challenge-Ind with
Re-Auth-Request, which is defined in the base spec.
Thanks,

PatC