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

From: [email-masked]
Date: Fri, 26 Oct 2001 10:24:54 +0300

Erik,

> It gets worse the more options you have.  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. With the current grammar some AVPs will be made
mandatory (and they are included even if that would be unnecessary) and the
rest optional. Natural language text in the command definition will then lay
out the rules on the interrelationships of these AVPs, specifying when each
optional AVP should be included, etc.

The proposed change would enable making these rules more formally defined
and easier to see from the command definition itself. 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 overall complexity of the command definition and it's implementation
should not change.

> > > This would require a rewrite of all Diameter specs.  This 
> is not only
> > > editorial work.  It would require quite a bit of 
> technical review to
> > > make sure it remained equivalent to the old representation.
> > > 
> > 
> > I though that the rules I presented were backwards 
> compatible. The current
> > way of placing each AVP in it's own brackets is still covered by the
> > proposed new grammar rules. Hence the grammar rules in the 
> Base Diameter is
> > the only place that needs to be changed.
> 
> If so - why do you want to introduce this change?!?  To ease the way
> for protocol complexity in the future?  :/
> 

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.

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 :-)

	Jarno

---

From: Erik Guttman <[email-masked]>
Date: Mon, 29 Oct 2001 09:55:53 +0100 (MET)

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.

> bugs can be fixed just as well by fine tuning the English describing the

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