Re: Subtypes (again) and other ideas

["Alan DeKok" <aland@ox.org>]

Victor Gamov <vit@lipetsk.ru> wrote:
> First of all: sorry for my English. I hope that you will be understand me.

  You're doing fine.

> 1. Subtypes.
> We have some unassigned attribute types in RFC-2865 and others. On other 
> hand we need to support many service or even application specific 
> attributes. So I think that we can use unassigned types to do it.
> 
> We can standardize that (for example) attribute 241 must be used for 
> WLAN, 242 for LAN, 243 for SIP and so on.  The format of such attributes 
>   like Vendor-Specific (26) attribute.

  I think that's a reasonable idea.  The extra attributes should
really be hidden from the main RADIUS attribute space.

  On a functional level, much of the data required for WLAN, etc. may
be treated as an opaque protocol, transported inside of RADIUS.  In
that case, a design similar to EAP-Message packaging EAP packets would
be useful.

  Where a protocol like EAP doesn't already exist, and where the
encapsulated data is specific to RADIUS, it just makes sense to put
them into TLV's, like other RADIUS attributes.

> We don't introduce new packet format.
> We don't introduce new packet type.
> We don't change dictionary format. Only extend it with new TLV 
> attributes and new Service-Specific (SERVICEATTR) attributes.
> We don't introduce subtypes. Only new attribute and attribute logic 
> similar Vendor-Specific attribute but potentially with more checks.

  I agree.

> 2. Large packets
> All current packets type has one format and maximum allowable length is 
> 4096 (why 4096 not? min UDP packet size?). But we still have unassigned 
> packet code.  So we can standardize new packets type 
> (Authorization-BIG-response) 

  Are there compelling reasons for these large packets?

  In this case, I'm inclined to agree with the charter restrictions.
Large RADIUS packets generally mean your system is designed
inefficiently.

> 3. Roaming and QoS

  I have fewer opinions here.

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