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

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Jul 2011 13:20:12 +0300

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Jul 2011 13:39:45 -0500

[as chair]

> 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-conve…

It would be unusual to allow meeting schedules to cause premature 
publication of a document in IESG review. The authors are presently 
working with the IESG to address the issues raised in the ballot. You 
can expect to see a new version once the IESG is satisfied with the 
authors' proposed changes.

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

Thanks for taking the time to review the document. Your input will be 
treated as IETF last call comments.

/a

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Jul 2011 23:44:33 +0300

Thanks, Adam. 

Great to see the progress. Hopefully we have an RFC published soon.

On Jul 13, 2011, at 9:39 PM, Adam Roach wrote:

> It would be unusual to allow meeting schedules to cause premature publication of a document in IESG review. The authors are presently working with the IESG to address the issues raised in the ballot. You can expect to see a new version once the IESG is satisfied with the authors' proposed changes.
> 
> 
> Thanks for taking the time to review the document. Your input will be treated as IETF last call comments.
> 
> /a