Comments regarding draft-ietf-sip-location-conveyance-05.txt

Hi Brian,
Hi James,

I have reviewed the document.

First, I would like to thank you for improving the document. But, I 
still have a few comments:

Questions:


You write:
"

    A dereference of a location-by-reference URI using SUBSCRIBE is not
    violating a PIDF-LO 'retransmission-allowed' element value set to
    'no', as the NOTIFY is the only message in this multi-message series
    of transactions that contains the UAC's location, with the location
    recipient being the only SIP element to receive location - which the
    purpose of this extension: to convey location to a specific
    destination.
"

I wasn't quite sure what you are about to say with this statement. If the

Location Recipient receives a reference and it resolves it then you are

saying that this is OK even if the retransmission-allowed flag says "no".

Correct?


Technical Aspects:

* Proxy Usage

When a proxy adds a reference to a PIDF-LO then a number of issues remain

unclear (as discussed throughout the Geopriv work), namely:

   - What does the PIDF-LO contain that is created by the SIP proxy?


* How does the proxy know that location information has to be added?

   - There is a privacy problem if the SIP proxy acts without explicit

indication that location information is added.


* Using Protocol

You write:
"
    Other protocols used in the Location URI MUST be reviewed against
    the RFC3693 criteria for a using protocol.
"

Later, in Section 3.6 you write:
"
Use of other protocols for dereferencing
    of a pres: URI is not defined, and such use is subject to review
    against RFC3693 using protocol criteria.
"

I disagree that the protocol used to resolve the reference has to be a 
using

protocol. Hence, I suggest to delete this sentence.


* Privacy Rules

You write:
"
    Entities receiving location information MUST honor the usage element
    rules per RFC4119.  Such entities MUST NOT alter the rule set.
"

The last sentence is not correct. Let me give you an example: A SIP UAC

obtains location information from GPS and uses a PUBLISH to upload the

PIDF-LO to the Location Server/ Presense Server. This server has rules that

control access to location information. As part of these rules the content

of the Location Object including the rules might be modified.


* The examples pick unfortunate references 
(sips:server5.atlanta.example.com/alice123)
that give me the impression that the reference contains the user identity.
The document clearly needs to point out that this is not the case. The 
document also does not indicate

that the reference is only kept for a certain period of time (soft-state).
The document does not even mention security aspects when retrieving the

reference.


* Security in Section 5 SIP Element Behavior

I am confused with the text in Section 5. What MUST and what SHOULD be used

when protecting a location-by-value and a location-by-reference?

SHOULD for TLS usage with location-by-value and location-by-reference.
No statement about usage of S/MIME.

I wonder why self-signed certificates shouldn't be used as stated with:
"
    Self-signed certificates SHOULD NOT be used for protecting PIDF,
    as the sender does not have a secure identity of the recipient.
"
For encryption (and that's what we are talking about here) it heavily

depends on the way how the self-signed certificate was obtained. I might

share my certificate with you and hence that's an extemely useful way todo

compared to the usage of TLS in a hop-by-hop way where a number of entities

see my location along the path.

Identity info in the PIDF. In previous discussion I was wondering and 
asking

the Geopriv group whether there is some semantic associated with the

identity in the PIDF. If there is, then you cannot put anything you like

into the PIDF. If there isn't then why should we ever want to put something

meaningful in there since it greatly impacts the privacy risks.

I see a problem with retargeting and forking where the Location 
Recipient is actually not know ahead of time and S/MIME usage is 
actually not really feasible. Would some guidance be useful?

* Section 7.

The document refers to 'using protocols' for both the UAC <-> UAS and to 
the dereferencing protocol. I assume that Section 7 only addresses the 
UAC <-> UAS communication. Since I am in favor of not treating the 
derefencing protocol a 'using protocol' I am fine with it.

Actually, I would prefer to move Section 7 into the appendix since this 
is just such an artifical story that it makes me nervous. It is not your 
fault; it is just the way how RFC 3693 was written.

* The security consideration section isn't particularly good. If I have 
time I rewrite it.



Editorial Aspects:

The term 'Location' is written with a capital letter (see for example first

paragraph in Section 1) whereas other RFC3693 terms that are meant to be

written with a capital letter aren't (example: 'target', 'location object',

'using protocol', 'location recipient'). I suggest to stick with RFC3693.


"
    This document describes how Location can be "conveyed" (that is,
    sent on the Internet) from a SIP user agent, or in some
    circumstances a proxy server acting on behalf of a user agent, to
    another entity using the SIP [RFC3261] protocol.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^

"

Either write using SIP [..] or using the Session Initiation Protocol [...].


I suggest to rewrite the following paragraph from:

"
    As recited in RFC3693, location often must be kept private.  The
    location object (PIDF-LO) contains rules which are binding on the
    location recipient and controls onward distribution and retention of
    the location.  This document describes the security and privacy
    considerations that must be applied to location conveyed with SIP.

"

to:

"
    The
    Location Object contains rules which provide guidance for the Location

Recipient on the onward distribution and retention of
    the received location information.  This document describes the 
security

and privacy
    considerations that must be applied to location conveyed with SIP.
"


I don't know what this sentence should mean in Section 1 at this part of 
the

section.
"
Often, location is sent from the User Agent Client to the User Agent
    Server, or vice versa for purposes that are beyond the scope of this
    document.
"

There seems to be a copy-and-paste problem.


You write:

"
    The Geolocation header is introduced to signify that location is
    included in a SIP message to provide either a content identifier
    (cid:) pointer to the body part containing the UAs PIDF-LO, or a
    location-by-reference URI that may subsequently be "dereferenced" by
    a using protocol (which may be SIP or another protocol).
"

Please delete the following part " by
    a using protocol (which may be SIP or another protocol)" since we 
haven't

concluded in our discussion that the dereferencing protocol is indeed a

using protocol.

Actually, I think that the entire paragraph is not particularly useful in

the introduction and the subsequent paragraph fits much better to the

previous one.


You write:
"
The Geolocation header MUST contain one two types of URIs:
                                     ^^^^^^^^^^^^
                                     one of two types
"


The example contains a company name

(<gp:provided-by>www.cisco.com</gp:provided-by>) although it should,

according to the guidelines something like "www.example.com".


Section 4.3 uses the term 'LIS' and does not mention what it is.
Just avoid it.


IDNITS:

   Experimental warnings:
   - Missing Reference: 'RFC3851' is mentioned on line 343, but not defined
     'resulting resolution, per [RFC3851], resolves to a sip: or sips:...'

   - Unused Reference: 'ID-Loc-Reg' is defined on line 891, but not

referenced
     '[ID-Loc-Reg]...'


   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
   - It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 26 pages


tmp/draft-ietf-sip-location-conveyance-05.txt(294): Line has weird spacing:

'...     Rr    ar ...'
tmp/draft-ietf-sip-location-conveyance-05.txt(298): Line has weird spacing:

'...     Rr    ar ...'



Ciao
Hannes

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip