RE: : RFC 4005 AUTH48 Review

On 5/10/2005 10:05 AM, Glen Zorn (gwz) wrote:
>Bernard Aboba <> supposedly scribbled:
>
> >> I agree on this; this is what I understood was the game plan for
>a
> >> longtime; that NASREQ could handle very general gatewaying
>issues,
>
>How does it do that?  The only "gatewaying issues" that I can see it
>handles are far from being general; in fact, they are specific to a
>set of AVPs that are both syntactically and semantically
>constrained.
>
> >> but
> >> not solve everything.
>
>Perhaps it would be a good idea for NASREQ to refrain from making
>such claims, then: "Initial deployments of the Diameter protocol are
>expected to include legacy systems. Therefore, this application was
>carefully designed to ease the burden of protocol conversion between
>RADIUS and Diameter.  This is achieved by including the RADIUS
>attribute space, and eliminating the need to perform many attribute
>translations.  The interactions between Diameter applications and
>RADIUS specified in this document are to be applied to all Diameter
>applications.  In this sense, this document extends the Base
>Diameter protocol." (from the abstract of
>draft-ietf-aaa-diameter-nasreq-17.txt).  I don't believe that it is
>possible to apply the interactions specified to any Diameter
>application other than the one at hand, and I've yet to hear any
>arguments to the contrary.  The problem is that, due to the
>incorrect claims of generality (which you repeat above) designers of
>other Diameter applications are declaring victory based upon the
>NASREQ "solution".
>

FWIW:
According to my records, this text for the most part has been there since
at least Nasreq-00 (Feb 2001), at which time the only authors listed in
common with the current list are Pat and Glen.

Actually (watersprings is wonderful) it was also there in
draft-calhoun-diameter-nasreq-00 (Dec 1999)

<quote>
Given that it is expected that initial deployments of the DIAMETER
protocol in a dial-up environment will include legacy systems, this
extension was carefully designed to ease the burden of servers that
must perform protocol conversion between RADIUS and DIAMETER.  This
is achieved by re-using the RADIUS address space, eliminating the
need to perform attribute lookups.
<end quote>

The additional modifiers and the sentence about how this document related
to the Base were added as a responses to review comments.


I don't see any claims here that can be proven to be incorrect:
- The expectations of legacy systems is still with us, RADIUS is stronger 
than ever
- The Diameter protocol does reuse RADIUS address space

- Perhaps "carefully designed" should be removed?  Now we're quibbling.

The problem is that the statements are vague and non-inclusive.
They don't speak to all the issues, but I don't expect that much detail 
from an abstract.

The design does "ease the burden" from other designs that could have used
ASN.1 or some other data encapsulation that is not culturally compatible 
with RADIUS.

That certainly "eliminated" attribute "lookups" and many concievable 
translations but not all.
(Somehow the WG saw fit to ban certain RADIUS attributes and replace them 
with different
Diameter AVPs.)  So the modifing word "many" crept in there.

Or course the amount of "ease" is not easily measured.

I'm not sure what the protocol specification gains with this quibbling over 
abstract text?
I cannot see what you think is provably incorrect.
.. and that text has been there, substantially, from the beginning.

Dave.