Re: Guidelines Document Discussion

[Alan DeKok <aland@nitros9.org>]

Avi Lior wrote:
> I don't think we could standerdize a VSA encoding.   But at least we can
> make a recommendation on how an VSA could be encoded.  I would offer the
> WiMAX encoding as a good example. It aligns with the RADIUS attribute
> extension encoding at least in the header. And for the payload it allows
> a structured types -- like 3GPP2.

  Sounds good to me.

>  - 1 or 2 byte VSA's for "efficiency" where "integer" type would do
> [Avi]You mean prohibit the use of 1 or 2 byte TLVs where an integer
> would do?  If yes I disagree.  RADIUS packets are getting smaller and
> smaller these days?  If I have an enumeration (of TRUE or FALSE) using a
> 32-bit value is wasteful in view of the size limitation of both
> attributes and packet size.

  I don't see it as necessary.  I won't object if other people think
it's necessary, though.

>  - SDO-specific interpretations of existing RADIUS commands, attributes,
>    or values for "integer" attributes.
> [Avi] Not sure I understand the "...values for integer" part.

  e.g. 'Service-Type = Foo'  doesn't mean "Foo", it means something else.

  Not that Service-Type is the problem... the problem is people saying
"Foo doesn't really apply, but it's the closest of the existing
standards to what we want, so we'll just use it."

>  - SDO's publishing standards that use existing standardized attribute
>    names for SDO-specific attributes, or which use confusingly similar
>    names
> 
> [Avi] A good idea for readability. But not a show stopper.  Is the IETF
> willing to also honor SDOs name spaces? Probably not.

  If the name space is SDO-specific.  "SDO-Attribute-Foo".  I don't see
why the IETF would not honor such name spaces.

  Having SDOs define attributes *without* a specific name-space leads to
problems.  Common terms are... common.  Is "DNS-Server" a good attribute
name for multiple SDO's to define?  Probably not.

>   SDO's and vendors should be reminded that the goal of VSA's is to
> obtain interoperability.
> 
> [Avi] interoperability within the SDO or with others?  I think within
> the SDO primarily.  To achieve interoperability between SDOs, and SDO is
> free to use another SDOs attributes.  It would be helpful for us RADIUS
> vendors if the encoding was the same though.

  Interoperability where we don't have to write or maintain a RADIUS
server implementation for every SDO.  VSA's and name spaces are useful
here, because they mean that one RADIUS server deployment can
interoperate with multiple SDO's simultaneously.

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