geopriv@conference.ietf.jabber.com - 2003/03/18
[09:09] %% logger has arrived.
[09:43] %% hildjj has arrived.
[09:52] * hildjj has changed the subject to: geopriv: 2003-03-18T09:00-08:00
[10:11] %% mrose has arrived.
[10:25] %% andy has arrived.
[10:26] %% randy has arrived.
[10:26] %% rjs3 has arrived.
[10:26] %% brtech has arrived.
[10:27] <randy> AM: document status
[10:27] <randy> AM: Revisions to req doc
[10:28] <randy> AM: WGLC on threat analysis
[10:28] <randy> AM: Today we're going to discuss dhcp using protocol -- doc not ready for WGLC
[10:28] <randy> AM: Will consider non-WG docs; should they be WG docs?
[10:28] <randy> AM: These include -pres- and
[10:28] %% mls has arrived.
[10:29] <randy> AM: 2 docs not refreshed (http and htrml)
[10:29] <randy> HS: what does it take to submit new docs as using protocol, such as civil locations
[10:29] <randy> AM: how is that a using protocol?
[10:29] <randy> HS: DHCP with civil instead of lat/long/alt
[10:30] <randy> AM: Let's discuss that later on
[10:30] <randy> AM: Now briewf review of WGLC changes to req doc
[10:30] %% mwatson has arrived.
[10:31] <randy> JC: new names for main 4 entities, easier to remember
[10:31] <randy> JC: LG= location generator
[10:32] <randy> JC: LG creates location object(LO) and publishes to location server (LS)
[10:32] %% resnick has arrived.
[10:32] <randy> JC: LS receives requests (one-time, event-based, or on subscription) from location recipient (LR)
[10:33] <randy> JC: LS applies privacy rules, may create new (filtered) LO and notifies LR as needed
[10:33] <randy> JC: LR receives LO from LS
[10:33] <randy> JC: Rule Holder (RH) stores rules
[10:34] %% mls has left.
[10:34] <randy> HS: Termins allow us to discuss behavior in common language. Does the text make it clear that many of these elements can be combined into one entity?
[10:34] <randy> JC: Yes, this is made clear in the text
[10:34] %% resnick has left.
[10:35] %% mls has arrived.
[10:35] <randy> Q; If I want loc I need to ask LS? How does RH handle who is auth to access someone's server?
[10:35] %% resnick has arrived.
[10:35] <randy> JC: This is out of our scope, but there would be initial registration and signtaures
[10:36] <randy> Q: No, I'm asking who is auth or get Location Information?
[10:36] <randy> JC: This is in the rules
[10:36] <randy> Q: Is this done on the server or between the endpoints?
[10:37] <randy> A: On the server
[10:37] <randy> JP: To clarify: endpoints and entities may be collapsed. It's not req to have separate rule holder
[10:38] <randy> Comment: by calling it "location server" you're implying a certain architecture. May be better to rename it as location provider or something
[10:39] <randy> HS: This has a notion that direction is pointing one way, but you're pointing the other way. Better to not use 'client" and "server"
[10:39] <randy> JP: There is a concept that people subscribe to this and receive requests
[10:41] <randy> R: have those who find the term "server" confusing read the doc? That is, is it confusing as used in the doc, or only as used in this room?
[10:41] <randy> JP: I'm really tired of arguing about names. Do we really need to hold things up for another argument?
[10:41] <randy> C: Server is appr. It's a controller.
[10:42] <randy> C: This doc is vastly improved. "Sighter" in prev doc was confusing. I understand "server" is party that answers queries
[10:42] %% mrose has left.
[10:42] <randy> C: If you thing about peers exchanging loc inf, the entity evaluating rules may be in the recipients.
[10:43] <randy> JP: There are many rules that are not suitable for recip to process. Such as rule about granulrity of rules. It doesn't make sense to send you accurate ino & rule saying ignore most precision
[10:44] <randy> JC: Entities can operate in different rules for different parties at diff times. That doesn't change what they do when they do it -- servers process rules
[10:45] %% mls has left.
[10:46] <randy> R; discussion on "server" not good use of mtg time -- if you object take it to list
[10:46] <randy> HS: servers process some set of rules
[10:46] <randy> JP: some rules need to be applied at server
[10:46] <randy> (end of JC presentation)
[10:47] %% resnick has left.
[10:47] <randy> (start of James Polk's present on DHCP as using protocol: draft-ietf-geopriv-dhcp-lo-option-00.txt
[10:47] <randy> (slide: bits in DHCP geo info)
[10:48] <randy> (slide: now proposed adding one byte to datum to hold IANA-registered ID of dataum for 255 possib datums. We init reg 3 most pop: EPSG WG 84 (etc))
[10:48] <randy> JP: codes start at 4100 so we want to offset that
[10:49] <randy> (slide: new format)
[10:49] <randy> JP: other open issue: based on req; the auth now feel this is not a location object (based on -03 of req)
[10:50] <randy> JP: need to dif btwn [ didn't catch]
[10:50] <randy> jp: need applicability stmt about use in closed env vs Internet
[10:50] <randy> JP: seems reasonable
[10:50] <randy> Q: is this an object conveying location info?
[10:51] <randy> JP: not an object because an object needs policy and rules
[10:51] <randy> JP: LG transmits LO to server, which applies rules. This is after the dhcp process
[10:51] <randy> Q: but arch elements can be combined. So in dhcp server we could have config option to make LG step in memory buffer
[10:52] <randy> JP: is that prior to LG step? Need IP address
[10:52] <randy> C; You're saying that for some reason loc inf transp over dhcp is different that loc in trabnsp any other way
[10:52] <randy> JP: what if notebook has gps?
[10:52] <randy> Q: nowhere in your loc obj def does it say ...
[10:53] <randy> jp: we're changing text in dhcp text
[10:53] %% jm has arrived.
[10:53] <randy> q: but you'r enot chang text in req doc
[10:53] <randy> q: this appears to be a loc obj. You're transp loc inf across prot. How is it diferent?
[10:54] <randy> HS: it might be helpful if draft had dotted box with loc source indic this is not geopriv
[10:55] <randy> JP: this is reasonable and essense of intent here
[10:56] <randy> TH: in this case you're saying LG is commun w/ loc serv using this protocol; in this case it is a split-client model, trust rel not same as betwn LS and LR. Priv/Sec req are thus different than btwn LS and LR (peers on the Internet). Might be useful to go through sec/priv reqs and say which ones do and do not apply inj this case
[10:57] <randy> TH: in some cases proto used to pass loc in may not have sec/priv capabilities otherwise needed
[10:57] <randy> TH: Useful to explicity state which sec/priv reqs do and do not apply
[10:58] <randy> C: the server that xmits loc config info is a loc server. It's a different box, not LS. Example of superior arch: "location generator" not "location server"
[10:59] <randy> JP: do we need to add something to our core geopriv docs to indicate this type of server?
[10:59] <randy> HS: use dashed line
[10:59] <randy> JP: that's unclear. Previous slide showed where geopriv object moves. Don't want to introduce arch elements that are outside that. We have text that covers this.
[11:00] <randy> JP: not totally comfortable with this back-door way of xmitting loc info but we need to find a way. How about adding to scenario?
[11:00] <randy> HS: helpful if we use term "LCI"
[11:01] <randy> AM: Good idea to put in scenario. New terms in scenarious anyway. We say it's related to loc gen, but is not a core part. Considering what Ted said about taking into account sec/priv rules w can help with this. Our req doc has helped with some analysis
[11:01] %% jm has left.
[11:02] <randy> HS: I've submitted as indiv sub a "sibling" document that is same as this dhcp one except that it carries civil not lat/long
[11:02] <randy> AM: what is nature of this? How real is it? Do devices need this?
[11:03] <randy> HS: Yes, devices need this. It's easier to generate and more useful.
[11:03] <randy> HS: granularity not nec. circular. Street adress, conforms to waht we think of as location.
[11:04] <randy> HS: If we have to map lat/long to civil, it introduces extra sec/priv issues. If we can avoid external translation service it's better
[11:05] <randy> [ LCI = location configuration information ]
[11:05] <randy> JP: I don't want 8000 definitions of this here
[11:06] <randy> JP: in terms of who does conversion. It could be done within location server. That won't introduce new sec/priv concerns
[11:07] <randy> HS: Depends on population of LS. Number of entities that have the db to do this is small. Few commercial companies that do this now. In practice the LS won't do this internally because of danger of innacurate data, rezoning, renaming streets, etc.
[11:07] %% resnick has arrived.
[11:07] %% resnick has left.
[11:08] <randy> AM: Once we have proceded to a doc that says 'here is a way to give out this sens. info on a large scale' we have to move forward to how to do this w/ priv/sec.
[11:08] <randy> AM: Once we've done this in dhcp we'll have turned on loc obj but without the sec/priv part. We're eating our dessert first. We need to rapidly make progress on the sec/priv part of the work
[11:09] <randy> HS: How can we include the civil stuff?
[11:09] <randy> TH: not a fund. change
[11:10] <randy> (next is Jon Peterson on threats)
[11:10] <randy> JP: one slide on threats analysis draft. Not many comments.
[11:11] <randy> JP: We've introduced new terms. Section on denial-of-service a little better. Doc seems done. Please let us know if you disagree.
[11:11] <randy> (Next is Jon on Presence draft)
[11:12] <randy> JP: Consider presence as using protocol for geopriv.
[11:12] %% resnick has arrived.
[11:12] <randy> JP: Location Object has interfaces for transit. What carries LO is "using protocol". Presence is a good candidate because geo loc is clearly an aspect of presence.
[11:12] %% mwatson has left.
[11:13] %% resnick has left.
[11:13] <randy> JP: Today there are commercial instant msging apps that have popularized the concept of presense. Buddies on-line, off-line. away, avail, etc. many have "polite blocking": where you can give different presence info to different people. Annoying people can always be told you're off line, for example. Handy feature
[11:14] <randy> JP: geopriv has very similar concepts. LR can subscribe to info about target; rule maker can set polciies that vary by LR.
[11:14] <randy> JP: See RFC 2778 which goes into lots of detail. More recent work has defined a "pres" URI scheme,
[11:15] <randy> JP: Presence provides framework for managing info
[11:16] <randy> JP: geopriv has same qualities as presence. e.g., 'watcher' can subscribe to 'presentity' presence, way to get events, way to unsubscribe
[11:16] <randy> JP also concept of not subscribing not instead doing one-time query
[11:17] <randy> JP: So, for some applications of geopriv, presence is very useful. Clearly, presence is not only use of geopriv. E.g., emergency services is a use of geopriv is different from presence
[11:17] <randy> JP: this is a prop to consider presence as *one* using protocol. But one that covers a lot of cases and details
[11:17] <randy> JP: presence work on publication maps very cleanly to geopriv work
[11:18] <randy> JP: even concerpt of compositor that shows different info to different requestors
[11:19] <randy> JP: Also, presence defs used today are MIME and XML based., PIDF (presence info data format). I think what geopriv defines could be encapsulated using presence
[11:19] <randy> JP: in geopriv we want concepts like subscriptionsm etc. This is hard work, and IETF has done a lot of it in presence work. Bad idea to redefine.
[11:21] <randy> HS: presence itself is a delivery mech; concept of 'presence' is an artifact of evoution; could deliver only loc inf with saying anything about other presence info (avail, etc)
[11:21] <randy> HS: this may not look like
[11:21] <randy> HS: 'buddy lists' because we've separated out the data from who gets it and how often
[11:21] %% mrose has arrived.
[11:22] <randy> JP: yes, and the PIDF has that concept and could carry geopriv w/o carrying other data
[11:22] <randy> JR: very difficult area is on rules and policy. SIP/SIPPING has made progres son this, such as discuss on throttling in SIMPLE
[11:23] <randy> JR: SIMPLE work is intended for geo inf. This is central to it. There are multiple commercial implementations of SIMPLE that are done for geo info
[11:23] <randy> C: Look at Japanese cell phone services where you provide password and get geo info of friends
[11:24] <randy> JP: This is covered in the geopriv docs
[11:24] <randy> AM: There are a lot of applications where you want to give you loc with a pseudonynouis character. This is a case where presence and location are related. We need to be able to separate presence from identity
[11:25] <randy> JP: "pres" URI could be something that gives lot of info, e.g., "pres:john@neustar" but we could also give opaque URIs; no reason to use permanent ID
[11:26] <randy> JR: In yetserday's SIPPING we talked about global URI. Maybe anonymous URI. This is intended for this use.
[11:26] <randy> JR: e.g., call (800) call center w/o knowing ID of call center agent. Nice that URI universe is infinily large
[11:27] <randy> AM: These concerns need to be made more explicit.
[11:27] <randy> JR: We need to talk about which document this needs to go into
[11:27] <randy> JR: This is a private draft. It's not clear in it.
[11:27] <randy> JP: This is presence, not specifically SIMPLE.
[11:28] <randy> C: Look at Jabber -- it has running code
[11:29] <randy> HS: when we talk about anonymity there are different degrees. All URIs generally have user@domain, so it isn't very anonymous, since they must be reachable and globally unique.
[11:29] <randy> HS: so if you're hostname is jonpeterson.com constructing a random user name won't help you
[11:29] %% behcets has arrived.
[11:29] <randy> JP: there are ways to use pres URI to provide anonymity
[11:30] <randy> JP: how many people here thing it's a good idea to re-use presence, my draft or not
[11:31] <randy> R: I'd like to focus on LO before using protrocol
[11:32] <randy> JP: if we want to concepts like sub/not that should be done in a using protocol, not in the LO
[11:32] <randy> JP: e.g., an epty LO may be considered a fetch. That isn't complete enough.
[11:32] <randy> JP: I'd like this to go forward as a WG doc describing one using protoco;
[11:33] <randy> AM: we think this is helpful because we have to WGs IMPP and SIMPLE that have woprk we can draw on
[11:33] <randy> TD: how about hum in room to guage support. This expands charter a lot.
[11:34] <randy> AM: let's take hum if it's appropriate to ask IESG to expand our charter to take on this using protocol?
[11:34] <randy> AM: hum if you support asking IESG to expand charter to include presence as using protocol
[11:34] <randy> AM: hum if you do not.
[11:34] <hildjj> hum
[11:35] <randy> Result: moderate hum in support; a few hums in opposition
[11:35] <randy> (next is discussion to start us on using protocols)
[11:35] <randy> AM: John Morris has draft which you're read on core elemenets of loc obj
[11:35] <randy> AM taking over typing here
[11:37] <randy> We now have talk on starting on protocols, starting off with draft-morris-core-01.txt,
[11:38] <randy> fields includes some required and optionals
[11:40] <randy> Anyone who is interest in non-privacy fields should talk to Jorge Cuellar and James Polk and John Morris specially interested in the privacy-related fields
[11:41] <randy> Privacy-protecting fields especially today. Rules to end-user now: 1. don't distribute this, in machine-readable and human readable. 2. machine-readable only
[11:43] <randy> HGS - confused by this. Human-readable: text. Not necessary, a rendering could happen. I'm concerned from a moving-forward perspective that there needs to be the equivalent to the fine-print on your credit card statement
[11:43] <randy> HGS- problems of silly state possible with the machine-readable stuff
[11:45] <randy> John Morris: reason for this was that a LO might be in HTTP object, but I'm not pushing this completely. I'm not strongly saying it needs to be in a text format or binary or in a form that needs to be in it rawest form
[11:46] <randy> RandyGellens: I really don't like having two forms, introduces silly states, internationalization problems, among many other issues
[11:46] <randy> JohnMorris (JM): will change the doc
[11:47] <randy> JM: some privacy rules may not b e understandable by humans in any forms, will only be transmitted between LSs
[11:49] <randy> RandyGellens(RG): certain rules are privacy risks to be sent to an end-user and should not have enduser forms and those should not even have enduser forms, but I dn't like the two-form types
[11:50] <randy> Jonathan Rosenberg (JDR): misguided to include display information in the document - machine/vs. human readble. All this geopriv stuff is a clear xml case
[11:51] <randy> JDR: encapsulate rules along with the data, rules applied along with the transformation process
[11:52] <randy> Henning (HGS): Discusses some approaches with xml that I did not capture (xslt and others but not in depth)
[11:52] %% rjs3 has left.
[11:54] <randy> John Morris: I thought you were saying there were going to be some articulations of privacy rules that were going to be too complicated to be carried in the location object. We have had debate whether any rules were in the object. We agreed a few simple ones there, and others outside
[11:57] <randy> HGS: Take imprecise rules and also have deal with ones that are contradictory (do not distribute bit with other rules that make exceptions to it) - take those and not get into trouble. Machine can't parse lawyerese.
[11:57] <randy> JM: If limited set of rules aren't fine-tuned, then the external rules should apply
[11:57] <randy> HGS:
[11:58] <randy> HGS: Suggestion I would like to make: if LO applies shorthand rules in object, and if non-machine possible rules are found elsewhere, lawyers will not be able to make suits
[11:58] <randy> JM: Comfortable with what you said
[11:59] <randy> SethSchoen: novice question: what kind of assurance can be obtained that someone will comply with privacy requirements?
[11:59] <randy> JM: there are no compliance assurances
[12:01] <randy> TedHardie (TH): How do I configure my device to obey some of these rules? I plan to send text to the list proposing to leave the word lawyer out of discussion
[12:02] <randy> AM: a few moments ago said we needed to keep the conversation moving past this
[12:02] <randy> JP: we need to work on this issue - it is one of the hardest
[12:03] <randy> RG: what the location object looks like and what form it takes
[12:04] <randy> HG: From a making progress quickly POV, it makes sense to do easy things first and go for extensibilyt, don't delay everything till we solve everything first. Do do not distribute first
[12:05] <randy> We don't agree now on does an identifier in email and sip match, e.g. things like this, so we should punt some of the hard problems
[12:05] <randy> HG continuing: find some non-identity based distribution
[12:06] <randy> RG: keep comments brief, but that's one that is excellent
[12:06] <randy> JP suggests we use the PIDF as the LO and he offers to do it
[12:07] <randy> Rather to extend it as a starting point for it
[12:07] <randy> AM: does it have encryption/authorizatin et
[12:07] <randy> JP: could do signatures etc. S/MIME or xml
[12:09] <randy> JP: explore S/MIME vs. xmldsig depending on the requirements
[12:09] %% gwachob has arrived.
[12:09] <randy> JM: core elements does not have group consensus so we need to work on the low hanging fruit
[12:10] <randy> RG asks who would want to work on the LO itself - asks for a show of hands, those on the jabber should speak too
[12:11] <randy> We would like to solicit commentators for geopriv work too
[12:12] %% andy has left.
[12:12] <randy> We are asking for any more work to do today, but it looks like we will end early
[12:13] %% brtech has left.
[12:18] <randy> We're adjorned
[12:18] %% mrose has left.
[12:18] %% randy has left.
[12:18] %% behcets has left.
[12:33] %% gwachob has left.
[12:36] %% hildjj has left.
[17:44] %% The Saint has arrived.
[17:44] %% The Saint has left.