[11:16:19] --- gcaron has joined
[11:17:17] --- gcaron has left
[11:46:48] --- gcaron has joined
[11:47:02] --- gcaron has left
[11:51:39] --- sommer@jabber.cc has joined
[11:52:40] --- gcaron has joined
[11:53:25] --- gcaron has left
[11:53:59] --- gcaron has joined
[12:00:20] --- jerome.grenier has joined
[12:00:56] --- Barbara has joined
[12:01:01] --- richard.barnes has joined
[12:01:12] <richard.barnes> good morning, everybody
[12:01:27] <Barbara> Afternoon here :)
[12:01:48] <richard.barnes> eh, whatever :)
[12:02:26] <gcaron> Good morning Richard.
[12:02:36] <richard.barnes> Milestones:
[12:02:45] <richard.barnes> Things are progressing
[12:03:55] <richard.barnes> Agenda slide
[12:04:18] <richard.barnes> Hannes says there's nothing to say about the L7LCP PS, so we're taking his time back
[12:04:30] <richard.barnes> Instead will talk about the location-conveyance ad-hoc from last night
[12:04:45] <richard.barnes> Other bashes from the jabber room?
[12:05:01] <gcaron> held extension?
[12:05:14] <richard.barnes> which one?
[12:05:27] <richard.barnes> Daviel: Maybe talk about HTML tags for location?
[12:05:28] <Barbara> Right, HELD ID extension
[12:05:36] --- stephen.morris has joined
[12:05:45] <richard.barnes> Sparks: HTML if we have time
[12:05:55] <gcaron> the held extension draft. Will it be discussed since we got time back?
[12:06:08] <richard.barnes> Winterbottom: Switch the last two items
[12:06:14] <richard.barnes> Sparks: We'll see
[12:06:33] <richard.barnes> Hannes: Can we remove the geoloc policy discussion? I don't have any proposals to make a useful debate here
[12:06:48] --- ray has joined
[12:07:02] <richard.barnes> Guy/Barbara: What should I say at the mic?
[12:07:19] <richard.barnes> Resolved: policy discussion moved to later on the list
[12:07:28] <Barbara> Can we add HELD identity extension discussion.
[12:07:30] <gcaron> can the 10 mins be use for held extension draft discussion
[12:07:57] --- andrew.daviel has joined
[12:08:28] <richard.barnes> ok, request stated
[12:08:29] --- sal has joined
[12:08:37] <gcaron> thx
[12:08:49] <richard.barnes> updated agenda slide has html, identity as "remaining time" items
[12:08:59] --- stephen.morris has left
[12:08:59] <Barbara> Thanks
[12:09:16] <richard.barnes> Mary Barnes talking about HELD
[12:09:34] <richard.barnes> Status slide
[12:09:34] --- JamesWinterbottom has joined
[12:09:38] --- stephen.morris has joined
[12:09:41] <richard.barnes> (do people have slides and/or audio?)
[12:09:50] --- ray has left
[12:09:54] <richard.barnes> Changes slide
[12:09:54] --- ray has joined
[12:09:57] <gcaron> audio yes, slides no
[12:10:55] <Barbara> Yes to both. Guy, go to https://datatracker.ietf.org/meeting/70/materials.html#wg-geopriv
[12:11:06] <richard.barnes> Thx barbara
[12:11:15] <richard.barnes> Changes singe -02 slide
[12:11:48] <gcaron> Got it thx
[12:11:58] <richard.barnes> Second changes since -02 slide
[12:12:11] <richard.barnes> Minor issues slide
[12:12:49] <richard.barnes> Winterbottom: In XML, "attribute" and "element" are different things
[12:13:02] <richard.barnes> Mary: So we'll keep those, and drop "parameter"
[12:13:33] --- isudo has joined
[12:14:30] <richard.barnes> Barnes: COuld you clarify what goes in the lbyr/lbyv sections
[12:14:39] <richard.barnes> Mary: Just what's already there, split into two seconds
[12:14:58] <richard.barnes> Second issues/discussion slide
[12:15:42] --- yuji has joined
[12:15:49] <richard.barnes> Winterbottom: This is an issue for all the LCPs
[12:16:06] <richard.barnes> Blatherwick: Want to correct that all LCPs have problems with VPNs
[12:16:15] <JamesWinterbottom> Not a problem for LLDP
[12:16:36] <richard.barnes> [James: Why not?]
[12:16:47] <richard.barnes> ['cause it can't come over the vpn?
[12:17:07] --- Lisa has joined
[12:17:09] <richard.barnes> Henning: Are you registering numeric codes or tags?
[12:17:15] <richard.barnes> Mary: Tags.
[12:17:42] <richard.barnes> James: Instead of having an enumerated type, just have a pointer to the IANA registry
[12:17:43] <andrew.daviel> How to add a slide (PDF) to online agenda ? Or do I switch laptops ?
[12:18:11] <richard.barnes> Next Issues/discussion slide
[12:22:03] <richard.barnes> Linsner: Security points to draft-barnes-geopriv-lo-sec
[12:22:29] <richard.barnes> Barnes: Let's address specific things here, then big things in lo-sec
[12:23:06] <richard.barnes> Peterson: Need to have a story for the IESG
[12:23:20] <richard.barnes> Mary: Guess we need to have a normative reference to lo-sec
[12:23:39] <richard.barnes> Winterbottom: Hum to adopt lo-sec as a wg item?
[12:24:45] <richard.barnes> Sparks: Action for group: Go read lo-sec
[12:25:01] <richard.barnes> Action for Sparks: Call for consensus on adopting lo-sec soon
[12:25:51] <richard.barnes> Marshall: A LIS could have many interfaces. HELD shouldn't constrain a LIS that doesn't do HELD
[12:25:51] --- Lisa has left
[12:25:53] <richard.barnes> Mary:
[12:26:05] <richard.barnes> We're just stating requirements for LISs that DO support HELD
[12:26:32] <richard.barnes> [FYI: I'm using "Mary" for Mary Barnes, and "Barnes" for Richard Barnes]
[12:27:01] <richard.barnes> Next Issues / discussion slide
[12:27:02] <richard.barnes> URI
[12:27:11] <richard.barnes> Henning: a couple of issues here
[12:27:20] <richard.barnes> protocol recommendations / operational issues
[12:28:17] <richard.barnes> Peterson: What we want to capture is the logical function of a HELD server
[12:29:14] <richard.barnes> Mary: We'll make a pass through the doc looking for those sorts of issues
[12:29:48] <richard.barnes> Way Forward slid
[12:30:21] <richard.barnes> (slide)
[12:30:40] <richard.barnes> Sparks: Everyone go ahead and review the current rev of the document, the protocol's mostly done
[12:30:47] <richard.barnes> Plan to WGLC early part of 2008
[12:31:01] <richard.barnes> Probably assign detail reviewers, send email to Sparks to volunteer
[12:31:20] <richard.barnes> Next topic: Location conveyance ad-hoc from yesterday
[12:31:25] <richard.barnes> Sparks talking without slides
[12:31:48] <richard.barnes> GEOPRIV had a long discussion of the "recipient=" parameter
[12:31:59] <richard.barnes> Still a lot of disagreement over what the parameter's good for
[12:32:14] <richard.barnes> Conversation yesterday ended in Peterson agreeing to write a draft
[12:32:44] <richard.barnes> Peterson: What we're trying to do is create an indicator within PIDF-LO to say whether routing is permitted
[12:32:47] <richard.barnes> another binary flag
[12:33:01] <richard.barnes> main difficulty is distinguishing midpoints from endpoints in SIP
[12:33:22] <richard.barnes> RFC3693 had a much clearer idea as to who the recipient was
[12:33:55] <richard.barnes> retransmission-allowed assumes that there's a specific place that you meant to send this
[12:34:15] <richard.barnes> with SIP, that's not clear [i.e., you don't know where your request will end up]
[12:34:19] <richard.barnes> Ted signed up too
[12:34:32] <richard.barnes> Ted: Can I also characterize the draft?
[12:34:53] <richard.barnes> We had a frank and open exchange of views yesterday
[12:35:17] <richard.barnes> noone invaded Poland
[12:35:25] <richard.barnes> Should have a draft by Philly
[12:35:33] <richard.barnes> but there's a serious problem here:
[12:35:55] <richard.barnes> We need to describe in terms actionable by a SIP entity whether it can use a PIDF-LO
[12:36:05] <richard.barnes> Or we need to change the notion of permissions in PIDF-LO
[12:36:28] <richard.barnes> Expect to see more discussion, arm wrestling, jello wrestling in Philly
[12:36:50] <richard.barnes> Henning: One problem we've had is that the discussion is often fairly abstract
[12:37:01] <richard.barnes> And we have now a more concrete model of what happens to location information
[12:37:07] --- david.mark.jones has joined
[12:37:29] <richard.barnes> It would be helpful in the new draft to have a set of test cases, specific examples of "what you do in this case"
[12:38:17] <richard.barnes> The other question is that we're talking about two separate things
[12:38:51] <richard.barnes> technical security measures vs. legal privacy measures
[12:40:04] <richard.barnes> Are we trying to fit a legal round peg into a technical square hole?
[12:40:26] <richard.barnes> Maybe we could get some of the people who originally worked on this to come to Philly? It's close to DC
[12:40:48] <richard.barnes> Drage: One thing that keeps coming up is "we can't do this with tel: URIs"
[12:41:19] <richard.barnes> Maybe there's a more general problem to be addressed?
[12:41:32] <richard.barnes> Cullen: I don't have an answer to that, but if people want to advise, we're interested
[12:41:34] --- david.mark.jones has left
[12:42:06] --- david.mark.jones has joined
[12:42:35] <richard.barnes> Winterbottom taking the mic
[12:42:39] <richard.barnes> talking about LIS discovery
[12:42:45] <richard.barnes> currently at -03
[12:43:11] <richard.barnes> This draft is the merger of DHCP and U-NAPTR discovery drafts
[12:43:38] <richard.barnes> (History slide)
[12:43:48] <richard.barnes> (Slide: What does it describe?)
[12:44:39] <richard.barnes> Order designed so that you get the LIS closest to you
[12:44:45] <richard.barnes> (Slide: Who needs it?)
[12:45:14] <richard.barnes> (Slide: LIS discovery details)
[12:46:13] <richard.barnes> Important note: If you've got more than one network interface, you need to do it for every interfac
[12:46:20] <richard.barnes> (Slide: Way forward)
[12:46:41] <richard.barnes> Sparks: Hum to adopt the document as a wg item
[12:46:46] <Barbara> Hum. Yes to LIS discovery as WG item.
[12:46:49] <gcaron> hum for
[12:46:57] <jerome.grenier> hum for
[12:47:00] <richard.barnes> Many hums for, none against
[12:47:11] <richard.barnes> Seems like strong consensus, will confirm on the list
[12:47:27] <richard.barnes> Henning taking the mic: PIDF-LO dynamic
[12:47:43] <richard.barnes> (Slide: Title)
[12:47:56] <richard.barnes> Idea is to extend PIDF-LO to include dynamic features
[12:48:05] <richard.barnes> (Slide: Requirements & Use Cases)
[12:49:30] <richard.barnes> (Slide: Dynamic Feature elements)
[12:49:33] --- david.mark.jones has left
[12:50:22] <richard.barnes> (Slide: Example)
[12:50:30] <richard.barnes> (Slide: Indicating use ... )
[12:50:40] <richard.barnes> Open to suggestions about how to do this better
[12:50:53] <richard.barnes> Could also say "don't worry about indicating acceptance"
[12:51:09] <richard.barnes> But there's probably a more general discussion to be had as we add more extensions to PIDF-LO
[12:51:14] <richard.barnes> (Slide: Open Issues)
[12:52:14] <richard.barnes> Winterbottom: Could we specify a URN for that?
[12:52:29] <richard.barnes> Henning: That adds another URN registry to be maintained
[12:52:38] <richard.barnes> Unless there's a plausible case that we NEED other units
[12:52:57] <richard.barnes> User interface vs. on the wire
[12:53:04] <richard.barnes> Easy to convert for the UI
[12:53:11] --- andrew.daviel has left
[12:54:04] <richard.barnes> Daviel: Agree with that. Just stick with one unit; avoid additional syntax.
[12:54:55] --- franck.martin has joined
[12:55:40] <richard.barnes> Polk: Is this all this document covers? Just bearing / direction?
[12:55:48] <richard.barnes> Henning: Also speed and acceleration
[12:56:01] <richard.barnes> Polk: Talking about geopriv phase 2 has a bunch of these things
[12:56:11] <richard.barnes> Maybe we want more than this
[12:56:28] <richard.barnes> Henning: All these extensions are pretty orthogonal
[12:56:35] <richard.barnes> This seems like a useful small set
[12:57:22] <richard.barnes> Polk: Not opposed to this, just wonder if there's been some discussion from the geopriv phase 2 list
[12:57:29] <richard.barnes> Seem to remember 15-20 things
[12:57:40] <richard.barnes> Henning: I hope there aren't; if you find them send them.
[12:58:36] --- anabolism@jabber.org has joined
[12:58:43] <richard.barnes> Rohan: Draft needs to explain that this is explicitly 2-dimensional
[12:58:58] <richard.barnes> this could be relevent, e.g., if tracking an airplane
[12:59:50] <richard.barnes> Acceleration is weird to me; it's a vector, but it can also be rotational
[13:00:16] <richard.barnes> Should probably say "if there's an acceleration that's not of this type, you just can't express it in this doc"
[13:00:24] <richard.barnes> Winterbottom: Just call it "linearAcceleration"
[13:00:53] <richard.barnes> Drage: If we do this, then we have another rathole in location-conveyance error handling
[13:01:08] <richard.barnes> (Slide: Next steps) (has been up for a while)
[13:02:00] <richard.barnes> Henning: There are two choices to make in general.
[13:02:31] <richard.barnes> 1. I only get to ask for geo, and maybe i get dynamic stuff
[13:02:47] <richard.barnes> If I don't understand it, I ignore it
[13:03:04] <richard.barnes> 2. You explicitly say "please give me these extensions, and fail if you don't have them"
[13:03:21] <richard.barnes> 3. "Please give me acceleration, and if not, I still love you"
[13:03:35] <richard.barnes> [in Henningworld, 2=3?]
[13:03:46] <richard.barnes> Option 1 requires no changes
[13:04:02] <richard.barnes> If we think the other cases are important, we can add stuff to HELD, SIP location-conveyance, etc.
[13:04:41] <richard.barnes> Drage: Could imagine doing this with civic as well
[13:04:47] <richard.barnes> location is in civic, dynamic in geo
[13:05:30] <richard.barnes> Ted: The draft has a section on multiple location objects. Are you thinking of adding mechanisms to HELD to account for updates?
[13:05:51] <richard.barnes> There's actually broader discussion to be had on LbyR
[13:06:03] <richard.barnes> My inclination is to omit that particular section
[13:06:20] <richard.barnes> Oops, last two lines were Henning
[13:06:43] <richard.barnes> Rohan: All these things are continuous entities, so the filters work might be relevant here
[13:07:05] <franck.martin> newbie question: does this solve issues with emergency services re location of the VoIP call?
[13:07:23] <richard.barnes> [franck: I would say 'no']
[13:07:41] <richard.barnes> [franck: But I would need you to clarify what sort of issues you have in mind]
[13:07:52] <richard.barnes> Sparks: How many people have read this draft?
[13:07:59] <richard.barnes> (answer: everyone that was at the mic)
[13:08:14] <richard.barnes> Rohan: This kind of work is useful, but I would like to see the document more mature before we adopt it
[13:08:19] <Barbara> [franck: only if you're locked in the trunk of a moving car]
[13:08:34] <richard.barnes> Henning: I'll do a rev before Philly, maybe we can discuss adoption then
[13:08:59] <richard.barnes> Sparks: Is there anyone who things the WG should NOT waste time on this? [hum]
[13:09:13] <richard.barnes> Ted: This could also progress independently of the working group
[13:09:14] --- andrew.daviel has joined
[13:09:58] <richard.barnes> James Polk taking the stage
[13:10:11] <Barbara> Without slides
[13:10:18] <richard.barnes> Didn't post slides beforehand, just handed USB drive to Sparks
[13:10:37] <Barbara> Will someone post to website?
[13:10:47] --- mlepinski has joined
[13:10:48] <franck.martin> [Barbara: the main issue with VoIP is that it cannot be used for emergency, because emergency services cannot locate the caller, which regulators want in the spec, caller location]
[13:10:58] <richard.barnes> [Barbara: Don't think that's possible while he's presenting]
[13:11:59] <Barbara> [franck: have you read the ecrit documents? Like phonebcp and framework?
[13:12:24] <franck.martin> [Barbara: no I'm a newbie, I need pointers ;) ]
[13:13:47] <richard.barnes> Polk is proposing a DHCP option to provision out Location URIs
[13:13:59] <richard.barnes> Peterson: Like the direction.
[13:14:22] <richard.barnes> Winterbottom: In the other two DHCP drafts, we talk about not providing the option unless it's specifically asked for. This one should do it too.
[13:14:31] <richard.barnes> Polk: Yes, certainly. Will clarify
[13:14:55] <mlepinski> [Franck: http://tools.ietf.org/html/draft-ietf-ecrit-framework-04 is a great starting point for information on emergency calling.]
[13:14:58] <richard.barnes> Ted: Agree this is a good start. Instead of talking about harmful URIs, just specify the URIs people should expect
[13:14:59] --- sal has left
[13:15:30] <richard.barnes> Sparks: Speak to the positives; don't try to enumerate all the bad stuff
[13:15:37] <franck.martin> [mlepinski: thx]
[13:16:20] <richard.barnes> Hannes: Needs some more work on the security section; probably boils down to link-layer security
[13:17:14] <mlepinski> James: Does Location by Reference need more security than Location by Value (in DHCP)
[13:17:41] <mlepinski> Hannes: Location by Reference has additional security concerns because it could be used for tracking
[13:17:56] <mlepinski> Sparks: Take this security discussion to the list
[13:18:37] <mlepinski> James: Location server can enforce privacy rules on de-reference to address security concerns
[13:19:25] <mlepinski> Rohan: Concern about the size of this DHCP option
[13:20:22] <mlepinski> James: I'll articulate the size limitation in the document
[13:22:46] <mlepinski> Barnes: The security concerns depend on the properties of the URI (e.g. access controls and lifetime of reference)
[13:23:24] <mlepinski> Hannes: Possession of the reference is equivalent to possession of the location
[13:23:30] <mlepinski> James: Disagrees with Hannes
[13:24:00] <mlepinski> James: Will work with Richard to improve security section
[13:24:39] <mlepinski> Jon: Hannes are you disagreeing with this deliverable?
[13:24:49] <mlepinski> Hannes: Thsi works if you have link-layer security
[13:24:58] <mlepinski> Jon: Then not a very applicable mechanism
[13:26:42] <mlepinski> Lisner: This is no different than receiving a URI via Held
[13:26:49] <mlepinski> Henning: Not quite true
[13:27:00] <JamesWinterbottom> I said that too
[13:27:13] <richard.barnes> Sparks
[13:27:21] <richard.barnes> :
[13:27:21] <mlepinski> Yes, my apology James :->
[13:27:42] <richard.barnes> Lisa: Could you have a hum on the understanding of the security issues?
[13:28:10] <richard.barnes> AFAICT, the security model is different from HELD
[13:28:55] <richard.barnes> Gellens: In addition to the mechanism for authenticating dereference, there's also the "pawn ticket" model from LEMONADE
[13:29:15] <richard.barnes> There's an RFC that describes ithis
[13:29:29] <richard.barnes> Lisa: This may already be equivalent to the "pawn-ticket" URL
[13:30:49] <richard.barnes> Transitioning to Henning's presentation
[13:31:32] <mlepinski> [Franck: The goal of the framework document is to be understandable by people who haven't been following ECRIT and GEOPRIV for years, if you have any suggestions about improving the readabilitry of the ecirt framework document, please send your comments to ecrit@ietf.org ]
[13:31:39] <richard.barnes> Henning:
[13:32:09] <richard.barnes> URLs have different types of access control: Randomized URL, IP address checking, authentication/authorization
[13:35:14] <Barbara> What is the current topic? Is this on the agenda, and are there slides?
[13:35:56] <ray> [scribe is in the queue - these are new discussions not on the original agenda]
[13:36:13] <anabolism@jabber.org> Barbara--this is within the agenda item discussion of draft-polk-geopriv-dhcp-lbyr-uri-option-02 (location-by-reference URI via DHCP)
[13:36:22] <richard.barnes> Right, we're flowing from DHCP URL discussion to more general URL discussion
[13:36:49] <anabolism@jabber.org> The specific topic is the question of security aspects of location URI in general, and if there are differences when URI is provided via DHCP
[13:37:42] <richard.barnes> Peterson: Comment on the DHCP draft is that an attacker has to associate the URI with an endpoint
[13:38:03] <richard.barnes> [did anyone else understand what Jon just said?]
[13:38:42] <richard.barnes> I think that Jon just said that the same thing that makes authentication hard (lack of a correspondence between MAC and IP addr) also makes the attacker's job difficult
[13:39:02] <richard.barnes> Hannes: If you compare HELD to DHCP, the important difference is that HELD has TLS
[13:39:17] <richard.barnes> So far, we haven't really differentiated between types of URIs
[13:39:52] <richard.barnes> Henning: Presenting on LbyR discussions that have been going on
[13:40:07] <richard.barnes> Location retrieval: 3 types of data
[13:40:12] <richard.barnes> target + location + time
[13:40:15] <richard.barnes> target + time
[13:40:20] <richard.barnes> target
[13:40:34] <richard.barnes> three types of "keys into the location database"
[13:42:48] <richard.barnes> fourth option: log retrieval, ask for "where the target was between 18:00 and 19:00"
[13:44:08] <richard.barnes> conceptually a "cone": (target over time), (target "now" or target "then"), (target, time, location)
[13:44:24] <richard.barnes> Hannes: I think this describes the issue well
[13:45:27] <mlepinski> Winterbottom: We can't necessarily cover all issues with one scheme, but we need to document the issues and applicability
[13:46:11] <mlepinski> Lisner: Question about DHCP case
[13:47:35] <mlepinski> Henning: There are really two DHCP cases: One where you can map MAC addresses to an identity and the URI corresponds to the identity, and the second where the URI always returns a constant location with no associated identity
[13:48:20] <mlepinski> Lisner: Existing DHCP options have no identity, hence low privacy risk
[13:48:34] <mlepinski> Jon: Thanks, great analysis!
[13:48:53] <mlepinski> Jon: What is actionable for DHCP?
[13:49:32] <mlepinski> Henning: Not try to pick on DHCP, this applies to any protocol that delivers URIs
[13:51:09] <mlepinski> Barnes: This is a great taxionomy of URI types, but this is orthoganol to access control options for Henning's earlier slide ... it is the tuple of URI-type and Access Control that determines privacy risk
[13:51:17] --- andrew.daviel has left
[13:52:24] <mlepinski> Jon: There are considerations that are generic to all L-by-R and these considerations should be captured somewhere
[13:53:06] <mlepinski> Henning: Depricate "L-by-R" except as a vague umbrella term and start using more precise terms
[13:53:31] <mlepinski> Winterbottom: Do these considers belong in the existing L-by-R requirements document
[13:53:52] <mlepinski> Barnes: Not sure this needs to go in the L-by-R document
[13:54:38] <richard.barnes> Sparks: Did this discussion inform the group enough to tell whether the DHCP draft is something we want to take up?
[13:55:00] <richard.barnes> Cullen: My understanding of that conversation is that "we need URIs, we need them in DHCP, we need to discuss their properties"
[13:55:06] <richard.barnes> Sounds like there's no open issues
[13:55:22] <richard.barnes> Peterson: The one thing could be whether you want to have a mechanism for requesting one of the types
[13:55:29] --- yuji has left: Replaced by new connection
[13:55:31] <richard.barnes> Hannes: I think we can make a decision on this
[13:55:35] --- yuji has joined
[13:56:09] <richard.barnes> Linsner: What Jon's saying requires interaction outside of DHCP
[13:56:20] <richard.barnes> Peterson: No, you're just configuring the LbyR
[13:56:51] <richard.barnes> Winterbottom: Are we planning for the DHCP to support all of Henning's types of URIs?
[13:57:26] <richard.barnes> Peterson: It would be good for clients to be able to request one of the types, don't want to restrict to just one
[13:57:47] <richard.barnes> We are in a position to go forward with this
[13:58:04] <richard.barnes> Sparks: Calling three questions
[13:58:15] <richard.barnes> 1. Adopting the draft
[13:58:18] <richard.barnes> 2. Not adopting the draft
[13:58:27] <richard.barnes> 3. Do nothing, leave it as it is now
[13:58:35] <richard.barnes> Hum for 1
[13:58:43] <richard.barnes> Hum for 2
[13:58:54] <richard.barnes> Hum for 3
[13:59:15] <richard.barnes> (raising hands)
[13:59:19] <richard.barnes> 6 for defer
[13:59:31] <richard.barnes> Several more for adopt
[13:59:44] <richard.barnes> Karl Heinz Wolf taking the mic
[13:59:45] <mlepinski> About twice as many for adopt
[13:59:52] <richard.barnes> Civic address considerations for Austria
[14:00:08] <richard.barnes> (Alexander Mayrhofer also up front)
[14:00:19] <richard.barnes> [are these slides on the web?]
[14:00:34] <mlepinski> Resolution on DHCP: Adopt as working group item subject to confirmation of rough concensus on the list
[14:01:00] <richard.barnes> Goal of Karl's draft: Uniform usage of RFC 4776 civic address elements within a country
[14:01:14] <richard.barnes> Consistent mapping scheme
[14:01:30] <richard.barnes> (Slide: What is in the draft?)
[14:01:52] <richard.barnes> (Slide: Problem: House Numbers)
[14:02:32] <richard.barnes> Austrian house numbers have more components even than are available in revised-civic-lo
[14:02:53] <richard.barnes> (Slide: Mapping to PIDF-LO)
[14:04:45] <richard.barnes> [can we just get the Austrians to change the standard?]
[14:04:57] <richard.barnes> JDR: Can we just get the Austrian postal system to comply to PIDF-LO?
[14:05:31] <richard.barnes> (Slide: Austrian Address Code)
[14:06:13] <richard.barnes> Address codes are a numeric code that completely identifies a civic location
[14:06:19] <richard.barnes> (Slide: Next steps)
[14:06:35] <richard.barnes> Henning: We have an element for this code that came out of Japanese requirements
[14:07:12] <richard.barnes> Personally not be in favor of providing only the address code
[14:07:28] <richard.barnes> Since it's not human-readable, end users can't recognize that it's bad
[14:07:35] --- andrew.daviel has joined
[14:07:55] --- stephen.morris has left
[14:08:06] <richard.barnes> Mayrhofer: Also thought about having a URN space to identify address components
[14:08:38] <richard.barnes> Henning: As far as house numbers, could define HN1, ... HNn, but Austria is a small population relatively speaking
[14:08:48] <richard.barnes> We would want to validate that other places have a similar problem
[14:09:36] <richard.barnes> US, DE have problems with house number ranges
[14:10:16] <richard.barnes> Mayrhofer: The funniest example is there are some addresses that say they're across from another address
[14:11:19] <richard.barnes> Henning: Also want to say that the "Concatenate elements" solution is more or less equivalent to the <HN*> solution
[14:11:54] <richard.barnes> If we decide not to do <HN*>, then maybe you can create a well-defined way to do concatenation
[14:12:18] <richard.barnes> Winterbottom: Address ranges are common to lots of countries
[14:12:48] <richard.barnes> Mayrhofer: How should we proceed with this document?
[14:13:05] <richard.barnes> Winterbottom: I think this is a good reference document and would support picking it up as informational
[14:13:13] <richard.barnes> Do cringe a little at every country doing this.
[14:15:19] <richard.barnes> Winterbottom taking the mic
[14:15:23] <richard.barnes> HTTP Dereference
[14:16:11] <richard.barnes> Slide: Background
[14:16:30] <richard.barnes> This is a combination of a document by James and one by Hannes and Henning, both of which were based on Ted's straw-man
[14:16:45] <richard.barnes> Slide: Scope
[14:17:26] <mlepinski> Barnes: The dereference server could be distinct from the configuration server
[14:17:38] <mlepinski> Winterbottom: Sure, but of course they need some kind of connection
[14:17:39] <richard.barnes> Slide: Content description
[14:18:38] <richard.barnes> Slide: Requirements
[14:18:55] <richard.barnes> They've squared this proposal against 3693 and against Roger Marshall's lbyr requirements doc
[14:19:06] <richard.barnes> Slide: What next?
[14:19:34] <richard.barnes> Who's read the document?
[14:19:36] <Barbara> I plan to read it.
[14:19:38] <richard.barnes> not many in the room
[14:19:45] <richard.barnes> not enough to make a decision here
[14:19:52] <gcaron> It is on my do-to list
[14:20:08] <richard.barnes> so we all need to go read the draft, then we can talk about adopting it
[14:20:37] <richard.barnes> Winterbottom now talking about uncertainty
[14:20:49] --- ray has left
[14:21:42] <richard.barnes> Slide: Intent
[14:22:20] <richard.barnes> Slide: Quantitative vs. Qualitative terms
[14:22:28] <richard.barnes> These terms are taken from other SDOs
[14:22:40] <richard.barnes> So it's good to remain consistent with the rest of the world
[14:23:00] <richard.barnes> Uncertainty and confidence are quantitative terms with measurable values
[14:23:05] <richard.barnes> Accuracy is qualitative
[14:23:21] <richard.barnes> Slide: What are uncertainty and confidence?
[14:23:45] <richard.barnes> uncertainty = magnitude of error, usually a range
[14:23:56] <richard.barnes> confidence = probability that target's within the uncertainty
[14:24:14] <richard.barnes> Slide: PDFs
[14:25:17] <richard.barnes> Confidence in a point is zero; need to be careful of points
[14:25:24] <richard.barnes> Slide: (no title)
[14:25:33] <richard.barnes> Bigger the uncertainty, the higher the confidence
[14:25:49] <richard.barnes> Civic addresses express uncertainty, defined by presence or absence of fields
[14:25:52] <richard.barnes> Confidence is harder
[14:26:27] <richard.barnes> Henning: This is one problem that's left unspoken in both cases -- is there "confidence" in the confidence value?
[14:26:58] <richard.barnes> There's a lot of stuff behind that one number -- highly dependent on an accurate understanding of how the measurement is made
[14:27:44] <richard.barnes> This is especially true with civic
[14:28:10] <richard.barnes> Clearly not the case that real geo situations have a nice gaussian distribution
[14:28:48] <richard.barnes> Winterbottom: Just to restate: Confidence associates back to the method
[14:29:34] --- mlepinski has left: Disconnected
[14:29:41] <richard.barnes> GPS actually measures pseudo-ranges, so it can do its own confidence explicitly
[14:30:01] <richard.barnes> Marshall: I thought this draft was really well written, Martin hit a triple
[14:30:21] <richard.barnes> Not a home run because civic addresses don't have a good definition of uncertainty
[14:30:38] <richard.barnes> Winterbottom: They do have an uncertainty, not sure we can quantify it reliably
[14:31:02] <richard.barnes> Marshall: For civic, you get a qualitative uncertainty, not quantitative
[14:31:14] <richard.barnes> Winterbottom: So, strip out civic, make the draft geo only?
[14:33:09] --- jerome.grenier has left
[14:33:10] <richard.barnes> Polk: Don't think the semantics are clear enough for this to be adopted
[14:33:41] <richard.barnes> Peterson: I made sure that epistemology were in the scope of this working group!
[14:34:25] <richard.barnes> Hannes: Generally good. Think you should try to decouple from geopriv policy draft
[14:35:18] <richard.barnes> Linsner: Unsure about the application of uncertainty
[14:35:46] <richard.barnes> Don't dispute that there's uncertainty and confidence, but are they relevant to applications
[14:35:57] <richard.barnes> Winterbottom: Geo-shape is intimately involved with those concepts
[14:36:11] <richard.barnes> Sparks: Some announcements to make
[14:36:22] <richard.barnes> 1. Going to try to pull together an interim in late January 2008
[14:36:38] <richard.barnes> 2. Richard Barnes has agreed to help manage GEOPRIV as secretary
[14:36:48] <richard.barnes> 3. If you haven't signed blue sheets, sign them
[14:36:51] --- anabolism@jabber.org has left
[14:37:05] <richard.barnes> ok, stopping the scribe stream
[14:37:09] <richard.barnes> have a nice day!
[14:37:12] <Barbara> Thanks, Richard
[14:37:22] <richard.barnes> glad to help
[14:37:23] <gcaron> Thanks Richard and congratulations!
[14:37:27] <richard.barnes> thanks guy!
[14:37:41] --- Barbara has left
[14:37:42] --- gcaron has left
[14:37:47] --- JamesWinterbottom has left
[14:38:34] --- richard.barnes has left
[14:39:16] --- isudo has left
[14:46:27] --- sommer@jabber.cc has left
[15:02:35] --- yuji has left
[15:06:08] --- andrew.daviel has left
[16:14:12] --- franck.martin has left
[19:08:32] --- richard.barnes has joined
[19:37:15] --- richard.barnes has left