Subject: Minutes of the Geopriv Meeting - IETF 56

From: Allison Mankin <[email-masked]>
Date: Fri, 11 Apr 2003 17:33:19 +0000

It seems these are due today, so comment to the list if you have any 
corrections or additions and we'll just have the corrections in
our archive.  Thanks to Hannes for the excellent minute-taking!

GEOPRIV MINUTES
Minute Taker:
Hannes Tschofenig

Chairs: Randall Gellens, Allison Mankin

Agenda Bashing
--------------
Intro
-----
Requirements document will be simplified a bit more (but has been
quite a bit already)
Location object not ready for last call
a number of non-working group documents to be discussed some to
be brought into working group.

geopriv core as a way into
geopriv using document

Document status - Chairs - 5 mins -
--------------------------------------
  Make sure you have read:
draft-ietf-geopriv-reqs-03.txt
draft-ietf-geopriv-threat-analysis-00.txt
draft-ietf-geopriv-dhcp-lo-option-00.txt
draft-cuellar-geopriv-scenarios-03.txt
draft-morris-geopriv-core-01.txt
draft-peterson-geopriv-pres-00.txt
(also on our charter, but not refreshed, documents on http and html)

Requirements draft (Jorge Cuellar)
--------------------------------------

Brief review of WGLC changes on requirements document

Two new authors
New names for domain entities of the protocol; new abbreviations
The new terms are described on the slide

Henning Schulzrinne: The entities are logical entities.
Jorge Cuellar: True. They might be co-located. 

James Kempf:  Authorization is done at the Location Server
Jorge: yes

Q: The work is more general - there is not necessarily a server-client
architecture. (location intermediary)
Henning: Some people would like to get rid of the term server
Randall Gellens: Are the terms confusing as defined in the document?

Henning: Less loaded term wouldn't hurt
Jon Peterson: The term server is the only term that is not changed from the 
previous version of the draft. It is perhaps not worth changing anything anymore.

James Polk:  The server is actually the controller. The server is the
appropriate term here

Comment: This draft has greatly improved. It looks good as it is.

Jorge: A peer-to-peer scenario does not contradict this notation here

Several: The LS is applying most rules, and particularly filtering the 
location
information, but In the minimum requirements the Location Recipient is
processing also some rules (do not distribute, do not store longer than
..)

Geopriv/DHC Option (James Polk)
-----------------------------

- Original format proposed was presented
- Suggestion that a datum has to be included. 3 are currently 
registered
- A main open issue: Based on the terms in the current requirements document,
DHCP may be seen not as an using protocol, but as a protocol that acts before
geopriv.  Thus the location information passed here is not a LO, but a "LCI
(location configuration information)".  Seen in this way, DHCP is only gathering
the location information to be used by the LG.

Q: Is LCI an object conveying location information.
A: Yes, but it does not contain security and policy information

There is some confusion about the DHCP information and the location object
definition in the requirements document

Henning: It might be helpful to indicate that this is not part of geopriv.
Unlike the other information where the info is available to the entity -
they
just happen to be at two different physical entities. There just need to
be twodifferent definitions

Ted Hardie: Privacy and security requirements in the two cases are different
It might be valuable to explicitly state which are the privacy and security
requirements in each case

Jon: Jorge's picture describes where the geopriv object moves. It should
additionally be specified where the Location Generator obtains the necessary
information about the location information. It might be good for the scenario

Henning: LCI ("Location Configuration Information") term should be defined
outside the DHCP draft since it is a useful concept

Allison: We should add it to the scenarios draft. Additionally we need to add
the security and privacy issues that Ted has mentioned

Henning: I also submitted a similar draft, but providing civil location
information via DHCP (instead of geo-location). It is easier to generate this
type of information. A street address conveys more the type of location that
people usually think of. It is useful (from security and privacy perspective,
and also for performance and simpler functionality) to provide this information
instead of using a translator (which could translate geo-location information to
civil location information).

Jon: This sounds like a good idea

Jon: Who should do the conversion you just mentioned?

Henning: The database to do the conversion is large - there are only a 
few companies doing this. The server could this do internally 
(theoretically) but in
reality you don't want to do this by yourself. You don't want to keep
track of all street changes.  This type of translation service may be expensive 
if you want to be always accurate.

