Location Conveyance for the Session Initiation Protocol
draft-ietf-sipcore-location-conveyance-09

[Ballot comment]
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.

[Ballot comment]
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])".

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
(1) I don't understand the privacy model for the case where a UA
does not support this (or has turned it off) and the outbound proxy
adds this header. How is the poor end user supposed to know what
is happening in this case? What if a user specifically wants to use
a UA that doesn't send her location (or have it added) - how could
that be supported?

(2) 4.1 says that SIP intermediaries "are not to view" location
information.  Why can't that be written with a MUST of some sort?
It seems very weak at present. (The same "not to view" is repeated
a few times later.) I don't understand what "viewing" means for
a piece of software.

(3) cleared

(4) If a UA or intermediary inserts a Geolocation or
Geolocation-Routing header field, I assume that doesn't get
deleted later.  So nothing prevents this information "leaking" out
beyond the domain/operator who set the field. That means all
operators are trusting all operators further down the signalling
path with all users location information.  Should there be
something about deleting these fields at some stage in path? Did
the WG consider this aspect?

(5) There is a MUST for conforming to rfc 3693 that says that you
have to follow the rules for retention and re-transmission. A quick
look at 3693 seems to imply that that document does not set out
rules with which one could conform, but only says those must exist.
Am I right there?  If so, then where do I go (as an implementer) to
find out how to handle retention and re-transmission?

[Ballot comment]
(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/ ?

[Ballot discuss]
(1) I don't understand the privacy model for the case where a UA
does not support this (or has turned it off) and the outbound proxy
adds this header. How is the poor end user supposed to know what
is happening in this case? What if a user specifically wants to use
a UA that doesn't send her location (or have it added) - how could
that be supported?

(2) 4.1 says that SIP intermediaries "are not to view" location
information.  Why can't that be written with a MUST of some sort?
It seems very weak at present. (The same "not to view" is repeated
a few times later.) I don't understand what "viewing" means for
a piece of software.

(3) in 4.1 there are a lot (7) of choices for locationURI and each
seems to be very generic, e.g.  http-URI is one choice. Are those
all MUST supports? If not then which is/are mandatory to
implement? Not specifying this seems likely to lead to interop
problems.

(4) If a UA or intermediary inserts a Geolocation or
Geolocation-Routing header field, I assume that doesn't get
deleted later.  So nothing prevents this information "leaking" out
beyond the domain/operator who set the field. That means all
operators are trusting all operators further down the signalling
path with all users location information.  Should there be
something about deleting these fields at some stage in path? Did
the WG consider this aspect?

(5) There is a MUST for conforming to rfc 3693 that says that you
have to follow the rules for retention and re-transmission. A quick
look at 3693 seems to imply that that document does not set out
rules with which one could conform, but only says those must exist.
Am I right there?  If so, then where do I go (as an implementer) to
find out how to handle retention and re-transmission?

IANA understands that, upon approval of this document, there are seven
IANA actions which need to be completed.

First, in the Header Fields registry in the Session Initiation Protocol
(SIP) Parameters located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Header Name: Geolocation
Compact:
Reference: [ RFC-to-be ]

Second, also in the Header Fields registry in the Session Initiation
Protocol (SIP) Parameters located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Header Name: Geolocation-Routing
Compact:
Reference: [ RFC-to-be ]

Third in the Option Tags registry in the Session Initiation Protocol
(SIP) Parameters located at:

http://www.iana.org/assignments/sip-parameters

two new registrations will be made as follows:

Name Description Reference
----------- ------------------------------------------ ---------
geolocation-sip The "geolocation-sip" option tag signals [RFC-to-be]
support for acquiring location information
via the presence event package of SIP
(RFC 3856). A location recipient who
supports this option can send a SUBSCRIBE
request and parse a resulting NOTIFY
containing a PIDF-LO object. The URI
schemes supported by this option include
"sip", "sips" and "pres".

geolocation-http The "geolocation-http" option tag signals [RFC-to-be]
support for acquiring location information
via an HTTP ([RFC2616]). A location
recipient who supports this option can
request location with an HTTP GET and
parse a resulting 200 response containing
a PIDF-LO object. The URI schemes
supported by this option include "http"
and "https".

Fourth, in the Response Codes in the Session Initiation Protocol (SIP)
Parameters located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Response Code Reference
------------------------------------------ ---------
Request Failure 4xx
424 Bad Location Information [ RFC-to-be ]

Fifth, in the Header Fields registry in the Session Initiation Protocol
(SIP) Parameters located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Header Name: Geolocation-Error
Compact:
Reference: [ RFC-to-be ]

Sixth, in the Header Field Parameters and Parameter Values in the
Session Initiation Protocol (SIP) Parameters located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Predefined
Header Field Parameter Name Values Reference
----------------- ------------------- ---------- ---------
Geolocation-Error code yes [ RFC-to-be ]

Seventh, this document creates an entirely new registry in the Session
Initiation Protocol (SIP) Parameters located at:

http://www.iana.org/assignments/sip-parameters

The registry name is "Geolocation-Error Codes." Geolocation-Error codes
provide reason for the error discovered by Location Recipients,
categorized by action to be taken by error recipient. The rule for new
registrations in this new registry is IETF Specification required. The
initial values for this registry are shown as follows:

Registry Name: Geolocation-Error Codes
Reference: [ RFC-to-be ]
Registration Procedures: Specification Required

Code Default Reason Phrase Reference
---- --------------------------------------------------- ---------
100 "Cannot Process Location" [ RFC-to-be ]
200 "Permission To Use Location Information" [ RFC-to-be ]
201 "Permission To Retransmit Location Information to a Third Party"
[ RFC-to-be ]
202 "Permission to Route based on Location Information" [ RFC-to-be ]
300 "Dereference Failure" [ RFC-to-be ]

IANA understands that these seven IANA Actions are the only ones
required to be completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Location Conveyance for the Session Initiation Protocol) to Proposed Standard


