Subject: RE: Self Describing record formats for multiple (non-network-acce ss) usage types ...

From: Abhi Deshmukh <[email-masked]>
Date: Wed, 17 Jan 2001 15:44:48 -0500

-----Original Message-----
From: Nelson, David [mailto:[email-masked]]
Sent: Wednesday, January 17, 2001 3:30 PM
To: [email-masked]'
Subject: RE: Self Describing record formats for multiple (non-network-acce
ss) usage types ...

>The AAA Working Group Charter states, in part: 
>(see http://www.ietf.org/html.charters/aaa-charter.html) 
>The Authentication, Authorization and Accounting Working Group focused on 
>the development of requirements for Authentication, Authorization and 
>Accounting as applied to network access. Requirements were gathered from 
>NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. 

>How do the applications you mention fit into this scope of work?  

I am trying to see if the AAA transport framework can be used to send
accounting info (available from usage records) in a peered Content Delivery
Network scenario (peered CDN). http://www.content-peering.org 

In particular the attributes of usage records in this case would be
different
than RADIUS, Mobile IP, etc. If the AAA transport can accomodate different
record formats, then the AAA framework will be very attractive for
*adoption* for billing systems for various services.

One way to accomodate known and unknown record formats is to have the
payload records describe themself. This way the transport can accomodate
*any* usage record.

I however understand the AAA framework is not meant to be all purpose. I was
trying to see if there was a thought process along the lines of extending
the AAA transport to accomodate "other" usage types.

Thanks for your time.

- Abhi

---

From: Erik Guttman <[email-masked]>
Date: Thu, 18 Jan 2001 10:03:57 +0100 (MET)

Abhi,

You wrote:
> different than RADIUS, Mobile IP, etc. If the AAA transport can 
> accomodate different record formats, then the AAA framework will be 
> very attractive for *adoption* for billing systems for various services.

DIAMETER data, represented by AVPs, is grouped in commands.  Both
the commands and the AVPs are accompanied by centrally assigned
identifiers for all standardized extensions to the protocol.  Two
compliant implementations of the protocol will be able to recognize
known commands and data, as well as unknown, non-implemented
formats, as such.  Vendor extensions allow for non-standard messages
to be sent.  

In order to make progress with AAA standardization, the working
group narrowed its focus.  This does not mean that DIAMETER extensions 
couldn't be written for other purposes than network access.  

It is up to you to figure out what your requirements are and to assess 
whether DIAMETER, SNMP or whatever best fulfill them.

> payload records describe themself. This way the transport can accomodate

Self describing data records alone do not achieve much.  Labeling a 
record format as having fields with particular data types does not 
allow the record to be *interpreted.*  Correct interpretation requires 
common rules (a protocol) to be implemented by communicating parties
so they know *what to do* with the data when they get it.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: [email-masked]
Sr Staff Engineer, Sun Microsystems       Email: [email-masked]
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 19 Jan 2001 09:06:08 -0800 (PST)

Just got back from out of town, so I appologize for the latency.

It is possible to make use of AAA for other accounting purposes. What I would
recommend is to come up with a set of requirements in an Internet-Draft, and
then figure out whether DIAMETER is the protocol that meets your requirements
(if memory serves, there already is an I-D on CDN accounting).

The biggest issue at that point is to find a home for this work. The AAA WG
has a fairly focused charter, and that shouldn't be changed since our work is
of high priority. Perhaps a BOF in Minn would be one alternative.

PatC