Subject: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 25 Jan 2001 11:37:11 -0800

The RADIUS RFCs contain a table at the end, detailing which
AVPs can and cannot be included in each message. The current
DIAMETER drafts have not included such information, 
effectively leaving the syntax of DIAMETER messages
undefined. 

We need to fix this. The question is how. Erik Guttman
has proposed some fixes to the BNF format used in
the existing specs, in order to clarify the issue. 

This is a request for discussion on whether these
proposed changes should be applied to the documents
or whether another approach should be taken. 

If we do not hear objections to the changes by 
Friday, February 2, 2001 then the changes will
be incorporated into the DIAMETER specs.

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 11:43:42 -0800 (PST)

> be incorporated into the DIAMETER specs. 
Just to refresh everyone's memory, Here is the proposed format definition:

2.2  Command Code Message Definitions

   All DIAMETER Command Code MUST include a corresponding ABNF
   specification, which is used to define the AVPs that MUST and MAY
   be present.  The following format is used in the definition:

      command-def      = command-name "::=" diameter-message

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

      command-name     = diameter-name
                          ; The command-name has to be Command name,
                          ; defined in the base or extended DIAMETER
                          ; specifications.

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

      header           = "<DIAMETER-Header:" command-id ">"

      fixed            = [qual] "<" avp-spec ">"

      required         = [qual] "{" avp-spec "}"

      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.

      qual             = [min] "*" [max]
                          ; See ABNF conventions, RFC 2234 section 3.6.
                          ; The absence of any qualifiers implies that one
                          ; and only one such AVP MUST be present.
                          ;
                          ; NOTE:  "[" and "]" have a different meaning
                          ; than in ABNF (see the optional rule, above).
                          ; These braces cannot be used to express an
                          ; 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.

      max              = 1*DIGIT
                          ; The maximum number of times the element may
                          ; be present.

      avp-spec         = diameter-name
                          ; The avp-spec has to be an AVP Name, defined
                          ; in the base or extended DIAMETER
                          ; 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 command code definition.

   The following is a definition of a fictitious command code:

      Example-Command ::= < DIAMETER-Header: 9999999 >
                          { User-Name }
                        * { Host-Name }
                        * [ AVP ]
                       0*1< Integrity-Check-Vector >

An example would be the MRI, which would look like:

      <Message-Reject-Ind message> ::= < DIAMETER Header: 259 >
                                       { Result-Code }
                                       { Host-Name }
                                       { Error-Reporting-NAI }
                                       [ Session-Id ]
                                       [ Failed-Command-Code ]
                                       [ Failed-AVP ]
                                     * [ AVP ]
                                     * [ Proxy-State ]
                                     * [ Route-Record ]
                                     * [ Routing-Realm ]
                                    0*1< Integrity-Check-Value >

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jan 2001 06:35:52 -0800

> or whether another approach should be taken.

Personally, I like the table approach.  It has the virtues of extreme
simplicity and clarity.  Of corse, it says nothing about how the semantics
of AVPs interact, but given that well-designed AVPs are both declaritive and
semantically idempotent (except for groupings of AVPs designed to describe
an instance of abstract entities), this should not be an issue.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 06:58:36 -0800 (PST)

> an instance of abstract entities), this should not be an issue.

Interesting view. As a developer of RADIUS (or ex- :), I have always found
that having to move to the end of the document to find out what belongs in a
particular message to be ackward. As I am working on a particular command, I
want everything in front on me.

So in RADIUS, we have a table that spans multiple pages, such as:

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

                      #     Attribute
                      0-1   User-Name
                      0     User-Password
                      0     CHAP-Password
                      0-1   NAS-IP-Address [5]
                      0-1   NAS-Port
                      0-1   Service-Type
                      0-1   Framed-Protocol
                      0-1   Framed-IP-Address
                      0-1   Framed-IP-Netmask
                      0-1   Framed-Routing
                      0+    Filter-Id
                      0-1   Framed-MTU
[ad nauseum]

(btw, Given that some DIAMETER extensions have as many as 5 or 6 commands, the
table would obviously be structured differently. In RADIUS this was simple due
to the small number of commands that can include attributes, or 1).

In DIAMETER, the approach we've taken is each individual command, while being
defined, contains the ABNF as follows:

(or course, there is a section that defines the ABNF format). 

I, personally, find this so much simpler since everything is in front of you,
and there is no chance of missing something in the table. HOwever, I am
willing to heard from others.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jan 2001 07:46:45 -0800

> want everything in front on me.

Recently, those smart software people have developed these things called
"windows".  Apparently, some systems even allow you to have view different
parts of the _same_ file in _two_ "windows" at once! ;-)

> defined, contains the ABNF as follows:

In other words, "In Diameter, we have ABNF-like stuff spanning several
pages..."

> willing to heard from others.

Whatever.

---

From: Erik Guttman <[email-masked]>
Date: Fri, 26 Jan 2001 20:45:59 +0100 (MET)

> > Glen writes: 
> > > simplicity and clarity. 

> Pat responds:

> In other words, "In Diameter, we have ABNF-like stuff spanning several

Glen has a point - a table may be all we need here.  There are two
additional things we need to bring out in our formal presentation
of DIAMETER, though.  

We need to say that certain AVPs MUST come first (or last).  We also 
need to specify that although optional AVPs can be included, mixed in 
with required AVPs in any order, these MUST NOT break the rules 
regarding how many AVPs of certain kinds may appear.  Like if the 
rule says one and only one Z AVP has to be in a message, we can't
include another couple Z AVPs as 'optional' AVPs in the message.
This would have to be stated formally of course, and that's the
hard part.

Erik

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Jan 2001 13:17:49 -0800

>Glen has a point - a table may be all we need here.  

The table is nice and simple and might be useful no matter
what else we do. But there may be situations which cannot be covered
in the table. So how do we specify those?

>We need to say that certain AVPs MUST come first (or last).  

I can think up a couple of things that haven't yet been discussed
that would fit in this category. How do you specify, for example,
that certain AVPs occur first in the message, and must not be
encrypted (e.g. message type, destination NAI, etc.)

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 13:36:46 -0800 (PST)

> encrypted (e.g. message type, destination NAI, etc.)

Correct. There are a couple of ordering rules, and these are REALLY hard to
put in a table. Of course, you can add text throughout the document, in the
actual AVP descriptions, but that, again, just makes it harder to find.

However, Glen really likes tables, and Erik seems to agree.

Both? Where the table is just a quick reference?

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Jan 2001 22:09:03 -0800

>Both? Where the table is just a quick reference?

Do both, but make sure they agree ;)

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 27 Jan 2001 03:41:01 -0800

> encrypted (e.g. message type, destination NAI, etc.)

(Continuing in semi-smartass mode)  How about English?

---

From: Patrice Calhoun <[email-masked]>
Date: Sat, 27 Jan 2001 10:15:28 -0800 (PST)

> (Continuing in semi-smartass mode)  How about English?  

Of course, that would be the language of choise. The issue, though (again) is
whether distributed information like this would ease interoperability, as
opposed to a central location (e.g. per message).

Again, I am flexible. I'll do what the WG wants.

PatC