Subject: [Ecrit] [RAI] Review of draft-forte-lost-extensions-02

From: "Andrea G. Forte" <[email-masked]>
Date: Mon, 07 Mar 2011 11:47:24 -0500

Martin,

Thank you for your comments and apologize for my late reply. Please read my
responses inline.
(Sorry for the duplicate, I forgot to include the ECRIT mailing list in my
previous email).

-Andrea

> From: "Thomson, Martin" <[email-masked]>
> Date: January 24, 2011 8:56:43 PM CST
> To: "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: [RAI] Review of draft-forte-lost-extensions-02
> 
> Review of draft-forte-lost-extensions-02
> Martin Thomson, 2011-01-25
> 
>   I don't think that I've had the opportunity to comment on this draft
>   before.  There are several issues that I think prevent this draft from
>   being the basis for interoperable implementations.
> 
>   The most significant concern I have arises from the underlying model that
>   is used to define the extensions to the <findService> query.  Lack of
>   clarity on how the draft defines the problem translates into what I think
>   is a confused solution.
> 
>   The solution as described can be made to work, but it relies on
>   assumptions that are not documented.  As documented, there are likely to
>   be interoperability issues.
> 
> Terminology
>   Section 3 of this document refines the concept of a service region.
>   Three concepts are extracted from the basic ideas in RFC 5222:
> 
>     1. services without the concept of a service region (point-based
>        services that are identified purely by proximity)
> 
>     2. services that serve a geographic area where the geographic area for
>        different services of the same basic type overlap significantly (for
>        example, the overlapping serving area of competing home delivery
>        services)
> 
>     3. services that serve strictly non-overlapping geographic areas for a
>        particular service (that is, PSAPs)
> 
>   The latter two cases are both referred to as "service region" without
>   qualification.  It appears that (2) is the concept intended in most
>   cases.  Some clearer terminology might help.  Perhaps if you use "service
>   boundary" - as RFC 5222 uses it - to refer to the fence that is crossed
>   where answers might change; and "served region" or to refer to the
>   geographic area that is served by the particular service instance.
> 
>   Thus you can observe that service boundaries might be of limited use
>   where multiple services of the same type have overlapping served regions.
>   And you can also observe that some services lack a served area; and for
>   these services, a service boundary may for different reasons (it's only
>   the area where the N service instances provided in the answer are closer
>   than other instances).
[AGF]
I agree on that clearer terminology might help.
In RFC 5222 what you call "served area" is called "service area" as you can
infer from reading Section 12.2, for example, while
a Service Boundary is the boundary of a Service Region. I will go ahead and
rewrite this part taking into consideration such
definitions.

> 
> 
> Extension proposals
>   RFC 5222 is dreadfully vague on the use of geographic areas in the
>   <location> element.  Particularly when the area intersects with the areas
>   of multiple services.  I have inferred that the idea is that the LoST
>   server picks the single best choice, because that makes the most sense
>   for emergency uses (no good comes from presenting a choice in these
>   cases).
[AGF]
What you infer is not correct.
The LoST protocol has been designed to support both emergency and
non-emergency services.
You can read in RFC5222, Section 12.2 the following: "A server MAY return
multiple <mapping> 
elements if the shape extends across multiple service areas.". I know of
some LoST servers behaving
like this also for emergency services so that when the user location
overlaps between two PSAP
boundaries, both PSAPs are returned by the LoST server.

> 
>   What this draft proposes for "within X" relies on some sort of implicit
>   processing that is inconsistent with RFC5222.  It relies on the fact that
>   the LoST server knows that a particular service is somehow special.
[AGF]
Currently the "within X" query is the default query so that unless you
specify 
the <region> element to be true it will treat it as "within X" query. The
LoST server does not need
to have some implicit knowledge.
I think it is a good idea though to assume that when the <region> element is
missing, it is assumed to
be true rather than false. This will make the default query a "served by"
query thus making the behavior
consistent with RFC 5222 for emergency services (which use a "served by"
query).

> 
>   This doesn't make for very clear protocol semantics.  It's probably still
>   viable, but the document needs to make this assumption clear.
> 
>   I'm not sure how this out-of-band information interacts with recursive
>   resolution.  A LoST gateway that performs recursive lookups might not be
>   able make the right choice without an explicit, in-band indication of
>   intent.
[AGF]
This does not apply as per comments above.

> 
>   Attempting to overload the <location> element as described in Section 5.1
>   does not make for clear protocol semantics.
[AGF]
Practically it is the same problem. I want to search for points of service
within that region because my
location is within that region (with a certain probability).

Let me rephrase it.
We can think of the area of uncertainty in a shape as the probability that a
user might be within
that area and so we want to look for services within that area.
All we are doing with a "within X" query is to manually set the uncertainty
level in user location.
The semantics are the same.
> 
> 
>   My reading of RFC5222 leads me to infer that there is an implicit
>   <le:limit> parameter in the protocol that is set to 1.  There's always
>   the possibility that a location with uncertainty overlaps the served area
>   of multiple PSAPs - but LoST assumes that there is only one right answer.
> 
>   It seems like the right way to approach the proposed extensions is to
>   lift the implied limit beyond 1.  Adding the <le:limit> element seems
>   like the right thing to do, but the semantics that I associate with
>   <le:region> element doesn't seem to fit.
> 
>   I'd encourage the authors to re-examine the basic model they are using to
>   construct their proposed solution.
[AGF]
I think I have already addressed this in a previous comment. As we can read
in RFC5222 in Section 12.2, the LoST server MAY return
multiple mapping elements therefore there is no such thing as an implicit
limit to 1. Since there is a MAY in the sentence, the implicit
limit has to be assumed to be equal to "no limit". As such, what we propose
is semantically correct.
Limits of current implementations should not be a limit for the design of
new protocols. You are thinking about emergency services but LoST
was designed also for non-emergency services, so it makes sense that RFC
5222 allows LoST to return multiple <mapping> elements.

> 
> 
>   Section 5.3 seems very confused for these reasons.  A simpler model would
>   require less explanation.
> 
> On <le:limit>
>   Section 5.4 states:
> 
>    When the <limit> element is not present in a <findService> query then
>    all available points of interest for the requested type of service
>    SHALL be returned by the LoST server.
> 
>   Which seems contrary to what is implicit in RFC5222.  See above.
[AGF]
It is not contrary. See my comment above.

> 
> 
> On <le:serviceLocation>
>   The admonition:
> 
>    [...] Only geodetic profiles SHOULD be used [...]
> 
>   ... and subsequent use of an unwrapped <ca:civicAddress> element in the
>   <mapping> element is strange.  How is a civic address not the location of
>   the service?  If there are multiple forms of location, it would be better
>   to use similar guidance to what is in RFC5491:
> 
>     1. recommend multiple <le:serviceLocation> elements when there are
>        multiple forms available
> 
>     2. recommend that a geodetic form is provided where possible
[AGF]
Yes, I agree.
> 
> 
>   The location profile can be used to identify which location you want to
>   use if the content of the element is not sufficient.
[AGF]
I am not sure what you mean by this.

> 
> 
>   The reason given for these recommendations:
> 
>     [...] as the computation of the distance, route and other metrics
>    would at some point require geocoding of the civic address in
>    geodetic coordinates.  Because of this, the position specified in
>    <serviceLocation> SHOULD be represented by using the <Point> element.
> 
>   ... is not necessary for interoperability.  This seems more for the
>   convenience of LoST server implementations.  Wouldn't these reasons be
>   better suited to a LoST server provisioning guide?
> 
>   A better reason might be that a recipient of the mapping information
>   might need to use this information without the necessary context to
>   understand the civic address.  However, the same reason doesn't support
>   the recommendation for using a <gml:Point>.
[AGF]
There might be situations where the client would want to perform some light
computations on location information
but without having enough "power" to do geo encoding/decoding.

> 
> 
> Iterative Responses
>   The use of iterative resolution in LoST is a weak point that the ability
>   to provide multiple mappings does not help.  In the case where a server
>   is able to provide only some answers, there is no facility for the server
>   to indicate where the remainder of the answers are found (that is, the
>   referral).
[AGF]
I am not sure I follow. The authoritative server for that region and for
that class of service will reply
with the results. Iteration continues only until an authoritative server is
found.

> 
> 
>   Even if you can address that concern, there's also the concern that the
>   referred LoST server is able to provide better (closer) answers than the
>   ones provided.  The draft might offer guidance on how to resolve this
>   issue.
[AGF]
I still do not understand the issue. From RFC5222, Section 8.3.3 you can
read: "In Iterative mode,
the server contacted returns a redirection response indicating the next
server to be queried if the
server contacted cannot provide an answer itself."
> 
> 
> Security
>   The security section could use some expansion.  It's not sufficient to
>   just refer to RFC5222.
> 
>   The denial of service concerns that Shida raised in his review are worth
>   discussing.  A LoST server is discovered using the same means whether it
>   be for emergency or commercial uses.  The possibility that commercial
>   uses could interfere with public safety is a significant concern.  As
>   Shida notes, scaling is probably trivial to address, but that's not the
>   whole story.
[AGF]
I am very skeptical about this.

>From a regulatory perspective: the NG911 infrastructure is mostly paid and
maintained by collecting 911 fees that tax payers
have to pay. I do not think LoST servers paid with tax payers money for 911
can be used for supporting non-911 services.

>From a security perspective:  in the most general case, let's assume we have
two different LoST servers, one used by the NG911 client to discover the
correct ESRP and one used by the ESRP to discover the correct PSAP. The
second LoST server would be inside the ESInet thus
behind a firewall. Access to this LoST server would be granted only to known
ESRPs via access control lists (this is how many
vendors have it implemented) or similar. The first LoST server will be more
reachable than the second one as it does not have to be necessarily in the
ESInet. This, however, can be configured to only support urn:service:sos as
type of service and will be an authoritative server for
this type of service only (given the regulatory issues mentioned above and
security concerns).
At this point, the same security considerations as in RFC5222 apply.

> 
> 
>   We've seen problems that overwhelm a system, despite calculations
>   predicting ample capacity, simply due to high demand for a particular
>   application that is poorly configured.  Specific mechanisms to protect
>   public safety queries might be difficult to design, but the document
>   should at a minimum acknowledge the problem.
[AGF]
We could indeed include the discussion above in the draft.

> 
> 
> Nits:
>   Section 5.2 - typo: wether
> 
>   Most of the examples use http://www.thisisnotdoneyet.net/lostNe still.
> 
>   Using a namespace prefix of "gml" rather than "p2" would be more helpful
>   to the reader.  Consistent use of namespace prefixes throughout would
>   also help disambiguate the three or so namespaces used.
> 
> --Martin
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 9 Mar 2011 07:20:26 +0800

It's been a while since I sent the original email, so this might take a little while to process.

