RE: [fquick@qualcomm.com: Re: draft-carroll-dynmobileip-cdma-04.txt]

["Nelson, David" <dnelson@enterasys.com>]

Frank Quick has written...

> One could argue that 2865's prohibition, "No other Attributes (except
> Proxy-State) are permitted in an Access-Reject" applies only to the
> attributes defined in 2865, and not to extensions as defined in
> 2869.

Well, RFC 2865 can only describe its own content.  I guess the question
is whether RFC 2869 updated RFC 2865 as to the permissible attributes in
an Access-Reject.  The answer is yes, but the basic intent did not
change.

> The comment is made that 2865 does not allow any service provisioning
> attributes in Access Reject.  However, 2865 does not contain the
phrase
> "service provisioning", nor do any of the attributes defined in 2865
> appear to have anything to do with service provisioning.

Well, the Service-Type attribute is all about service provisioning.

> I doubt the authors of
> 2865 anticipated the over-the-air provisioning that is performed in
> cellular systems, which would explain why there is no allowance for
it.

No argument here.

> The only alternative I can see is to add a new message to RADIUS to
signal
> that a key update is required. 

No, the alternative would be to use the existing message type
Access-Challenge.  :-)

> The reality is that IETF
> has little control over what vendors do with vendor-specific
> attributes.  Perhaps that's as it should be, otherwise why allow such
> attributes to exist?

The intent was to allow vendors to create new attributes, and use them
in the traditional way, not to also invent new RADIUS message exchange
paradigms.