Subject: proposed new section for DIAMETER base specification

From: "Erik Guttman" <[email-masked]>
Date: Wed, 10 Jan 2001 14:10:03 +0100

I am in the process of reworking the diameter specification
according to proposals made in the AAA design team.

I would like more feedback from implementors and working
group participants about some of these changes, as they
have received very little feedback.  I believe we do not want
to add requirements or change the protocol at this point unless
there is strong support and a good reason for doing so.

Please refer to draft-ietf-aaa-issues-04.txt, section 9.1
and draft-ietf-aaa-solutions-01.txt, section 9.1.

The proposed changed text would define 3 flags for the
diameter message header.  

-----------------------------------------------------------

Proposed change to section 2.1

   Flags
      The Message Flags field is five bits, and is currently unused.
      This field MUST be initialized to zero.

is replaced by ->

      The Message Flags field is five bits.  The following bits are
      assigned:

      +---+---+---+---+---+
      | z | z | E | I | R |
      +---+---+---+---+---+

      0x10 MUST be zero - this flag bit is reserved for future use.
      0x08 MUST be zero - this flag bit is reserved for future use.
      0x04 ('E' Expect Reply) The message solicits a response.
      0x02 ('I' Interrogation) The message is a Query or a Reply.
      0x01 ('R' Response) The message is a response another message.

      These flags are set depending on the command code used in a
      DIAMETER message.  This enables the type of message to be 
      interpreted, even if the specific command code is not recognized.
          
      Command Type   Flags Set
       Indication      - - -
       Request         E - -
       Answer          E - R
       Query           E I -
       Reply           E I R

      A DIAMETER node MUST NOT set these flags in any other combination.
      A DIAMETER node receiving a message in which these flags are not
      set appropriately SHOULD NOT reject the message for this reason,
      but MAY log the event for diagnosis.

---

From: "Kevin Purser" <[email-masked]>
Date: Wed, 10 Jan 2001 10:07:59 -0800

Hi Erik/All,

Just a quick comment... (inline)

>       interpreted, even if the specific command code is not recognized.

It seems a bit odd to set the "Expect Reply" bit in a Reply message, and
probably an Answer message as well, since neither of which directly solicit
a Reply.