Much of what Richard says I think is okay. But please, please, please don't re-open the can of worms concerning the reference restriction in the ABNF. This issue has been battled to death and I think that the document clearly describes the outcome on which consensus was reached. The text will provide restrictions but the ABNF will not.
Cheers James > -----Original Message----- > From: Richard Barnes [mailto:[EMAIL PROTECTED] > Sent: Saturday, 14 April 2007 1:55 AM > To: [email protected] > Subject: [Sip] Review of draft-ietf-sip-location-conveyance > > Draft: draft-ietf-sip-location-conveyance-07 > Reviewer: Richard Barnes > Review Date: 13 Mar 07 > > > Security / Privacy Concerns: > ------------------------------------------------------------------------ > 1. In the first full paragraph of Section says that if an emergency call > using TLS fails to complete, it MUST be retried without TLS. I don't > think it's the place of the spec to mandate UA behavior in this case; it > should be up to the user to define their urgency/privacy trade-off. > > 2. In general most of section 6 is either out of scope or true in all > contexts (not just emergency services). The only exceptions I note are > the explanatory text at the beginning and the requirement that S/MIME > MUST NOT be used in emergency cases. > > 3. Saying that S/MIME MUST NOT be used for emergency calls rules out > that security mechanism when UA itself has queried a LoST server and > contacts a PSAP directly. Is this intentional? > > 4. In Section 6, in the second to the last paragraph, it basically says > for an emergency call certain policy flags "SHOULD" be set to "yes" and > that if those flags are set to "no" or are not present then they may be > ignored. A GEOPRIV "using protocol" shouldn't dictate that certain > policy flags be ignored for "emergency calls" -- especially since > emergency call marking is still poorly specified. > > 5. On the other hand, if you're going to allow certain policy flags to > be ignored, then shouldn't setting them to "yes" be a "MUST"? When > would an entity legitimately set the policy flags to "no" in a situation > where intermediate entities are allowed to ignore "no" values for these > flags? > > 6. The draft's stance on multiple locations seems to take an absolutist > stance on multiple locations. In particular, Section 3.4.6 allows for > multiple locations to cause a call to fail (which seems dangerous to > me). This seems dangerous in an emergency context. > > > General Comments: > ------------------------------------------------------------------------ > 1. The draft says several times that proxies cannot insert LbyV because > they can't modify bodies. That seems like a small reason to remove a > potentially important use case, and it seems to contradict the fact that > the ABNF in section 3.2 allows for the use of "data:" URIs. > > 2. More generally, the looseness of the criteria for allowable URIs > could also allow for URIs that convey LI outside of a PIDF-LO, either by > reference or by value (e.g., the "geo:" URI defined in > draft-mayrhofer-geo-uri). Perhaps this could be restricted to the usage > "sip:", "sips:", and "pres:" defined by this document, plus any specific > LbyR protocols later defined. > > 3. Likewise, I don't see anything that says that the body part indicated > by a "cid:" URI or returned by a reference MUST be a PIDF-LO (although > this is said throughout). > > 4. Several times, the draft says that it's only describing a "push", but > there are at least two places it defines mechanisms for "pull": The > inclusion of the "geolocation" option tag in a Require header, and the > description of the usage of SIP as a dereferencing protocol. > > 5. The routing-query-allowed element for PIDF-LO is never defined. This > definition would be a better place for a lot of the discussion in > section 5.3 (just in the introduction, not subordinate bullets). > > 6. Several times, the document assumes that content protected with > S/MIME is encrypted, when it could be signed, but otherwise readable. > In most cases where use of S/MIME for encryption causes problems, use of > S/MIME for signing only doesn't, and these cases should be noted. > > 7. Several sections start out by talking about how sensitive location > information is. This repetition should be removed. > > > Localized Comments and Nits: > ------------------------------------------------------------------------ > Section 1, paragraph starting "The Geolocation header is introduced..." > This paragraph should be broken into multiple sentences. > > Section 3.1, paragraph starting "This document creates..." > Missing closing parenthesis after "[RFC2392]". > > Section 3.1, paragraph starting "If a SIP message is routed..." > The requirement that header parameters SHOULD NOT be deleted seems like > it should be a MUST NOT. What's the case where a parameter SHOULD be > deleted? > > Section 3.2, paragraph with ABNF > Since the Geolocation header can hold multiple values, should messages > be forbidden to have multiple Geolocation headers? > > Also, this specification is very permissive about what URIs may be > inserted. Perhaps it should be restricted to SIP, SIPS, PRES, and CID > for now, with a provision for adding more in the future. > > Section 3.2, paragraph starting "The cid-url is defined..." > The meaning of the sentence "This URI MUST be present if location is > by-value in a message" needs to be re-worded or deleted. As I read it, > it would imply that if a message has a PIDF-LO body part (for any > reason), and a Geolocation header, than that header must have a CID URI > pointing to that body part. > > Section 3.2, paragraph starting "Use of the header..." > Use of the header in BYE is stated to be both allowed and undefined. > > Section 3.2, paragraph starting "The Geolocation header MAY be..." > A Geolocation header added by a proxy could specify LbyV, e.g., if it > contained a "data:" URI. > > Section 3.3, paragraph starting "The UAC can use whatever means..." > Need an article before "SIP Intermediary". > > Section 3.4, paragraph starting "To illustrate this..." > Replace "would be in here" with "is" > > Section 3.4.1, paragraph starting "A Warning header ..." > You refer to data-URLs here; it would be useful to have an Informative > reference to RFC 2397. > > Section 3.4.6 > Allowing this response code would seem to encourage UASs to reject calls > with multiple locations. This is obviously dangerous in an emergency > setting. Also, it seems odd to include this in a 424 message that goes > back to the UAC, since there may not be anything he can do about it > (e.g., if a proxy is adding conflicting location information). > > Section 3.5, paragraph starting "A UAC SHOULD NOT include..." > Need to define what the semantic would be when included. Is it > requesting that a proxy insert a Geolocation header? > > Section 5, paragraph starting "Because a person's location..." > Location in general is considered sensitive (not just people), and the > protocol is designed to describe more than people. > > Section 5, paragraph starting "A PIDF includes identity information..." > I don't really see the value of anonymizing the location in this case, > since it's already contained in a SIP message that has identifying > information. > > Section 5, paragraph starting "Self-signed certificates..." > This paragraph is out of scope. It's general PIDF/GEOPRIV concern. > > Section 5.3, paragraph starting "Proxies that perform..." > Need some text before the colon at the end of the paragraph, e.g., > "fields in a PIDF-LO document". With regard to the table, would it be > simpler just to say that the routing-query-allowed attribute supercedes > the retransmission-allowed element? > > Section 6, bullet number 2 > Remove "s/he", reword. > > Section 6, paragraph starting "While many jurisdictions..." > This should say that many jurisdictions "require" a user to reveal a > location. It seems out of scope to mandate the configurability of > positioning mechanisms. > > Section 7, paragraph starting "Transmitting location information..." > Remove the word "Transmitting". Remove the word "tracking" from > "eavesdropping, tracking, and alteration". Replace "any protocol > wishing to be considered a GEOPRIV \"using protocol\"" with "a GEOPRIV > using protocol". Changes "transport protocol meetings" to "transport > protocol meets". I would remove the quotes from RFC 3693, and just cite > the requirement numbers. > > Section 8, paragraph starting "Conveyance of physical location..." > Insert "the" before "physical location" in the first sentence. In the > second sentence, change "session set-up" to "SIP request" and strike > "initiating the session or SIP MESSAGE". Also in the second sentence, > it should be made clear that only location-based routing is only screwed > up by S/MIME encryption, not other protections. In the third sentence, > I would add "(except by proxies)" after "eavesdropping and modification". > > Section 8, paragraph starting "When the UAC is the source ..." > Change the beginning of the first sentence to "When location is inserted > by a UAC". What, exactly is being RECOMMENDED here? Should that clause > be struck? > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
