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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
