Subject: RE: [AAA-WG]: Comments on Base v.3

From: James Kempf <[email-masked]>
Date: Fri, 11 May 2001 10:54:01 -0700 (PDT)

Afraid I'll have to side with Erik here. The current Diameter types are
very simple, based purely on syntax. This proposal seems to be returning to the 
idea of having more complex, semantic based types. I think the spec
should stick to one or the other.

If you want to have a complex AVP, then you should be using a data
definition language like XML (but not confined to XML) to define it.
Grouped should be for a predefined collection of AVPs, not for
defining complex hierarchies.

		jak

>Delivered-To: [email-masked]
>X-Sender: [email-masked]
>Date: Fri, 11 May 2001 13:22:17 -0400
>To: [email-masked], Erik Guttman <[email-masked]>, Fredrik Johansson 
<[email-masked]>, Patrice Calhoun 
<[email-masked]>, [email-masked]
>From: Paul Funk <[email-masked]>
>Subject: RE: [AAA-WG]: Comments on Base v.3
>
>The issue of flexibility in the ABNF for a grouped AVP is clearly one that 
>Dave Frascone and I feel strongly about, and Erik Guttman has ardently 
>spoken against.
>
>The way the draft is written now, if you wanted to define a grouped AVP, 
>you'd have to specify the exact sequence of AVPs it must contain. If you 
>realize later than additional information would useful, you'd have to define 
>a brand new grouped AVP. If you want to collect a set of attributes in a 
>group but allow some to be present and some not, you'd have to define a 
>separate grouped AVP for each possible combination.
>
>One argument against polymorphic groups is that we have no concrete 
>examples of a hard requirement for it. Well, it we wait for the dispositive 
>example to come along, we may be out of luck when it does.
>
>Meanwhile, there are many reasons to anticipate polymorphic groups will 
>become necessary in the future.
>
>How will we be able to return complex policy or hierarchical accounting 
>data without flexibility in grouping?
>
>People have been told to use XML inside a Diameter AVP or just package 
>some other accounting format within a Diameter AVP, because Diameter 
>as a protocol is too "flat" to handle their data. But if we allow polymorphic 
>groups, we'd be able to render the XML data model perfectly when that 
>becomes necessary.
>
>Plus, my original email on the subject raised an issue which no one has 
>yet attempted to address: 
>
>The draft states that when a Redirect DSI is issued, it provides the 
>addresses/ports of one or more home servers to redirect to in the 
>Redirect-Host grouped AVP, and it may also provide certificates 
>for the home server. The question is, if different home servers have 
>different certificates, how do you associate each home server with 
>the appropriate certificate without extending the Redirect-Host AVP. 
>Pat, any thoughts on this question?
>
>Erik, I responded to your points in line.
>
>Paul
>
>
>At 09:57 AM 5/11/01 +0200, Erik Guttman wrote:
>>
>>"Fredrik Johansson" <[email-masked]> wrote:
>>> >> 4.4 Grouped AVP Values
>>> >> What about Paul's idea of being able to define optional AVPs
>>> >> in a grouped AVP?
>>> >
>>> >I am waiting for WG concensus. I think that the chairs need to step in
>>> >to help us out. I have two people that have asked for this, Erik has
>>> >opposed it. That's not exactly what I would call concensus, so Bernard
>>> >and Dave need to intervene, and help us out.
>>> 
>>> Ok, then it's 2-1, not much of a WG concensus, hope that more people 
>>> speaks up.
>>
>>We are not voting here.  draft-ietf-aaa-issues-04.txt akes the case for 
>>a regular grammar for Diameter.  This WG draft has gone through WG last 
>>call.  It's really up to Paul and Dave to show that this *WG consensus 
>>action* is off base.
>
>We can argue about the rules of the game, or we can argue about the 
>issues. 
>
>And, since Fred revived the question, I'm wondering whether it isn't 3-1 by 
>now. Is this the beginnings of a groundswell?
>
>>
>>The perception is that this is at the cost of some RADIUS-like
>>flexibility.  Well, Diameter allows arbitrary AVPs to be added 
>>to a message, just not to a Group value.  And RADIUS didn't have 
>>Group values. So the ability to add arbitrary AVPs to Groups doesn't 
>>amount to less flexibility for Diameter than was present in RADIUS.
>
>The only grouping concept in RADIUS is tagged tunnel attributes. But 
>in RADIUS, you can have a subset of the tunnel attributes in a tag 
>group, not necessarily all of them. And, if new tunnel attributes are 
>defined, they can be added to the tag group. So that hack of a 
>mechanism in RADIUS provides more flexibility than what we have 
>defined for Diameter.
>
>>
>>The Grouped AVP replaces the complex data type and the Group-AVP bag. 
>>It facilitates (1) a data dictionary compatible with complex data 
>>(2) ensures that all components of complex data are present 
>>(3) eliminates the need for specialized parsing code for complex data 
>>(4) facilitates automatic parsing / message completeness checking.
>>
>>If Group values can include arbitrary AVPs, I do not see that they
>>serve these 4 ends.  
>
>First, let's be precise. I never proposed that grouped AVPs can include 
>arbitrary AVPs. I proposed that grouped AVPs be defined via ABNF, just 
>as the Diameter message itself is. The ABNF can be as flexible or 
>restrictive as is deemed necessary. I would hope that people would 
>define new AVPs flexibly. But they could still have rules for required 
>attributes, sequencing, etc.
>
>I think that an ABNF-specified group absolutely does meet the four 
>goals listed above.
>
>>
>>If the constraints on Group values are truly thought to be too 
>>binding, let's just eliminate the Group type altogether and go 
>>back to the RADIUS model of 'strictly' non-organized AVPs 
>>bundled together to form a message.  But let's hear some good
>>arguments why this is preferable before revising the position 
>>supported by draft-ietf-aaa-issues-04.txt.
>
>Obviously, no one is saying we should eliminate grouped AVPs 
>entirely.
>
>
>Paul Funk
>Funk Software, Inc.
>617 497-6339
>[email-masked]
>
>