Subject: [Geopriv] draft-ietf-sip-location-conveyance-13: WGLC comments

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 21 Mar 2009 21:04:59 +0200

I read through
http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-13. 
I have concerning the current version of the document. 

Here are my high-level comments. Detailed comments on paper available for
the authors. 

* The draft comes up with new terminology even though we have these terms
already defined in other documents. This is bad (tm). 
Cite terms (a common and preferred procedure) or copy the text exactly (and
quote it) rather than defining your own. Useless and as we saw in recent
discussions is rather harmful. 

* The document repeats stuff over and over again. Gives the reader the
impression that this is rocket science. Could be significantly shorter. 

* The draft has to avoid the term "using protocol" at all costs. As we know,
this term is very confusing. 

Example:    Other protocols used in the Location URI MUST be reviewed
against
   the RFC 3693 criteria for a Using Protocol.

In human readable language this means: You have to consider security and
privacy with new extensions.

* Don't understand why this document does not allow a HELD URI to be
conveyed. I commented this already several times and got ignored. 

See Section 4.5. Having an IANA registry appears to be totally crazy to me.
Even saying that the protocols are mandatory to implement is also not a good
idea. I really wonder why this is useful given that the recipient then just
cannot fetch location when it receives something that it does not
understand. What is the big deal with that? 

* Is "routing-allowed" policy really useful and, if so, does it need to be
in the SIP header rather than in the PIDF-LO where all the other policies
are? 

The problem is, again (also mentioned several times), with the lack of
description of the recipient is for a PIDF-LO with respect to the
'retransmission-allowed' policy. For example, in a location application
where the message is directed towards a Service URN the intended behavior is
that there is some form of location based routing involved. 

* This document is about the transport of a PIDF-LO and not about deployment
considerations.

Example: 
"
   Adding a new locationValue to an in-transit request SHOULD NOT
   occur for at least two reasons,

   #1 - SIP Servers are not the best Sighters, as defined by [RFC3693],
        of geographically where a UAC can be; meaning the location
        information is not necessarily the greatest.  There MAY be
        exceptions, but this SHOULD be the rule of thumb.

   #2 - without appropriate caution to the fact that Location
        Recipients might not understand how to process more than one
        location, given this document's limited guidance as to what a
        Location Recipient should do when receiving more than one
        location  (i.e., currently no priority instructions are given
        for which locationValue to use if there are more than one).  A
        Location Recipient can easily be confused by too much location
        information, producing undesirable results.  The <tuple id>
        element in the PIDF-LO XML indicates whose location is
        contained in the PIDF-LO.
"

This example also shows inappropriate usage of RFC2119 language which should
be used for interoperability rather than philosophical stuff. 

We know who wants some of this functionality and what the exact use case it.

* The location-based error codes (100, 200, 300, 400, 500 on page 14ff) are
extremly fuzzy. They clearly lack implementation experience (as the text
continuesly repeats by saying "for future work") and I believe they should
be removed and incorporated in a future version when more implementation
experience is available. 

* " S/MIME can be used for just signing, and not encrypting, a
   PIDF-LO message body to ensure the integrity of the PIDF-LO is
   maintained."

  I am not sure what this means. S/MIME cannot only be used for signing. 

"
   Use of self-signed certificates is inappropriate for use in
   protecting a PIDF, as the sender does not have a secure identity of
   the recipient.
" 

 This sentence does not make a lot of sense to me. 

* This document does not need to repeat the text from other documents.
Example: 
   " 
   When using LbyR, the LbyR MUST NOT contain any
   user identifying information. For example, use something
   unidentifiable like
   " 

  Already in the LbyR requirements document. Reference it -- no need to
write new text. 

   Other examples can be found with the description how
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-03.txt
works. 

* "
If the Location Generator wishes to control whether any location
   included in the SIP request or added along the signaling path of
   this request can be viewed for routing decisions, the Location
   Generator adds a Geolocation header value including the
   "routing-allowed=no" parameter.
" 

The Rule Maker controls, not the LG. 

* Remote useless statements. Example:  
  "
   Unless stated otherwise by future standards-track publication(s), a
   LbyR URI only has meaning within the Geolocation header field and
   MUST NOT appear in any other SIP header field.
  " 

* Avoid author bias.

"Proxies inserting location for location-based routing are
   unable to meet this requirement, and such use is NOT RECOMMENDED."

The document defines functionality to allow the proxy to add location and we
know who is going to use this. 

* Avoid inappropriate treatment of subjects that are discussed somewhere
else.

