Re: Encoding of Location-Id and Location-Name in draft-black-radius-lanedge-00.txt

[Richard Perlman <perl@lucent.com>]

Avi:

I am not sure that the parsing of a string is all that much more difficult.
Given an arbitrarily large base of locations, you would probably search a
hashed list anyways, and strings are a lot easier for people to manage in
some table or file rather than having to add value assignments to a
dictionary.

Richard

On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" <chuck.black@hp.com>
wrote:

> Hi Avi,
> 
> The encoding of Location-ID is identical to that proposed by the Wi-Fi
> Alliance in it's WISPr document in section 5.2 for their "Location-ID"
> attribute.  I'm not sure where that encoding originated, so I'm not sure if
> there are other applications which make use of it or not.
> 
> There have been discussions regarding making attributes such as Location-ID
> into a common (not vendor-specific) attribute.  Since it may be used widely,
> whichever encoding format is preferable (the current WISPr or else TLV)
> should be chosen.  Perhaps there are others who have knowledge of why and
> how the WISPr Location-ID format was chosen, and could add their input here.
> 
> /chuck
> 
> 
> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Monday, December 22, 2003 2:03 PM
> To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1);
> radiusext@ops.ietf.org
> Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l
> anedge-00.txt
> 
> 
> 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/>
> 


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