RE: Encoding of Location-Id and Location-Name in draft-black-radi us-l anedge-00.txt

["BLACK,CHUCK (HP-Roseville,ex1)" <chuck.black@hp.com>]

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