Re: [Ecrit] FW: Gen-ART LC review ofdraft-ietf-ecrit-location-hiding-req-01

[Ben Campbell <[e-mail]>]

Hi,

Thanks for the response. Comments imbedded. I removed sections in  
which I think we are in agreement.

On Jul 10, 2009, at 2:29 PM, Hannes Tschofenig wrote:

> Hi Ben,
>
> Thanks for your review.
>
> Please find some comments below:
>

[...]

>
>
>>>
>>> -- Req-B
>>>
>>> Is it appropriate for this document to put requirements on the ISP/
>>> IAP? Or do you mean to say they MUST be _able_ to support this,  
>>> while
>>> hiding information location from the VSP and/or UA?
>
> A lot of the emergency services work relies on assumptions of what  
> various
> parties provide or do not provide.
>
> For this specific requirement the group thought it would be  
> important that
> the ISP/IAP allows either the end point or the VSP to do some form of
> emergency call routing.

Assuming that we expect to build protocol mechanisms around these  
requirements (Is that the intent?), how would you determine compliance  
with a requirement on an ISP?

[...]


>
>
>>> -- Security Considerations:
>>>
>>> I'm a little skeptical of this statement that this does not raise
>>> additional considerations. For example, would you consider
>> that a human
>>> might be endangered because an ISP wanted to reserve location
>>> information as a "for pay" service a security consideration,
>> in that it
>>> requires the solution to be more fail-safe than other
>> protocols? On the
>>> other hand, is the need to keep the UA from inferring
>> location when an
>>> ISP wants to hide it a security consideration?
>
>
> I at least did not know what to write into the security consideration
> section.
>
>

I'm not sure I understand your meaning--do you mean to say that you  
think the section is adequate as is, or do you think in needs more  
text/work?

[...]
>
>>>
>>> -- 3.3, first bullet:
>>>
>>> Is it appropriate to have "MUST"s in a section on "desirable
>>> properties"?
>
> Hmmm. Not sure.

I took the section title of "desirable properties" to mean "properties  
that are (perhaps very) nice to have, but not hard requirements." If  
that's what it means, then it seems odd to have a MUST here (except  
perhaps as a sub-requirement of some feature, where the feature itself  
is "nice to have".

Was the intent something different?


Thanks!

Ben.