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