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