RE: DISCUSS and COMMENT: draft-ietf-radext-design

["Glen Zorn" <glenzorn@comcast.net>]

Alan T DeKok [mailto:aland@freeradius.org] writes:

> Glen Zorn wrote:
> > I wonder, does your survey include only actual vendors or just
> distinct
> > vendor IDs?
> 
>   The data is freely available, you are welcome to do your own analysis
> on it.
> 
> >  I suspect the latter, since 3COM (not on your list) bought USR,
> > inheriting that type space.
> 
>   Ah.  So a vendor doesn't count if they've "sold out" to a bigger one?

You didn't count 3COM in you "nonstandard".  Far from saying that USR
doesn't count, I'm saying that _both_ USR and 3COM count.

> 
> >  It also appears that the same weight is given
> > to vendors like Cisco & Lucent as to "Bob's NAS Factory".  Is this
> > important?  It certainly seems important to me, since small vendors
> are
> > unlikely to put RADIUS to the number and variety of uses that would
> push the
> > envelope of the type space.
> 
>   So small vendors don't count because the design of RADIUS is
> sufficient for them?

I didn't say that they don't count, and the fact that they may not have
needed to define huge numbers of VSAs doesn't say anything about the design
of RADIUS.  Another important thing that was left out of your simple count
was the question of how many vendors, when needing a particular piece of
functionality, simply chose to support a VSA already defined by another
vendor (the Microsoft MS-MPPE-*-Key Attributes are poster children for this,
but there are others).

> 
> >  It also ignores the internal structure of those
> > "RFC format" VSAs, in many cases chosen to avoid exhausting the VSA
> type
> > space (see below).
> 
>   It also ignores the many vendors (large ones) who have poached on the
> standard attribute space... without coming close to exhausting the VSA
> space assigned to them.

What's your point?

> 
> >>   This includes Cisco, who uses the RFC format, and then extends it
> to
> >> encapsulate (almost) free-form text.
> >
> > Perhaps you are unaware of the fact that a major purpose of the
> > encapsulation of "(almost) free-form text" was to extend the
> inadequate VSA
> > type space.
> 
>  In an ad-hoc and inefficient way.  If Cisco had simply asked for a new
> vendor-Id, and then used the USR style format in that space, there
> would
> have been no need to extend the VSA space with VSAs formatted as text
> strings.  Since USR had been a major player, all RADIUS servers support
> the format.

Again what's your point?  My point was that the size of the VSA type size
was inadequate, so people had to work around it.  Does it really matter what
forms the work-around took?  It's also a little bizarre that you are
suggesting that Cisco go from a (superficially) "standard" VSA format to one
you list as "non-standard" (although it seems at least as "standard" as the
Cisco format...

> 
>   I would think that 2^32 VSAs is sufficient space, even for Cisco.

The Type field in the Vendor-Specific Attribute is one octet long; where did
2^32 come from?

> 
> > So do I, which would be damning indeed if these statistics had any
> meaning
> > at all.
> 
>   Then by all means, let's ignore the data we have at hand.  

The problem isn't with the data at hand, it's with the analysis.

> In it's place we might use appeals to authority, dismissal of "minor"
playors, suggestions to move to protocols that the "major" vendors don't
support, etc.

If you like; I don't recall suggesting any such things, however.  An
alternative might be to use reason and logic, as opposed to relying solely
upon primary school counting skills.

> 
>   Since Cisco is such a large player, and has a blatant need for more
> VSA space, let's just ignore the IETF review process, and standardize
> on
> whatever Cisco comes up with.  

If you want to pick one, I much prefer the USR method; there is IPR
attached, though.

> But I recall some objection to that idea.

I don't remember your being involved in the discussions at the time, maybe
lurking?  In any case, IIRC, the Cisco engineers participating in the radius
WG attempted to argue for a 16-bit (at least) Type field in the
Vendor-Specific Attribute but were shut down.  Since the very existence of
VSAs was highly controversial, they gave up & took what the could get (along
w/USR).  I'm not really sure what we're arguing about, anyway: I thought
that you were defending the suggestion in the Guidelines draft that 16-bit
Types be supported & I'm agreeing.  Did you change your position?

> 
>   Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>