RE: Guidelines Document Discussion

["Avi Lior" <avi@bridgewatersystems.com>]

Bernard and Alan,
 

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Alan DeKok
Sent: Sunday, April 08, 2007 10:35 AM
To: Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: Re: Guidelines Document Discussion

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

[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO
will always need to create their own VSAs.  We are starting to see
convergences in the Wireless/Wireline networks and it would be nice if
SDOs attributes would interoperate or at least it should be easy to
translate between SDOs.  

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.


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

[Avi] I think that SDOs will always create their own attributes. But as
to the attribute format, I don't think an SDO would invent something if
there was already a good example to follow.

> 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.
[Avi] I agree.

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

 - defining attributes in the IANA managed space, rather than using
   VSA's
[Avi] When feasible.
 - SDO-specific interpretations of existing RADIUS commands, attributes,
   or values for "integer" attributes.
[Avi] Not sure I understand the "...values for integer" part.

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

  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.


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

  Yes.

[Avi] I agree as well.

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

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