RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

from
[Reese, Theresa E]

Subject:

RE: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

From:

"Reese, Theresa E"

Date:

Wed, 7 Feb 2007 10:00:39 -0500

Hi Hannes,
Thank you for your prompt response to my questions and comments.
I have included my responses and additional comments/questions for
clarification in-line.
Terry
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Tuesday, February 06, 2007 3:15 PM
To: Reese, Theresa E
Cc: ecrit@xxxxxxxx
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03
Hi Theresa,
Thanks for your review. Please find a short response below. Further
discussion is certainly needed.
Reese, Theresa E wrote:
> Authors of draft-ietf-ecrit-lost-03:
>
> I have reviewed draft-ietf-ecrit-03, and have a number of
> comments/questions. Like my review of draft-ietf-ecrit-02, my review
of
> lost-03 was done in the context of considering how LoST could be used
to
> support the real-time routing of emergency calls in a NENA i3 Solution
> environment. In particular, a number of questions/comments relate to
> the use of LoST between an i3 Emergency Services Routing Proxy (ESRP)
> and an i3 Emergency Call Routing Function (ECRF) (where the ESRP is
the
> LoST client and the ECRF is the LoST server).
>
>
Good to know the context of your review. That helps to understand
certain things much better.
> Thank you in advance for consideration of my questions/comments, and
for
> providing the requested clarifications.
>
>
>
> 1. Section 1, last paragraph indicates that the LoST server returns
> URIs "along with optional information, such as hints about the service
> boundary" in a response to a LoST client. Section 3 also specifies
that
> "a client may omit requests for other auxiliary information." The
> "include" attribute that was previously defined in lost-02 has been
> removed, so what is the mechanism in lost-03 that allows the client to
> state specifically what information it is trying to obtain? For
example,
> in the context of an i3 Emergency Services Routing Proxy (ESRP),
> elements such as the serviceNumber and displayName are not useful to
the
> ESRP. Using lost-02, I could omit these from the 'include' element,
and
> they would not be returned by the server. With lost-03, how do I
> accomplish the same thing, or have I lost that flexibility in lost-03?
> I assume I can omit the serviceBoundary element, if I do not want the
> server to return that information, but I don't see how to omit other
> undesired information (e.g., serviceNumber) using the mechanisms
defined
> in lost-03.
>
>
The displayName is optional. The same is true for the serviceNumber.
A serviceBoundary needs to be requested by the client (using the
serviceBoundary="value" attribute) or is included by the server if a
local policy indicates it.
Hence, the following XML instance document is validating against the
schema:
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml&quot;>
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
<service>urn:service:sos.police</service>
<uri>sip:nypd@xxxxxxxxxxx</uri>
</mapping>
<path>
<via source="lost:authoritative.example"/>
</path>
</findServiceResponse>
[TER] Thank you for the XML illustrating a response that is streamlined
to provide URI information. Just for clarification, is it the LoST
server that determines whether to include the displayName and
serviceNumber elements, and if so is that determination based on local
policy?
> 2. Related to this issue is the question of how the server should
> respond if it does not support information that is requested (e.g.,
> location validation). Section 6.3.4 of lost-02 stated that the server
> could ignore any element names it did not understand. Section 7.3 of
> lost-03 states that the <findService> request includes attributes that
> govern which elements must be contained in the response. Section 7.4.2
> states that the server MUST include validation information in the
> response if the 'validateLocation' attribute in the request is set to
> "true."
>
> What is the appropriate response to return if the server is capable of
> returning the URI but does not do validation, and either does not have
> arrangements with other servers to do validation, or the query is
> iterative? Again, I am looking at this in the context of using LoST
for
> queries between an i3 ESRP and an i3 Emergency Call Routing Function
> (ECRF) which is optimized for emergency call routing. (i3 defines a
> separate functional element for location validation which is accessed
> prior to an emergency call being originated.)
>
You concerned that someone asks for validation but the server does not
support it.
I personally believe that an error message has to be returned in the
sense that the mapping is provided by the LoST server states that it
was unable to perform validation. What do you think about something
like:
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/&quot;>
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example"
sourceId="fb8ed888433343b7b27865aeb38f3a99" version="1" >
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<uri>sip:nypd@xxxxxxxxxxx</uri>
</mapping>
<warnings source="lost:authoritative.example">
<noValidation
message="Unable to perform validation."
xml:lang="en"/>
</warnings>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</findServiceResponse>
[TER] Yes, that is that sort of thing that I was thinking would be
appropriate.
A little bit background for me:
One of the reasons for introducing validation was to address some of the
requirements particularly raised by NENA members?
Is validation not important anymore?
[TER] Location validation is still a necessary part of the NENA i3
Solution. However, in the context of the i3 Solution, it is assumed
that the validation can be performed independently of call routing, and
that it will be done prior to an emergency call origination. The server
that supports the validation request may not necessarily be the same as
the server that supports emergency call routing requests. When an
emergency call is originated, a query to the Emergency Call Routing
Function (routing server) will be attempted using the pre-validated
location information.
> 3. It would be helpful if the definition of the <mapping> element
> provided in Section 5 clearly stated that this element is only present
> in responses. This is implied later in the document, but it would
> reduce confusion if it was stated up front.
>
Certainly reasonable to include.
[TER] Thank you.
> Also, the definition of the <mapping> element states that all elements
> within the <mapping> element except the service URN are optional, but
> for elements other than the boundary information, does the client or
the
> server determine whether the information will be returned, and how
does
> it do so?
>
In some environments it is not necessary to include the serviceNumber or
the displayName. This is true, for example, in the 3GPP architecture
where LoST could be used between the E-CSCF (a SIP proxy) and the LoST
server.
If LoST is run with the end host then it would perfectly make sense to
always include this information.
[TER] So, are you saying that the server may determine, based on the
querying entity, whether certain information should be included in the
response or not?
>
> 4. Section 5.3 indicates that on occasion, a resolver will be
> forced to return an expired mapping if it cannot reach the
authoritative
> server or cannot get useful information from the authoritative server.
> Is this information flagged as expired (e.g., by including some kind
of
> warning in the message) or is it up to the client to check the date
each
> time to make sure the information is valid before using it?
>
>
Another good point.
Both approaches are possible but the current draft version currently
only allows a check of the expires attribute.
I believe that the Phone BCP document should mandate some behavior for
emergency services.
> 5. Section 6 describes the encoding of one or more <via> elements
> if the request involved recursion. This section also states in the
> second paragraph, "If a query is answered iteratively, the querier
> includes all servers that it has already contacted." Can you
elaborate
> on what is meant by this text? The document would benefit from a more
> detailed description of the iterative query method (e.g., in Sections
6
> and 7.3.3) and the associated error handling procedures.
>
Imagine the following interaction for the recursive query.
A ---> B ----> C ----> D
<--- <---- <----
"A" is the LoST client. The query travels from B, to C and finally to D
(and the way back).
The <via> elements would contain:
<via>D</via>
<via>B</via>
<via>C</via>
<via>B</via>
For an iterative query initiated by the LoST B server when it receives a
request from A the following interaction would take place:
A ---> B ----> C
<----
B ----> D
<----
A <----
B would create the via list as:
<via>D</via>
<via>B</via>
<via>C</via>
<via>B</via>
Although we have already updated the text with version -04 (not yet
published though) I believe we have to provide more text.
[TER] So if the query from A to B is iterative, would the via list only
consist of "B"? Would there still be a via list in the response?
> 6. Can the "forbidden" error defined in Section 12 also be used if
> the LoST server receives a query from an entity that is not
> allowed/authorized to receive the requested information? (This is an
> error case that can occur in the context of the NENA i3 Solution.) As
> indicated in item 5 above, what is the appropriate error to return if
> some requested information is available, but other requested
information
> is not available?
>
It might be necessary to include more error messages. Hence, it is good
that you raise them now.
I could imagine that it is necessary to address these two error cases in
separate error messages
For example, one could use "unauthorized" a LoST client is not allowed
to retrieve the requested information.
On the other hand, when would you use this error message? Would you deny
access to a LoST database to an emergency caller?
[TER] While, in the context of the i3 Solution, we do not expect that
emergency callers will be authenticated, we do expect that i3 ESRPs that
access the ECRF/LoST server will need to be authenticated. Therefore,
this error case could arise if an unauthenticated ESRP attempts to
access an ECRF. An error code of "unauthorized" could be useful for
this case.
I also agree that it would be good to define a separate error indication
for situations where requested information is not available.
Thanks a lot for your review.
[TER] Thank you for your very helpful responses.
Ciao
Hannes
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit