[00:03:46] <jmorris> test
[00:04:56] --- jmorris has left
[00:06:03] --- jmorris has joined
[00:09:15] --- anewton has joined
[00:10:45] <jmorris> hi andy
[00:11:35] --- HannesTschofenig has joined
[00:12:48] <anewton> hello
[00:13:10] <jmorris> any chance of a jabber scribe?
[00:13:25] <HannesTschofenig> yes.
[00:13:32] <jmorris> great....
[00:23:53] --- SAH has joined
[00:24:18] --- sakai has joined
[00:24:27] --- rlbob has joined
[00:28:04] <HannesTschofenig> Andrew started with the Agenda Bashing.
[00:28:15] --- hardie has joined
[00:28:49] <hardie> Ted volunteers to jabber scribe
[00:29:11] <hardie> Andy goes on with Agenda bash
[00:29:32] <hardie> Administrativia, new rfcs, drafts in transit, milestones, wg managed webpages,
[00:29:37] <hardie> then civil lcoation
[00:29:41] <hardie> then pidf-lo
[00:29:45] <hardie> and architecture
[00:29:55] <hardie> Then LO policy preso from Henning
[00:30:04] <hardie> then GLI system architecture from Watanabe-san
[00:30:15] <hardie> Then Radius extension for Geopriv
[00:30:26] <hardie> Then agenda goes un-bashed
[00:30:33] <hardie> WG administrivia starts
[00:30:52] <hardie> 3693 and 3694 are published, rqts and threats
[00:30:59] <hardie> dhcp-lci in RFC ed queue
[00:31:29] <hardie> Update milestones presented (except completed 'stones)
[00:32:07] <hardie> The SIP using protocol draft -- James Polk takes the mic'
[00:32:34] <hardie> He and a co-author have authored a using protocol draft for sip.
[00:32:50] <hardie> The emergency services aspects of call routing based on geolocation
[00:33:10] <hardie> He wants eyes on the draft now, and he wants this to become the using protocol
[00:33:16] <HannesTschofenig> James wrote the following draft: draft-ietf-sipping-location-requirements-00.txt
[00:35:37] <hardie> The first use case is emergency service (pick a target for an emergency call based geolocation data); other use cases (passing geolocation to the sip target) is also in scope for the draft.
[00:35:52] <hardie> Andy will ask whether this should be the geopriv milestone meeter to the list.
[00:36:42] * hardie notes that it would not have met the milestone if it were emergency services, which is why I wanted to ask the question.
[00:37:03] <hardie> s/emergency services/emergency services *only*/
[00:37:39] <hardie> Next item: http://ecotroph.net/geopriv is wg website; 4 of ppt presos from this meeting are there now.
[00:37:52] --- jmorris has left: Disconnected
[00:38:03] --- jmorris has joined
[00:38:07] --- jmorris has left: Disconnected
[00:38:14] --- jmorris has joined
[00:38:18] <hardie> this is linked from charter page.
[00:38:27] --- jmorris has left: Disconnected
[00:38:30] <hardie> henning comes up to cover civil location
[00:38:41] --- randy_g has joined
[00:39:42] --- jmorris has joined
[00:39:45] <hardie> Complementary to draft-ietf-geopriv-dhcp-lo-option
[00:39:55] <hardie> meant for network operator to convey civil location to device
[00:40:05] --- jmorris has left: Disconnected
[00:40:06] <hardie> Does not provide location to third parties; just own location to target.
[00:40:15] <hardie> attempts to be country neutral
[00:41:02] <hardie> open issues: room indication? character set indication (utf-8 +optional language)
[00:41:07] <hardie> IANA registration mechanism
[00:41:43] <hardie> the optional language would help indicate layout
[00:41:54] <hardie> iana work needs some fleshing...
[00:42:06] <hardie> after that, wg last call would be request
[00:42:09] <hardie> requested
[00:42:39] <hardie> James notes that lci rather than lo is correct.
[00:43:26] --- jmorris has joined
[00:43:30] <hardie> Call from the floor to new participants, especially non-U.S. residents, to be sure that the address format can reach all addressing possibilities
[00:43:49] --- jmorris has left: Disconnected
[00:43:54] <hardie> This is critical for emergency services--if they can't get unambigous addresses in, the consequences may be severe.
[00:43:55] --- jmorris has joined
[00:44:25] <hardie> Allison asks what the load on IANA will be?
[00:44:58] <hardie> Henning indicates that registration would only come into play for extensions
[00:45:31] <hardie> It may be the initial set, and the next one two years.
[00:45:54] <hardie> Jon Peterson takes the floor
[00:46:04] <hardie> two documents on the floor
[00:46:15] <hardie> draft-ietf-geopriv-pres-00
[00:46:29] <hardie> motivation for using presence as a using protocol for geopriv
[00:46:50] <hardie> not exactly a using protocol, but more a motivation for using pidf and geopriv in concert
[00:47:15] <hardie> This is referenced by pidf-lo
[00:47:27] <hardie> He's updated the draft since making that reference
[00:48:16] <hardie> open items: a bit more to make it less like a using protocol (de-SIMPLE-ificiation)
[00:48:36] <hardie> Any comments? Is this is still needed?
[00:49:06] <hardie> No one thinks this should be forgotten for all time, so the update will occur after this IETF
[00:49:14] <hardie> On to pidf-lo
[00:49:46] <hardie> Civil location has been added, along the lines set out in Henning's draft.
[00:49:59] <hardie> Schemas have been updated, based on Andy's validation.
[00:50:18] <hardie> The unmet requirements setction has been updated.
[00:50:29] <hardie> Basically, it was deleted
[00:50:57] <hardie> hannes pointed out that the requirements met by pidf-lo are not easy to distinguish from those met by the using protocol
[00:52:29] <hardie> the question becomes, how much to set out about the bits that are handled by pidf lo, and the bits that are handled by the using protocol
[00:52:49] <hardie> Hannes suggests that the split might be documented in the motivation document
[00:53:34] <hardie> Jon thinks it is good idea, but is concerned that the document would have to become a protocol-specific document again.
[00:54:20] <hardie> Henning asked whether adding a "these are met by a using protocol section":
[00:54:32] --- jm has joined
[00:54:32] <hardie> That was removed, according to Jon, since it was small and not useful.
[00:54:56] <hardie> Discussion of how to produce this document
[00:55:12] <hardie> James doing the example in his sipping document is proposed.
[00:56:32] <hardie> henning points that there are several ways to tackle the problem
[00:56:57] <hardie> henning suggests that it go into pidf-lo
[00:57:17] <hardie> for timeline reasons
[00:57:24] <hardie> and interdependencies
[00:57:58] <hardie> Jon has some reservations about how extensive the information sipping requires would be.
[00:58:23] <hardie> Brian notes that mechanism is a more restricted bit of info than has been read in.
[00:58:35] <hardie> Tools involved in making that decision are external
[00:58:50] <hardie> Jon asks whether sipping needs to convergence on this advance of deciding here?
[00:59:08] <hardie> Brian agrees, saying that waiting a few days for convergence makes sense.
[00:59:32] <hardie> "ranging, gps, etc." are the types of mechanisms proposed
[00:59:49] <hardie> emergency info really wants this
[01:00:56] <hardie> James notes that some of the confusion was due to poor wording, and that the requirment should be obvious when the wording is set
[01:01:26] <hardie> Allison proposes allowing a working group last call with an elided section for this, noting that it will be coming in (optional element, enumerated list)
[01:02:03] <hardie> another IANA registry may be needed
[01:03:22] <hardie> James raised other elements which are required, and Jon asks James to reply to Brian's email
[01:03:40] <hardie> jon suggests that this must be an extension, if they are going to be in discussion for a while.
[01:04:23] <hardie> henning indicates that picking just "mechanism" now would be possible, and not holding up for the others.
[01:04:49] <hardie> Jon is concerned that there are interactions which may be intended for the groupings
[01:05:22] <hardie> James channels Nina, saying that confidence should not be dropped
[01:05:50] <jmorris> NENA
[01:06:06] <hardie> Allision notes that including not-well-understood features may endanger our ability to deliver
[01:06:27] <hardie> Keep it simple! she says
[01:06:34] <hardie> Andy asks that the issue go to the list.
[01:06:46] <hardie> Thanks for the correction
[01:07:00] <hardie> Henning returns to the plate
[01:07:58] <SAH> <taking over for Ted temporarily...>
[01:08:40] <SAH> Issues: commonality, pidf and not just pidf-lo?
[01:09:00] <SAH> policy relationships...
[01:09:28] <SAH> basic structure of rules: conditions, actions, transformations
[01:09:32] --- memo56 has joined
[01:09:51] <SAH> exceptions for identity matching:
[01:10:14] <SAH> very restricted, better viewed as more capable matching
[01:10:44] <SAH> match domain and then check if user matches exceptions
[01:11:24] <randy_g> ("exceptions" are exceptions to the same rule, not any other rule)
[01:12:02] <hardie> exceptions only allows user not a full user id (all in example.com except joe@example.net) does not happen
[01:12:10] <hardie> Thanks, SAH.
[01:12:26] <hardie> Combining rules, rule matches if all conditions match
[01:12:37] <hardie> additive permissions only, order not important
[01:12:50] <hardie> any field can be null; very small number of operators
[01:12:53] --- tomphelan has joined
[01:13:18] <hardie> Open issues: any additional data types needed (boolean, set, integer covered)?
[01:13:40] <hardie> date type? maybe not, since it is representable as an integer
[01:14:01] <hardie> URI in common is really a user protocol, but depends on the using protocol
[01:14:08] <hardie> Geo conditions is new topic
[01:14:31] <hardie> Civil location match (useful mostly when user doesn't know full hierarchy)
[01:14:38] <hardie> e.g., knows city but not county
[01:14:54] <hardie> geo location match
[01:15:04] <hardie> currently within a specified trapezoid
[01:15:13] <hardie> Geo transformations
[01:15:55] <hardie> Should the keep rule be generic, not just geopriv?
[01:16:23] <hardie> Jonathan believes we had this converstation last time.
[01:16:33] <hardie> He believes we agreed to that
[01:17:12] <hardie> Jonathan realizes we looking at something else (he had been thinking of distribute/retention rules)
[01:17:26] <anewton> someone has commented on the geopriv page that the link for location-info-radius-IETF59.ppt is broken, howerver I am not seeing that problem. Is anybody else having this problem?
[01:17:42] <hardie> Comments on this to the list, please
[01:18:38] <hardie> In next revision, civil location will get a datum qualifier
[01:18:59] <hardie> new draft with editorial changes coming; then ready for wglc?
[01:19:11] <jmorris> andy, my machine shows draft-ietf-geopriv-pidf-lo-01.txt as being infected by a virus, and then it chokes
[01:19:27] <jmorris> oops, no the radius one I mean
[01:19:53] <hardie> Henning *strongly* urges reading this, if you have opinions about privacy
[01:20:02] <hardie> And which of us does not?
[01:20:20] <hardie> GLI system archittecture is presented
[01:20:38] <hardie> Watanabe-san presents
[01:21:00] <hardie> http://www.gli.jp
[01:21:53] <hardie> registers: long, lat, altitude, and identifier called HID
[01:22:05] <hardie> You can look by identifier, or look up nodes by location
[01:22:32] <hardie> Complex figure; please consult slides
[01:22:33] --- SAH has left: Disconnected
[01:23:54] <hardie> current slide looks at assumptions and threats, which is primarily specifying and tracking a mobile node by a third person
[01:24:17] <hardie> wiretapping, and spoofing are also issues noted, but the connection is not yet clear
[01:24:24] --- SAH has joined
[01:24:50] <hardie> Now the privacy protection is described
[01:25:09] <hardie> forward look up limited to those with whom a confidential relationship has been established
[01:25:49] <hardie> Any client do a reverse lookup, but you need a confidential relationship to recognize the nodes found
[01:26:20] <hardie> Watanabe-san argues that it is different from Geopriv, but simple, scalable and sufficient
[01:27:21] <jmorris> "sufficient" meaning that geopriv is not needed?
[01:27:27] <HannesTschofenig> a paper can be found at: http://www.csl.sony.co.jp/person/sohgo/GLI/ieice2001/ieice2001.html
[01:27:40] --- jmorris has left: Disconnected
[01:27:55] --- jmorris has joined
[01:28:20] --- jmorris has left: Disconnected
[01:28:26] <hardie> Description of the HID generation (hashed ID_
[01:28:27] --- jmorris has joined
[01:29:10] <hardie> parameters: real identifers, timestamp, interval, and random values to generate HID
[01:29:18] <hardie> time value is included-hid changes with time
[01:29:41] <hardie> this, and the need to share data, prevents mobile nodes being tracked
[01:29:56] <hardie> comparison against reqts.
[01:30:09] <hardie> no rule holder, no location informtion filtering.
[01:30:24] <hardie> asserts others are present
[01:30:53] <hardie> Now GLI system architecture is presented
[01:31:04] <hardie> did not catch new speakers name, sorry
[01:31:14] --- tomphelan has left: Disconnected.
[01:31:52] <hardie> entity generates hid, registers with registration server
[01:32:23] <hardie> way cute animation of moving kitty
[01:32:56] <hardie> distinguishing how the same client may be associated with different area servers,
[01:33:14] <hardie> exact method seems to depend on forwarding by registration server to new HID server
[01:33:29] <hardie> registration flow slide presented; too complex, please consult slides
[01:34:19] --- memo56 has left: Replaced by new connection
[01:34:19] --- memo56 has joined
[01:34:19] --- memo56 has left
[01:34:20] <hardie> forward lookup message flow presented
[01:34:33] --- memo56 has joined
[01:36:28] <hardie> reverse look up message flow presented
[01:37:12] <hardie> field experiment using yokohama city bus
[01:37:33] <hardie> plans to present future contributions
[01:38:22] <hardie> Associate of Watanabe is Kurisu-san
[01:38:37] <hardie> Now two presentations on Geopriv and Radius Extensions
[01:40:20] <hardie> a little slide problem
[01:41:25] <hardie> Farid Adrangi presents draft-adrangi-radiusext-location-information-attribut-00.txt
[01:41:52] <hardie> intent to present this to radiusext group, when it is chartered
[01:42:05] <hardie> gsma & wifi groups inspired the work
[01:43:27] <hardie> motivation: location aware subscriber authentication and authorization
[01:43:37] <hardie> location aware billing, info sent only to home network
[01:45:07] <hardie> roaming agreements are based on things like "place type" might be better
[01:45:38] <hardie> given that a civil location is a bit more ambiguous
[01:45:57] <hardie> GSMA requirements presented
[01:46:24] <hardie> RADIUS access-request to convey from NAS to Home radius server directly or via intermediators
[01:49:15] <hardie> Sorry, asked a question about radius/diameter interop, so no scribing; answer was that they would plan on doing both formats
[01:50:17] <hardie> information elements: operator type and operator name, country telephone area code, city, unstructured string contain description, location relation information in english to be used for detailed bill
[01:52:07] <hardie> attribute: format and syntax for presenting the information elements should have minimum overhead (253 bytes to avoid fragmentation)
[01:52:30] <hardie> avi notes that quick processing is also a requirement
[01:52:59] <hardie> Radius intermediaries--trust intermediaries
[01:53:10] * hardie wonders whether this a security model?
[01:53:29] <hardie> User privacy: recommends use of identity privacy
[01:54:06] <hardie> "real identity" is only revealed to the home network--meaning the real identity is only known to the home network
[01:54:40] <hardie> Henning notes tha the privacy issues go beyond tracking
[01:54:50] <hardie> (Is there continuity?)
[01:56:22] <randy_g> Ted asks about Radius information passing through intermediaries
[01:56:41] <randy_g> Ted: seems to be a business model, not a security/trust model
[01:57:16] --- HannesTschofenig has left: Disconnected
[01:57:24] <randy_g> Answer: In the RADIUS model, each hop trusts the others; it's hop-by-hop not end-to-end
[01:57:51] <randy_g> Ted: but you don't want to deal with this by simply trusting the hops, you want to build something in to the data model
[01:58:26] <randy_g> Ted: you need to secure the object, not the channel
[01:58:54] <hardie> Hannes notes that many EAP methods don't provide user identity confidentiality
[01:59:07] <jmorris> the end user does not know or trust the hops
[01:59:41] <randy_g> Exactly, John. The carriers may trust each other, but does the user?
[01:59:44] <hardie> Jon notes that threat model has a large number of threats that have been described
[02:00:01] <hardie> These may not be able to be handled by radius in any incarnation
[02:00:20] <hardie> So it seems like we are being asked "what are you willing to discard in order to use radius"?
[02:00:48] <randy_g> Or even "we use radius, hence we must trust the hops"
[02:02:24] <hardie> There is an issue with operator desires versus user desires, and choice either to make operators aware of the risks or lose interopability
[02:03:33] <hardie> Hannes now presents
[02:04:17] <hardie> Background discussed (how to address li/lo within radius protocol)
[02:05:06] <hardie> Different scenarios (user in home network, user in the visited network, infrastructure with and without proxies)
[02:05:34] <hardie> different parties involved, user/home & visited network, proxies, other entities
[02:06:18] <hardie> conflicting requirements: taxation might require that the home network knows the users' location/ user might not want to reveal its location information
[02:07:22] <hardie> Henning points out that the home network can know via ip location mappings
[02:07:33] <hardie> The difference is the passage through intermediaries
[02:09:49] <hardie> Hannes describes how they would go about merging the documents
[02:12:46] <hardie> Asks the group what it thinks
[02:13:00] <hardie> (Sorry, I have done a lousy job in this bit)
[02:13:17] <hardie> Henning talks about how the privacy sensitive information is linked to an identity
[02:13:51] --- memo56 has left: Replaced by new connection
[02:14:01] <hardie> He also wants to be clear what the privacy concern is versus existing data distribution (again with the traceroutes)
[02:14:03] --- memo56 has joined
[02:15:15] <hardie> Privacy hell rings for henning (1,2,3)--in other words, authentication mechanism and identities presented getting tied
[02:16:13] <hardie> brian believes the drafts should be combined and some low-hanging fruit picked
[02:16:32] <hardie> brian reminds that there will be fallout from voip emergency calling
[02:17:09] <hardie> points out that format for that will be ubiquitous
[02:17:21] <hardie> starting there, rather than from radius biling formats
[02:17:33] <hardie> It will be there, and the same people will have to know it.
[02:19:35] <hardie> Allison points out that threats analysis and "do not distribute"; special case any of our requirements is not a good idea. Rapid analysis on some of the scenarios is not a good idea; we need to be very very careful here.
[02:21:04] --- memo56 has left
[02:21:09] <hardie> radius doesn't go to the end user...that's why there is a "hard" issue
[02:22:10] <SAH> Allison and Ted debate the issue...
[02:22:14] <randy_g> Alison: subscriber contracts can include rules
[02:22:30] <randy_g> Ted: user might not trust carrier [ did I get that right? ]
[02:23:16] <randy_g> Ted; you have requirements that are bloody nice but you're not going to get in short term
[02:23:43] <randy_g> Ted: e.g., short packets won't be possible without compression
[02:24:09] <randy_g> Ted: same format as VoIP for emerg. calls
[02:24:18] --- rlbob has left
[02:24:45] <randy_g> Comment: a huge XML BLOB will degrade RADIUS performance by 10x
[02:25:41] <randy_g> Chairs call for new business
[02:25:46] --- SAH has left
[02:25:51] <randy_g> Seeing none, the meeting is closed
[02:26:16] <jmorris> Ted, great notes .... thanks
[02:26:31] <jmorris> Ted, SAH, Randy, others....
[02:26:50] --- sakai has left
[02:27:47] <jmorris> but Ted, you should have done the kitty for us in ASCII ..... time for sleep in D.C.....
[02:27:52] --- jmorris has left
[02:28:16] <hardie> sleep well guys
[02:28:20] --- hardie has left
[02:28:26] --- jm has left
[02:35:48] --- anewton has left
[02:36:08] --- randy_g has left: Disconnected
[07:59:13] --- LOGGING STARTED