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

[Avi Lior <avi@bridgewatersystems.com>]

Richard,

First, maybe for an enterpirse level RADIUS sever performance is not an
issue but for a carrier grade products performance is definetly an issue.

I don't think I would load up the location attributes in a dictionary.  TLVs
just make it easier to extract the attribute.

Instead of parsing " location-name = foobar,  address = 123 Main Street, " ;
we have using the TLV encoding

0106foobar0215123 Main Street

Where 01 is the location-name followed by the length of 6 and the value
"foobar" 2 is the address field etc... This is far quicker to parse and more
compact.

In both cases you will use the hash tables etc....

The only thing you add to the dictionary is the type 1 for location-name 2
for address etc...

> -----Original Message-----
> From: Richard Perlman [mailto:perl@lucent.com] 
> Sent: December 29, 2003 12:50 PM
> To: 'Avi Lior'
> Cc: BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL 
> (HP-Roseville,ex1); radiusext@ops.ietf.org
> Subject: Re: Encoding of Location-Id and Location-Name in 
> draft-black-radius-lanedge-00.txt
> 
> 
> 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/>