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

From: "Reese, Theresa E" <[email-masked]>
Date: Wed, 7 Feb 2007 15:25:41 -0500

Hannes - 

A couple of additional comments in-line.

Thanks.

Terry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Wednesday, February 07, 2007 3:05 PM
To: Henning Schulzrinne
Cc: Reese, Theresa E; [email-masked]
Subject: Re: [Ecrit] Comments/Questions on draft-ietf-ecrit-03

Hi Henning,

Henning Schulzrinne wrote:
> 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:
>>
>>
>>  <warnings source="lost:authoritative.example">
>>    <noValidation
>>        message="Unable to perform validation."
>>        xml:lang="en"/>
>>  </warnings>
>>
>
> 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?
>
>
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?)
>
>
>> If LoST is run with the end host then it would perfectly make sense 
>> to always include this information.
>>
>
> Subject to the qualification above.
>

Understood. Fine with me.

[TER] As I indicated in my response to Henning, this does not address
the situation with emergency services where something like the
serviceNumber may be useful to a client that is end user equipment, and
not useful to a client that is an ESRP - even though both are requesting
the same service.  Henning's answer seems to be to return the same
information to both, and let the ESRP ignore what it doesn't want. Thus
there is a tradeoff between adding logic at the ECRF/LoST server to
optimize the response vs. including unnecessary information in the
response and having the ESRP determine that certain elements can be
ignored.  

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

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

>
>
>>
>>> 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?
>
> 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.)
>
>
Understanding the use case is certainly important. No doubt.

[TER] My preference is to include the additional errors in the LoST
protocol.

Ciao
Hannes

>
>
>>
>>
>> Thanks a lot for your review.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Feb 2007 22:16:09 +0100

Hi Terry,

thanks for your response. Please find my response inline:

> response and having the ESRP determine that certain elements can be
As I mentioned in my other mail it would be quite easy to differentiate 
these two deployment cases.
If some wants to "optimize" the size of the LoST response to the ESRP 
then it would be possible without changing the protocol or the 
description in the protocol. It is a pure deployment choice.
Practically speaking I doubt that it will be a big win to omit two 
elements.

> [TER] My preference is to include the additional errors in the LoST
I understood your scenario. There are two more questions:

* What type of security protocol for authentication do you envision?
Currently, we talk about TLS usage in the LoST document.
Hence, I assume that you would use some TLS ciphersuite, such as  TLS 
with pre-shared  secrets,  to authenticate the client to the server.

* If authentication in TLS fails then you are not really able to send 
any LoST message. Hence, you cannot return an error in the LoST 
protocols to say that authentication did not work. Are there cases where 
you authenticate a client successfully but then you decide to reject him?

Ciao
Hannes