Re: Strawman RADIUSEXT WG charter

[Bernard Aboba <aboba@internaut.com>]

> Would this last sentence preclude future work items to
> specify the behavior of packet types reserved by RFC 3575, but
> not defined by RFC 2882?  In particular, I think producing
> a specification for packet type codes 33 & 34 (Event-Request/
> Response) will be useful in a number of forums and can be
> done in a Diameter compatible way.

The focus is on extensions that are already deployed or providing
support for extensions that are already deployed.  For example, there is
work that SIPPING WG would like to do in order to standardize SIP use of
RADIUS accounting, and they have requested work on RADIUS prepaid and
RADIUS transport profiles to support that.  It has been claimed that
RADIUS prepaid work would benefit from an extension of the attribute
space.  And there are WLAN extensions that have already been defined in
WFA, IEEE 802, vendor-specific attributes, etc.

So my question is:

What do packet type codes 33 and 34 do?  Are these extensions used today?
Are they useful for newer applications as well as legacy ones?

> Will this work item include addressing the attribute size
> limitation in the extended space?  A number of methods
> for fragmenting large values across attributes have popped
> up, e.g. as in the PacketCable 1.0 spec.  It would be nice
> to have a standard way of doing this.

If this represents something that is already deployed, then it might be
appropriate.  Can you describe the issues that came up in the PacketCable
1.0 spec?


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