[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Hi,
On Wed, Mar 08, 2006 at 06:03:11PM -0500, Nelson, David wrote:
> Alan DeKok writes...
>
> > Yes, though this document simply re-uses the existing standards
> > track type defined in 3162.
>
> There are several examples of new data formats, generally speaking
> complex or compound data types, that appear in RADIUS RFCs, both
> Standards Track and Informational, that were published after the close
> of the RADIUS WG and before the chartering of the RADEXT WG. I have no
> idea how much review and comment each of these documents received by the
> IESG and the IETF at large. Certainly, there was no attribute design
> guideline at the time, and probably no designated expert to review
> proposed attributes.
>
> It is important to document these practices in the RADIUS Attribute
> Design Guidelines draft. We need to recognize their existence, and
> therefore their validity. I also believe that we want to strongly
> discourage further use of "novel" attribute formats, in any new work.
Let's keep it into perspective. The attribute in this document and in
3162 needs to convey two pieces of information: a prefix length, and the
actual prefix.
Where there are two bits of information for one attribute, pre-RADEXT
RADIUS has always taken the approach of simply putting them together
into C struct-like subfields. That can hardly come as a surprise, and
indeed, without a grouping mechanism, it's the most efficient and
sensible approach.
As long as the compound format made sense for the actual entity
generating or processing the attribute's contents and as long as the
individual member values were not needed in any RADIUS policy nor
generated dynamically by the RADIUS server proper, there's never been a
strong problem with such compound attributes, and I don't think there
necessarily should be any such problem now.
Case in point: MS-CHAP2-Response (RFC 2548); this attribute only makes
sense as a whole and only to the actual MSCHAPv2 authenticator endpoint;
the values of the individual subfields are neither dynamically generated
at the RADIUS level nor interpreted by the server as part of executing
any local policy.
If we want to deprecate ALL forms of C-structure like attributes, and
expose all subfields as individual attributes, however grouped, then for
sure any new proposal for structuring needs a *thorough* assessment
whether it can meet the challenge.
The current Extended Attribute draft uses the DIAMETER format, and the
only facility it has toward structured data is the 'Grouped' data type,
which is a *blank* container for *top level* attributes only.
My alternative suggestion for the Extended Attribute contents at
<http://www.e-advies.nl/ietf/draft-evbergen-radext-extended-attribute-01.txt>
allows RFC2868-style tags for all attributes and allows any attribute to
refer to a tagged set to create lightly structured data.
Attributes that are only meaningful as members of a structured
attribute, can use parent attribute dependent Type numbers, so that they
need not be assigned a number from the global attribute type registry.
Before disregarding C structures as proper solutions, I think that each
alternative solution should be carefully applied to the problem to see
how it plays out. This process is only just beginning in the WG, and
deprecating all existing practice *now* seems rather premature.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
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/>