RE: [Geopriv] Comments regardingdraft-ietf-sip-location-conveyance-05.txt

Thanks for your detailed review comments.  My views are inline.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email protected]]
> Sent: Tuesday, November 21, 2006 6:06 AM
> To: IETF SIP List; GEOPRIV
> Subject: [Geopriv] Comments regardingdraft-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?
Yes, correct.  In fact if 3 proxies on the path sequentially resolve the
reference when retransmission-allowed='no' that is okay.  However, none of
those proxies may retransmit the location.

> 
> 
> 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?
First of all, you are making an assumption that the proxy creates the value
returned by the reference it adds.  That is not likely the case.  It's more
likely that the proxy has access to a LIS which supplies it the reference to
include.

I think the reference resolves to the same PIDF-LO that the LIS would have
given the endpoint.  If indeed the proxy actually is the dereference agent,
then it would return a PIDF-LO that would look exactly like a LIS would
provide.  I'm expecting such a PIDF-LO would have very few of the fields
defined in PIDF.  For example, a "Contact" is unlikely to be present.  Most
importantly, I think the proxy, like the LIS, has to include a ruleset that
conforms to the preferences of the target.

I'm not sure that there needs to be any text in conveyance that says that.
> 
> 
> * 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.
The use case we know about is the emergency case, where location is not
provided by the endpoint and the proxy knows where the endpoint is.  The
only circumstance that is likely to be true is where the SIP network and the
access network are the same domain, or they have pre-established
relationship, and a way of correlating identifiers such that the SIP network
can get the correct location (or reference).

Here, perhaps we need text that explains this.  I had expected this would
appear in ecrit-framework, but I'm not sure now that it's a good idea to
limit proxy add of location to the emergency case.

I do think we get into pretty serious sticky wickets with what we can say
for the non-emergency case.  I would expect we have to say that the proxy
has explicit permission, and a ruleset by the target for the location it is
adding, but that doesn't really express the wishes of the target of WHEN it
is okay to add location.

> 
> 
> * 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.
Well, perhaps this should be discussed in the LbyR design team.  Certainly,
the location value is carried in the protocol.  I don't understand how it
could not be viewed as a using protocol.

> 
> 
> * 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.
While I can imagine a way to express a rule that modifies the ruleset, I
don't think we have ever discussed that kind of rule.  If we allow such
things that we need some pretty convoluted language.  If you want such a
capability, then please propose wording that permits a rule to modify a rule
set, but doesn't allow an arbitrary modification of the ruleset and show me
some other place where we have used that language.  This has to be the same
as, for example, presence.
 
> 
> 
> * 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
I think this is a good point and we should modify the example text.

> 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.
The notion of a time limited reference is specific to the scheme.  It was
proposed in Henning (et al)'s SIP based LCP for example, but not in all LbyR
mechanisms.  I don't know if -conveyance is the right place to discuss that
issue.

We don't have any mechanism that discusses how long any element should keep
a reference, regardless of whether the dereference mechanism has an
expiration.  Another LbyR design team topic?

I'd prefer that -conveyance not be the place that defines such things.

> 
> 
> * 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.
Yeah, we should clean up the language here.  I think both.

> No statement about usage of S/MIME.
Right.  Need some text that S/MIME SHOULD be used to protect a value or
reference if the intention is that the only element that should get it is
the opposite UA.

> 
> 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.
Perhaps you would send some text to cover this case.  I tried a couple of
ways and didn't think my attempts made any sense.

> 
> 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 don't understand this.  If it's LbyV and the endpoint puts it in, then it
controls the identity, and it CAN put anything it wants to.

In a case of LbyR, then the LIS, or whomever is constructing the PIDF needs
a mechanism to allow the target to specify a ruleset, and probably needs to
allow it to specify the identity as well.

> 
> 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?
Not sure I know what you mean.  I've long considered the problem that the
hop by hop mechanism allows any proxy on the path to see location, but it
also allows the opposite UA to see it.  There isn't a way to say "I trust
the proxies, but I don't trust the endpoint".  On the other hand,
retarget/fork may be precisely the reason S/MIME can't be used, and TLS is
very appropriate.

I do think at least mentioning the issue here is warranted.  I don't see
need for more mechanism.

> 
> * 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.
See above; I fail to see how the dereference can possibly avoid being a
using protocol.

> 
> * The security consideration section isn't particularly good. If I have
> time I rewrite it.
Suggestions are welcome.  Send text, or at least talking points.

> 
> 
> 
> 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.
Good point.  We'll fix this.

> 
> 
> "
>     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
> [...].
Okay

> 
> 
> 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 understand your objection to the text as written.  Are you objecting
to the reference to 3693, the explicit mention of PIDF-LO, the word
"binding" or something else?

> 
> 
> 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.
We'll look at it

> 
> 
> 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.
See above

> 
> 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
> "
OK

> 
> 
> 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".
OK

> 
> 
> Section 4.3 uses the term 'LIS' and does not mention what it is.
> Just avoid it.
Hmmm.  We really do have to agree on terminology, no question.  The notion
that LIS is not acceptable is very disconcerting.  Outside of IETF, LIS is a
well understood term.  Location Generator is not. 

> 
> 
> 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]...'
Will fix

> 
> 
>    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
Hmmm, tool problem.  James uses the Word template.

> 
> 
> 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 ...'
OK



_______________________________________________
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