[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-lost-02
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:andy at hxr.us]
Sent: Monday, November 20, 2006 8:32 PM
To: Reese, Theresa E
Cc: ecrit at ietf.org
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
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit