RE: : RFC 4005 AUTH48 Review
"Glen Zorn (gwz)" <[email protected]> Sun, 22 May 2005 20:36:43 -0700
| Newsgroups | gmane.ietf.aaa |
|---|---|
| Message-ID | <[email protected]> |
David Mitton <> supposedly scribbled: > On 5/10/2005 10:05 AM, Glen Zorn (gwz) wrote: >> 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". >> > > FWIW: > According to my records, this text for the most part has been there > since at least Nasreq-00 (Feb 2001), at which time the only authors > listed in common with the current list are Pat and Glen. > > Actually (watersprings is wonderful) it was also there in > draft-calhoun-diameter-nasreq-00 (Dec 1999) > > <quote> > Given that it is expected that initial deployments of the DIAMETER > protocol in a dial-up environment will include legacy systems, this > extension was carefully designed to ease the burden of servers that > must perform protocol conversion between RADIUS and DIAMETER. This > is achieved by re-using the RADIUS address space, eliminating the > need to perform attribute lookups. <end quote> > > The additional modifiers and the sentence about how this document > related to the Base were added as a responses to review comments. Your historical spelunking is impressive, but I fail to see the relevance to your defense. In fact, that passage quoted has likely been there since Diameter & RADIUS shared ports, at which point it was probably accurate; the fact that it's still there seems to be evidence less of its basic validity than the lack of critical thought applied to the problem since. > > > I don't see any claims here that can be proven to be incorrect: > - The expectations of legacy systems is still with us, RADIUS is > stronger than ever > - The Diameter protocol does reuse RADIUS address space If you haven't noticed, that's a large part of the problem. > > - Perhaps "carefully designed" should be removed? Now we're > quibbling. > > The problem is that the statements are vague and non-inclusive. > They don't speak to all the issues, but I don't expect that much > detail from an abstract. > > The design does "ease the burden" from other designs that could have > used > ASN.1 or some other data encapsulation that is not culturally > compatible with RADIUS. > > That certainly "eliminated" attribute "lookups" and many concievable > translations but not all. (Somehow the WG saw fit to ban certain > RADIUS attributes and replace them with different Diameter AVPs.) So > the modifing word "many" crept in there. > > Or course the amount of "ease" is not easily measured. > > I'm not sure what the protocol specification gains with this > quibbling over abstract text? > I cannot see what you think is provably incorrect. > .. and that text has been there, substantially, from the beginning. > > Dave. 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