I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-ecrit-location-hiding-req-01
Reviewer: Ben Campbell
Review Date: 20090507
IETF LC End Date: 20090511
IESG Telechat date: (if known)
Summary:
This document is almost ready for publication as an informational RFC.
There are some minor clarity issues where the reader is left to infer
some things that could be more explicit.
Major issues:
None
Minor issues:
-- 1.1, last paragraph:
Can you expand on how withholding information information needed for
call routing concretely differs from withholding information from
emergency personnel? I assume there is more to this than the intent of
the ISP. Also, by saying an ISP is "not interested", I think the point
is to say that they have legal obligations to disclose to emergency
personnel, regardless of any interest otherwise, right?
-- 1.2, first paragraph:
I think this leaves out what I assume to be the actual problem
statement, which is we need a way that an ISP/IAP can hide location
info from the user agent of the VSP in such a fashion that it is still
available for PSAP routing, correct? I can infer that pretty easily,
but I don't see where it is explicitly stated in one place.
Is there a case where an ISP is simply unable to provide location
information? I assume that would be out of scope for this document,
but it should be stated as such.
-- 1.3, fourth paragraph:
This paragraph could be more clear--how does the PSAP having
credentials meet a requirement to _hide_ information? I infer the
assumption is that the caller does _not_ have the necessary
credentials. If so, it would be better to state it explicitly
-- Fifth paragraph:
is compatibility with LoST a requirement?
-- 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?
-- Req-C
I don't really understand what is being said here. Is the point to say
that they must be able to validate that the URI identifies a "bona
fide" emergency service contact, and that a call to that URI actually
routes to the right place? How does this interact with the later
requirement that the entities need not be SIP aware?
-- Req-D
this is stated as a requirement on the ISP rather than a statement
about the solution. I _think_ you are saying there is a requirement to
be _able_ to provide location info to the PSAP while withholding it
from the caller. Is that correct?. Also how does "by value or by
reference" interact with the previous statement concerning LoST
requiring LbyV?
-- Req-5
How does the requirement that the ISP/IAP not need to know SIP
interact with the statement in Req-D that the ISP must be able to
determine if a call is being routed to a bona-fide location service?
Also, does Req-5 imply a requirement to work with non-SIP VoIP services?
-- Req-6
What does it mean for a PSAP boundary to have holes?
-- Req 12:
"Minimal impact" is vague--can you add clarifying text to make this
more concrete?
-- Req 15:
Is that really a requirement, or just an observation of fact?
-- 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?
Nits/editorial comments:
-- Abstract, paragraph 2:
It's not clear to me that the document described architectural
impacts. It refers to architecture, but I don't see explicit
statements about how the architecture breaks if the ISP is not willing
to disclose.
-- 1.1, list item "3."
Please expand VSP on first use.
-- Req-A:
I don't think the requirement is to be able to withold location from
"any entity it wishes", since that would include the PSAP, etc.
-- Req-2: "jurisdiction of the PSAP"
Geographical jurisdiction?
-- Req-10: The solution MUST allow the end host to determine PSAP/
ESRP URLs prior to the call, for all emergency services.
Who is the "end host"?
-- 3.3, first bullet:
Is it appropriate to have "MUST"s in a section on "desirable
properties"?
-- Third bullet:
That's an implementation detail. I think you mean to say something to
the effect of the presence of NATs SHOULD not break the mechanism.
-- idnits reports the following (which I include without prejudice):
idnits 2.11.11
tmp/draft-ietf-ecrit-location-hiding-req-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
http://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should
update this
to the boilerplate described in the IETF Trust License Policy
document
(see http://trustee.ietf.org/license-info), which is required from
December 16, 2008. Version 1.34 of xml2rfc can be used to produce
documents with boilerplate according to the mentioned Trust
License
Policy document.
-- Found old boilerplate from RFC 3978 Section 5.1 on line 22.
-- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC
4748 on
line 377.
-- Found old boilerplate from RFC 3979 Section 5 paragraph 1 on
line 388.
-- Found old boilerplate from RFC 3979 Section 5 paragraph 2 on
line 395.
-- Found old boilerplate from RFC 3979 Section 5 paragraph 3 on
line 401.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
