Farid,
you wrote:
1) the new attribute is not mandatory. 2) The suggested CUI advertisement in Access-Request is optional.
Lothar:
okay, I acknowledge that there may be multiple definitions of mandatory and that I may have misused the term. I did not mean to say that the CUI shall be a mandatory attribute and therefore must be present in all RADIUS access-request messages. In the opposite my intention was to avoid that the CUI-Null attribute will have to be sent in ALL access-request messages as part of an "always advertise CUI capability" policy.
- I can not see how a home RADIUS server can implicitly determine CUI support of a NAS from an "unknown" access provider, and how he can sometime determine that all NASes are upgraded. Therefore, the "always advertise CUI" policy will have to be implemented forever/until migrating to DIAMETER.
- The same may apply to other new proposed attributes, such as GeoPriv, etc etc
other comments:
- in your draft text-snippet, I would recommend to totally drop or replace the part-sentence: "if the CUI is required for proper billing"
with:
"if the home RADIUS server considers CUI support of the NAS to be required for any reason, for example for billing or charging purposes"
Justification: There is a good reason that the C in CUI stands for chargeable, because charging means more than just billing. For example, a chargeable user identity may be required to be able to charge a malicious user in court. Regulation in the country of the home network operator and/or in the country of the visited network may very well mandate to never grant access without the ability to identify the user after the fact if he did something malicious.
That is what I meant when previously using the term "mandatory". From the perspective of the RADIUS server, he may well need absolute assurance that the NAS supports CUI, before he sends an access-accept with a NAI that is insufficient for identification of the user. Otherwise the home network operator may not only risk the ability to collect end-user payment for the usage, but may even be in violation of local laws.
- another Question similar to David's question raised earlier: How shall a NAS determine from the error cause value 402 (decimal), "Missing Attribute", if the missing attribute is the CUI attribute or some other attribute such as GEOPRIV ?
Question: Instead of allocating a new error code for every new attribute, would it not be better to adopt a general approach, which allows to include the missing attribute(s)in a Reject message with error cause 402 ? This may even allow to include multiple NEW attributes such as CUI and GEOPRIV in the event that the home network requires both. Also, we would not need another error cause for every new attribute of this kind, let alone error codes for combined missings, or a precedence setting which attribute is to be preferred to be indicated in the error cause if multiple attributes are missing.
Farid wrote as part of the snippet:
if the NAS supports the CUI attribute the CUI attribute will override the identity portion the UserName (1) attribute.
Lothar: what exactly means "override the identity portion of the UserName" ? Do you mean it in the sense of "overwrite", that the CUI will be combined with the realm portion of the NAI ? In this context, maybe it would be usefull to clarify the significance of the identifier which we refer to as CUI or Chargeable-user-identity, i.e. if the home-network provider should always be able to resolve a CUI, or if it is allowed that he also requires other information present in the RADIUS accounting data (such as the realm portion of the NAI) to be able to resolve the CUI to the identity of the user.
Farid wrote:
Before we get into developing a protocol (as suggested below) to determine the CUI support, I would like to know why the above paragraph does not address the backward compatibility problem.
Lothar:
- I agree, that the text adresses the backward compatibility problem.
I hope that the choosen approach of "always advertise" will be widely adopted - I still have some concern regarding the following "chicken and egg" problem: Users will not see CUI benefits (in particular roaming-privacy) until a critical mass of network-access-providers adopts CUI with always advertise policy. Network-access-operators may hesitate to introduce an always-advertise CUI policy before seeing any evidence that a critical mass of users is requesting it.
Lothar