Subject: Re: [AAA-WG]: Issue #4: Grouped AVP

From: Patrice Calhoun <[email-masked]>
Date: Tue, 15 May 2001 09:30:18 -0700 (PDT)

thanks for the comments Ignacio.

So far we have four people very vocal to changing the Grouped AVP to be more
flexible, and one reason being that the protocol wouldn't be useable in today's
networks. There is one person against such a proposal.

I believe that the chairs will have to evaluate whether or not we have
consensus, and I am not sure that all of the interested parties can make the
meeting next week.

PatC
> At 07:17 AM 5/15/01 -0700, Pat Calhoun wrote:
> >Erik has made a claim that issues against the issues draft need to be 
> >raised, since this draft had passed last call, with no objections. Changing
> >the Grouped-AVP at this time could add significant delays.
> 
> Maybe, but it will also make Diameter useable. As it stands, Diameter
> cannot be deployed realistically on an environment that implements
> tunneling (or at least, not without some serious vendor extensions).
> 
> There are many reasons why someone will not want to specify all the
> tunneling attributes. For example, we have customers that will not send
> a Tunnel-Password attribute under any circumstance. They have business
> reasons that can't be ignored just because they don't fit the AAA WG
> schedule.
> 
> I know you and the WG have been working extremely hard on this (the community
> at large appreciates your effort) but, IMHO, ignoring the real world because
> "it would add delays" essentially will condemn Diameter to be a passing fad.
> RADIUS lives on simply because it is simple and very flexible. If you want
> Diameter to have a long life, it MUST be flexible as well because simple, it
> isn't.
> 
> 
>

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 15 May 2001 07:17:44 -0700

Given that this one hasn't been closed, I will open an issue so we can
discuss it next week.

Paul has indicated some circumstances where the strictness of the Grouped
AVP is a disadvantage.

Example:
  The tunneling Grouped AVP in NASREQ requires that ALL tunneling AVPs be 
  present, even if they shouldn't). So either we leave it as-is, or
  create a group for all combinations.

PatC

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 15 May 2001 09:22:21 -0700

Diameter to have a long life, it MUST be flexible as well because simple,
it isn't.

---

From: David Spence <[email-masked]>
Date: Fri, 18 May 2001 14:40:23 -0400

I think there were actually two different needs that got somewhat mixed up. 
I think we ought to meet both needs.

The Grouped type AVP originally replaced the Complex type.  RADIUS has a few
attributes of a complex type, that is, the value field encompasses multiple
sub-fields.  The Grouped type was a way of dealing with that problem while
providing stronger typing.

RADIUS also introduced attribute tagging which, as I and others have argued,
suffers from a number of limitations.  The Grouped type also became a
replacement for tagging.

But these two goals are not always consistent.  Sometimes you want an AVP
with fixed, well-defined contents.  Sometimes you just want a bag to lump
some AVPs together.

We could create two types -- a Grouped type (same as currently defined) and
a Bagged type.  Alternatively, we could simply broaden the definition of the
Grouped type to allow flexible bagging, but also allow fixed groups.  This
would be accomplished using the ABNF.  Each AVP definition for a Grouped
type AVP would specify via the ABNF what degree of flexibility that
particular AVP had -- possibly flexible, possibly fixed.

Would that work?

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 18 May 2001 13:28:51 -0700

> particular AVP had -- possibly flexible, possibly fixed.

Right. My preference would be to simply make use of ABNF with the Grouped
type, and not introduce yet another type.

PatC

---

From: Erik Guttman <[email-masked]>
Date: Mon, 21 May 2001 09:18:55 +0200 (MET DST)

David,

> particular AVP had -- possibly flexible, possibly fixed.

I think so.  It is a good compromise.  

Groups with a fixed ABNF can be dealt with automatically and 
verified.  (Satisfies section 9 of draft-ietf-aaa-issues-04.txt)

We have to be very clear which ABNF is fixed.  Possibly it is
enough to say if all productions are single items (i.e. there 
are no '*' qualifiers in the grammar).

ABNFs with indefinite '*[AVP]' terms are effectively Bags.
Bags can be flexible and imposes the least possible restrictions.  
(Satisfies RADIUS afficionados and Perl programmers :-)  I guess
this is better than a bunch of separate Bag types to get around
the fixed grammar of the Group.  No one wants an ever growing
list like <Tunnel-Bag>, <Tricky-Firewall-Traversal-Bag>, etc.

Erik