Subject: [AAA-WG]: Issue 103: More editorial comments

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 30 Jul 2001 16:26:56 +0200

Submitter name: Fredrik Johansson
Submitter email address: [email-masked]
Date first submitted: July 30th, 2001
Reference: N/A
Document: base
Comment type: E
Priority: 1
Section:
Rationale/Explanation of issue:

Some of these comments may be duplicates of earlier posted issues, I've
tried to find them but might have missed a few.

Section 1.1 Last sentence
"An example of an unsolicited message would be for a request that the client
issues an accounting update"
If I'm not misstaken that feature was removed, if so, use another example
e.g. "... for a request that the client re-authenticate"

Section 1.3
Reference in the NAI should be 8 instead of 3.

Section 2.1
3rd paragraph, replies MAY any -> replies MAY be any

Section 2.3.2
"Note that new AVPS to be used with an existing application MUST NOT
   be defined to have the 'M'andatory bit set."

is contradictory with section 2.4
"An implementation MAY add arbitrary AVPs to any command defined in an
   application, including vendor-specific AVPs. However, implementations
   that add such AVPs with the Mandatory 'M' bit set are not compliant,
   and are at fault if the peer rejects the request."

remove sentence in 2.3.2

Section 2.6
- Status. This is the state of the peer entry, and MUST match one
  of the values listed in section 5.6.

Do you mean the values in 5.5.3?

Section 3.0
E(error) - If set, the message contains a protocol error

Just a protocol error, why not any error?

Section 4.4

"If no rule matches, the packet is
         dropped if the last rule evaluated was a permit, and passed if
         the last rule was a deny."

To me it seems a bit strange that what to do with the packet should be
determined by the last rule evaluated even if it doesn't match that rule.
Even more strange when you decide to pass the packet based on the fact that
the last rule was a deny even if it didn't match.

But that might be the correct behavior for ipf, just wanted to point this
out to see if someone who perhaps knows more about this reacts to it.

Section 4.5
"All AVPs included in a Grouped AVP Every Grouped AVP defined MUST
   include a corresponding grammar, using ABNF [31] (with
   modifications), as defined below."

Strange sentence.

Section 6.1.4
"A request is known to be for local consumption when one of the
   following conditions occur:
      - The Destination-Host AVP contains the local host's identity,
      - The Destination-Host AVP is not present, the Destination-Realm
        AVP contains a realm the server is configured to process
        locally, and the Diameter application is locally supported, or
      - The Destination-Realm AVP is not present."

If the Destination-Host AVP contains a non local host identity and the
Destination-Realm AVP is missing this will evaluate to be a request for
local consumption. But on the other hand, a request with a Destiantion-Host
AVP and without a Destination-Realm AVP is considered wrong, right?!?

Section 6.3
Might want to clearify that the route records removed must be saved with the
pending request so that they can be restored when answering.

Section 7.0
"Figure 8 provides an example of a Diameter message that caused an
   application error. When application errors occur, the Diameter entity
   reporting the error clears the 'R' bit in the Command Flags, and adds
   the Result-Code AVP with the proper value. Application errors do not
   require any proxy or relay agent involvement, and therefore the
   message would be forwarded back to the originator of the request.

Should one realy return the whole request but with the 'R'-bit cleared and a
result code AVP? Why not have the same abnf for all errors, the request that
caused the error is stored as pending anyway. Set the 'E'-bit and return the
abnf specified in section 7.2.

Section 7.2.

{Destination-Host AVP}

if I'm not misstaken, this avp should never be present in any answers.

Section 8.4
"
   When a user session that required Diameter authorization terminates,
   the access device that provided the service MUST issue a Session-
   Termination- Request (STR) message to the Diameter server that
   authorized the service, to notify it that the session is no longer
   active. An STR MUST be issued when a user session terminates for any
   reason, including user logoff, expiration of Session-Timeout,
   administrative action, termination upon receipt of an Abort-Session-
   Request (see below), orderly shutdown of the access device, etc."

add something like: "unless an Auth-Session-State AVP was received set to
'NO_STATE_MAINTAINED'."

Section 8.9
Authorization Lifetime is of type Unsigned32, i.e. it can never become a
negative number remove the (-1) or change the number.

Section 8.11
It's not clear that it's the answer from the server that should be applied,
even if it's stated in section 8.0

Section 10.1

Could you send a Class AVP in a DWR? it's marked as 0+ in the table.

Can't all answers have a Failed AVP?

That's all for now,

/Fredrik