[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strawman RADIUSEXT WG charter
> > 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
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
> 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 126.96.36.199 of their event messaging spec:
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.
> to unsubscribe send a message to firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.