[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] FW: Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-01
FYI
>-----Original Message-----
>From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On
>Behalf Of Ben Campbell
>Sent: 08 May, 2009 01:16
>To: hgs+ecrit at cs.columbia.edu; Laura.Liess at t-systems.com;
>Hannes.Tschofenig at gmx.net; barbara.stark at att.com;
>andres.kytt at skype.net; General Area Review Team
>Cc: Cullen Jennings; marc.linsner at cisco.com; ietf at ietf.org
>Subject: Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-01
>
>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.
>
>_______________________________________________
>Ietf mailing list
>Ietf at ietf.org
>https://www.ietf.org/mailman/listinfo/ietf
>