[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 Thu, Mar 09, 2006 at 12:11:25PM -0500, Nelson, David wrote:
> Emile van Bergen writes...
>
> > 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.
>
> Are you suggesting that the RADEXT WG work items of RADIUS Attribute
> Design Guidelines and RADIUS Extended Attributes should be applied
> *only* to RADIUS related I-Ds that are submitted *after* RADEXT
> completes its work on all the other extensions on its charter? IMHO, it
> would be cynical, to say the least, that we establish design guidelines
> and new attribute formats for others but exempt ourselves from paying
> heed to them. Do as I say, not as I do. :-(
Quite the contrary. *After* the Extended Attribute design is completed,
and tested against existing real world situations, and approved by rough
consensus, I would encourage that authors of *existing* I-Ds and even
standards documents revisit their material in the light of the new
recommendations.
However, as it is, the solution in the Delegated-IPv6-Prefix attribute
draft is more mature than the Extended Attribute design work. That's not
something to be overly worried about. A new attribute that follows a
template set out in an existing standard (RFC3162) will surely be done
in less time than a new, future proof design for structured data in
RADIUS.
Also, because it follows an existing standard (RFC3162), it can easily
be deployed *now* by any implementation that offers dictionary driven
support for the IPv6 attributes defined in RFC3162.
Finally, if you already have an Framed-IPv6-Prefix attribute that needs
review, adding a Delegated-IPv6-Prefix attribute with the exacy same
data type does not do any harm.
You're not suggesting that we have a Framed-IPv6-Prefix attribute with
one data type, and a Delegated-IPv6-Prefix that uses an entirely
different structure, do you?
Therefore, to make the Delegated-IPv6-Prefix wait for the new Extended
Attribute design would be entirely unreasonable. Indeed, to do so would
only make sense if you *do* hold the cynical view that only documents
submitted *after* the Extended Attribute and Design Guidelines work is
completed, need to pay any consideration to it.
I think it's more reasonable to expect that shortly after the Extended
Attribute work completes, people will provide review documents showing
in painstaking detail how existing solutions that leave something to be
desired, can be reimplemented using the new framework.
Those suggestions can then be adopted by the authors that want to update
their work.
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/>