RE: Questions on modified Extended Attribute format?

"Glen Zorn" <glenzorn@comcast.net> Thu, 27 December 2007 23:35 UTC

Return-path: <owner-radiusext@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J82G1-0006wW-BU for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 18:35:21 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J82Fz-0003g0-OB for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 18:35:21 -0500
Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1J82AT-000Fq0-C9 for radiusext-data@psg.com; Thu, 27 Dec 2007 23:29:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3
Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from <glenzorn@comcast.net>) id 1J82A1-000Fnq-Te for radiusext@ops.ietf.org; Thu, 27 Dec 2007 23:29:23 +0000
Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id VyqN1Y00816AWCU0A02d00; Thu, 27 Dec 2007 23:29:09 +0000
Received: from gwzPC ([67.168.164.234]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id VzV81Y00653lGY38S00000; Thu, 27 Dec 2007 23:29:09 +0000
X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=48vgC7mUAAAA:8 a=No5EcEP4AAAA:8 a=ECnOX4djFyjpVVWMxboA:9 a=UWfgv0dW2oblu7RHuf8A:7 a=_wMaV0gE8aUV72-Uf9d3EpytRIYA:4 a=tqucuuI3bnEA:10
From: Glen Zorn <glenzorn@comcast.net>
To: 'Alan DeKok' <aland@nitros9.org>
Cc: radiusext@ops.ietf.org
References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> <47732E9D.4030803@nitros9.org>
In-Reply-To: <47732E9D.4030803@nitros9.org>
Subject: RE: Questions on modified Extended Attribute format?
Date: Thu, 27 Dec 2007 15:28:26 -0800
Message-ID: <00b401c848e0$2f0e9c60$8d2bd520$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchIRFH0Fy3x6ehPQu6lbVwDQtyEOQACiamA
Content-Language: en-us
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44

Glen Zorn wrote:
> I understand, & sympathize; I think that it's important to remember that a
> major reason that we ended up in the position of having multiple external
> SDOs defining their own mutually incompatible VSAs is that we (the IETF)
> refused to address RADIUS' problems in a useful and meaningful way.  We
have
> an opportunity now to ameliorate if not solve that problem; I don't think
> that we should pass it up.

  If we're going to re-design the attribute format from scratch again,
I'd like to know what we've accomplished in the past year.  

[gwz] I don't know where the "from scratch" comes from; there is a format
defined in
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00
.txt.  I am suggesting adding a single octet to the format which A) would
considerably enlarge the new type space and B) _could_ be used to
standardize functionality that has been added to RADIUS over the years in an
ad hoc fashion.
[/gwz]

There were
proposals that were ugly, but solved almost all of the concerns that
were raised.  This includes the ability to group legacy RADIUS
attributes in a "new" format.

  The one show-stopper I see is putting standard RADIUS attributes into
a VSA.  If this has *zero* impact on implementations that don't
understand the new format, then it would be acceptable.  Otherwise, it's
an incompatible change to RADIUS.

[gwz]
Interesting definition of "incompatible".  If that is in fact the standard
to be met we may as well just fold up our tents and go home since there is
_no_ change that could be made which would have "*zero* impact on
implementations that don't understand".
[/gwz]

  If we can't put standard attributes into the new format, then we
should just pick a better format, and ideally one that's been deployed.
 The WiMAX format (plus grouping) seems to fit that definition fairly well.

[gwz]
Can you tell us what it looks like?
[/gwz]

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>