Subject: RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-lost-02

From: "Reese, Theresa E" <[email-masked]>
Date: Tue, 21 Nov 2006 09:17:02 -0500

Andy -

Thank you for your very helpful clarifications of the LoST document.

I have one more question related to the use of the LoST protocol in
scenarios involving an ESRP (e.g., as described in
draft-ietf-ecrit-framework-00).  Since an ESRP will likely have a need
to handle multiple emergency session requests at the same time, what is
the mechanism by which the ESRP can correlate a response from the LoST
server with the LoST query it generated associated with a specific
emergency session request?  There doesn't seem to be anything in the
LoST protocol itself (e.g., a Message ID) that would allow the ESRP to
correlate LoST responses with their associated query messages.  Is the
assumption that the ESRP will use the TLS connection over which the
query/response is exchanged as the basis for this correlation?  If so,
then there will need to be multiple TLS connections set up between the
ESRP and the LoST server to ensure that performance (i.e., query
response time) is optimized. (I am assuming here that the LoST server
will be able to process multiple routing requests in parallel, like many
routing databases do today.) Otherwise, the ESRP will have to wait for
the response to a query related to one emergency session to be returned
before it sends out a query related to another emergency session.  If
there is some delay in returning a response (e.g., due to the need for
the LoST to interact with another LoST server), this delay will impact
all emergency session requests that the ESRP has received subsequent to
the one for which the LoST query was sent.  In the context of emergency
calling, it would seem to be critical that routing of one session not be
delayed waiting for a response to come back for another session
(particularly if the LoST server is capable of processing more than one
query at a time).

Can you tell me if there been any discussion regarding the inclusion of
something like a Message ID in the LoST protocol, or whether the
assumption has been that this correlation would be based on the TLS
connection over which the specific query/response was exchanged?  Has
there been any discussion regarding the number of TLS connections that
might exist between an ESRP and a LoST server to handle potential
traffic volumes?  (I know this goes beyond the specification of the LoST
protocol itself, but it does relate to the use of LoST for routing
emergency calls.)

Thanks again for any guidance you can provide.

Terry

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, November 20, 2006 8:32 PM
To: Reese, Theresa E
Cc: [email-masked]
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-lost-02

Theresa,

Thanks for the questions.  Comments/answers are in-line:

On Nov 20, 2006, at 2:19 PM, Reese, Theresa E wrote:

> 1.	Is the 'recursive' attribute mandatory in all <findService>
> queries?
> Is the 'recursive' attribute mandatory only in <findService> civic
> queries?
> Is the 'recursive' attribute optional in <findService> queries?
>
> Currently, the 'recursive' attribute is not shown in Figure 2
> (<findService> geodetic query), but is included in Figure 4
> (<findService> civic query).

It is optional in both cases, with a default value of true.

> 2.	If a 'recursive' attribute is included in a <findService> query,
> must a <via> always be present in the associated response?
>
> Figure 4 includes a 'recursive' attribute in the query, but Figure 5,
> which shows the associated response does not include a <via> element.
> Also, the text in Section 6.4.1 specifies that responses to iterative
> queries contain one <via> element, while responses to recursive  
> queries
> will have a <via> element for each server that was used in the
> resolution.

This is an inconsistency in the example.  We did a very poor job of  
putting <via> in anywhere.  That has been rectified in the new set of  
examples.  I believe you have specified the behavior correctly,  
though.  However, I'll let Henning have the last word here.

> 3.	If the query originator sets the 'recursive' attribute in a
> <findService> query message to "true," and the LoST server cannot  
> answer
> the query and has nowhere to forward the query to (i.e., the LoST  
> server
> does not have any arrangements with any other LoST servers to provide
> assistance under this type of failure scenario), should the LoST  
> server
> treat the query as an iterative query (i.e., return an
> <iterativeSearchExhausted> message)?

Well, the <iterativeSearchExhasted> was actually a redirect.   
Confusing, huh?  We've pulled it, and the new XML just has a  
redirect.  You can see the next schema and examples on-line here:
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG/

To answer your question, I believe <notFound> would be the correct  
response to the scenario you have described.

> 4.	The <findServiceResponse> message in Figure 6 includes some
> elements that were not identified in the 'include' attribute of the
> <findService> query (e.g., displayName, serviceBoundary). Is this a
> typo?  Also, this example includes a 'recursive' attribute in the  
> query,
> but there is not via in the response.  Should the <via> element be
> present in the response?

Again, the examples were not consistent with the text.  We'll fix  
that problem next time around.

> 5.	There seem to be some inconsistencies in Figure 12 between the
> information being requested in the <findService> query and the
> information provided in the <findServiceResponse> message.  The query
> requests the uri and serviceNumber.  The response provides
> <displayName>, <service>, and <serviceBoundary>, and does not provide
> <serviceNumber>.  I assume the author intended the query to include a
> request for serviceBoundary, but this raises a question.  If the query
> originator did not request serviceBoundary information, and provided
> location using two different profiles (as is illustrated in Figure  
> 12),
> and the server did not understand the non-baseline profile, would the
> server still communicate the locationProfileError, even if it was not
> returning location information (in the form of a serviceBoundary)
> itself?

Good question.  The answer would be yes, the server should provide a  
warning (<locationProfileUnrecognized> in the new schema).

> 6.	There seems to be text missing from the last sentence of the
> first paragraph in Section 10.  The text begins to talk about errors
> that are labeled as fatal, but then the text just stops.  The sentence
> fragment either needs to be completed or deleted.

Thanks.  As we mentioned in the meeting, we've overhauled the error/ 
warning scheme.  You can see that reflected in the schema which is on- 
line.  I suspect most of the text for that section will be rewritten  
entirely.

> Also, the text in Section 10.2 says that the errors described in this
> section "may be generated by referent LoST serve[r]s queried on behalf
> of seekers by a resolving LoST server."  This seems to imply that  
> these
> would be error indications that would be received by the resolving  
> LoST
> server.  I assume that these would be passed back to the query
> originator by the resolving LoST server.  Also, I assume that if the
> LoST server is both the resolving and the responding LoST server, that
> it would generate these error messages and pass them back to the query
> originator (possibly with the exception of the serverError element  
> which
> seems to only apply to an error indication that a resolving LoST  
> server
> would receive from a responding LoST server).  Is this correct?

I believe you have it correct.

-andy

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 21 Nov 2006 10:15:49 -0500

On Nov 21, 2006, at 9:17 AM, Reese, Theresa E wrote:
[..snip..]
> protocol itself, but it does relate to the use of LoST for routing

Since the current definition of LoST uses HTTP and HTTPS, both of  
which are TCP based, the way that a request is matched up with a  
response is via the session semantics of HTTP over TCP.  We have not  
discussed a message ID, as that is really a trait of the transfer  
protocol and its bound transport protocol.  With HTTP, you simply  
rely on the underlying TCP session semantics.

This means that an ESRP would indeed need to keep a connection pool  
of long-lived HTTPS/HTTP connections.  However, because of the  
caching involved and the likelihood that an ESRP would probably be  
coupled with a LoST caching resolver, it is not clear to whom the  
persistent connections will need to be made and how many will be  
needed.  We can theorize that an ESRP/LoST resolver pair will need a  
certain number of connections to the forrest guide of its  
jurisdiction and perhaps a certain set of LoST authoritative servers  
within its coverage area, but I think deployment experience will be  
the only way we really know in the end.

Within the author team and the working group, we have discussed  
bindings to other protocols... specifically SOAP and UDP.  I don't  
believe SOAP offers an answer here (and it may cause problems,  
actually), but UDP would allow many simultaneous sessions if the UDP  
binding had a message ID (like DNS or IRIS-LWZ).  The obvious problem  
with UDP is that the payloads cannot be large and there is no  
practical channel security (I believe DTLS would get you right back  
to the same point as using HTTPS).

We, the author team, decided that we could spend many thousands of  
hours trying to figure this out, and in the end we may not get it  
right due to lack of true deployment experience.  Will we need UPD?   
Will we need something like BEEP?  We truly don't know, but we are  
very confident that the XML as designed is easily adaptable to other  
transfer/transport schemes.

-andy