On 2011-03-08 at 03:47:24, Andrea G. Forte wrote:
> Martin,
> 
> Thank you for your comments and apologize for my late reply. Please 
> read my responses inline.
> (Sorry for the duplicate, I forgot to include the ECRIT mailing list 
> in my previous email).
> 
> -Andrea
> 
> 
> 
> 	   1. services without the concept of a service region (point- based
> In RFC 5222 what you call "served area" is called "service area" as 
> you can infer from reading Section 12.2, for example, while a Service 
> Boundary is the boundary of a Service Region. I will go ahead and 
> rewrite this part taking into consideration such definitions.
> 
> 
> 
> 
> 	Extension proposals
> The LoST protocol has been designed to support both emergency and non- 
> emergency services.
> You can read in RFC5222, Section 12.2 the following: "A server MAY 
> return multiple <mapping> elements if the shape extends across 
> multiple service areas.". I know of some LoST servers behaving like 
> this also for emergency services so that when the user location 
> overlaps between two PSAP boundaries, both PSAPs are returned by the LoST server.
> 
> 
> 
> specify the <region> element to be true it will treat it as "within X"
> query.
> The LoST server does not need
> I think it is a good idea though to assume that when the <region> 
> element is missing, it is assumed to be true rather than false. This 
> will make the default query a "served by" query thus making the 
> behavior consistent with RFC 5222 for emergency services (which use a 
> "served by"
> query).
> 
> 
> 
> Practically it is the same problem. I want to search for points of 
> service within that region because my location is within that region 
> (with a certain probability).
> 
> Let me rephrase it.
> We can think of the area of uncertainty in a shape as the probability 
> that a user might be within that area and so we want to look for 
> services within that area.
> All we are doing with a "within X" query is to manually set the 
> uncertainty level in user location.
> I think I have already addressed this in a previous comment. As we can 
> read in RFC5222 in Section 12.2, the LoST server MAY return multiple 
> mapping elements therefore there is no such thing as an implicit limit 
> to 1. Since there is a MAY in the sentence, the implicit limit has to 
> be assumed to be equal to "no limit". As such, what we propose is 
> semantically correct.
> Limits of current implementations should not be a limit for the design 
> of new protocols. You are thinking about emergency services but LoST 
> There might be situations where the client would want to perform some 
> light computations on location information but without having enough 
> "power" to do geo encoding/decoding.
> 
> 
> 
> 
> 	Iterative Responses
> I am not sure I follow. The authoritative server for that region and 
> for that class of service will reply with the results. Iteration 
> continues only until an authoritative server is found.
> 
> 
> 
> 
> the server contacted returns a redirection response indicating the 
> next server to be queried if the server contacted cannot provide an 
> answer itself."
> 
> 
> 
> 	Security
> From a regulatory perspective: the NG911 infrastructure is mostly paid 
> and maintained by collecting 911 fees that tax payers have to pay. I 
> do not think LoST servers paid with tax payers money for
> 911 can be used for supporting non-911 services.
> 
> From a security perspective:  in the most general case, let's assume 
> we have two different LoST servers, one used by the NG911 client to 
> discover the correct ESRP and one used by the ESRP to discover the 
> correct PSAP. The second LoST server would be inside the ESInet thus 
> behind a firewall. Access to this LoST server would be granted only to 
> known ESRPs via access control lists (this is how many vendors have it 
> implemented) or similar. The first LoST server will be more reachable 
> than the second one as it does not have to be necessarily in the 
> ESInet. This, however, can be configured to only support 
> urn:service:sos as type of service and will be an authoritative server 
> for this type of service only (given the regulatory issues mentioned 
> above and security concerns).

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 18 Mar 2011 12:59:13 +0800

Hi Andrea,

I'll go through those parts that I think need clarification.

I think that I understand where the disconnect is occurring.  We need to fix that.  Regrettably, it's looking more like a fault in RFC5222 than any special fault in your document.

> (Sorry for the duplicate, I forgot to include the ECRIT mailing list 
[...]
> overlaps between two PSAP boundaries, both PSAPs are returned by the LoST server.

Thanks for finding that, I looked twice and couldn't find it.  We should do something about that in -phone-bcp - it's a real problem.

> behavior consistent with RFC 5222 for emergency services (which use a 

That's where we'll have to disagree.  There is an implicit assumption here that a location with uncertainty (the circle that you attempt to use) does not get a choice between the two implicit (existing) behaviours:

 1 - Pick the best match for my location
 2 - Show me all possible matches for my location

And the new option (subtle difference)
 
 3 - Show me all possible matches for this area

I can live with 2 and 3 being collapsed, but the protocol semantics need to be clear about this, or we end up in a mess.

I think that the document makes a reasonable case for 2, but I'd like to keep 1 for emergency services and keep the two distinct.

My previous comments about recursive resolution still apply.  An in-band indication is even more necessary when recursion occurs.

> I am not sure what you mean by this.

This is related to the above problem.

> "power" to do geo encoding/decoding.

How does that support the use of Point over other types?  I assume that a client just uses the location that it has.  That only requires whatever computations the client has to do in order to get the location (GPS, HELD, DHCP, whatever).

> continues only until an authoritative server is found.

It's not possible, with a location shape that overlaps with the serving areas of multiple LoST servers to have the first LoST server provide some mappings and some referrals.
 
> At this point, the same security considerations as in RFC5222 apply.

This isn't a regulatory issue or anything related to a particular deployment.  It's a problem that you discover a LoST server in the same way regardless of whether your service URI is "urn:service:sos" or "http://www.pizza-restaurant.example/"  Unless you change the way that a value-add LoST is discovered, the same server is contacted.  Therefore, the same server needs to handle ESRP requests and coffee shop requests.

--Martin

---

From: "Andrea G. Forte" <[email-masked]>
Date: Fri, 18 Mar 2011 18:03:30 -0400

Martin,

Again thank you for the comments. A few more inline.

-Andrea

On 3/18/11 12:59 AM, "Thomson, Martin" <[email-masked]>
wrote:

>>      processing that is inconsistent with RFC5222.  It relies on the
>>fact 
>> that
>That's where we'll have to disagree.  There is an implicit assumption
>here that a location with uncertainty (the circle that you attempt to
>use) does not get a choice between the two implicit (existing) behaviours:
>
>I can live with 2 and 3 being collapsed, but the protocol semantics need
>to be clear about this, or we end up in a mess.
>
>I think that the document makes a reasonable case for 2, but I'd like to
>keep 1 for emergency services and keep the two distinct.
>
>My previous comments about recursive resolution still apply.  An in-band
>indication is even more necessary when recursion occurs.

[AGF]
For case 1, that would be a "served by" query (<region> equal to true or
missing) with a <limit> of 1. As I mentioned before, since LoST by default
may return any number of <mappings>, you must explicitly tell it to return
just one, the best. In case of PSAPs, however, since we only have one PSAP
per service area, the LoST server will return always one PSAP except for
overlapping areas, in which case it MAY return multiple PSAPs. This is
consistent with a "served by" query with no <limit> tag specified.

I guess this last point is what you want to address in phone-bcp. I leave
further comments on this for the new thread in the mailing list. I just
want to point out that the draft is consistent with the protocol semantics
defined in RFC 5222.

>
>> 
>> 
>>      The location profile can be used to identify which location you
>>want 
>> to
>>      convenience of LoST server implementations.  Wouldn't these
>>reasons 
>> be
>How does that support the use of Point over other types?  I assume that a
>client just uses the location that it has.  That only requires whatever
>computations the client has to do in order to get the location (GPS,
>HELD, DHCP, whatever).

[AGF]
Maybe I was not clear enough earlier. Here I am talking about the point of
service location, not the location of the client. We are talking about the
<serviceLocation> tag.

>It's not possible, with a location shape that overlaps with the serving
>areas of multiple LoST servers to have the first LoST server provide some
>mappings and some referrals.

[AGF]
I do not understand why we cannot just use what is already defined in RFC
5582.

In RFC 5582, Section 7.3 we read:
"[...] The solution for overlapping coverage regions is relatively simple.
 If a query matches multiple coverage regions, the node returns all
 URLs or server names, in redirection mode, or queries both children,
 if in recursive mode.  If the overlapping coverage is caused by
 imprecise coverage maps, only one will return a result and the others
 will return an error indication.  If the particular location is
 disputed territory, the response will contain all answers, leaving it
 to the querier to choose the preferred solution or try to contact all
 services in turn."

> 
>>     Security
>>      The security section could use some expansion.  It's not
>>sufficient 
>> to
>>      just refer to RFC5222.
>> 
>>      Shida notes, scaling is probably trivial to address, but that's
>>not 
>> the
>>      whole story.
>> 
>> [AGF]
>This isn't a regulatory issue or anything related to a particular
>deployment.  It's a problem that you discover a LoST server in the same
>way regardless of whether your service URI is "urn:service:sos" or
>"http://www.pizza-restaurant.example/"  Unless you change the way that a
>value-add LoST is discovered, the same server is contacted.  Therefore,
>the same server needs to handle ESRP requests and coffee shop requests.

[AGF]
I see your point. However, aside from scalability issues, right now I
cannot think of any other additional issues we would have in this case
when compared to the emergency-only case. I will do more thinking on this
but if you have a clear example please send it along.

I have not gone through the lost discovery RFCs yet. Is there anything
that prevents from provisioning the client with more than one LoST server?
Not that I am saying that this should be the way to go.