Subject: RE: [Geopriv] GeoPriv :- Revised HTTP Enabled Location Delivery D raft

From: "James Winterbottom" <[email-masked]>
Date: Mon, 25 Jul 2005 18:23:39 +1000

Trying again, the list seems to have eaten my first attempt this morning.

-----Original Message-----
From: Winterbottom, James [WOLL:5500:EXCH] 
Sent: Monday, 25 July 2005 9:55 AM
To: 'John Schnizlein'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] GeoPriv :- Revised HTTP Enabled Location Delivery
Draft

John specific comments inline.
 
I think that you have misunderstood the context of the location server in
this document. It is not analogous to the registrar (wireless HLR
equivalent) used in the SIP model, it is a node in an access network capable
of determining and providing location. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of John Schnizlein
Sent: Saturday, 23 July 2005 7:21 AM
To: Marc Linsner
Cc: 'GEOPRIV'
Subject: Re: [Geopriv] GeoPriv :- Revised HTTP Enabled Location Delivery
Draft

Below this line is what I am considering sending - help! 

_______________ 

I am having difficulty understanding just how HELD is supposed to work. 

Please answer a few questions to help me interpret the draft: 

1) What does the location URI look like? Since section 6 says:  

[AJW] In our examples we are using URLs, please look at the example on page
32, it is quite clear.

This is not to say that this could not be provided as a SIP URI or any other
URI that the server knows how to deal with.

"The Location Server MUST be able to uniquely identify the IP-device 

based on a location URI or presentity pseudonym. Identity matching 

SHOULD occur through internal correlation only; it SHOULD NOT be 

possible to perform a computational transform on these data to 

identify the IP-device." 

it seems clear it does not contain the host's name or address. 

I could not find and example URI in the appendix. 

draft-winterbottom-location-uri-00.txt motivates the URI concept, 

but does not define its form or provide an example. 

2) What is the purpose for defining the special on behalf of (OBO) 

entity, with all its complications?  

[AJW] I am not aware of any location aware clients today, are you? I fully
expect that there will be a lot of non-location aware clients for a long
time to come. This provides a means of allowing non-location aware clients
to use location aware services, and there are a lot of them, emergency
services being only one. 

3) Since the OBO specification includes a pre-arranged trust 

relationship between the OBO and Location Server, why doesn't 

the Target need a trust relationship for where its location and 

location-disclosure policy reside?  

[AJW] I think that you have missed the point of the OBO, please refer to the
previous answer. 

4) What sort of relationship is assumed between the operator 

of the target's DHCP server and the Location Server? 

Without a relationship there, how could we expect the DHCP 

server to be configured with the right list of LocServer URIs?  

[AJW] Location servers in this document are not arbitrary, they are tied to
access network, or associated services. For example your ISP may have one,
or your infrastructure provider may have one. To this end, this information
is provided in the same manner as a DNS server address, default gateway
address etc...

5) In what domain is the proposed SRV record? 

In other words, what is the fully-qualified owner? 

Similarly to question 4, what compels the zone operator 

of this (as yet unspecified) domain to include any 

particular Location Server names in these SRV records?  

[AJW]  They must only provide reference to the Location Server in their
domain, if they don't have one then they must not provide a reference to
one.

BTW: the syntax of the SRV owner name is _service._tcp.<domain>. 

The '_' is on the wrong side of the '.' in the draft.  

[AJW] Thanks 

6) How does the target, or any host for that matter, know what 

name (beyond the _locserv+http._tcp prefix) to look up?  

[AJW] There are two cases I can see here. The first is for the target itself
to make this request, and as pointed out the target MUST be in the domain in
the first place, so this occurs in the same manner as asking for any other
service with in that domain. The second is an OBO situation, for example the
target's voice service provider (VSP). This situation is more complex as it
requires the VSP to first determine the domain in which the call originated.

7) Why does a host capable of generating its own location 

have to provide the Location Server a means of interrogating 

it, rather than just providing its location?  

[AJW]  Location may change, and providing this mechanism meant that we did
not need to preempt any deployment or technology configurations.

8) How is the ruleset URI associated with the location URI?  

[AJW] Please read sections 5.2.7, 6 and 9.3. A location URI in this instance
is associated with the location of a target in a network. The ruleset is
bound to the authorization service invoked when this URI is dereferenced.

9) Without knowing the user, how does the Location Server 

know that the ruleset URI points to the user's authorized 

set of disclosure rules?  

[AJW] Please read section 5.2.7. The IP device has provided this over a TLS
session to the Location Server. If the Location Server does not trust the IP
device to provide its own ruleset governing who may gain access to its
location then I think presence overall is doomed to failure. You may also
benefit from reading
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-05.txt
<http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy-05.txt
> .

