[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6

Glen Zorn wrote:
> Alan DeKok [mailto://aland@deployingradius.com] writes:
>>   RADIUS attributes are typed.  
> 
> In your mind, perhaps; in the real world (where RFC 2865 exists), one may
> read page after page without ever seeing an attribute "typed".

  Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an
"ipv4 address" is just there for joviality.  It can really be anything
you want.

  Or, as the design guidelines document says:

   Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
   not define a formal data definition language.  A handful of basic
   data types are provided, and a data type is associated with an
   attribute when the attribute is defined.

>> The list of types is small.  Each type
>> is statically defined in an RFC.  
> 
> In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined?  That's
> easy, none.  The fact that some implementations _treat_ it as a "data type"
> doesn't make it so, since there are other ways to implement a tag.

  Strange.  I was talking about the protocol, and the definition of
attributes.  Having done some minor programming from time to time, I am
aware of the difference between wire encoding and data structures
internal to an implementation.

  Would you be happier if I said "there are a limited number of data
formats that are encoded/decoded on the wire" ?  Maybe that would make
it clearer that I am talking about the protocol.

  New formats require new encoders/decoders.  Is that controversial?

  Re-using existing formats is usually good.  Is that controversial?

  Alan DeKok.

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