RE: : RFC 4005 AUTH48 Review

Hi,

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

I disagree. What is stated in NASREQ draft regarding the Radius-Diameter
translation is useful for most applications that would utilize such translation.
I agree it is not a complete solution, but it's not something that is specific
only to NASREQ either. The application-specific issues should and can be handled
separately as application-specific issues.


BR,
Mikko


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext Glen Zorn (gwz)
> Sent: 10 May, 2005 17:05
> To: 'Bernard Aboba'; Loughney John (Nokia-NRC/Helsinki)
> Cc: [email protected]
> Subject: RE: [AAA-WG]: RFC 4005 AUTH48 Review
> 
> 
> 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
>