Subject: [AAA-WG]: Grouped AVPs

From: Paul Funk <[email-masked]>
Date: Tue, 01 May 2001 19:54:38 -0400

Though it is perhaps ambiguous in the base draft, the 
intent of the grouped type is to allow only a fixed set 
of AVPs in a specified order within any particular 
grouped AVP.

I think this severely limits the usefulness of grouped 
AVPs and is contrary to the spirit of extensibility 
which characterizes Diameter. And what a waste of bits 
it is to use a self-describing format to encapsulate 
what amounts to a fixed structure.

Diameter as currently defined is a hierarchical, 
self-describing data modeling language with extensibility 
at the top level, and calcification into fixed structures 
thereafter. If ASN.1, XML or LDAP had such limitations, 
they would never have achieved success.

One need look no further than the original RADIUS 
grouping mechanism to see why fixed structures is a bad 
idea. 

In RADIUS, tunnel attributes are tagged to allow related 
attributes to be grouped. In Diameter, this is 
accomplished by including all values for a particular 
tunnel within the grouped Tunnel AVP. But in RADIUS, 
it is possible to omit particular tunnel attributes, or 
define new ones as required. In Diameter, it is not.

Another example is the Redirect-Host AVP, comprising 
one AVP for address and another for port. But the 
draft vacillates, saying that if only address is 
required, it may be sent ungrouped. The draft also 
states that the redirect may also include certificates 
for the home server. But if different certificates are 
required for different servers, how would you 
associate the certificate with the address/port it 
applies to? Better would to require redirect 
destinations to be specified only one way -- within 
the grouped Redirect-Host AVP, allow it to contain 
an address and optionally a port, and let it be 
extensible to contain a certificate reference or any 
other information that may be required in the future.

I suggest that we allow a grouped AVP to be defined 
as restrictively or as liberally as we allow Diameter 
messages to be defined. Thus, the ABNF for a grouped 
AVP could contain sequence rules or not, could contain 
optional attributes or not, could contain the wildcard 
[AVP] or not, etc. In general, the liberal approach 
should be used, unless there is a really good reason to 
fix the contents of a group.

An additional benefit of this approach is that it makes 
it possible to define an AVP as a homogeneous list of 
AVPs, simply by defining its ABNF as *[Some-AVP].

Should the group agree, here's some suggested language:

Every Grouped AVP defined MUST include a corresponding ABNF
specification, which is used to define the AVPs that MUST, MAY and
MUST NOT be present. 
   
The format to be used follows the format for Command Code ABNF 
specifications (3.2), with the following additional definition:

group-def = AVP-name "::=" [*fixed] [*required] [*optional] [*fixed]

It is possible to include an AVP with a Grouped type within a
Grouped type, that is, to nest them. AVPs within an AVP of type
Grouped have the same padding requirements as non-Grouped AVPs, as
defined in section 4.0.

Example:

group-def ::= example-avp
              {Origin-FQDN}
              {Host-IP-Address}
             *[AVP]

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: David Frascone <[email-masked]>
Date: Tue, 1 May 2001 19:37:19 -0500

I can not agree with you more.  I love the idea of grouped AVPs,
but I am very much against the strict ordering and format of them.
A grouped avp shoud be as extensible as the Diameter message itself.

-Dave

---

From: Paul Funk <[email-masked]>
Date: Wed, 02 May 2001 18:04:12 -0400

Erik,

At 03:19 AM 5/2/01 -0700, Erik Guttman wrote:
>On Tue, 1 May 2001, Paul Funk wrote:
>
>It is not too ambiguous I hope.

The ambiguity arises from requiring ABNF specification 
for grouped AVPs, implying the expressive power of 
that language, yet a grouped AVP must be a well-defined 
sequence. If it's just a list of attributes, why use ABNF?

>The purpose of the Grouped-AVP was to allow certain AVPs
>to be provided in combination with each other - always
>the same exactly the same AVPs.  This allowed complex
>data to be delivered.  The only other options would have
>been to have a complex data type (which would have made
>for an indeterminate set of parsers - and a messy base
>protocol requiring specialized parsers) or an open ended
>grouping (which defies a regular grammar and automatic
>parsing).  The complex data type approach was tried in
>draft-calhoun-diameter-0..14 and the group-avp bucket
>was tried in draft-calhoun-diameter-15..17.

We already have a regular grammar for the Diameter message, 
so having one for grouped AVPs doesn't add to the order of 
complexity. Just set your automatic parser to "stun" when you 
want to use it on an AVP rather than on an entire message.

>
>The requirements for diameter protocol clean up vis-a-vis
>data representation issues was discussed in 
>draft-ietf-aaa-issues-04.txt - with solutions proposed
>in draft-ietf-aaa-solutions-01.txt.  The WG last call on
>the issues document ended Feb 28.  Please read section 9
>of that document - which now represents working group
>consensus.

Now I have to cry foul. What you're saying is that any discussion 
of this issue is out-of-bounds. But the solutions document is 
a set of recommendations for how the group ought to proceed, 
according to then current thinking, not a bounding box.

>What we have in DIAMETER is *one* feature which allows for
>structuring data - the Grouped-AVP.  These allow for regular
>groupings.  If more groupings are needed - say a Bag-AVP,
>these too can be defined.  Please feel free to define one.

"Grouped" is not an AVP -- it's a data type. I certainly don't 
feel free to define a new type. We need to make sure that the 
primitive data types that are defined in the base draft are 
adequate for expressing the data exchanges that will be 
required, rather than just dodge the issue by saying that you 
can define an AVP however you like. AVPs that represent 
collections should not follow ad hoc rules defined for that 
AVP alone.

>So - either do not define tunnel attributes as being
>delivered by a Group-AVP or define a new Group-AVP when
>it becomes clear that the old one is no longer correct.
>In either case, backward compatibility is a problem which
>doesn't go away by removing rules from the protocol.

Your suggestion of "either don't use it or define lots of them" 
really argues for a single extensible AVP. In fact, the ability 
to provide backward compatibility is greatly enhanced by 
being able to extend the same grouped AVP. For example, 
additional AVPs could be added to the group and marked 
non-mandatory, allowing older servers to remain compatible.

>Where it is not necessary, we should not specify that
>the Grouped-AVP be used.  In some cases it is necessary.
>
>This would lose the advantages of simplicity, regularity,
>and specifiability, as discussed in the issues draft.

These are minor advantages that really dumb-down the 
protocol -- a bad tradeoff against flexibility and durability.

>We have not had any specific examples of where lists
>would be needed.  No examples exist in current RADIUS
>specs.  If we could find such uses, we should specify
>a mechanism to do this.  The Grouped-AVP does not support
>creation of lists, I fully agree.

Well, see section 9 of draft-ietf-aaa-solutions-01.txt. It 
recommends that "List" be one of the data types. That 
represents working group consensus, right?

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]