Encoding of Location-Id and Location-Name in draft-black-radius-l anedge-00.txt

[Avi Lior <avi@bridgewatersystems.com>]

Hi Paul, Chuck

I have an issue with Location-ID and Location-Name.

Since these attribute may appear in an Access-Request message, I assume that
they would be used by RADIUS in evaluating policy.  Therefore I would not
want these encoded as a string the way you have it.  I would rather see a
more efficient encoding scheme, one that would make it faster for RADIUS to
parse.

In discussions on this list I proposed to use a single attribute that is of
type string (the same as yours) that would encode the information using TLV.
Both of these schemes provide for extensibility and optionality.  But the
TLV approach as an advantage that it is easier to parse for RADIUS ( we
don't want to slow RADIUS down), and is more compact.  The encoding approach
in your document is human readable. 

IMO the string encoding you propose would be okay if it already has an
application that expects this type of encoding. 


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