Re: Strawman RADIUSEXT WG charter

[Greg Weber <gdweber@cisco.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.  

Given there is a claim of usefulness and apparently some uncertainty, 
is it desirable to preclude this work in the charter itself, as opposed 
to simply not having a current work item for the attribute space until
need can possibly be demonstrated?

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

These packet types are used for cross-session accounting data and
do ship today from a major NAS/server vendor as a google search
will show.

> Are they useful for newer applications as well as legacy ones?

I'm not sure I can answer that right now, but my main point
was that I don't think we want to preclude describing something
that we've defined and allocated in RFC 3575.  I'm fine with the
language in your subsequent strawmen.

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

Some of the attributes needed to support lawful intercept for
voice exceeded the maximum length for VSAs.  The PacketCable
spec defines a scheme for fragmenting data across VSAs in 
section 13.1.5.2 of their event messaging spec:
  http://www.packetcable.com/downloads/specs/PKT-SP-EM-I07-030815.pdf

RFC 2865 already offers SHOULD advice on the VSA attribute
encoding.  I think it would be helpful to offer some guidance
on long VSA attributes, so we don't end up with a profusion of
incompatible techniques like PacketCable's.

Greg

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


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