Re: REMINDER: RADEXT WG Last Call on Design Guidelines Document

[Alan DeKok <aland@deployingradius.com>]

David B. Nelson wrote:
> OK, so that's not a viable simplification.  I'm still fishing for a
> definition of "security functionality", as used in this context, that's less
> open-ended than the plain meaning as found in the dictionary.

  Leaving it open ended might not be catastrophic.  The rest of RADIUS
is open ended.

  e.g. I just ran into devices with multiple interfaces that send
Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
Interim-Updates.

  Since this isn't forbidden by the specs, they have no interest in
fixing it.  It's everyone *else* that has to butcher their systems in
order to deal with such nonsense.

>>   If SDOs need functionality that is useful to *everyone*, they can
>> request standard space allocation.  If SDOs are defining their own
>> specifications, they do not need standard space allocation.
> 
> How, exactly, do we define "everyone"?

  "The wider Internet community".

>> I'm not sure many SDOs would agree to cede change control over
>> their allocations to IANA.  I'm not sure that IANA wants that work,
>> either.
> 
> Isn't IANA funded to allocate code points to anyone who presents a valid
> request, even individuals?

  Yes.. but change control?  I don't think any SDO forum would be
willing to go through IANA for SDO specific attribute allocation.

> To some extent, I think this is a matter of nomenclature.  If we say that
> the RADIUS code space is divided between "standard" space and "Vendor
> Specific" space, we effectively lump SDO uses, would could be very broadly
> adopted, with proprietary vendor uses, which could have minimal, if any,
> deployment.

  Yes.  That's the reality, unfortunately.

>  That's why I've been touting the term SDO Specific Attribute.
> True, it uses the Vendor Specific Attribute format (and top-level ID), but
> it allows for a distinction between proprietary vendor uses and standardized
> uses.  The distinction between "IETF standard" space and "other SDO
> standard" space then becomes merely a matter of which registry is used, and
> not a matter of "standard" vs. "non-standard".

  The document already refers to SSA's.  I think that's good enough.

  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/>