RE: : RFC 4005 AUTH48 Review

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

I think this is accurate.

> 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".

I agree.  The general problem of RADIUS/Diameter translation remains
unsolved.

> How about a general solution, rather than yet another piecemeal
> approach?  BTW, what is the rationale for forging ahead despite all,
> here?

The rationale for forging ahead is that the WG made the decision
to support interoperation via a gateway design very early on.  In fact,
the decision was made once Diameter moved from UDP transport and a RADIUS
packet format to TCP, with the new header and AVP design.  It's simply too
late to revisit decisions made that long ago, although we can (and in my
opinion should) work on more general gateway solutions within AAA WG or
its successor.