Dave Nelson wrote:
I understand the technical perspective of this reasoning, but this particular RFC is very much policy related. Observe, that the RFC allows the visited institution to turn an Access-Accept into and Access-Reject if the reply does not contain the CUI. Now *this* is something that is very likely to interoperability, if the parties have not agreed on the principles first.MUST makes for highly predictable behavior in a protocol and leads to interoperable implementations. There is an implicit assumption of trust between a NAS and RADIUS server that's central to the RADIUS architecture. I understand that proxies and roaming consortia may have business, legal, privacy and other non-protocol concerns that make RADIUS a less than ideal protocol for such use cases. The problem is that, in the absence of a real capabilities negotiation feature in RADIUS, SHOULD and other forms of variable behavior make the implementation and error recovery design needlessly complicated.
In order for the CUI to be usable, there always has to be a business agreement between the parties even if, as in eduroam case, it is not direct. Since the CUI support is optional anyway, I do not see any real danger that not responding to a CUI request can seriously harm the RADIUS protocol.
Some of our concerns are not about trust in the eduroam infrastructure, but about making our lives easier by convincing our site lawyers that the amount of opacity introduced by our procedures is high enough to state that the CUI is not personal data of our guests.
Tomasz -- 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/>