"
   One facet within this extension is such that locations can be placed
   on a remote server, accessible with the possession of a URI.  The
   concept of an LbyR URI has its own security considerations.  It is
   tempting to assume that the dereference would have authentication,
   authorization and other security mechanisms that limit the access to
   information.  Unfortunately, this might not be true.  The access
   network the UAC is connected to can be the source of location
   reference, and it might not have any credentialing mechanism
   suitable for controlling access to location.  Consider,
   specifically, a nomadic user connected to an access network in a
   hotel.  The UAC has no way to provide a credential acceptable to
   the hotel Location Server (LS) to any of its intended Location
   Recipients.  The recipient of a reference does not know if a
   reference has appropriate authorization policies or not.  The LS
   should provide location to any requestor.
"

The LbyR can have policies attached to it, if needed. We have worked on
solutions to get this to work. 
If in a particular scenario policies cannot be uploaded to, for example, a
LIS then put the reference somewhere else where you have the policies. 

* S/MIME example in the appendix isn't useful as it is currently put in
there. Everybody knows that S/MIME allows you to encrypt a MIME body. So, if
you want to put it in there then encrypt the stuff and attach the keys so
that other folks can decrypt it. 

Ciao
Hannes

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Mar 2009 17:35:30 +0100

(As SIP WG chair)

Two points:

1)	This is a SIP WG document and a SIP WGLC. If you post the comments on the geopriv list, then they are not going to be addressed. So if you want them addressed, please post them to the appropriate list.

2)	This net effect of this set of comments makes some really fundamental changes to the draft now being progressed. The draft has already had one working group last call. So I am going to make a ruling that if the technical solution being commented on was already present in the document in the first WGLC, then I am raising the consensus barrier for adoption of a change of that technical solution very very high. Additionally for such issues, it is up to the commenter to prove there is consenus to change.

None of the above restricts getting the document correct. If there are provable technical errors we will change the document.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Saturday, March 21, 2009 7:05 PM
> To: 'GEOPRIV'
> Subject: [Geopriv] draft-ietf-sip-location-conveyance-13: 
> WGLC comments
> 
> I read through
> Here are my high-level comments. Detailed comments on paper 
> available for the authors. 
> 
> * The draft comes up with new terminology even though we have 
> these terms already defined in other documents. This is bad (tm). 
> Cite terms (a common and preferred procedure) or copy the 
> text exactly (and quote it) rather than defining your own. 
> Useless and as we saw in recent discussions is rather harmful. 
> 
> * The document repeats stuff over and over again. Gives the 
> reader the impression that this is rocket science. Could be 
> significantly shorter. 
> 
> * The draft has to avoid the term "using protocol" at all 
> costs. As we know, this term is very confusing. 
> 
> In human readable language this means: You have to consider 
> security and privacy with new extensions.
> 
> * Don't understand why this document does not allow a HELD 
> URI to be conveyed. I commented this already several times 
> and got ignored. 
> 
> Even saying that the protocols are mandatory to implement is 
> also not a good idea. I really wonder why this is useful 
> given that the recipient then just cannot fetch location when 
> it receives something that it does not understand. What is 
> the big deal with that? 
> 
> * Is "routing-allowed" policy really useful and, if so, does 
> it need to be in the SIP header rather than in the PIDF-LO 
> where all the other policies are? 
> 
> The problem is, again (also mentioned several times), with 
> the lack of description of the recipient is for a PIDF-LO 
> with respect to the 'retransmission-allowed' policy. For 
> example, in a location application where the message is 
> directed towards a Service URN the intended behavior is that 
> there is some form of location based routing involved. 
> 
> * This document is about the transport of a PIDF-LO and not 
> about deployment considerations.
> 
> Example: 
> "
> This example also shows inappropriate usage of RFC2119 
> language which should be used for interoperability rather 
> than philosophical stuff. 
> 
> * The location-based error codes (100, 200, 300, 400, 500 on 
> page 14ff) are extremly fuzzy. They clearly lack 
> implementation experience (as the text continuesly repeats by 
> saying "for future work") and I believe they should be 
> removed and incorporated in a future version when more 
> implementation experience is available. 
> 
> 
>   Already in the LbyR requirements document. Reference it -- 
> no need to write new text. 
> 
> The document defines functionality to allow the proxy to add 
> location and we know who is going to use this. 
> 
> * Avoid inappropriate treatment of subjects that are 
> discussed somewhere else.
> 
> "
> The LbyR can have policies attached to it, if needed. We have 
> worked on solutions to get this to work. 
> If in a particular scenario policies cannot be uploaded to, 
> for example, a LIS then put the reference somewhere else 
> where you have the policies. 
> 
> * S/MIME example in the appendix isn't useful as it is 
> currently put in there. Everybody knows that S/MIME allows 
> you to encrypt a MIME body. So, if you want to put it in 
> there then encrypt the stuff and attach the keys so that 
> other folks can decrypt it. 
> 
> Ciao
> Hannes
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>