Subject: RE: [geopriv] draft-winterbottom-geopriv-held-sighting-00

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 5 Mar 2006 20:40:23 -0600

Responses inline.

________________________________

From: John Schnizlein [mailto:[email-masked]] 
Sent: Thursday, 2 March 2006 7:18 AM
To: Winterbottom, James
Cc: [email-masked]
Subject: Re: [geopriv] draft-winterbottom-geopriv-held-sighting-00

A few questions: 

1) How many of the 27 elements and attributes described in this document
are necessary for an Internet host to discover its location, rather than
for other HELD uses? 

[AJW] Please look at section 9.1, the very first example! If all you
want is a location then this is all you need do. If you want more
sophisticated forms then you have the tools to make these requests. The
response also allows any location that complies with PIDF-LO profile,
which now includes all the shapes described in geo-shape allowing the LG
to use the most appropriate technology and subsequent representation
rather than artificially constraining the geodetic shape type to one
form.

2) What Identifier is specified by the sighting function, where
"Identifier" is as used in this excerpt from RFC 3693, section 5.1? 

Some variant of the sighting information is included in the Location 

Object. Abstractly, it consists of two separate data fields: 

(Identifier, Location) 

[AJW] The response to a successful location request is a PIDF-LO. You
will note therefore that the PIDF-LO is extended from PIDF defined in
RFC-3863, which in section 4.4 defines the XML schema for PIDF and you
will notice that there is a parameter called "entity" that has a use of
required. This is an identifier, and inline with the top of page 9 from
RFC-3693 "is the identifier of the Target being sighted". 

3) Since RFC 3693 does not include transmission of rules as part of
sighting, why is this included in sighting in figure 3?

[AJW] RFC-3693 does not have any diagrams showing the flow of sighting
information. Furthermore section 5.1 of RFC-3693 does not preclude it,
the section merely does not explicitly include it as it states what
should be minimally provided. The need for this additional information
for the higher functions offered by HELD is clearly described in the
document. As was stated in response to 1), the user does not want to
make use of this function then they need only make a simple GET request.

4) Why are rules transmitted to the Location Generator rather than to
the Location Server?

[AJW] Section 1.3 paragraph 4.

5) I did not find the role of the target's source IP address in this
document. Where are the description of the feasibility of the location
determination (I), and/or the applicability statement (Henning)
requested during the discussion at IETF 64? 

[AJW] IP address is discussed in section 3.1 the second paragraph under
figure 2. It is also mentioned in section 8.1 paragraph 2.

[AJW] As I pointed out to you at the last IETF, and I shall point you
again to the WG charter: 

"Out of Scope:
This WG won't develop location-determining technology.  It will work
from existing technologies and where the technology is undeveloped,
will state that applicability may await others' developments."

[AJW] We shall add Henning's applicability statement suggestion, thanks
for pointing this one out. 

6) Considering that HELD is an application protocol, what information
about the host is available to the Location Generator to enable finding
its location?

[AJW] See previous answer to 5

7) What does the following statement have to do with sighting? 

The protocol described has specific support for mobile devices 

through the assertion of LI to the LG and update URIs, which allow 

the LG to query a Device for its current location. This feature, in 

combination with Location URIs enables location determination at the 

time that it is needed by the Location Recipient (LR), and in the 

form requested by the LR. 

[AJW] It is a general description of what the protocol does. Please
indicate where in RFC-3693 that such behaviour is explicitly forbidden.
It seems that you are suggesting the existence of restrictions to
"sighting" that are neither stated nor implied in RFC-3693.

8) Considering: "This document does not define how an LG is discovered
or configured." How can the sighting communication occur without
determining the other party to the interaction? 

[AJW] Our position is that there are several options available for this
and that we would explore these in an additional document, and let the
focus of this document rest on the necessary protocol exchange. There
are clear IETF precedents for such approaches.

John 

On Feb 22, 2006, at 3:09 PM, Winterbottom, James wrote: 

	The  HELD sighting protocol draft is now available from
internet-drafts directory. 

	Title:                HTTP Enabled Location Delivery (HELD) -
Sighting 

	Authors:          J. Winterbottom, M. Thomson, B. Stark 

	Abstract 

	A Geopriv sighting protocol is described that is used for
retrieving location information from a server within an access network.
The protocol includes options for retrieving location information either
by-value or by-reference.  The protocol supports mobile and nomadic
devices through Location URIs and location update URIs, which enables
generation of location information at the Device.  The protocol is an
application-layer protocol that is independent of session-layer; an
HTTP, web services binding is specified. 

http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-held-sigh
ting-00.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]

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 22 Mar 2006 16:23:52 -0600

embedded in context:

On Mar 5, 2006, at 8:40 PM, Winterbottom, James wrote:

>> 1) How many of the 27 elements and attributes described in this 
>> document are necessary for an Internet host to discover its location, 
>> rather than for other HELD uses?
> sophisticated forms then you have the tools to make these requests. 
> The response also allows any location that complies with PIDF-LO 
> profile, which now includes all the shapes described in geo-shape 
> allowing the LG to use the most appropriate technology and subsequent 
> representation rather than artificially constraining the geodetic 
> shape type to one form.

