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

[Alan DeKok <aland@deployingradius.com>]

David B. Nelson wrote:
> My review comments on the -04 version as are follows:
> 
> (1) Short-lived reference.
...
> The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
> WG completes its charter and closes one of these days.  :-)  This text
> provides no guidance to the reader as to how to determine what constitutes
> an "equivalent" IETF mailing list.

  The introduction references the AAA doctors list.  A similar reference
should be added here.

> Requested change:
> 
> * Reviews of specifications are posted to the RADEXT WG mailing list or
> another IETF mailing list suggested by the Operations & Management Area
> Directors of the IETF;

  I think that referencing the AAA doctors list would be useful, too.

> (2) Misplaced modifier.
...
> Requested change:

  OK.

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

> (4) Needlessly IETF-centric viewpoint.
..
> This leads me to believe that the authors think that other (non-IETF) SDOs
> (or worse yet, groups of SDOs) are unlikely to define attributes that are
> useful to the broad Internet Community.

  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.

  e.g. 3GPP2 defines a number of RADIUS attributes.  I haven't seen them
implemented in a Wifi hotspot or in a low-end Wifi home router... and I
don't expect to see them there.  As such, the 3GPP2 specifications
belong in the SDO space, and not in the IETF space.

>  That may or may not be true.  I'm
> guessing that what this really means is that only the IETF ought to be
> consuming standard RADIUS attribute IDs, based on IANA allocation, and all
> other bodies need to host attributes in a private code-point space (i.e. the
> assigned VSA block).  Does this document intend to Update RFC 3575?

  Yes (to the first sentence), and no (to the second).  Pointing out
that IETF and IANA are responsible for standard-space allocations isn't
an update to IETF processes.  It's a re-iteration that vendors and SDOs
SHOULD NOT stomp on the IETF space for vendor-specific, or SDO-specific
allocations.

> I think the conditional phrase "for attributes matching any of the following
> criteria" will almost always evaluate to TRUE because of the second and
> third bullet items, so the whole paragraph makes little sense to me.

  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.

> If the issue is standard attribute scarcity, isn't this addressed by the
> RADIUS Extended Attribute format [EXTEN]?

  No.  While the guidelines document was started when [EXTEN] had 8-bit
attributes, the issue isn't attribute scarcity.  The issue as I see it
is requesting "standard" space allocation for SDO-specific
functionality.  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.

> I think that this document should provide better guidance as to when an IANA
> allocation from the standard RADIUS Attribute code-point space is
> appropriate.  Does the need for interoperability between multiple SDOs meet
> that threshold? 

  I don't think so.  WiMAX is referencing 3GPP attributes.  There's no
need to re-host the 3GPP attributes in the IETF standard space just
because another SDO decides to reference them.

> Or must the usage be of general applicability to the
> Internet Community?

  Yes.  And it should be *new* functionality.

>  How does the existence of the Extended RADIUS Attribute
> (a VSA with a code-point block assigned to the IETF) change the distinction
> between "standard" and "VSA" allocations?

  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.

> Requested change:

  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.

> (5) Format issues.

  Fixed.

> (6) Bad reference.

  Fixed.

> (7) Missing definition/reference.
...
> Where do we normatively define the term "extended data types"?

  I would suggest in a new section, 2.1.6, as shown above.

> (8) Duplicate section title.
...
> Both of these sections are entitled "Complex data types".  One of them is
> permissive and the other prohibitive.

  The first talks about Opaque data types being OK.  I've changed the
title to "Opaque data types".  The second is about Complex data types in
RADIUS being NOT RECOMMENDED.

> (9) Confusion over allocation policy.
...
> As discussed in comment (4), above, attributes intended for interoperable
> use across multiple SDOs *could* qualify for allocation from the standard
> RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
> space.

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

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