Re: Please review draft-carroll-dynmobileip-cdma-04.txt

[Thomas Narten <narten@us.ibm.com>]

Hi David.

Thanks for looking at this.

> I don't know if this draft is describing an existing implementation, in
> which case "on the wire" protocol changes are not likely to be welcomed,
> or whether this is a protocol under development.

It describes what has been deployed. The authors were never willing to
make changes that impacted the on-the-wire behavior. My understanding
(this is in some notes that have made it out onto the mailing list
yet):

Gerry.Flynn@VerizonWireless.com writes:

> Thomas

> Thank you for the e-mail and heads up with respect to additional discussion
> of our submission.  As a matter of update to Frank Quick's 29 October 2003
> note, Verizon Wireless has expanded its commercial deployment of 1xEV-DO to
> cover over 75 million population across thirty large metropolitan areas.  We
> have also shared DMU with other Operators both domestically and
> internationally and intent is to point Operators to IETF for use of this
> submission. 

And

Frank Quick <fquick@qualcomm.com> writes:

> Thanks for the update.  Sorry this has been such a struggle.

> I am unaware that anyone other than Verizon Wireless is actually using 
> DMU.  Within their network it is my understanding that every CDMA EV-DO 
> device uses DMU.  (Gerry, anything to add?)

and again

Gerry.Flynn@VerizonWireless.com writes:

> Frank

> We have had discussions and shared information on DMU with several Carriers
> who are planning to launch Ev-DO networks but they are not commercial yet. 

Note also that I asked 3GPP2 explicitely about the document and they
said "it's not one of ours". So, AFAIK, it's not used formally by
3GPP2.

> I would suggest that there may be alternate ways for the protocol to
> achieve its operational goals, without violating any MUSTs or MUST
> NOTs in the base RADIUS RFCs.

Too late for this document I think. However, on a somewhat related
note, a new document has just shown up:

      draft-nakhjiri-radius-mip4-00.txt

I'm not 100% sure who needs this, but it may be that this becomes a
vehicle for doing this right. 

> Would it be possible, for example, for the HAAA, in step 7, to send an
> Access-Challenge message instead of an Access-Reject?  This approach
> would have two benefits, IMHO.  First, it would avoid the normative
> requirements violation of using an Access-Reject.  Second, the
> traditional data flow in RADIUS, when the RADIUS Server is not satisfied
> with something in an Access-Request from a RADIUS Client and wishes to
> prompt the client for more (or different) information, is to send a
> Access-Challenge back to the client.  My reading of the data flow in
> steps 8 - 11 leads me to believe that this is just that sort of
> "prompting for more/different information" scenario that is
> traditionally handled using an Access-Request, Access-Challenge,
> Access-Request sequence.


> -- Dave

Thomas