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

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 23 Mar 2006 09:52:56 -0600

Comments in line.

> >>
> >> 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.
> 
> I count 3 of the 27 elements defined in the sighting document in this
> example.  Should the other 24 be defined somewhere else?
[AJW] No
> 
> >  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".
> 
> 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?

[AJW] Yes

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

[AJW] Perhaps we have different copies of RFC-3693, but the figure you suggest, has no indication of a sighting interface in the copy that I have. 

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

[AJW] Good idea!

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

[AJW] I would ask if anyone has an opinion on this. I see this as a benefit and not a requirement.

>     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.
> 
> >> 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.
> 
> Is the "source address" in this text the same identifier as in your
> answer to my question 2?

[AJW] No
> 
>     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.

[AJW] My question to you here is, can I use an IP address to send a message to a host? If you answer yes to this question, then the network MUST contain sufficient correlators to enable the IP address to be mappped to a point of network attachment, i.e. the location. How and LG obtains these correlators is clear stated as being out of scope of geopriv. 

[AJW] This paragraph was left unspecific because there is no requirement to limit this identification to IP address.

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

[AJW] the essential linkage has already been established, this is a security consideration.  We pointed this section out as an FYI.

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

[AJW] I disagree with your statement completely. This paragraph is recommending that you don't provide incorrect location information. It provides guidance on how to avoid some such problems.

> 
> > [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."
> 
> 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] I think that I have done this above, and we shall add this to the next revision. Thank you for clarifying what it is that you were requesting.

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

[AJW] We shall clarify this in the next revision

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

[AJW] For SIP Location Conveyance, the term "location indication" was proposed to refer to both by-value and by-reference location information.  This protocol provides all the tools necessary to request or acquire a location indicator.

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

[AJW] The assumption that all internet hosts are potentially mobile is a useful one. While assuming the opposite you significantly restrict the application and usefulness of any solution you devise.

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

[AJW] We are were asked to split the document up into to clearly separable entities. One area that was clearly separable was the discovery function. 

> John

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