RE: : RFC 4005 AUTH48 Review

Glen and Bernard,

I think your points are valid; revisiting decisions made long ago is
probably a bad thing at this late date - does anyone want to track
the time that NASREQ has been under development?  I think do agree
that a more general gatewaying solution or at least a BCP for 
RADIUS-Diameter interworking is strongly needed. 

John

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