Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-09
Yes
(Robert Sparks)
No Objection
(Adrian Farrel)
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 09 and is now closed.
Robert Sparks Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2011-06-21)
Unknown
1. I think that the usage of the term 'SIP modifications' in the title and first paragraph of section 4 is too strong for what this document does. Modifications to SIP would imply updating some previous documents. I suggest replacing 'modifications' by 'extensions'. 2. section 4.1: The Geolocation header field can have one or more locationValues. A Geolocation header field MUST have at least one locationValue. The first sentence seems to have been made redundant by the second. 3. Any locationValue MUST be related to the original Target. This is equally true the location information in a SIP response, i.e., from a SIP intermediary back to the Target as explained in Section 3.4. Something is missing in the second sentence (maybe 'true FOR the location information ...) 4. The text string are OPTIONAL, fix grammar 5. Unless there is a specific reason here it would be better to order the RFCs in the references sections according to the RFC numbers.
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2011-06-19)
Unknown
I don't expect any of these to turn into "DISCUSS" comments, but I'd like some explanation to get my head around them: - Section 3 (or something similar to it) seems to be something I've seen before in other documents, though I can't figure out where it is I've seen it. Is this information that can be referenced from somewhere else? - Section 4.2 says: The Geolocation-Routing header field satisfies the recommendations made in section 3.5 of RFC 5606 [RFC5606] regarding indication of permission to use location-based routing in SIP. My reading of 5606 3.5 is that the indication of "permission" is basically an optimization: That is, it is an indication that using the location is likely to fail and ought be avoided. But 4.2 reads differently, making it out to be some sort of access control mechanism (without any enforcement): ...when the Geolocation-Routing header-value is set to "no", if a cid:url is present in the SIP request, intermediaries SHOULD NOT view the location (because it is not for intermediaries to view), and if a location URI is present, intermediaries SHOULD NOT dereference it. I'm left wondering what the downside is if an intermediary does view or dereference a location when you've got a "Geolocation-Routing: no". Why is it that the intermediary SHOULD NOT do these things? - Sections 4.3. It seems inevitable that 424's will leak back to the originating UA even when the location was inserted by an intermediary (because there will be a badly behaved intermediary that doesn't handle a 424). Should there be any instruction about how a UA should handle (ignore?) a 424 even when it hasn't included location info? - Section 4.4. Is "permission reset" an understood term in SIP-land? It wasn't clear to me (though I could guess) how the term "reset" was being used in this context.
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2011-06-21)
Unknown
This is a fine document. I have a few small comments and questions. Section 4.1 says "GEO-URIs [RFC5870] are not appropriate for usage in the SIP Geolocation header." It would be good to explain why not. Section 4.1 says "SIP intermediaries SHOULD NOT modify or delete any existing locationValue(s)." As we know, "SHOULD NOT" is functionally equivalent to "MUST NOT unless you have a really good reason"; what is the really good reason here? In Section 4.3, please add a reference for PIDF-LO (presumably RFC 4119). Such a reference exists in Section 4.4, but Section 4.3 contains the first mention of PIDF-LO. Sections 4.6 and 8.3 both have "via an HTTP ([RFC2616])" instead of, presumably, "via HTTP ([RFC2616])" or "via an HTTP URI ([RFC2616])".
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-06-22)
Unknown
Please consider the editorial comments from the Gen-ART Review by Pete McCann on 17-Jun-2011.
Sean Turner Former IESG member
No Objection
No Objection
(2011-06-23)
Unknown
I had many of the same concerns Stephen did. But, I see in the emails exchanged between the authors and Stephen that it all seems to be worked/ing out. I'll support Stephen's discuss, but I'll assume you'll fix the draft up as you've noted in the emails.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2011-06-17)
Unknown
(1) Last para of section 3 - SIP intermediaries don't receive diagrams, probably needs a rephrase. (2) 3.1: Can Bob use the error code to get Alice to progressively give him more location information? If Alice's LO is "fuzzed" then each iteration might expose more precise information to Bob. If that's likely or possible, it probably deserves a mention in the security considerations. I'd suggest that Alice SHOULD include some kind of limit for repeatedly sending an LO in a short period, if she is fuzzing or similar. (Or maybe even generally - is there ever a real reason to iterate on this 10 times in a few minutes?) (3) Same as (3) but for section 3.2 - should the LS have some controls on how often Bob (or anyone) can de-reference the URI? (4) Are there a set of rules specified somewhere as to what is required of an LR? The repeated refereences to what is or is not an LR sort of implies there is, but rfc 3693 doesn't seem to contain that. If there are such rules specified somewhere then please add a reference. (5) 3.3, 1st para, could do with a bit more explaination of the location based routing case (maybe just as a forward reference or an example). The current text doesn't make it clear who'd be routing what for whom based on the LO. (6) I don't understand why GEO-URIs are not appropriate for use here - a sentence explaining why seems warranted. (7) What is a RuleMaker and where is that defined? I assume it means something like a telcoms regulator. (8) It seems odd to have a MUST not just for rfc 3693 but also for its "updates and successors" - how do you know that that'll be possible? (9) It seems odd that appendix A presents requirements but is not referenced in the text of the document at all. What is the status of this? Partly it looks like historic information that the WG used, but nothing says that. (10) UAC-7 s/must be met/MUST be met/ ?
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown