Chargeable-User-Identity and Operator-Name

[Tomasz Wolniewicz <twoln@umk.pl>]

There is one more issue about the CUI.
The RFC states:

   If a home RADIUS server that supports the CUI attribute receives an
   Access-Request packet containing a CUI (set to nul or otherwise), it
   MUST include the CUI attribute in the Access-Accept packet.

As Stefan has described, the information about the visited institution
may be important for the CUI generation. In our (eduroam) case we would
want to generate different CUI values for different visited networks,
but in scenarios described by Stefan, the information about the visited
institution is also crucial. Therefore I would see it as completely
justified to say, that a server supporting the CUI can refrain from
sending it, if some of additional policy-related conditions have not
been met (for instance there is no business agreement stating that this
should be done for a particular visited network or that the
Access-Request does not carry an additional attribute required by this
business agreement).

The unconditional MUST in the quoted paragraph seems to be too strong.

Greetings
Tomasz Wolniewicz

-- 
Tomasz Wolniewicz    
          twoln@umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576


--
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/>