RE: : RFC 4005 AUTH48 Review

David & Glenn,

I did a little digging through Watersprings and came to the same conclusion
that David did.  At this point, I think we need to wrap this up.

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