[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADEXT charter for comment...

Since I have been complaining about having come trouble understanding the meaning of some parts of the proposed charter, It seems I ought to propose wording that I think is clearer. Of course, this reflects what I think it "should" mean, which may not be the same as other peoples interpretations.

In particular, I want to clarify one item in the constraint list, and one goal.

- New attributes which contain sub-attributes must use only one level on nesting, in parallel with the construction used for VSAs in RFC 2865.

-Pre-paid support.  Prepaid services are contemplated in a number
 of potential applications, including wireless LAN access and IP
 telephony.  In order to enable support of pre-paid services in an
 interoperable way, the WG will provide definitions of the
 attributes required to support the operator service models for
 pre-paid, including time, volume, and event oriented charging.
 This work will include support for limited differential charging.

Yours,
Joel M. Halpern

At 08:31 AM 3/11/2004 -0800, Bernard Aboba wrote: 
In order to ensure backward compatibility with RADIUS as well as the
Diameter, the following restrictions are imposed on extensions considered
by the RADIUSEXT WG:

...
- Sub-attributes MUST be utilized only in a manner compatible with RFC
  2865.
...

Work Items

...
- Pre-paid support.  Pre-paid services are contemplated in a number
  of potential applications, including wireless LAN access and IP
  telephony. In order to enable support of pre-paid services in an
  interoperable way, the WG will initially focus on a BCP describing
  "simple prepaid" which utilizes existing RADIUS attributes.

... 


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