RE: IPv6 Address Option

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

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?  

...


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