[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On a related note, there is a proposal in the GEOPRIV WG on encoding civil (city/street) locations in DHCP; see draft-schulzrinne-geopriv-dhcp-civil-01.txt

It would be really nice if there was some commonality across these formats.

On 12/29/2003 12:50 PM, Richard Perlman wrote:

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


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