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