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 protected] [mailto:[email protected]] 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 protected] 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] _______________________________________________ Sip mailing list https://www.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
