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"FA: Agree. Good suggestion.
- 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 ?
FA: Yes I have already agreed with David's point.
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.
FA: one possibility is to use error-code attribute defined in draft-zorn-radius-err-msg-01.txt -- what do you think?
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 ?
FA: No. it means that the UserName(1) attribute will be used for routing and the CUI attribute will be used for identity purposes.
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.
FA: BTW, the text (the snippet that I sent you) does not say "always advertise". The NAS MAY advertise ....
Lothar