RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Frank Quick <mailto:fquick@qualcomm.com> supposedly scribbled:

...

>> Does Verizon really have millions of PDSNs deployed?
> 
> I was thinking of the terminals.  

Yeah, but the RADIUS changes only effect the PDSN <-> AAA interface,
right?

> Maybe the numbers are not as
> impressive for PDSNs, but the infrastructure is still installed
and
> operating.  Whether Verizon would be interested in changing the
> infrastructure is up to them.   
> 
>>> But since it is deployed, and working, changes aren't feasible.
>>> 
>>> I suppose that if IETF had an interest in creating a new,
>>> standards-track version of DMU, that version could include
changes
>>> to address the issues that have been identified.
>>> 
>>> Regarding the "violation" of 2865, this is not the only use of
>>> vendor-specific attributes in access reject messages; other RFCs
>>> also do this.
>> 
>> I am apparently ignorant of these RFCs; would you mind providing
>> references to them?
> 
> Possible memory failure on my part.  RFC 2869 and RFC 3579 have
> attributes in Access Reject, but probably not VSA.  On the other
> hand, the principle is this: if these RFCs can create new
attributes
> and add them to the Access Reject, then vendors should have the
> freedom to do the same with VSAs.    
> 
>>> IMHO, the restriction on VSA in 2865 is unnecessary; and since
we
>>> seem to be able to do it without negative consequences, the
>>> restriction is also impractical to enforce.
>> 
>> Indeed; in fact, standards have little use in a closed system.  I
>> actually see the inclusion of VSAs as a relatively minor offense;
in
>> my mind the modification of the Access-Reject semantics is much
more
>> serious.
> 
> I still don't understand why it's so serious.

If a standard RADIUS client receives an Access-Reject, it closes the
relevant connection.  So, outside Verizon's walled garden, this
protocol would always fail, irrespective of whether the client was
generous enough to accept a VSA in an Access-Reject.

> 
>>> As I pointed out to
>>> others, IETF may be able to block the publication of this draft
as
>>> an RFC, but they are powerless to prevent DMU from being used as
>>> is. I don't see the harm in making the protocol publicly
available
>>> as an RFC for those who may want to make interoperable devices.
>> 
>> If the RADIUS portion of the protocol had been designed
correctly, it
>> would have automatically been interoperable and we wouldn't be
having
>> this conversation.  As for harm & benefit, the harm lies in the
IETF
>> laying its imprimatur (even as informational) upon a document
which
>> rather brazenly violates an IETF standard; it's difficult to see
the
>> benefit in publishing what amounts to an advertisement for
>> Verizon/Qualcomm IPR.  It's a shame, because portions of the
draft
>> are really quite clever. 
>> 
> 
> Thanks for the flames.

My original intent was not to flame you, and I assure you that I
mean no personal affront.  

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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