10) How is ruleset provided to the Location Server? 

"If a "ruleset" is provided to the Location Server then the Location 

Server MUST adhere to the rules, unless it is also provided with a 

"rulesetURI", in which case the rules referenced by the "rulesetURI" 

are used. "  

[AJW] Please read section 5.2.8 

On Jul 21, 2005, at 2:06 AM, James Winterbottom wrote: 

The HTTP Enabled Location Delivery (HELD) draft has been updated to version
01.

This protocol describes a comprehensive application layer location
acquisition protocol using HTTP over TLS.

http://www.ietf.org/internet-drafts/draft-winterbottom-http-location-deliver
y-01.txt

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "James Winterbottom" <[email-masked]>
Date: Tue, 26 Jul 2005 16:22:18 +1000

Hi John,

I think we are making progress, comments inline.
Thanks for the great feedback

Cheers
James

Thank you for the answers. Please confirm my interpretations of your  
answers or further resolve the details embedded in context:

On Jul 24, 2005, at 7:54 PM, James Winterbottom wrote:
> I think that you have misunderstood the context of the location server
> in this document. It is not analogous to the registrar (wireless HLR  
> equivalent) used in the SIP model, it is a node in an access network  
> capable of determining and providing location.

Is it necessary for the system built on your protocol specification to  
work that each access network operates such a Location Server?

------------------------
[AJW] Each domain requires a logical location server.
------------------------

> [AJW] In our examples we are using URLs, please look at the example on
> page 32, it is quite clear.

Please confirm that this example is intended to say that some host  
connects to the Location Server at lis.example.com, sends an HTTP POST  
containing the information:
    locationURI=unbounded&rulesetURI=https://1.2.3.4:9974/ruleset.xml
and gets back a location URI of the form
    https://lis.example.com/362b0e75du908n1

If this is correct, that helps explain how the ruleset URI gets bound  
to both the host's source IP address and to the location URI, answering  
my questions 8 & 9.  I would suggest that this is important enough to  
be explicit in the specification rather than in an example.

------------------------
[AJW] Yes. Thanks for the comments, we will make this more explicit
-------------------------

> This is not to say that this could not be provided as a SIP URI or any
> other URI that the server knows how to deal with.
>  
>> it seems clear it does not contain the host's name or address. I
>> could not find and example URI in the appendix.  
>> draft-winterbottom-location-uri-00.txt motivates the URI concept, but  
>> does not define its form or provide an example.
>>
> [AJW] I am not aware of any location aware clients today, are you? I
> fully expect that there will be a lot of non-location aware clients  
> for a long time to come. This provides a means of allowing  
> non-location aware clients to use location aware services, and there  
> are a lot of them, emergency services being only one. 

Oh. It appears that the OBO, with its trust relationship to the  
Location Server, is able to enable locating and provide disclosure  
rules for any IP address. It remains unclear how the person whose  
privacy we are trying to protect controls this situation.

------------------------------
[AJW] OBO is an acknowledgement that the rulemaker is not always the target.
In practical terms OBOs are most likely to be implemented due to regulatory
requirements.
-------------------------------

>> relationship between the OBO and Location Server, why doesn't the  
>> Target need a trust relationship for where its location and  
> [AJW] I think that you have missed the point of the OBO, please refer
> to the previous answer. 

Whatever the point of the OBO, it is still unclear why no trust  
relationship is required between the user and the Location Server that  
is implicitly believed to be enforcing the disclosure rules specified  
by the user.

---------------------------
[AJW] See previous answer
---------------------------

>> 4) What sort of relationship is assumed between the operator of the
>> target's DHCP server and the Location Server?  Without a relationship  
>> there, how could we expect the DHCP server to be configured with the  
>> right list of LocServer URIs?  
>
> [AJW] Location servers in this document are not arbitrary, they are
> tied to access network, or associated services. For example your ISP  
> may have one, or your infrastructure provider may have one. To this  
> end, this information is provided in the same manner as a DNS server  
> address, default gateway address etc...

Are you saying that the proposal assumes that the same organization  
(ISP, for example) that operates the DHCP server operates the Location  
Server?

If the "infrastructure provider" is not the ISP, hence not operating  
the DHCP server, what reason does the DHCP operator have to put this  
other party's address in its database?

-------------------------------------------------
[AJW] The ISP is responsible for providing services to its customers. One of
these services is location. The ISP must therefore provide sufficent
configuration information to enable the discovery of the hosts providing
these services. Incidently, DHCP does not seem to be commonly used to
provide configuration information to broadband routers, PPP seems to be more
prevalent.
-------------------------------------------------- 

>> 5) In what domain is the proposed SRV record? In other words, what is
>> the fully-qualified owner? Similarly to question 4, what compels the  
>> zone operator of this (as yet unspecified) domain to include any  
> [AJW]  They must only provide reference to the Location Server in
> their domain, if they don't have one then they must not provide a  
> reference to one.

Sorry, that answer did not clarify.  Breaking the question down into  
parts:

A) When the host performs a DNS lookup to find its Location Server, how  
does it compose the fully qualified domain name?  That is: what is the  
<domain> part of the query name, and how does the host learn it?

--------------------
[AJW] RFC-2132, DHCP option 15, provides a host with its domain suffix. This
is one option.
RFC-3397, DHCP option 119 indicates how a domain search list may be provided
to a host, and this is also an option. We will add these to the next
revision.
---------------------

B) Does "must only provide reference to the Location Server in their  
domain" imply that the same party that operates the DNS server for a  
zone operates the Location Server?

---------------------
[AJW] You are quite right, there is no requirement for the DNS operator to
own the location server. There is a need for the DNS to have a service
record that can resolve to a location server host name for the specified
domain.
----------------------

>> BTW: the syntax of the SRV owner name is _service._tcp.<domain>. The
>> '_' is on the wrong side of the '.' in the draft.  
>
> [AJW] Thanks
>>
>> 6) How does the target, or any host for that matter, know what name
>> (beyond the _locserv+http._tcp prefix) to look up?  
>
> [AJW] There are two cases I can see here. The first is for the target
> itself to make this request, and as pointed out the target MUST be in  
> the domain in the first place,

Please explain what is meant by "host must be in the domain". Do you  
mean that there be an A record in the zone with the suffix of the  
<domain> part of the query?  Do you mean that the IN_ADDR record for  
the source IP address must have a PTR to an A record with a suffix that  
matches the <domain>?

Recall that the purpose for the invention of the SRV record was that I  
could find the directory server for your organization by asking for  
_ldap._tcp.your.organization. There is no presumption of which  
your.organization I might want to query.

-------------------------------
[AJW] I mean that there must be a PTR record for the domain service that may
point to any location server capable of servicing that domain. This
subsequently ties back to the previous answer.
-------------------------------

> so this occurs in the same manner as asking for any other service with
> in that domain. The second is an OBO situation, for example the  
> target's voice service provider (VSP). This situation is more complex  
> as it requires the VSP to first determine the domain in which the call  
> originated. 

Have you considered that this determination might not even be possible?

---------------------------
[AJW] Yes, we have considered that in some circumstances it may not be
possible.
One way in which it may be possible is for to perform a reverse DNS lookup
on the source to determine the domain, and then do a DNS look up to
determine the location server for the domain. 
----------------------------

>> 7) Why does a host capable of generating its own location have to
>> provide the Location Server a means of interrogating it, rather than  
>> just providing its location?  
>
> [AJW]  Location may change, and providing this mechanism meant that we
> did not need to preempt any deployment or technology configurations.

It is not clear that requiring a call-back to a specified URL better  
accommodates changed locations than allowing the host to send its  
location again after it moves. Because some hosts are only  
intermittently connected to the Internet, or are behind a Network  
Address Translator, connecting to the host could be problematic when  
accepting connections from the host would be fine. Just what preemption  
is of concern?

[AJW] Martin Thomson will provide a description of this at the IETF in
Paris.

> [AJW] Please read sections 5.2.7, 6 and 9.3. A location URI in this
> instance is associated with the location of a target in a network. The  
> ruleset is bound to the authorization service invoked when this URI is  
> dereferenced.
>
>> 9) Without knowing the user, how does the Location Server know that
>> the ruleset URI points to the user's authorized set of disclosure  
>> rules?  
>
> [AJW] Please read section 5.2.7. The IP device has provided this over
> a TLS session to the Location Server. If the Location Server does not  
> trust the IP device to provide its own ruleset governing who may  
> gain access to its location then I think presence overall is doomed to  
> failure. You may also benefit from reading  
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-common-policy 
> -05.txt.
>

To be more precise, what protocol is used to perform the "multipart  
file transfer" specified in 5.2.8? Unless this is in the POST operation  
that yields the location URI, the question of how the rules and  
location URI are bound (associated) is raised again.

-----------------------
[AJW] Correct, it is in the POST. The examples do show this, we will make
section 5.2.8 more explicit by saying that it is posted.
-----------------------

John