Subject: [Geopriv] draft-tschofenig-geopriv-l7-lcp-ps-02.txt

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Aug 2006 22:23:48 +0200

Hi all,

we have submitted a draft update of "GEOPRIV Layer 7 Location 
Configuration Protocol; Problem Statement and Requirements"

Please find it at:
http://www.tschofenig.priv.at/svn/draft-tschofenig-geopriv-l7-lcp-ps/draft-tschofenig-geopriv-l7-lcp-ps-02.txt

Ciao
Hannes

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

---

From: John Schnizlein <[email-masked]>
Date: Thu, 31 Aug 2006 12:06:25 -0400

On Aug 29, 2006, at 4:23 PM, Hannes Tschofenig wrote:
> http://www.tschofenig.priv.at/svn/draft-tschofenig-geopriv-l7-lcp-ps/ 
> draft-tschofenig-geopriv-l7-lcp-ps-02.txt
>

The goal of the document stated in the abstract is correct: "a problem  
statement and lists requirements for a GEOPRIV Layer 7 Location  
Configuration Protocol". From the Dallas minutes: "Jon Peterson  
proposed that a document specifying the requirements for a layer 7  
location configuration or sighting protocol be developed in order to  
facilitate a proper discussion."  However, this document does not  
identify requirements (if any) for a Layer-seven location retrieval  
protocol.  Instead it appears to assume a hypothetical protocol is  
required and discusses characteristics of such a protocol.  It does not  
answer the questions: What problem would a layer-7 protocol solve?  Why  
are other methods inadequate to solve that problem?

Also from the minutes of the Dallas meeting in March: "Henning  
Schulzrinne ... noted that there were varying reasons for the  
motivations of the proposals and that each sub-motivation needed to  
pulled out and stated for the purposes of clarity."  These do not  
appear in the draft.

Although those minutes also state "Ted Hardie noted that the IETF works  
on solutions that work across the Internet and cannot restrict itself  
to solutions for very specific network environments.", the draft starts  
(section 3, after Intro and Terminology) with several specific network  
"scenarios" for unspecified reasons.

Section 5 does not answer the question also in those minutes: "Henning  
stated that there was a need to answer the fundamental question that a  
source IP address would be enough of a key to base location sighting  
upon."  This question appears important because "Ted Hardie agreed that  
an IP source address was not enough information to be the key to a  
location database. Jon Peterson agreed and noted that the IESG would  
likely not approve of such a proposal on these grounds."

Section 6 appears to justify Location-by-Reference on three grounds:  
(1) inefficiency of periodic queries by mobile hosts, (2) host MIGHT  
WANT TO delegate publication, and (3) "the network operator might not  
want to make location information available to the end hosts."   
However, (1) it is unclear why mobile hosts need to make periodic  
queries, and they might use GPS or Galileo if they wanted location  
frequently, (2) location values can be given to a presence server as  
well as location references, and (3) for what reason would a network  
operator deny information about the host's location to that host while  
offering it to others?  References might be nice to have, but are they  
required?

Section 7 discusses a non-requirement of preventing faked locations.

John

---

From: Andrew Newton <[email-masked]>
Date: Thu, 31 Aug 2006 12:24:23 -0400

John Schnizlein wrote:
> Configuration Protocol". From the Dallas minutes: "Jon Peterson proposed 
> that a document specifying the requirements for a layer 7 location 
> configuration or sighting protocol be developed in order to facilitate a 
> proper discussion."  However, this document does not identify 
> requirements (if any) for a Layer-seven location retrieval protocol.  
> Instead it appears to assume a hypothetical protocol is required and 
> discusses characteristics of such a protocol.  It does not answer the 
> questions: What problem would a layer-7 protocol solve?  Why are other 
> methods inadequate to solve that problem?

I can't answer all the questions you just asked, but I will answer one of 
them.  The layer 7 protocol to dereference a location reference and the 
layer 7 protocol to hand out a location reference do not have to be the same.

> on solutions that work across the Internet and cannot restrict itself to 
> solutions for very specific network environments.", the draft starts 

Actually, I think this is very valuable.  We all approach problems based on 
our experiences and sometimes fail to consider understand the requirements 
others desire for a protocol because we have not had their same experience.

> likely not approve of such a proposal on these grounds."

I believe there is a desire to attach an applicability statement to the use 
of IP addresses, and other identifiers are also considered.

