Prepaid authors & all,
I hope not having a chartered WG is not a restriction to discuss
the drafts. Please let me know if I have the wrong assumption.
Here are the comments/questions on prepaid-draft-02.
1) I'm not really convinced with the way *Service Element" work?
How can an element sits in between access device and a Prepaid
server *disconnect* a session on the access device? I can unserstand
it can meter the things but can not disconnect sessions.
You can argue that Service element asks/updates the quotas. How do
you handle the re-authorizations that are supposed to be initiated
by access devices.
Can you explain little further of its significance and how it works?
2) Doesn't PP draft *standardize* the servic keys? I would assume
that it is really important for interoperation.
3) Always, Termination-Action MUST be set to Radius-Request to
make sure that access device will ask for another quota rather than
disconnecting the session (it is the case if Termination-Action
= default).
4) Section 4.2 talks about sending User-Password attribute while sending
the message from HAAA to Prepaid server for more security.
I disagree with this. What are we doing here? Are we making PP server
another
authentication server?
5) Sections 4.2.1 and 4.4, Ascend-data-filter was mentioned separately.
I guess we can remove this.
6) Section 4.4, Mid-Session Operation - doesn't consider if there are
Broker
AAAs in between. For example, You may need to add IP addresses of
PP servers to the Access-Requests.
7) Section 4.4, Mid-Session operation:
Isn't it possible that the operator wants to update his services
and wants to notify the access points.
8) Section 4.5.1. says "Each AAA MUST route the Disconnect Request
packet.
How the routing decision is made is an implementation detail. "
Can you explain how can a Disconnect message initiated by PP
server will reach the Access Device? I mean what are the attributes
involved to make the packet reach its destination through the proxies.
9) what does a PP server do if it receives Disconnect-NAK?
Does it keep billing?
10) Section 4.5.1
"Once the Disconnect Request packet reaches AAA that is in the same
network as the serving Access Device, if the Access Device supports
Disconnect-Request (as per [RFC3576]), it sends the message directly
to the Access Device; otherwise it uses other mechanisms such as
SNMP or Telnet to command the Access Device to terminate the
session."
- How does a AAA server know that if the access point supports
Disconnect (or) CoA messages? Is this also out of scope? :)
- How does Telnet/SNMP work in this scenario. Can you further explain?
11) Should there be a threshold value always ( with Volume/Time quota).
Is it possible that an access device choose not to implement
this attribute?
12) Section 5.3.
"Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
Length: length of VolumeQuotaOverflow attribute (= 4 octets)
VolumeQuotaOverflow (VQO):
The optional VolumeQuotaOverflow Sub-Type is used to indicate how
many times the VolumeQuota counter has wrapped around 2^32 over
the course of the service being provided. "
Is this present in access-request (or) access-accept? Its worth
mentioning
who sends to whom.
Regards
Nagi.
PS: Can you tell us what does it take to flatten the attributes.
Roughly, how many
new attributes are needed? I believe it is really important to debate
this topic
to make progress.
--
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/>