[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Response to Issue 46
Bernard,
> Bernard Aboba wrote:
> > As I understand it, this scenario cannot be handled by the User-Name
> > attribute when:
> >
> > a) The CUI is not a valid NAI
>
> Yes, although presumably pretty much anything could
> be [and has been :-) ] mapped to a NAI using some
> sort of a convention.
I agree.
> > b) It is necessary for the Authentication-Request and
> > Accounting-Request to traverse the same path.
>
> Yes. But I seem to recall that there were also other
> issues in User-Name rewriting.
>
> > Are we clear why the Class attribute couldn't be used to handle this
> > scenario? While RFC 2865, Section 5.25 says "The client MUST NOT
> > interpret the attribute locally", it doesn't say that the client can't
> > store the blob for the purpose of simultaneous usage comparison.
>
> I think this one is clear -- there is no guarantee that class
> attribute can be used for identity comparisons -- the equal
> operator may not be defined for it, as that was never
> required in the RFCs. Implementations could use something
> else than a stable handle, like a pointer to an event
> record in a database, portion of the contents could be
> a sequence number of some kind, and so on.
I agree with Jari on this.
John
--
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/>