Skip to main content

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