> Section 6 appears to justify Location-by-Reference on three grounds: (1) 
> inefficiency of periodic queries by mobile hosts, (2) host MIGHT WANT TO 
> delegate publication, and (3) "the network operator might not want to 
> make location information available to the end hosts."  However, (1) it 
> is unclear why mobile hosts need to make periodic queries, and they 
> might use GPS or Galileo if they wanted location frequently, (2) 
> location values can be given to a presence server as well as location 
> references, and (3) for what reason would a network operator deny 
> information about the host's location to that host while offering it to 
> others?  References might be nice to have, but are they required?

Going through these number by number,
1) If the end host is required to send location by value but the location is 
determined by the network, then that location must be sent from the network 
to the end host, and then from the end host to the next hop.  You are right 
that the first leg could be done by push instead pull, but it is still less 
efficient than delegating the task to the network.
2) Other than an answer for #1, I know of no other reason.
3) I have no answer to this, but it is not the IETF's place to stop entities 
from making unwise customer service decisions.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2006 12:35:54 -0400

> 1) If the end host is required to send location by value but the 
> location is determined by the network, then that location must be sent 
> from the network to the end host, and then from the end host to the next 
> hop.  You are right that the first leg could be done by push instead 
> pull, but it is still less efficient than delegating the task to the 
> network.

I don't think we're disagreeing, but since this gets mentioned a lot, it 
is probably worth qualifying this before the unqualified statement 
becomes accepted wisdom. This is only true if the client access 
bandwidth is dramatically more scarce or expensive than the bandwidth 
used by the consumers of location information. A reference, due to the 
need to set up a TCP connection and wrap the request and response in 
some kind of protocol, can easily turn a 60-byte (unsigned) location 
object into a 500-byte network transaction, even without TLS. With TLS, 
we're probably closer to 2000 bytes, although this is no more than a 
rough guess.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Aug 2006 21:28:11 +0200

Hi John,

upfront I need to say a few things: This document aims to capture the 
design team discussions and is still work in progress. I am happy with 
the progress so far although we got a bit stuck with some selected 
issues. Andy (and some design team members including Henning, Brian and 
myself) proposed to close the design team soon in order to continue our 
discussions on the Geopriv mailing list.

The document has received a couple of reviews already and hence your 
review is welcome as well. Please find my comments inline:

> methods inadequate to solve that problem?

The scenarios outlined in Section 3 motivate the requirements in Section 8.

We do not discuss why other solutions do not fulfill the requirements. I 
think that's OK for such a document.

> pulled out and stated for the purposes of clarity."  These do not appear 
> in the draft.

I am just guessing what Henning wanted but the draft aims to capture 
several months of design team discussions and was really challenging to 
write.

> "scenarios" for unspecified reasons.

The design team discussed these scenarios and they seem to be a good way 
to motivate the requirements listed in Section 8.

> likely not approve of such a proposal on these grounds."

As you can read from Section 5 there are various identifiers that can be 
used. The IP address is a very promising identifier with nice 
properties. In the design team discussions we couldn't agree whether the 
client needs to convey multiple identities to the server. That's fine; 
the work is not yet over.

> others?  References might be nice to have, but are they required?

Most design team members very much agreed that the usage of 
location-by-reference mechanism is a very useful concept.

I also had the impression that it is a useful concept although the 
details need further work (which is not subject of this document anyway).

I personally don't see a problem with the listed motivation.

> Section 7 discusses a non-requirement of preventing faked locations.

Very recently in the design team work we concluded that we will not 
specify requirements on this particular issue since it is largely a 
bigger picture problem. Brian raised a discussion on this subject and we 
agreed to put the current status of the design team thoughts on this 
subject in this section. I re-wrote the entire section and I think it 
nicely captures the topic.

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 31 Aug 2006 11:50:11 -0500

It's a bit difficult to see how to clarify the location reference
scenarios without citing specific scenarios by way of example - which
you state should not be done... so I'll ignore that oxymoron and use
examples anyway:

1) I'm a scientist tracking a number of weather balloons through a wide
area network of location measurement receivers. Location is being
determined by uplink signal measurements using a periodic low power
pulse from the balloon electronics. I request the balloons to provide
the unique ID provided by the network and from then on I poll the
network for location. That allows me to continue tracking the balloons
even if I lose contact with them. I don't need to put a load on the
battery by regular communication directly with the balloon - thereby
permitting a smaller battery and permitting more useful instruments in
the payload. It's so nice I can use an IETF defined protocol to do this.
Thing is John, people have their own requirements and the reference will
be just the sort of thing that meets their need even if it's not
something you can imagine yourself.

2) In the NENA i2 architecture the host *wants* to delegate the queries
to the third party because there is no mechanism for a PSAP in the i2
network to query the handset for a location update. Maybe it'll be done
by the time i3 exists. In the mean time, the PSAP queries the VPC via
the ALI and the VPC has the reference by which it can obtain updated
location information. This is vital for mobile broadband networks.

3) Well I know some network operators want to be able to control who
gets the location information. They'll let emergency services ask for it
for free but they want to charge other applications. I don't think this
will be viable in the long run - but that's just one person's opinion.
In the mean time if it makes the decision easier for broadband providers
to put location infrastructure in place for emergency services, then I'm
quite happy for them to have the option. As Andy says, it's not our
place to tell them they can't do that. They need a protocol feature
engineered, so we engineer to that requirement.

Cheers,
Martin

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Friday, 1 September 2006 2:06 AM
> To: Hannes Tschofenig
> Cc: GEOPRIV; [email-masked]
> Subject: Re: [Geopriv] draft-tschofenig-geopriv-l7-lcp-ps-02.txt
> 
> 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Aug 2006 21:34:54 +0200

Hi Andy,
Hi John,

Andrew Newton schrieb:
>> required and discusses characteristics of such a protocol.  It does 
>> not answer the questions: What problem would a layer-7 protocol 
>> solve?  Why are other methods inadequate to solve that problem?
> 
> I can't answer all the questions you just asked, but I will answer one 
> of them.  The layer 7 protocol to dereference a location reference and 
> the layer 7 protocol to hand out a location reference do not have to be 
> the same.

John: Do you got the impression that this is the case?
To avoid confusion I actually stated it in the document. See text below 
Figure 4.

> 
>> Although those minutes also state "Ted Hardie noted that the IETF 
>> works on solutions that work across the Internet and cannot restrict 
>> itself to solutions for very specific network environments.", the 
>> draft starts (section 3, after Intro and Terminology) with several 
>> specific network "scenarios" for unspecified reasons.
> 
> Actually, I think this is very valuable.  We all approach problems based 
> on our experiences and sometimes fail to consider understand the 
> requirements others desire for a protocol because we have not had their 
> same experience.

I bet Ted will also review the document. I am already looking forward to 
see his feedback given the hard work we did in the design team.

>> upon."  This question appears important because "Ted Hardie agreed 
>> that an IP source address was not enough information to be the key to 
>> a location database. Jon Peterson agreed and noted that the IESG would 
> I believe there is a desire to attach an applicability statement to the 
> use of IP addresses, and other identifiers are also considered.

That's true. We discussed this an decided that an applicability 
statement does not fit into this document.

> 3) I have no answer to this, but it is not the IETF's place to stop 
> entities from making unwise customer service decisions.

Let me phrase it differently. Our work is focused on protocols and we 
should make sure that we
* make them as simple as possible, and
* make the applicable to a wide range of environments (and this includes 
business models).

I see absolute no problem with the reasons stated in here:
"
    In mobile wireless networks it is not efficient for the end host to
    periodically query the LIS for up-to-date location information.
    Furthermore, the end host might want to delegate the task of
    retrieving and publishing location information to a third party, such
    as a presence server.
"

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 31 Aug 2006 18:10:14 -0500

I might point out that the if the route determining proxy isn't the
first proxy, and TLS is used , then the solution argument below is void
as the message size is propagated over each link when transported by
value, but only over one link where done by reference.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, 1 September 2006 2:36 AM
> To: Andrew Newton
> Cc: GEOPRIV; John Schnizlein

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Aug 2006 20:22:33 -0400

I'm sorry, but that is wrong. Each link only incurs the incremental  
cost of carrying 60 bytes if by value. You'd have to have a dozen  
server hops to compensate for one reference retrieval.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 31 Aug 2006 19:26:37 -0500

Ummm, I am sorry, but how many PIDF-LOs are only 60 bytes?

> Sent: Friday, 1 September 2006 10:23 AM
> To: Winterbottom, James
> Cc: Andrew Newton; GEOPRIV; John Schnizlein
> >>> from the network to the end host, and then from the end host to
the
> > next
> >> I don't think we're disagreeing, but since this gets mentioned a
lot,
> > it
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
>