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

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Mar 2009 15:01:00 -0500

As far as I am aware, the WGLC on this document attracted no response on the SIP WG list.  I can't entirely attribute this to ambivalence, but would be concerned if anyone got the impression that there were no issues on this document.

This is a document that has had more changes recently and it is still: (a) difficult to read, far too long; and (b) generating little or no list discussion.

This document needs to be finished.  However, I don't believe that it is fit for publication.

I've forwarded comments from Hannes, which are very similar to those I made many moons ago.  Unfortunately, these comments were sent to the wrong list.

So... if you want to get overly procedural, you might interpret the response as representing consensus for ambivalence.  That would be a mistake.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Saturday, 21 March 2009 12:05 PM
To: 'GEOPRIV'
Subject: [Geopriv] draft-ietf-sip-location-conveyance-13: WGLC comments

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

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 24 Mar 2009 18:10:13 -0500

At 03:01 PM 3/24/2009, Thomson, Martin wrote:
>As far as I am aware, the WGLC on this document attracted no 
>response on the SIP WG list.  I can't entirely attribute this to 
>ambivalence, but would be concerned if anyone got the impression 
>that there were no issues on this document.
>
>This is a document that has had more changes recently

The only change that is recent is addressing the "routing-allowed" 
flag, which had very little new next.

the biggest change in the last 4 years was 2 years ago, surrounding 
the errors section (which Hannes now says he wants removed, but the 
rest of the folks at that bar bof (2 years ago) didn't agree with him 
then, and it would leave this spec underspecified... so that's not a 
good option IMO).

I haven't heard any really substantial change requests in the last 2 
years - other than this "routing-allowed" flag issue, which I have 
addressed in the current doc.

>and it is still: (a) difficult to read, far too long; and (b) 
>generating little or no list discussion.

a lot of (b) can be attributed to this fact; the ID has existed since 
2003, and perhaps folks are tired of reading the doc that has to deal 
with Geopriv's inconsistencies over the years.

>it is fit for publication.

I don't see comments to address here from you, so I cannot comment on 
those comments, and I certainly cannot address them either if I don't 
know what they are...

>I've forwarded comments from Hannes, which are very similar to those 
>I made many moons ago.  Unfortunately, these comments were sent to 
>the wrong list.
>
>So... if you want to get overly procedural, you might interpret the 
>response as representing consensus for ambivalence.  That would be a mistake.
>
>Cheers,
>Martin
>
>Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip