RE: Deployment (Was: Re: NAI decoration: User Identity issues)

[Avi Lior <avi@bridgewatersystems.com>]

Hi Jari,



> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Friday, July 16, 2004 10:55 AM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: Deployment (Was: Re: NAI decoration: User 
> Identity issues)
> 
> 
> Avi Lior wrote:
> 
> > I think the MUST should be changed to SHOULD and thus not requiring 
> > any changes to NASes.
> 
> I can see the "legal" distinction between a MUST and a 
> SHOULD, but wouldn't the change still be needed in practise 
> on the NASes, before this functionality becomes operational?

There are two general uses for User-Alias.

1) One is the case where Intermediaries or Access network etc are trying to
control policy such as how many times a user can connect to the network.
(Appatently this is the case in some deployements)

2) The other is the case where it is needed during accounting.

So to have the functionality operational in somecases it doesn't have to be
a MUST.


> In fact, I'd be happy even with a MUST -- NASes that don't 
> support that MUST don't support this particular RFC, which is 
> of course perfectly legal...

We could do that. My prefence is to use MUSTs whenever I can so if there
were no objections then leave it as a MUST.  But its not allways necessary
as pointed above.  

> > In a situtaion where a NAS does not support this attribute yet an 
> > Intermediary needed to correlate accounting to the 
> > User-Alias-Identity, the Intermediary would insert the 
> Class attribute 
> > in the Access Accept and if the NAS supported the Class attribute, 
> > problem solved.
> 
> I think the NASes must support the Class attribute if they 
> are compliant with RFC 2865/66.

In 2865 Class is a SHOULD not a MUST.

"This Attribute is available to be sent by the server to the client
      in an Access-Accept and SHOULD be sent unmodified by the client to
      the accounting server."

And while I am at the section - just in case some are thinking that its okay
to have the client interpret Class:

"The client MUST NOT interpret the attribute locally."

> Anyway, I think your compatibility scheme works. I just wish
> we didn't need to have alternative modes of operation.

Me too.

> --Jari
> 

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