RE: : RFC 4005 AUTH48 Review

On 5/22/2005 11:36 PM, Glen Zorn (gwz) wrote:
>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,

You keep saying that... but you haven't helped a thing.
Instead of complaining, could you make a viable suggestion?

Dave.


>~gwz
>
>Why is it that most of the world's problems can't be solved by
>simply
>   listening to John Coltrane? -- Henry Gabriel