[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-carroll-dynmobileip-cdma-04.txt
Frank Quick <mailto:firstname.lastname@example.org> 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,
> Maybe the numbers are not as
> impressive for PDSNs, but the infrastructure is still installed
> 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
>>> 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
> 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
>>> 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;
>> my mind the modification of the Access-Reject semantics is much
> 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
>>> 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
>>> as an RFC for those who may want to make interoperable devices.
>> If the RADIUS portion of the protocol had been designed
>> would have automatically been interoperable and we wouldn't be
>> this conversation. As for harm & benefit, the harm lies in the
>> laying its imprimatur (even as informational) upon a document
>> rather brazenly violates an IETF standard; it's difficult to see
>> benefit in publishing what amounts to an advertisement for
>> Verizon/Qualcomm IPR. It's a shame, because portions of the
>> 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,
Why is it that most of the world's problems can't be solved by
listening to John Coltrane? -- Henry Gabriel
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.