Re: Guidelines Document Discussion

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> One of the things that struck me about the current document is that it
> assumes that the differences in data model between the IETF Standard
> space and the VSA space represent a long term problem which needs to be
> resolved.

  I think the problem does need to be resolved in a standards body.
I've had any number of off-line discussions trying to get people to fix
their implementations (less code usually means it is more
inter-operable).  It's difficult to convince people that they're doing
anything problematic if they can point to RFC 2865, and say "the VSA
space is a free-for-all".

> Even if there were to be some convergence of the standard and VSA data
> models, it strikes me that this convergence might only be temporary,
> since a vendor or SDO using the VSA space can define their own attribute
> format as well as attributes.

  As many have already done.

> As a result, it strikes me that the Guidelines document probably needs
> to accept that the RADIUS standard and VSA data models are currently
> different and are likely to remain so.  The document also needs to
> recognize the reality of today's VSA usage in other ways.

  Yes.

...
> While this paragraph has been used to argue that SDO usage of VSAs has
> gone beyond the original intent of RFC 2865, on comparing this paragraph
> with those in Section 5.26, I am not sure.  Since this paragraph comes
> from the IANA considerations section, it is really talking about the
> circumstances in which vendors (which would include SDOs) should be
> encouraged to use VSAs rather than requesting an allocation from the
> standards space.

  Yes.  That should be made very clear.

> It strikes me that RADIUS VSA usage may face a similar evolution, and
> that such a parth, if successfully traveled, should not be cause for
> dismay.   As we have discovered, there may be circumstances in which a
> particular RADIUS attribute set may be easier to define within a VSA
> space than within the standards space.  Rather than trying to fit a
> square peg into a round hole by modifying the document to work with the
> existing RADIUS standard data model, it is simpler to retain use of VSAs.

  I concur.

> If we were writing an equivalent paragraph to the VSA allocation
> description found in RFC 2865 Section 6.2 today, I think we might
> include more instances in which allocation of VSAs is desirable.  For
> example:
> 
> * Where interoperability is useful but usage is confined to a specific
> access mechanism or SDO specification;
> * Where allocation of a large number of attributes is required (>5?)
> * Where data types are required that fall outside of the usage defined
> in the Guidelines document;

  And where SDOs wish to exert change control over the specification.

> We might also include circumstances in which VSA usage would be strongly
> discouraged:
> 
> * Where the VSAs represent a change to the RADIUS protocol.  This would
> include definition of new commands or operational modes.

  We should also encourage good practices, and discourage bad ones:

 - near-random numbering of VSA's per packet
 - VSA's containing ASCII string data, rather than TLV's
 - 1 or 2 byte VSA's for "efficiency" where "integer" type would do
 - defining attributes in the IANA managed space, rather than using
   VSA's
 - SDO-specific interpretations of existing RADIUS commands, attributes,
   or values for "integer" attributes.
 - SDO's publishing standards that use existing standardized attribute
   names for SDO-specific attributes, or which use confusingly similar
   names

  SDO's and vendors should be reminded that the goal of VSA's is to
obtain interoperability.

> I would suggest that the Guidelines document needs to tackle this and
> other issues arising from the usage of VSAs.

  Yes.

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