Re: Potential work items

[wolfgang.beck01@t-online.de (Wolfgang Beck)]

1.
I am proposing HTTP Digest RADIUS (aka sterman draft) as WG work item:
> a. Don't require new RADIUS commands.
ok.

> b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
the current draft needs 11 attributes. Sub-types are not required but
would make sense as 10 of the attributes will be mostly used
together. 

> c. Don't require changes to the RADIUS attribute format.
ok.

> d. Need to be handled as a WG work item.
SIPPING would prefer if RADIUSEXT would do this work.

> e. Are likely to be widely deployed, if specified.
There seems to be a demand: the current sterman-draft is widely
implemented, Dean Willis reported that other proprietary mechanisms exist.
HTTP Digest is by now the only SIP security mechanism that is implemented
in commercial products. ISPs with an existing RADIUS infrastructure that
want go into the SIP business need a solution for that.


2.
SIP accounting (based on draft-schulzrinne-sipping-radius-accounting-00.txt):
> a. Don't require new RADIUS commands.
ok.

> b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
ok. Around 10  - 15 attributes will be required.

> c. Don't require changes to the RADIUS attribute format.
ok.

> d. Need to be handled as a WG work item.
see above 
> e. Are likely to be widely deployed, if specified.
By now, most SIP vendors define their own set of RADIUS attributes. If
there was a standard, it's likely they will comply to it.

3.
Media accounting:
Information about media streams must be associated with SIP- H323- RTSP-
etc. users for accounting purposes. RfC 2959 hints how to structure
this information.

> a. Don't require new RADIUS commands.
ok.

> b. Don't require changes to the RADIUS dictionary (e.g. no sub-types).
This is ugly. I expect that 20 - 40 attributes are to be expected (extensions
to RfC 2595 are constantly added). As this data doesn't need to be
interpreted by the RADIUS server, I don't see a reason why
sub-attributes are bad here.

> c. Don't require changes to the RADIUS attribute format.
ok.

> d. Need to be handled as a WG work item.
Media accounting is not only interesting for SIP. All WGs using RTP
can benefit from this work. AVT would be the only other group where
this would fit in. 

> e. Are likely to be widely deployed, if specified.
see above 


--
Wolfgang Beck
T-Systems GmbH

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