Subject: Re: Suggestions regarding RADIUS encoding for draft-ietf-dime-qos-attributes-07.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Oct 2008 23:33:38 -0700

Alan DeKok said:
"The sheer number of attributes, and use of Diameter functionality
(e.g. grouping && data types) makes it difficult.
I'm not sure there are any good methods for doing this."

I would agree with Alan that there is no obvious RADIUS encoding of these attributes 
compatible with the RADIUS Design Guidelines.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 28 Oct 2008 22:26:18 +0800

Alan DeKok said:

I would agree with Alan that there is no obvious RADIUS encoding of these
attributes 

and this matters because?

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 28 Oct 2008 16:37:59 +0200

The problem is the following. Whatever we do we with the encoding someone
will come along and say that it does not comply with the RADIUS Design
Guidelines document.

I can already envision some folks who will later complain. 

Ciao
Hannes

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Glen Zorn
	Sent: 28 October, 2008 16:26
	To: 'Bernard Aboba'
	Cc: [email-masked]
	Subject: RE: Suggestions regarding RADIUS encoding for
draft-ietf-dime-qos-attributes-07.txt

	Alan DeKok said:

	

	I would agree with Alan that there is no obvious RADIUS encoding of
these attributes 

	 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 28 Oct 2008 17:24:02 -0700

As Alan noted, the issues are:

1. Sheer number of attributes.
2. Grouping. 
3. Data types.

Issues #1 and #2 could be addressed if a way could be found to use the
RADIUS Extended Attribute format.  This would address the concern of
allocating a significant fraction of all resources remaining within the
attribute space defined in RFC 2865, within a single document. 
Can you live with the grouping functionality provided in the Extended
Attributes document?

Issue #3 is more difficult.  Is there a way to live with the existing RADIUS
data types?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Tuesday, October 28, 2008 7:38 AM
To: 'Glen Zorn'; 'Bernard Aboba'
Cc: [email-masked]
Subject: RE: Suggestions regarding RADIUS encoding for
draft-ietf-dime-qos-attributes-07.txt

Ciao
Hannes

	Alan DeKok said:

	

	I would agree with Alan that there is no obvious RADIUS encoding of
these attributes compatible with the RADIUS Design Guidelines.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 29 Oct 2008 21:04:38 +0100

> will come along and say that it does not comply with the RADIUS Design

  The guidelines are guidelines, not absolute rules.  If following the
guidelines results in something horrible (e.g. 100's of attributes),
then it may be better to create a complex type, which is permitted:

   ... the introduction of new complex data types within RADIUS
   attribute specifications SHOULD be avoided,

  It's not a MUST.

  Alan DeKok.