I count 3 of the 27 elements defined in the sighting document in this 
example.  Should the other 24 be defined somewhere else?

> will notice that there is a parameter called “entity” that has a use 
> of required. This is an identifier, and inline with the top of page 9 
> from RFC-3693 “is the identifier of the Target being sighted”.

Is the answer that the first of the "two separate data fields" is 
embedded as the value of the "entity" parameter in the PIDF-LO that 
includes the Location?

> information.

The first diagram in RFC 3693 (section 4, page 6) shows different 
interfaces from the Location Generator (which includes the Sighting 
function) and the Rule Holder.

> Furthermore section 5.1 of RFC-3693 does not preclude it, the section 
> merely does not explicitly include it as it states what should be 
> minimally provided. The need for this additional information for the 
> higher functions offered by HELD is clearly described in the document.

If HELD does not require the inclusion of rules transmission as part of 
sighting, why is this specified in the portion of the separated HELD 
specification on Sighting?

Since the inclusion of rules transmission in Sighting seems to me a new 
concept, the WG should decide a consensus view before adopting a 
document including this.

> As was stated in response to 1), the user does not want to make use of 
> this function then they need only make a simple GET request.
>  
>>  

If the following text is your reference, it seems at odds with the 
design concept of the Internet that application flexibility is in the 
hosts attached to the network.  Has "a very simple client" been defined 
as a requirement of GeoPriv?

    This interface between Device and LG includes some features that
    could be equally described by a direct interface between Device and
    LS.  Communication with the LS is directed through the LG because it
    places the complexity on the LG; this enables the implementation of a
    very simple client in the Device.

>> document. Where are the description of the feasibility of the 
>> location determination (I), and/or the applicability statement 
>> (Henning) requested during the discussion at IETF 64?
> [AJW] IP address is discussed in section 3.1 the second paragraph 
> under figure 2.

Is the "source address" in this text the same identifier as in your 
answer to my question 2?

    The LG needs to uniquely identify the Device within the access
    network.  The source address of the request message is sufficient in
    most cases.  Once the Device is identified, the LG uses network
    domain-specific information to determine the location of the Device.

The above text could be read as using layer-2 addressing information, 
which might hint at the feasibility of reliably mapping from IP address 
to location.

> It is also mentioned in section 8.1 paragraph 2.

Do you intend this Security Consideration section to establish the 
essential linkage of source IP addresses to the Location Generation 
(Sighting) function?

    Addressing information used in a request to the LG is used to
    determine the identity of the Device, and to address a response.
    This ensures that a Device can only request its own LI.

If so, the embedding of dynamic notification of location changes in the 
access network implied by the following statement seems to restrict the 
utility of this approach to only certain kinds of access network:

    o  The LG and network SHOULD be configured so that the LG is made
       aware of Device movement within the network and addressing
       changes.  If the LG and LS detect a change in the network that
       invalidates a context, the context MUST be terminated.

> “Out of Scope:
>  will state that applicability may await others' developments.”

The distinction unrecognized in this answer is the difference between 
developing location-determining technology and indicating that a 
proposed approach has a feasible method.  Feasibility, not 
specification, of the mapping of IP address to location is what I have 
been requesting.  The feasibility argument might be reflected in an 
applicability statement of the sort that Henning requested.

>  [AJW] We shall add Henning’s applicability statement suggestion, 
> thanks for pointing this one out.
>  
>> about the host is available to the Location Generator to enable 
>> finding its location?

Neither of the sections indicated in your answer to question 5 suggests 
that mapping IP addresses to location is feasible.  Your interpretation 
of "source address" as the IP address seems to preclude the layer-2 
address.  It remains unclear what host information would make this 
feasible.

> indicate where in RFC-3693 that such behaviour is explicitly 
> forbidden. It seems that you are suggesting the existence of 
> restrictions to “sighting” that are neither stated nor implied in 
> RFC-3693.

My impression was that the WG withheld a decision on continuing to 
consider this proposal for a WG item on the basis of a promised 
separation of the compound document that raised so many issues.  The 
"general description of what the protocol does" other than its Sighting 
functions seem misplaced in this document. No inferred restrictions are 
involved in attempting to see how your proposal changes the simple 
interfaces between separate functional blocks in RFC 3693.

I hoped that the specification of "mobile devices" might suggest the 
applicability restriction rather than just special support for a class 
of hosts.  It might also be helpful to indicate which meaning of 
"mobile device" you mean e.g. cellular phone, Mobile-IP, roaming IP 
hosts.

>>  8) Considering: "This document does not define how an LG is 
>> discovered or configured." How can the sighting communication occur 
>> without determining the other party to the interaction?
> [AJW] Our position is that there are several options available for 
> this and that we would explore these in an additional document, and 
> let the focus of this document rest on the necessary protocol 
> exchange. There are clear IETF precedents for such approaches.

Since the feasibility of the discovery mechanisms proposed earlier was 
questioned, it seems that the feasibility should be established before 
the WG accepts the proposal.  It would be different if the proposal did 
not depend on application-layer interaction where the other party to 
the interaction is unknown. Yes, sadly, there are precedents for 
presuming some feasibility solution that never arrives in the IETF.  
That is why we rely on running code rather than process precedent for 
standardization.

John