[sipcore] draft-ietf-sipcore-location-conveyance ?

[Hannes Tschofenig <[e-mail]>]

Hi guys, 

what is the status of draft-ietf-sipcore-location-conveyance? It is fairly close to completion, I guess. 
I did not see a new version submitted for this submission deadline and there are still a few remarks from the IESG to address, see https://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/ballot/

I read through the document and here are my review comments: 

1.  I suggest to delete this sentence: "SIP acts as a Using Protocol
  of location information, as defined in 
RFC 3693."

2. this sentence is difficult to parse (at least for me) - maybe restructuring would help.
"
  In order to convey location information, this document specifies
  three new SIP header fields, Geolocation, Geolocation-Routing and
  Geolocation-Error, which carry a reference to a Location Object
  (LO), grant permission to route a SIP request based on the
  location-value and provide error notifications specific to location
  errors respectively.
"

3. I suggest to have a brief look at the Geopriv Arch document 
http://www.rfc-editor.org/authors/rfc6280.txt
and then to see what modifications are need for this paragraph from the draft: 
"
  A Target is an entity whose location is being conveyed, per RFC 3693
. Thus, a Target could be a SIP user agent (UA), some other IP
  device (a router or a PC) that does not have a SIP stack, a non-IP
  device (a person or a black phone) or even a non-communications
  device (a building or store front). In no way does this document
  assume that the SIP user agent client which sends a request
  containing a location object is necessarily the Target. The location
  of a Target conveyed within SIP typically corresponds to that of a
  device controlled by the Target, for example, a mobile phone, but
  such devices can be separated from their owners, and moreover, in
  some cases the user agent may not know its own location.
"
4. Why aren't GEO URIs not appropriate?

  GEO-URIs [RFC5870] are not appropriate for usage in the SIP

5. What does this really mean?

  Other URI schemas used in the location URI MUST be reviewed against
  the 
RFC 3693 [RFC3693] criteria for a Using Protocol.

6. In what cases are intermediaries allowed to modify or delete locationValues?

  SIP intermediaries SHOULD NOT modify or delete any existing
  locationValue(s).

7. Editorial: The RFC Editor will insist on this. 

Instead of "section X" write "Section X".

8. The Geopriv Privacy Considerations are more or less nonsense. 

I suggest to reference the Geopriv Architecture doc instead of RFC3693. 

While the text in the section says: 

"
[ID-GEO-ARCH] updates
  the guidance in RFC3693
to include subsequently-introduced
  entities and concepts in the geolocation architecture.
"

It does not even provide a brief summary of the privacy threat model or the proposed countermeasures. 
I would omit it and instead point to the Geopriv architecture document. 

Ciao
Hannes