RE: IPv6 Address Option

["Glen Zorn" <glenzorn@comcast.net>]

I wrote:

> Alan DeKok [mailto://aland@deployingradius.com] writes:
> 
> >   Is there a response to my review?
> >
> > http://ops.ietf.org/lists/radiusext/2009/msg00401.html
> >
> >   Addressing the minor issues brought up in the review would allow
> > server implementations to support the document by simply updating
> their
> > dictionaries.  As it stands now, new data types will have to be
> > defined,
> > which can be a significant barrier to adoption.
> 
> In your review you say "Defining a tag field *and* a 32-bit integer
> means
> that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section
> 3.1 for the historical definition. It would seem to be OK to have a 24-
> bit
> lifetime.  That would allow everyone to use this attribute by simply
> updating their dictionaries, rather than writing new code to handle a
> new
> format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking
> about
> the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT
> use
> this tagging method...".  Which is it?

Even more interestingly, your latest missive seems to strongly imply that
adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
to adoption" of new attributes designed following them...




--
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/>