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

CUI issue 22 (was AW: CUI - issues addressed in version 3



Title: CUI issue 22 (was AW: CUI - issues addressed in version 3

Barney wrote:Adrangi, Farid

Issue 22 is about which party requires that CUI be present.  Given the business case claimed, it appears to be the NAS owner or proxy, not the server owner.  If that's so, the draft's suggestions on how to indicate support for CUI seem backwards.  If the NAS or a proxy

*requires* CUI, rather than simply supporting it, that's the case where putting a null CUI in the Request makes sense, and an Accept that comes back without CUI can then be treated as a Reject.

Lothar:
Interesting proposal to turn the whole logic upside down, but I tend to disagree.

Justification:
1) It is unclear how a NAS owner or Proxy can determine this "requirement". I say in some scenarious it is impossible, leading to an "always advertise" because the NAS owner "MAY require presence of CUI but cannot determine if he requires presence of CUI".

2) it is unclear what Barney means with "presence of CUI". It could mean the NAS owner requires "presence of CUI in the Access-Accept", whereas the Server requires "presence of CUI in the RADIUS accounting messages". The whole backwards compatibility discussion is about these two presences not being the same thing, and about how the server can be assured that a CUI presented downstream to the NAS will also be presented upstream in the accounting messages.

3) it appears to me that a differing interpretation of the word "require" may be the root cause for Barney's perception that it is primarily the NAS owner who *requires* CUI presence.

We have to ask ourself what Barney meant when stating "require that CUI be present".  Is it a "require to increase revenue" - or a "require to avoid loss", also is he talking about CUI presence in the Accept or CUI presence in the accounting messages or both.

In the roaming privacy application of CUI, the NAS owner requires CUI to make money from an inroaming privacy roamer. If he does not support or advertise CUI he may loose top line revenue, but he does not incur a bottom line damage because he just rejects the potential customer. End of story. No hard damage occured, except a soft damage of loosing potential revenue.

For the Home Server, it is a much stronger requirement to have assurance of CUI Support when accepting (to pay for) the usage of a privacy roamer. If it turns out the NAS did not support CUI than he incurs a bottom line hard damage, because he has to pay the NAS-owner anyway for the usage that he authorized, but has no means to charge it back to the user.

In summary: I beleive the only one who has a *strong requirement* for CUI presence *in the accounting messages* is the server.

I agree thought with Barney's business case view, that the NAS owner in a hotspot requires CUI presence to be able to serve privacy roaming customers. But there is no issue with that "requirement", as the NAS owner is in full control of his destiny, if he wants to increase revenue by serving privacy roamers, he may just  "always advertise CUI" or "advertise CUI as determined to be required".


Lothar

this email was sent as text only, if still received as HTML please let me know.