[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Encoding of Location-Id and Location-Name in draft-black-radi us-lanedge-00.txt
I don't think there is much to optimize here. You have to do a character by
character examination to extract the information you want.
Let me be clear about something. I am not really concerned about the
performance hit in parsing this particular attribute. My concern is that
protocol designers will continue to use this style of encoding and then we
would have a performance problem. Using X.500 style of encoding is very
alluring for many reasons. What about XML encoding? That is even more
alluring. When will we have to deal with that?
I would like to adopt the following heuristic (we can refine this): If the
item in question is defined elsewhere then we adopt its encoding scheme.
Otherwise, if it is just for the consumption of AAA we adopt an encoding
scheme that is most efficient for RADIUS.
We also have to be very vigilant that the contents of the strings are
specified tightly!!!
On the other hand, I get the feeling that resistance is futile ;-)
Avi.
> -----Original Message-----
> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com]
> Sent: Saturday, January 03, 2004 6:46 PM
> To: 'Henning Schulzrinne'; Richard Perlman
> Cc: 'Avi Lior'; 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-radi us-lanedge-00.txt
>
>
>
> The origin of the current Location-ID string comes from X.500
> formats. Surely there is optimized code that can parse this...
>
> Paul
>
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Saturday, January 03, 2004 12:48 PM
> > To: Richard Perlman
> > Cc: 'Avi Lior'; 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
> >
> >
> > 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/>