Subject: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF specification

From: [email-masked]
Date: Thu, 18 Oct 2001 16:33:55 +0300

Submitter name: Jaakko Rajaniemi 
Submitter email address: [email-masked] 
Date first submitted: 2001-10-18 
Document: base 
Comment type: T 
Priority: 1 
Section: 3.2 
Rationale/Explanation of issue: 

The section 3.2 "Command Code ABNF specification" contains the ABNF
specification which must be followed when contructing Diameter Command
Codes. It does not contain a possibility to use the alternatives (see
RFC2243, section 3.2) when defining the AVPs included into the commands.
This is very restrictive and does not allow enough flexibility when defining
command codes and therefore it is proposed that the alternatives is
included. 

Requested change:

Include following description to the avp-spec in the section 3.2:
 
avp-spec         = diameter-name *("/" diameter-name)
                  ; The avp-spec has to be an AVP Name, 
			; defined in the base or extended Diameter
                  ; specifications. The avp-spec may contain AVP Names 
			; which are alternatives, see RFC 2234 section 3.2.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 18 Oct 2001 07:32:28 -0700

May I ask why you've used 200? There is already one. Is this a new issue that 
requires a new issue number?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 22 Oct 2001 08:16:44 -0700

> 			; which are alternatives, see RFC 2234 section 3.2.

What this section proposes is that each AVP name have an alternate name, 
increasing the confusion in the protocol.

Why does the Diameter protocol require alternate names for AVPs?

PatC

---

From: Erik Guttman <[email-masked]>
Date: Wed, 24 Oct 2001 10:20:22 +0200 (MET DST)

Jaakko,

> Codes. 

This is intentional.  Command codes are terminals in Diameter messages.
I can't say an AVP is either this or that.  

> This is very restrictive and does not allow enough flexibility when 
> defining command codes and therefore it is proposed that the 
> alternatives is included. 

Restrictiveness in a type system is good.  It makes it clear what you
require.

Let's say we get things wrong and have to revise a particular diameter
application.  We just create new AVPs and commands as necessary.  
Backwards compatibility is assured precisely **because** we have been 
very strict and very clear about what AVPs mean.

  First version                Revised version
  -------------                ---------------
  Application A                Application B
     Command A1                   Command A1
        Avp A11, A12, A13            Avp A11, A12, B13, B14
     Command A2                   Command B2
        Avp A21, A22                 Avp B22
     etc.                      etc.

Note the revised version 
 - has a new application id
 - will reuse command IDs, if possible, but may replace them (A2->B2)
 - will reuse AVP ids if possible, but may replace them (A13->B13),
   remove them (A21-> not supported) or invent new ones (A1 uses B14).

The result of your change would be much more complicated rules to
determine if an AVP was supported for any given application.  These
rules would get ever more complex as we revised the application.
Consider if each AVP in the 'first version' referred to possibly many
variants.  This aliasing complicates revision, interpretation and
reasoning about the specification.  

I say KISS ('Keep It Simple Standards-cowboys!')

> It does not contain a possibility to use the alternatives (see

The section you refer to describes how to list alternatives among
non-terminals.  AVP names are currently terminals and I argue they
should stay that way.

Erik