The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Location Conveyance for the Session Initiation Protocol'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity.  The SIP extension covers
end-to-end conveyance as well as location-based routing, where SIP
intermediaries make routing decisions based upon the location of the
Location Target.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/


No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?


Adam Roach is the document shepherd for this document. He has
reviewed the document and believes it is ready for publication,
with one minor editorial reservation.

The following text, from page 15, paragraph 5, may be somewhat more
informal than expected in a protocol specification:

    There is no guidance given in this document as to which
    locationValue, when more than one was present in the SIP request,
    is related to the Geolocation-Error code; meaning that, somehow
    not defined here, the LR just picks one to error.

The shepherd suggests replacing it with more formal language
containing identical meaning, such as:

    When more than one locationValue is present in a SIP request,
    this mechanism provides no indication which one the Geolocation-
    Error code corresponds to. If multiple errors are present, the
    LR applies local policy to select one.


  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?


Discussions on the mechanism in the document have generated over
350 messages since its transfer into SIPCORE. More than 250 of these
were discussing the "new" version of the document, after a substantial
reworking for simplicity. (See 1.e, below)

Input from participants of the GEOPRIV working group was solicited
throughout the development of the document, and significant discussion
of the mechanism within the GEOPRIV working group (over 80 messages
on the GEOPRIV mailing list) were incorporated into the document.

Finally, the document underwent a period of intense scrutiny in
February of this year, during which several SIPCORE participants
attended weekly conference calls to finalize the remaining open
issues associated with the document.

The final SIPCORE working group last call generated three very
in-depth reviews of the document.

Given the relative simplicity of the mechanism, this level of review
seems more than adequate. The shepherd has no concerns about either
depth or breadth of the reviews.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?


The shepherd has no such concerns.


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.


There are no such concerns or issues.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?


The initial work for the location-conveyance document began in the
SIP working group back in 2005 (with roots stretching back to
requirements discussions in the SIPCORE working group as early as
mid-2003).

The document underwent many years of development and refinement
from 2005 to 2010, accumulating a number of mechanisms to accommodate
several sets of requirements relating to geolocation conveyance.
In early 2010, the working group took on the task of simplifying
the mechanism (and consequently the document) to reflect a more
recent understanding of the actual requirements.

During the development of the document, many IETF participants
offered comments, including several who do not typically participate
in the SIP and SIPCORE working groups.

Based on this history, and based on the detailed reviews performed
on the simplified mechanism, the shepherd believes that the document
has significant support within not just the SIPCORE working group
(and its antecedents), but within the IETF real-time communications
community as a whole.


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)


Although the aforementioned decision to simplify the document and
the mechanism it describes was met with initial skepticism by some
parties, no participants have objected strenuously, nor have any
appeals been threatened.


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?


The document has been verified to satisfy all ID nits. The automated
nits checker tool identifies the copyright notice as potentially
incorrect, although it is in error in doing so. This document contains
text from before November 10, 2008; so the copyright notice is correct.

The shepherd has not identified any formal external reviews as
necessary at this time. Since the document deals with location
information, an initial SIPCORE working group last call in 2009 was
copied to the GEOPRIV working group mailing list. Followup was
requested to the SIPCORE mailing list, so it is not possible to
directly gauge how many WGLC reviews were the result of this posting.
The shepherd notes that at least one detailed set of comments was
posted to the GEOPRIV mailing list in response to this WGLC, along
with another message indicating that the poster had reviewed the
draft in detail and concurred with the previous comments.


  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].


References are split into normative and informative. No downrefs
are present.


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?


The IANA considerations section registers a number of new values
in existing, clearly-defined registries, and adds a new registry
(including its initial contents and registration policy).


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?


The ABNF definitions in sections 4.1, 4.2, and 4.4 have been validated
using the tool at
http://www.apps.ietf.org/content/chris-newmans-abnf-validator.  All
undefined rules reported by that tool are external to the document,
and the document clearly cites the origin documents for these rules.


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

      Technical Summary
        This document defines an extension to the Session Initiation
        Protocol (SIP) to convey geographic location information
        from one SIP entity to another SIP entity.  The SIP extension
        covers end-to-end conveyance as well as location-based
        routing, where SIP intermediaries make routing decisions
        based upon the location of the Location Target.

      Working Group Summary
        This work began in the (now concluded) SIPPING working group
        back in 2003, and progressed through the (also concluded)
        SIP working group before being finalized in the SIPCORE
        working group. The protocol mechanism underwent significant
        simplification in early 2010 to reflect a better understanding
        of the core requirements underpinning the work. Although
        this simplification was initially controversial, the working
        group did manage to achieve a rather strong consensus around
        the new mechanism after some additional changes.

      Document Quality
        This protocol mechanism is described in the 3GPP document
        24.229 as a component of certain emergency calling scenarios
        in IMS-based networks. It was developed in the SIP and
        SIPCORE working groups with input from GEOPRIV working group
        participants.