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

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Thu Aug 31 2006 - 15:28:11 EDT

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:

John Schnizlein schrieb:
>
> On Aug 29, 2006, at 4:23 PM, Hannes Tschofenig wrote:
>>
>> we have submitted a draft update of "GEOPRIV Layer 7 Location
>> Configuration Protocol; Problem Statement and Requirements"
>>
>> Please find it at:
>> http://www.tschofenig.com/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?

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.

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

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.

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

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

>
> 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."

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.

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

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

>
> John
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 31 Aug 2006 21:28:11 +0200

This archive was generated by hypermail 2.1.8 : Thu Aug 31 2006 - 16:15:24 EDT