RE: AW: backwards compatible introduction of NEW attribute such a s CU I

[Avi Lior <avi@bridgewatersystems.com>]

Bernard,

> Assuming we can define what a RADIUS client and server need 
> to do in order to support "privacy" then we can write an 
> applicability statement for CUI that requires RFC 3579 and 
> "privacy" support as a precondition for CUI support.

I strongly disagree.  CUI should not require RFC 3579 and "privcy" support.
There is no justification to formally do this. I would agree with this only
if you can demonstrate that CUI will not work if 3579 was not being used
etc....

Even the flip side does not hunt. That is requiring CUI when 3579 is being
used. CUI is not required when 3579 is being used.  Second, the horses are
out of the barn.


> The way I think of it, NASes can already claim compliance to 
> RFC 3579 if they support EAP.  But we are talking about 
> something above and beyond that -- RFC 3579 plus RFC 2486bis 
> plus CUI.  So we can state that the CUI assumes support for 
> RFC 2486bis and RFC 3579, and then place requirements on 
> RADIUS servers that support all of that.

Absolutely not.  Use of CUI should remain generally optional. It is only
required when roaming partners determine that they need it.

We must not prevent the use of CUI when 3579 and 2486bis is not being used.

Avi.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Friday, December 17, 2004 2:47 AM
> To: Nelson, David
> Cc: radiusext@ops.ietf.org
> Subject: RE: AW: backwards compatible introduction of NEW 
> attribute such as CU I
> 
> 
> > server that implements RFC 3579 and "Privacy" as defined in RFC 
> > 2486bis will be upgraded to also support CUI.  CUI support 
> therefore 
> > becomes part of the "Privacy" functionality package.
> >
> > That sounds like a reasonable approach.  How would we effectively 
> > document this scope of applicability and interdependencies?
> 
> First off, we have to define what "privacy means".  The 
> logical place to do this is in RFC 2486bis.  I've failed an 
> issue relating to the perceived vagueness of the definition.
> 
> Assuming we can define what a RADIUS client and server need 
> to do in order to support "privacy" then we can write an 
> applicability statement for CUI that requires RFC 3579 and 
> "privacy" support as a precondition for CUI support.
> 
> > The other part of the question is when and how to require that the
> > RADIUS Clients (i.e. NASes), and Proxies support CUI?   Do we make a
> > similar assertion around NAS support for RFC 3579 and RFC 2486bis?
> 
> The way I think of it, NASes can already claim compliance to 
> RFC 3579 if they support EAP.  But we are talking about 
> something above and beyond that -- RFC 3579 plus RFC 2486bis 
> plus CUI.  So we can state that the CUI assumes support for 
> RFC 2486bis and RFC 3579, and then place requirements on 
> RADIUS servers that support all of that.
> 
> This way we're not trying to upgrade every RADIUS server and 
> NAS in the world, just the ones that already have enough 
> functionality to make CUI worthwhile.
> 
> --
> 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/>
> 

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