RE: IPv6

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

David B. Nelson [mailto://dnelson@elbrysnetworks.com]:

> > That same RFC 2865, in section 5, states:
> >
> >      string    1-253 octets containing binary data (values 0 through
> >                255 decimal, inclusive).  Strings of length zero (0)
> >                MUST NOT be sent; omit the entire attribute instead.
> >
> > With that, Ipv6 Prefix, Route options, Auth-IPv6-Prefix-User-ID, etc
> > would be pretty much covered by using the string term.
> 
> With all due respect, the String data type is just a string of
> undistinguished octets.   

Reference, please (don't tell me you've adopted the DeKok method of just
making it up as you go, as you please!).

> While you may conceptually overlay it with a
> structure, i.e define sub-fields, that action creates a new data
> type.  In other words, the String type is just a string.  You may
> lament the fact that RADIUS, as defined in RFCs up through 2865, has
> no method to formally define structured data, but the fact is that it
> has none.

There are a number of problems with this little fantasy (along with the idea
that so-called "complex" attributes are not a "traditional" RADIUS data
type), among them that a) RFC 2548 contains oodles of "structured data" in
_very_ widely implemented and deployed attributes, b) RFC 2865 itself
contains "structured data" in the CHAP-Password attribute and c) RFC 2868
(which was published the same day as 2865 -- in fact it was delayed in the
queue to let 2865 go first), again, has lots of "complex" attributes and,
for that matter, structured data.  You may lament the fact that RADIUS has
methods to define "structured data" and even try to write it out of history
(as Alan apparently wishes to) but the fact is that it does.


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