Minutes of the GEOPRIV Working Group 16-17 May 2005 Interim ----------------------------------------------------------- Co-Chairs: Allison Mankin Randall Gellens Andrew Newton Minutes: Tom Taylor 1) Agenda Andrew presented the agenda sent to the GEOPRIV working group mailing list, and noted that agendas for interim meetings are more flexible than those for sessions held at plenary meetings. There were no objections to the agenda. 2) Properties of Network Elements for Conveyance of Location Information Andrew noted that none of the volunteers who offered to write drafts on this topic had done so. He presented a table of functions for conveyance of location information broken down by network layer, link layer, and application layer. Where possible, ratified or developing standards to fulfill the appropriate function was noted. The room then began discussion on providing geographic location information to a client device. This led into a discussion regarding GEOPRIV terminology for the various elements in the network and the functions they provide. Some participants felt that the GEOPRIV terminology was now out of date since it did not cover the sending of location information for a DHCP server to a DHCP client. Randall Gellens noted that GEOPRIV terminology includes the term ÒsiterÓ which does cover the use case. The next discussion centered around passing civic location information to a client device. Henning Schulzrinne noted that LLPD-MED uses the same format as draft-ietf-geopriv-dhcp-civic and that the two were synchronized. Discussion then focused on RFC 3825 not being adequate for wireless infrastructure. James Polk noted that it was never intended for this purpose. The next discussion centered around trust relationships between various layers in the network. It was noted by Ted Hardie that cryptographically signed data does not establish a trust relationship by itself. There was some discussion regarding the architecture of PIDF-LO and the use of S/MIME vs. XML D-SIG. Jon Petereson and Ted Hardie felt the passing HTTPS URIs by DHCP servers was a better solution than signing of data by DHCP servers. There was no conclusion in the room regarding this idea. Jon Peterson then asked the participants who should be trusted more with regard to location information, an end-user or a layer 2 network. After much discussion, it was the general feeling of the room that layer 2 was not the only trust anchor point that could be defined. 3) Location Determination and Delivery in IP Networks James Winterbottom gave this presentation over the phone (Andrew moved along the slide presentation for the in-person meeting participants). Following the presentation, the participants discussed the complexity of having multiple location conveyance protocols. Some participants stated that a layer 7 protocol would stop the need for implementing the same function for each type of layer 1/layer 2 network. Some participants stated that this function should only be conducted via DHCP and that depending on a layer 2 specific protocol would unnecessarily complicate the work to be done by implementors. Many participants did not believe this was an issue and that most clients would only need to implement a few protocols for this function. Allison Mankin noted that a layer 7 protocol must implement measures to limit the unintended distribution of information. Other participants noted use cases for emergency services in which a target proxy needs to participate on behalf of a target. The participants of the room then began another discussion on the signing of DHCP data. There were differences of opinion on the security needs for such a feature, and some participants expressed doubts regarding the ability for DHCP to posses the necessary security functions. The discussion was discontinued once the time alloted for the presentation was used up. Andrew noted that this discussion may continue at another time during the interim meeting where spare minutes could be found. 4) Schema work for Common Policy Hannes Tschofenig gave a presentation on the current XML Schema work being done on draft-ietf-geopriv-common-policy. Hannes noted that he had not received feedback with regard to using elements vs. attributes for compatibility with XCAP. Ted noted that the desired use with XCAP may not work because XCAP is hierarchical in nature. Hannes described the type of identities given in the draft as authenticated identity, unauthenticated identity, asserted identity, and anonymous identity. It was suggested by Randall Gellens that there be a category for undisclosed identity. A discussion then took place regarding the element. Ted Hardie urged the group to reconsider its use as it would be anathema to the additive permission model. Jon Peterson agreed and stated he did not understand the need for this element. Ted volunteered to ask the SIMPLE working group to give a solid use case or remove the feature. Andrew asked the rest of the participants if this was their desire; the participants agreed. 5) PIDF-LO in HTTP Andrew opened discussion on draft-daviel-kaegi-html-geo-tag and draft-daviel-kaegi-http-geo-header. He noted that these drafts had been discussed at the GEOPRIV interim meeting in Washington DC, but was willing to reopen discussion because he felt the group had not fully understood the intended use cases. There was some discussion regarding forward progress of this work, interest in it by the working group, and the understanding of IETF process by the draft authors. Andrew stated that he did not believe the draft authors understood IETF process, but that unfamiliarity of IETF process should not be a reason drafts are not given IETF consideration. Several participants expressed concerns that these drafts were attempting to by-pass all the privacy considerations that GEOPRIV has defined. Many participants felt both drafts needed to be clarified. It was the consensus of the participants that draft-daviel-kaegi-html-geo-tag be accepted as a working group document so long as it described static location information meant for public consumption, and that this draft should reference GEOPRIV work for any other work. It was the consensus of the participants that draft-daviel-kaegi-http-geo-header would only be accepted as a working group item if it were first rewritten to use PIDF-LO. 6) LCI Transmitted Upstream James Polk presented draft-polk-geopriv-dhc-geo-lci-upstream. James noted that this draft would specify a clarification about communicating RFC 3825 information back to the DHCP server, an issue which was raised during last call of the draft-ietf-geopriv-dhc-civic draft. Jon Peterson expressed concern that this would then lead to sending location information to unauthenticated entities. Ted Hardie clarified the comment by Ralph Drums during last call, noting that the last call comment noted that DHCP communications happen both ways at multiple times and that draft-ietf-geopriv-dhc-civic needed to clarify the meaning of the communication at certain time but not that location information should be sent from a DHCP client to a DHCP server. It was the consensus of the participants that both drafts should state that location information should not be sent from a DHCP client to a DHCP server. It was the consensus of the participants that draft-polk-geopriv-dhc-geo-lci-upstream be accepted as a working group item. 7) Resumption of discussion on Location Determination and Delivery in IP Networks Andrew re-opened this discussion with spare time on the agenda. Henning Schulzrinne presented an idea about signing DHCP data and then passing through to PIDF-LO objects. There was much disagreement regarding the need for signed data. Ted Hardie noted that without attaching the signed data to a trusted entity, the signature provides no meaning. Brian Rosen pointed out that signatures are vulnerable to replay attacks. Jon Peterson then presented concepts on push vs. pull models and the security considerations provided by them. Andrew closed the discussion declaring that there was no apparent consensus on the need for signed DHCP data. He asked Henning to continue this discussion on the mailing list. 8) Proposed Enhancements to PIDF-LO: PIDF-LO Profile Andrew opened this agenda item noting that there had been lack of discussion on this on the mailing list and that only James Polk had provided comment. Hannes presented the draft-winterbottom-geopriv-pidf-lo-profile. The participants then discussed updating PIDF-LO with a newer version of GML. Concern was stated that by using an older version of GML, PIDF-LO might become obsolete. A counter-concern was stated that consist versioning would limit the amount of experience gained by deployment of a standard. A concern was also expressed that libraries would support the newer versions of GML, however it was also stated that vendors tend to support older versions of standards. Ted Hardie proposed that the working group should not consider upgrading to a newer version of GML without a draft stating a reasonable need for the newer version of GML. Andrew found that the room had consensus on this proposal. It was decided that Hannes and James Winterbottom would split their current draft into two separate drafts: one specifying the usage for the current version of PIDF-Lo and one specifying what changes they are seeking to PIDF-LO. 9) Proposed Enhancements to PIDF-LO: NENA Requirements Brian Rosen presented his ideas on changes needed to PIDF-LO to support emergency requirements. The group discussed the need for having multiple sets of location information and the need for labeling these sets. There were some questions about this information needing to be in a presence container such as PIDF-LO. The group then discussed the need for a timestamp on sets of location information. Multiple timestamps were discussed: one for the creation of the PIDF-LO object, one for the acquisition of the location information, and one for the validation of the location information. Andrew declared that the group was not coming to a consensus on this issue and asked those in favor of a timestamp to clarify their positions on the working group mailing list. This agenda item closed with a discussion of uncertainty and confidence with respect to location information. Many participants expressed concern over changing the current model as it could lessen privacy constraints. Other participants felt that this needed to be addressed for the wireless community. After continued discussion, Andrew noted that no consensus was forming on this issue and urged participants to take this discussion up on the working group mailing list. 10) Any Other Business: Multiple Locations Andrew asked if there were any other business. Nadine Abbot brought to the floor the issue of multiple locations for emergency call routing. Brian Rosen expressed concern that call routing would be inhibited without labels for location information. Jon Peterson and Ted Hardie noted the need to understand the function of the compositor in presence architectures and the need to have this as an independent function for the purposes of allowing privacy policies. After continued discussion, Andrew noted that the group was still not reaching any consensus on this issue and asked that the participants express their concerns on the mailing list in hopes that it may be a better forum to facilitate mutual comprehension. 11) Any Other Business: Carrying Location Objects in RADIUS Andrew asked if there was any other business. Hannes presented an issue with draft-ietf-geopriv-radius-lo. The existing draft specifies that a visited network sends location information to a home network when it knows via configuration that the home network needs this information. Hannes noted that one of the draft authors would prefer that the home network be required to ask for this information before it is sent. Hannes proposed an amendment to this request in which geographic or civil location is explicitly requested. There were no comments from the participants regarding this change. Andrew closed the meeting.