Re: [71attendees] [Geopriv] GEOPRIV Experiment at IETF 71

"Winterbottom, James" <James.Winterbottom@andrew.com> Fri, 11 April 2008 11:34 UTC

Return-Path: <71attendees-bounces@ietf.org>
X-Original-To: 71attendees-archive@ietf.org
Delivered-To: ietfarch-71attendees-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AEF28C10B; Fri, 11 Apr 2008 04:34:47 -0700 (PDT)
X-Original-To: 71attendees@core3.amsl.com
Delivered-To: 71attendees@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DA33A6E57; Fri, 11 Apr 2008 04:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.003
X-Spam-Level:
X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GGAj4euWx5q; Fri, 11 Apr 2008 04:34:45 -0700 (PDT)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4A1EC3A6E84; Fri, 11 Apr 2008 04:34:44 -0700 (PDT)
X-SEF-Processed: 5_0_0_910__2008_04_11_06_48_29
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 11 Apr 2008 06:48:29 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 06:35:06 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 11 Apr 2008 06:35:05 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF157C71D@AHQEX1.andrew.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] GEOPRIV Experiment at IETF 71
Thread-Index: AcibsjoTnTdRFU9+T3SiwAhz1U1GqAAFC7PU
References: <47D5FBD0.70008@bbn.com><f77644530804040552s2b0d06fbl8925ad6d391e609a@mail.gmail.com><E51D5B15BFDEFD448F90BDD17D41CFF157C70E@AHQEX1.andrew.com> <fe9f45350804110158qf4d2ae8nd0e339bec2efeb66@mail.gmail.com>
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: Alberto Ballauri <tesi.ballauri.sacco@gmail.com>
X-OriginalArrivalTime: 11 Apr 2008 11:35:06.0968 (UTC) FILETIME=[1779C580:01C89BC8]
Cc: GEOPRIV <geopriv@ietf.org>, Richard Barnes <rbarnes@bbn.com>, 71attendees@ietf.org
Subject: Re: [71attendees] [Geopriv] GEOPRIV Experiment at IETF 71
X-BeenThere: 71attendees@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for IETF Meeting 71 attendees <71attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/71attendees>, <mailto:71attendees-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:71attendees@ietf.org>
List-Help: <mailto:71attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/71attendees>, <mailto:71attendees-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: 71attendees-bounces@ietf.org
Errors-To: 71attendees-bounces@ietf.org

Hi Alberto,

In answer to the first question.
The LIS uses things called location determination functions (LDFs), which are configured through the config.inc file.
There are instructions in that file describing how to change the LDF, the basic LIS from source forge comes with 3 options.
The first two options are SNMP variants, as you will have seen. The third option is a static mapping option, that allows you statically map an IP address to a location.
I think you can do what you are trying to do using this last option, and that will reduce the amount of code you need to write to isolate the HELD component from the LDF.

Secondly the HELD client.
The HELD client is actually more versatile than you give it credit for.
It does have DHCP discovery capability, but you can also set it to always point to a well known LIS by changing the HELDClient.properties file. This is what we did at the IETF meeting.
Next, the HELD client does provide a "raw" API function, which will take a raw XML request and simply pump it over to the LIS. In this way you can use the HELD client to make On-Behalf-Of (OBO) requests by including the IP address of the Target you want to learn the location of. This works very well and we have tested and used it extensively. I think that this is the function you wanted in your third question below.

Note that LIS 2.0 is a little less forgiving that LIS 1.0 in this mode, there is now a OBO whitelist permissions list. Any device that wants to make an OBO location request MUST have its IP address added to the list. Access to this page is available from the ..<LIS PATH>/entry web page.

As for more information on the Client we have produced quite an extensive design document that I may be able to provide to you, but not until next week, and not until I have had a few discussions with a couple of people.

If this didn't answer some of your questions I could be available for a call sometime next week.

Cheers
James



-----Original Message-----
From: Alberto Ballauri [mailto:tesi.ballauri.sacco@gmail.com]
Sent: Fri 4/11/2008 3:58 AM
To: Winterbottom, James
Cc: Richard Barnes; GEOPRIV; 71attendees@ietf.org
Subject: Re: [Geopriv] GEOPRIV Experiment at IETF 71
 
Hi James,
We have some philosophical questions about the LIS and the HELD client,
First, we would like to know if we could use the LIS 2.0 without the SNMP
part, the part that we are really interested in is the HELD interface and
the DB. In fact we would like to populate database manually and don't be
binded to a specific localization approach such as SNMP.
Could it be achieved isolating some part of the code? So that the LIS
continue to work properly on HELD interface but independently from physical
interface.
Second, we noticed that the HELD client work as a Windows service, it suits
well when it work on the target, and could be considered as a service
enabler, but if we would like to use it on a different logical entity could
we wrap it in a jar file and use it as an isolated program? Is there
available some more doc about the building of the Java Client?
Last but not least, we are interested in using the client also on the LDP
interface, so is it able to take a uri and resolve it to gain the location
of a different target? This is the role in wich we would like to use it now,
and possibly as a program and not a service.

Thanks a lot

Alberto&Tommaso

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
71attendees mailing list
71attendees@ietf.org
https://www.ietf.org/mailman/listinfo/71attendees