Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command Code ABNF sp ecification

From: [email-masked]
Date: Thu, 18 Oct 2001 18:38:47 +0300

Hi,

I took the number from the diameter.org but now I noticed that this is
already used. Sorry for this confusion. This is a new issue and requires a
new number.

Best Regards, Jaakko

> -----Original Message-----
> From: ext Pat Calhoun [mailto:[email-masked]]
> Sent: 18 October, 2001 17:32
> To: Rajaniemi Jaakko (NET/Espoo)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Issue 200: Alternatives to the Command 
> Code ABNF
> specification
> 
> 
> May I ask why you've used 200? There is already one. Is this 
> a new issue that 
> requires a new issue number?
> 
> PatC
> On Thu, Oct 18, 2001 at 04:33:55PM +0300, 
> [email-masked] wrote:
> >  
> > 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: [email-masked]
Date: Tue, 23 Oct 2001 16:40:56 +0300

Hello,

The same change would be nice to have in the Grouped AVP definition also.
This would mean that in the section 4.5 "Grouped AVP Values" and the
avp-spec definition in there is modified in the same way:

      avp-spec         = name-fmt *("/" name-fmt)
                        ; The avp-spec has to be an AVP Name, defined
                        ; in the base or extended Diameter
                        ; specifications. The avp-spec may contain AVP Names

section 3.2

This would allow the same type of ABNF grammar to be used with the Command
codes and the Grouped AVPs.

Best Regards, Jaakko
> Sent: 22 October, 2001 22:46
> Cc: [email-masked]; [email-masked]
> sp ecification
> Ah, I like it.
> Others?
> On Mon, Oct 22, 2001 at 07:23:16PM +0300, 
> > > 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?
> > 
> > The proposal allows to contruct commands where it is 
> required (or fixed or
> > optional) to include one of the alternatives in the ABNF 
> definition. This is
> > not like allowing to have alternate names for AVPs for no 
> reason at all. For
> > example, in the following command definition:  
> > 
> >       Example-Request ::= < Diameter-Header: 9999999, REQ, PXY >
> >                           { User-Name }
> >                           { Origin-Host }
> >                           { example1_AVP / example2_AVP }
> > 				* [ AVP ]
> > 
> > The Example-Request command MUST have either example1_AVP 
> or example2_AVP.
> > These type of definitions are quite common but they are not 
> possible with
> > the current command code ABNF specification.
> > 
> > Or as in the following example below, the Example-Request 
> command can
> > optionally have either example1_AVP or example2_AVP and 
> nothing else.
> > 
> >       Example-Request ::= < Diameter-Header: 9999999, REQ, PXY >
> >                           { User-Name }
> >                           { Origin-Host }
> >                           [ example1_AVP / example2_AVP ]
> > 
> > >  
> > > PatC
> > 
> > Best Regards, Jaakko
> > 
> > > Sent: 22 October, 2001 18:17
> > > 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: [email-masked]
Date: Thu, 25 Oct 2001 11:23:52 +0300

Hi Erik,

> 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 can't see how my proposal complicates rules to determine if an AVP is
supported by an application at all, because alternatives means that the
actual AVP included into the command can be one of the alternatives
represented in the definition and therefore all alternatives must be
supported by the application. 

The proposal only improves the representational power of the Diameter
command code definition.
 
> > 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.

I think that you mean that the diameter-name is terminal and my proposal
does not change that.

Best Regards, Jaakko

PS. As you may have noticed the reference to RFC2243 is wrong. It should be
RFC2234 (ABNF specification).

> From: ext Erik Guttman [mailto:[email-masked]]
> Sent: 24 October, 2001 11:20
> 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
>

---

From: [email-masked]
Date: Mon, 29 Oct 2001 14:36:12 +0200

Hi,

> > If the command definition needs all those options they are going to 
> > be there in a form or another.
> 
> None of them need it now.  Why do you think some will in the future?

Well, you could answer that they don't seem to need it because it has not
been possible. At least this is true, for example, in the capability
negotiation, where this would have been useful (see mail):

http://www.merit.edu/mail.archives/aaa-wg/2001-09/msg00091.html

What comes to new applications in the future, it is difficult to say what is
needed and due to this the base should allow enough possibilities to define
ABNF grammar for commands.

> > It will increase the complexity of the ABNF format of the command 
> > definition, but will make the intended syntax of the command more 
> > explicit, and the command definition more understandable.
> 
> The *command* itself will be more complex as a result.  
> That's what I'm
> trying to say.

I think that it is the people who specify commands who make things complex
and not alternatives. In the right hands, alternatives can make
specifications more clear.

Best regards, Jaakko

> From: ext Erik Guttman [mailto:[email-masked]]
> Sent: 29 October, 2001 10:56
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [email-masked]; Rajaniemi Jaakko (NET/Espoo);
> [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Issue 200: Alternatives to the Command 
> Code ABNF
> sp ecification
> 
> 
> Jarno,
> 
> > > If there are 3 rules which have 3 options each, there are 9 valid 
> > > combinations.  Are all valid?  Things get ugly if the 
> options aren't 
> > > independent.  Further, more options make interoperation harder to 
> > > verify and protocol implementations more complex and less 
> likely to 
> > > be hardened.
> >
> > If the command definition needs all those options they are going to 
> > be there in a form or another.
> 
> None of them need it now.  Why do you think some will in the future?
> 
> > It will increase the complexity of the ABNF format of the command 
> > definition, but will make the intended syntax of the command more 
> > explicit, and the command definition more understandable.
> 
> The *command* itself will be more complex as a result.  
> That's what I'm
> trying to say.
> 
> > To enable more explicit command definitions in the future, 
> where more 
> > of the command syntax is being described by the ABNF rather 
> than the 
> > English text accompanying it.
> 
> Expliciteness isn't the issue.
> 
> Imagine if a TCP implementation in LISTEN state could receive 
> a SYN or 
> a SYN1 or a SYN2.  SYN1 and SYN2 are alternatives, different 
> than SYN.  
> Would this simplify the state table of TCP?  Would this lead 
> to better 
> interoperability, to more robust and efficient implementations?  No.
> 
> TCP was defined with as few options as possible.  When it was 
> discovered
> that TCP had to be enhanced and extended - that's what folks 
> did - and 
> the base protocol (extension options) allowed for this.  So 
> with DIAMETER, 
> we allow for optional AVPs and in the worst case, if we get 
> it wrong, the
> creation of new Commands.
> 
> > But to respond to Pat's comment, I am not aware of an 
> existing bug in the
> > current Diameter specs that this would be a solution for. 
> All the possible
> > bugs can be fixed just as well by fine tuning the English 
> describing the
> > command :-)
> 
> Here I disagree:  You can't say in text that either AVP A or AVP B is 
> *required.*  The grammar of each command specifies all 
> 'required' AVPs.  
> Either AVP A is required or it isn't, AVP B likewise.
> 
> We have to decide whether to open the spec up for required message
> components which are contingent on implementation choice 
> ("Should I send
> AVP A or AVP B today?")  Or should we stick with a definite and 
> unambiguous specification of command message required components?
> 
> Erik
>