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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Alan DeKok writes...

> > (3) Undefined term.
> ...
> > Add a definition of what constitutes "security functionality". 
> > Given that I'm having difficulty in suggesting specific text to 
> > accomplish this, I'm thinking it's not all that obvious.  Do we
> > need to reference "security functionality" at all, or is an 
> > exception for "authentication credentials" sufficient?
> 
>   The Message-Authenticator attribute provides authentication of 
> RADIUS packets that is independent of any user authentication 
> credentials.

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.

>   SDOs don't have a problem referencing RADIUS specifications from other
> SDOs.  That's not the issue.  The issue is whether or not everyone
> *else* finds the specifications useful.

>   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"?

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

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

I'm an engineer but I recognize that sometimes marketing considerations are
important.  :-)

>   How about adding 2.1.6:
> 
>   The extended RADIUS attribute document [EXTEN] defines a number of
>   extensions to RADIUS.  The standard attribute space is extended by
>   permitting standard allocations from within a specific subset of the
>   VSA space; the format of extended attributes is defined; and
>   extended data types are defined within that format.
> 
>   New specifications seeking to extend the standard RADIUS data model
>   SHOULD examine [EXTEN] to see if their needs fit within the extended
>   RADIUS data model.

Yes, I think that would be helpful.

>   We could add the following sentence after the existing bullet points
> that discuss "SDOs or groups of SDOs".
> 
>   Any new RADIUS attributes or values intended for interoperable use
>   across a broad spectrum of the Internet Community SHOULD follow the
>   normal IETF process, and SHOULD result in allocations from the RADIUS
>   standard space.

I think that would also helpful, although the interpretation of "broad"
remains subjective.  I'm not sure ewe can do much better, though.

>   As noted in my response, there are many uses of attributes *outside*
> of SDOs and groups of SDOs.  The text here can be clarified a bit, but I
>  think it's relatively good.
> 
>   How about this text:
> 
>   When attributes are used primarily within a group of SDOs, and are
>   not applicable to the wider Internet community, we expect that one SDO
>   will be responsible for allocation from their own private space.

I guess this OK.   See my discussion, above.



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