RE: : RFC 4005 AUTH48 Review

"Glen Zorn (gwz)" <[email protected]> Tue, 10 May 2005 07:05:10 -0700
Newsgroups gmane.ietf.aaa
Message-ID <[email protected]>
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".
 
>> 
>> I also think that we should go forward with point c. The
implications
>> for this are that a simple "Use NASREQ to interwork with
Diameter"
>> will be insufficient for on-going work in RADext; so that
specific
>> new 
>> RADIUS extensions should have a short dicussion on how to
interwork
>> with Diameter. 
> 
> Any other comments from the WG?

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

> 
> In terms of publication of RFC 4005, I'd suggest that we need to
> decide whether Dave's new proposed draft is an Informative or
> Normative reference (I suggest Informative).  Also, we need to
> resolve the issue of length restriction vs. a new flag.   
> 
> Separately, we need another document on the general
RADIUS/Diameter
> gateway problem.  I'd suggest that RFC 4005 doesn't need to depend
on
> this document (either normatively or informatively).  

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