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

From: "Reese, Theresa E" <[email-masked]>
Date: Tue, 6 Feb 2007 11:19:55 -0500

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

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.

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

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.  

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

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.

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?

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 06 Feb 2007 21:15:21 +0100

Hi Theresa,

Thanks for your review. Please find a short response below. Further 
discussion is certainly needed.

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

> undesired information (e.g., serviceNumber) using the mechanisms defined

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">
  <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:[email-masked]</uri> 
  </mapping>
  <path>
    <via source="lost:authoritative.example"/>
  </path>
</findServiceResponse>

> 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/">
  <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:[email-masked]</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>

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?

> reduce confusion if it was stated up front.  

Certainly reasonable to include.

> server determine whether the information will be returned, and how does

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.

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

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

> some requested information is available, but other requested information

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?

Thanks a lot for your review.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 6 Feb 2007 22:14:06 -0500

Some additional comments inline.

On Feb 6, 2007, at 3:15 PM, Hannes Tschofenig wrote:

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

I don't think the warning is strictly necessary. If I ask for  
validation and the server doesn't return the corresponding  
validation, I know that the server doesn't support it. After all,  
we're presumably not having teenagers operate servers: "I don't feel  
like it and you can't make me do it".

My concern about adding these types of warnings is that this just  
adds another special case to consider: What if there is no warning  
and no validation? Does this mean something different?

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

Also, it is not clear that long-term, all services will have a  
service number. After all, we may eventually outgrow the notion of a  
12-button keypad. Certainly, for non-emergency service URNs, there  
may no such number at all. (What number would you assign to  
urn:service:restaurant?)

> If LoST is run with the end host then it would perfectly make sense  
> to always include this information.
>

Subject to the qualification above.

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

The client has to check the expiration date in any event, so I would  
not include a warning. The expiration date indicates this  
unambiguously. (Otherwise, you can get strange cases, where, due to a  
slight clock offset, the data appears expired, but there's no  
warning, or vice versa. Again, that would be yet another unhelpful  
special case to deal with.)

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

For the reasons I mentioned above, I don't think it's helpful to  
include error messages for partial information. The only case I could  
see where this is useful where you get different information when you  
"log in" vs. without login.

But I'd like to understand a real use case before adding complexity.  
(I think having a design where somebody would try without login, then  
get partial information, then supply credentials, is needlessly  
complex. It would be better to have a separate server that requires  
authorization, if that's necessary.)

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Feb 2007 21:04:41 +0100

Hi Henning,

Henning Schulzrinne wrote:
>> 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:
>>
>>
> validation and the server doesn't return the corresponding validation, 
> I know that the server doesn't support it. After all, we're presumably 
> not having teenagers operate servers: "I don't feel like it and you 
> can't make me do it".
>
> My concern about adding these types of warnings is that this just adds 
> another special case to consider: What if there is no warning and no 
> validation? Does this mean something different?
>
>
It is also fine with me to avoid adding another error message and to 
indicate that the LoST server just does not support validation if 
nothing is returned based on a request by the LoST client.

>>
>> 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.
>>
>
> Also, it is not clear that long-term, all services will have a service 
> number. After all, we may eventually outgrow the notion of a 12-button 
> keypad. Certainly, for non-emergency service URNs, there may no such 
> number at all. (What number would you assign to urn:service:restaurant?)
>
>

Understood. Fine with me.

> slight clock offset, the data appears expired, but there's no warning, 
> or vice versa. Again, that would be yet another unhelpful special case 
> to deal with.)
>
>

We have to add a statement that the LoST client checks the expiration 
date. I couldn't find anything.

The Phone BCP would then say "For the emergency service usage even 
expired mappings are acceptable if no other more recent information is 
available."

>> I could imagine that it is necessary to address these two error cases 
>> in separate error messages
Understanding the use case is certainly important. No doubt.

Ciao
Hannes