Henning: Hum on the DHCP draft?

Ted: Seems ok. The charter covers the draft of DHCP that James =
presented, this topic is not far from that one

Threat Analysis (Jon Peterson)
-----------------------

draft-ietf-geopriv-threat-analysis-00.txt

This work is done. We could do a WG last call
Randall gave Jon comments (on paper) during the presentation

Presence as a using protocol (Jon Peterson):
-------------------------------------------

Presentation about draft-peterson-geopriv-pres-00

Describes what a using protocol is and how it is location information 
can be used in presence protocols
There is some similarity between presence and geopriv.

RFC2778/RFC779 defined a framework for presence

Presence is not the only way how location information can be 
distributed.
Emergency calls are another example where you simply provide location
information to the desired entity

Hence presence is only one example of using geopriv but not the only
one
MIME/XML based data format: PIDF (draft-ietf-impp-pidf-0x)
This exact work has been done before. Hence it would be good to reuse it 
instead of reinventing it

Henning: The presence itself is a delivery mechanism. We should not be 
mislead by the presentation where presence is usually used

Jonathan Rosenberg: Rule stuff is the hardest stuff. Simple and sipping working 
group is discussing these issues.

James Kempf: Take a look at the Japanese Phone system.
Jon: Jorge mentioned this usage already (codeword, token, password)

Allison: Identifiers can be pseudonymous for the presence application?

Jon: I gave a link to a presence URI. It is very easy to get opaque 
URIs

Jonathan: The principle application of anonymous URIs (proposed in SIP). 
Call
centers offer some examples where this is useful. Identity independent 
SIP URIs. This is a private draft

Allison: These things should be made more explicit

Henning: Publication: Notion of an anonymous contact address. Usually all have a user@domain
characteristic. Hence there are no random numbers and globally unique.
Hence
there is a pseudonym and a domain name

Jon: How many people think that this work is useful for geopriv WG?

Randall: Work on security and policy (location object) has to be done

Jon: There can be parallell activities: Work on security and policies at 
the same time of working on an using protocol

Allison: Area directors should decide whether this should become a 
working group
document if the IESG agrees to expand the charter

Ted: Hum?

Group: Acceptance

Geopriv Elements & Fields (John Morris)
--------------------------------------

ftp://67.cdt.org/pub/ietf-geopriv-03mar-elements.ppt

Description what requirements document says about specific fields. Some 
of them
are optional.

Henning: Optional might mean
a) default value assumed
b) not defined

John Morris: needs to be defined

Limited privacy rules: draft-Morris-geopriv-core-01.txt
Two different groups of rules

Henning: A little bit confused about the human-readable rule.
This causes a number of problems (e.g. internationalization problem)

John Morris: I am not pushing this requirement or the wording. That 
language
came from discussion with others. It needs to be discussed further

Randall: I had the same concern with the document

John Morris: Instead of saying that some rules are only machine 
readable, we may
want to say that some rules are never presented to a human, those rules 
are
passed only between two servers

Randall: It is appropriate to have rules to an end user. These rules do 
not need
to be formatted as human readable within the LO, but made readable when
presented to the human

Jonathan: This is only about information rendering. It is misguided to 
include
any display information. This is a separate problem

Henning: Different formulation: Specify information by value or 
reference

John Morris: Some rules are too complex to have it specified in the 
location
object. In this case there should be a external reference to these rules 
then if
they are not included. 

Henning: If you cannot express all exceptions then you might want to 
include
additional things. (Because you don't want to encode all human 
relationships).
In that case however, you cannot sue someone

Ted: How can I configure my device based on these rules?
Henning should send text to the list

John: We need these issues soon

General discussion of protocols - Chairs and AD - up to 30 mins
---------------------------------------------

Randall: What should be included in the location object and what 
shouldn't?
Henning: Doing the easy things first. Make it extensible. Not delaying
everything until the tough problems are solved

Jon: would like to make a first proposal (based on PIDF from IMPP)

Allison: Do they contain security?

Jon: yes as part of smime. more advanced stuff can be done at the XML 
level

Randall: Who is going to work on a geopriv location object? Please send 
your names to Allison and Randall.