[00:39:16] --- richard.bzdega has joined
[00:40:00] --- richard.bzdega has left
[02:29:05] --- rob.sired has joined
[02:29:49] <rob.sired> test
[02:31:37] --- rob.sired has left: Logged out
[02:31:49] --- rob.sired has joined
[02:34:08] * rob.sired has set the topic to: IETF 67 geopriv meeting
[02:35:02] --- rob.sired has left: Logged out
[02:35:12] --- rob.sired has joined
[02:35:43] <rob.sired> test
[02:38:18] --- rob.sired has left: Replaced by new connection
[02:41:14] --- rob.sired has joined
[02:41:24] --- rob.sired has left
[02:42:32] --- rob.sired has joined
[02:44:11] --- rob.sired has left
[02:44:40] --- rob.sired has joined
[02:45:11] --- rob.sired has left
[02:45:52] --- rob.sired has joined
[02:46:49] --- rob.sired has left
[03:22:21] --- hak has joined
[03:25:58] --- sschroedl has joined
[03:26:10] <hak> hi stevge.
[03:26:20] <hak> what's de haps.
[03:26:20] <sschroedl> Hnagggass
[03:26:29] --- joelja has joined
[03:26:41] <joelja> lets take this place over
[03:26:44] <hak> where's the sheep"?
[03:26:53] <sschroedl> all your bases belong to us
[03:26:59] <hak> screw you guys I'm going home...
[03:27:02] --- hak has left
[03:35:45] --- rob.sired has joined
[03:36:07] <rob.sired> test
[03:36:12] <sschroedl> test back
[03:36:17] <rob.sired> tks
[03:36:20] <sschroedl> np
[03:46:59] --- Barbara has joined
[03:50:55] --- richard.barnes has joined
[03:54:18] --- gcaron has joined
[03:54:22] --- jerome.grenier has joined
[03:55:13] --- HannesTschofenig has joined
[03:56:33] --- anewton has joined
[03:58:52] <HannesTschofenig> Henning and Jon are chairing today
[03:59:30] <anewton> Is the meeting in Congress I?
[03:59:37] --- mlepinski has joined
[03:59:51] <HannesTschofenig> Yes.
[04:00:08] --- Fadi has joined
[04:02:24] <anewton> Thank you Cullen!
[04:02:42] --- martin.dawson has joined
[04:02:54] <richard.barnes> Good morning, my name is richard, and I'll be your scribe this morning
[04:03:13] <richard.barnes> Agenda bash:
[04:03:57] <richard.barnes> Brian Rosen: Moves to rearrange agenda to not spend time on location signing, use on L7LCP today to try to get somewhere
[04:04:39] <richard.barnes> Hum for objectsions -- no hums. Motion stands
[04:04:48] --- m_ersue has joined
[04:05:33] --- dominique.asselin has joined
[04:05:46] --- jiangxingfeng has joined
[04:05:55] --- isudo has joined
[04:06:06] --- isudo has left
[04:06:09] <richard.barnes> James Polk: Request that the chairs reserve a block of time for future discussion
[04:06:19] --- isudo has joined
[04:06:31] <richard.barnes> Peterson: Cullen has time reserved, we can have time later as possible
[04:06:33] --- pdube has joined
[04:06:37] --- ysuzuki has joined
[04:06:37] --- axelm has joined
[04:08:02] <richard.barnes> document status:
[04:08:17] --- ekr has joined
[04:08:18] <richard.barnes> Cullen: Only interesting one is Radius: Got significant coments from radext that need resolution
[04:08:19] <anewton> The document status is on the agenda.
[04:08:30] <richard.barnes> yes, that's on the projector now
[04:08:34] <anewton> http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt
[04:08:42] <anewton> No, the original published agenda.
[04:08:44] --- cullenfluffyjennings@jabber.org has joined
[04:09:12] --- berry has joined
[04:10:03] <richard.barnes> James: resolved most of the comments, should have last call after this meeting on revised civic
[04:10:36] <richard.barnes> Brian: Provision of multiple locations continues to pop up
[04:10:56] <richard.barnes> And several documents have independent text about multiple locations
[04:11:17] <richard.barnes> Get comments in if you have any about this.
[04:11:18] --- ShoichiSakane has joined
[04:11:39] <richard.barnes> Cullen Jennings taking the mic to talk about GEOPRIV futures
[04:12:07] --- Lukisan has joined
[04:12:25] --- jiangxingfeng has left
[04:12:49] --- otmar has joined
[04:13:02] <richard.barnes> We've done a lot of work, design teams; got a lot of "facts on the ground"
[04:13:12] <richard.barnes> we've got a lot of information, let's put some stakes in the ground
[04:13:21] --- ben has joined
[04:13:22] <richard.barnes> lets take lots of hums, make some decisions today
[04:13:35] <richard.barnes> LCP has been a big topic
[04:13:42] --- m_ersue has left
[04:14:05] <richard.barnes> WG agreed on updated milestones a while back, but haven't been approved because the AD wanted to see today what priorities really were
[04:14:13] <richard.barnes> See if we could get some of this work done first
[04:14:23] <richard.barnes> Pluralism of LCP protocols
[04:14:32] <richard.barnes> Agreements that we're going to do more than one
[04:14:37] <richard.barnes> want a hum on this
[04:14:56] <richard.barnes> Rohan: Do you mean more than one L7LCP or more than one LCP in general?
[04:14:58] --- hakem.habib has joined
[04:15:02] --- jiangxingfeng has joined
[04:15:08] <richard.barnes> More than one in general, yes, but also more than one L7
[04:15:17] <richard.barnes> SIP? HTTP?
[04:15:31] <richard.barnes> Rohan: And you mean here Configuration, and not Conveyance
[04:15:35] <richard.barnes> Cullen: Yes
[04:16:09] <richard.barnes> Brian: I've bemoaned the fact that we need more than one, but there's too much diversity in networks
[04:16:17] <richard.barnes> Brian: Thought we'd made that decision
[04:16:45] <richard.barnes> James: LCP requirements draft indicates that we need another
[04:16:56] <richard.barnes> (sorry, last one was James Winterbottom)
[04:17:14] <richard.barnes> Polk: Need to acknowledge that there's more than one, just not in the IETF (LLDP)
[04:17:19] --- ben has left
[04:17:41] <richard.barnes> Henning: Who is in favor of >1 additional IETF LCP, in addition to DHCP?
[04:17:48] <Barbara> Hum
[04:18:05] <gcaron> hum
[04:18:08] <richard.barnes> Hums in the jabber room?
[04:18:10] <martin.dawson> hum
[04:18:12] <jerome.grenier> hum
[04:18:15] <hakem.habib> hum
[04:18:16] <Fadi> hum
[04:18:19] <berry> hum
[04:18:21] <Lukisan> hum
[04:18:22] <HannesTschofenig> hum
[04:18:26] <rob.sired> hum
[04:18:27] <jiangxingfeng> hum
[04:18:27] --- ben has joined
[04:18:28] <dominique.asselin> hummmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
[04:18:29] <pdube> hum
[04:18:35] --- rbzdega has joined
[04:18:50] --- schulzrinne has joined
[04:19:00] <richard.barnes> So noted at the mic
[04:19:03] --- hardie@jabber.psg.com has joined
[04:19:11] --- rohan has joined
[04:19:13] <richard.barnes> Consensus called in favor of the proposal
[04:19:33] <richard.barnes> Cullen: Only solution that I've seen on a subscribe-based approach is a SIP-based approach
[04:20:01] <richard.barnes> Hum on SIP-based approach to meet subscription requirements?
[04:20:26] <richard.barnes> Henning: To add some technical explanation, this is essentially presence, plus possibly a different identifier
[04:20:48] <richard.barnes> Peterson: Hum on SIP approach without many other assumptions
[04:20:58] <richard.barnes> (not actually holding hum yet)
[04:21:07] <richard.barnes> Brian: Context is still LCP, right?
[04:21:17] --- jfischl has joined
[04:21:18] --- kafka-j31415927 has joined
[04:21:27] <richard.barnes> Brian: If this is something that we say yes to, we're expanding the set of things that all phones must do
[04:22:11] <HannesTschofenig> Are we humming on the LocationRef?
[04:22:17] <richard.barnes> No humming right now.
[04:22:24] <richard.barnes> This is all LCP discussion
[04:22:31] --- hak has joined
[04:22:38] <anewton> No the question is about a subscribe feature in LCP.
[04:22:50] <richard.barnes> Rohan: Thought this was fine until you said LCP
[04:22:50] --- hak has left
[04:22:53] <anewton> Nobody mentioned specifically LocationRef.
[04:23:07] <HannesTschofenig> Why not?
[04:23:12] <richard.barnes> Rohan: Thought we had a consensus that a host be able to retreive/subscribe over sip
[04:23:24] <anewton> Because Cullen isn't trying to be specific about drafts.
[04:23:34] <HannesTschofenig> Ok
[04:23:39] <richard.barnes> Rohan: Didn't think that we had any requirements for a target to be able to do anything outside of subscribing to a reference, just like any other endpoint
[04:23:57] <richard.barnes> [andy: conversely, he's trying not to be specific]
[04:24:14] <richard.barnes> Henning: There seem to be two proposals, direct vs indirect
[04:24:31] <richard.barnes> Direct: WIthout having an AOR relation with the access net, can subscribe to location
[04:24:40] <richard.barnes> Indirect: LCP provides a URL to accomplish that goal
[04:25:14] <richard.barnes> Perhaps we could decide between these two
[04:25:24] <richard.barnes> Peterson: Is one of these discovery?
[04:25:34] <richard.barnes> Henning: No, you need server discovery in either case
[04:25:59] <richard.barnes> Rohan: One is a SIP subscribe with just the URI, the other is a subscription where you provide the identifiers to the LIS
[04:26:18] <richard.barnes> Keith: THought we had prior WG agreement that the terminal has to implement all of these. Is that being overridden?
[04:26:31] <richard.barnes> Henning: That discussion seems to havebeen in ECRIT, in the phonebcp
[04:26:55] <richard.barnes> Brian: Yes, in particular, it's not GEOPRIV's role to classify its work as suitable for a particular use
[04:27:10] <richard.barnes> We could make lots of LCPs and ECRIT could require >1
[04:27:22] <richard.barnes> We should keep that in mind, but that shouldn't limit what we do
[04:27:32] <richard.barnes> Henning: We should separate those out
[04:28:20] <richard.barnes> Hum: Do we want to specify a protocol profile or extension within the SIP context to allow subscription to its location?
[04:28:33] <richard.barnes> Rohan: Direct, indirect or both?
[04:28:38] <richard.barnes> Henning: Both.
[04:28:40] --- xmlscott has joined
[04:28:44] <richard.barnes> Hum now:
[04:28:54] <HannesTschofenig> I don't really understand what it is about.
[04:29:05] <richard.barnes> All hums are in favor
[04:29:11] <HannesTschofenig> For what?
[04:29:14] <otmar> you're not alone, hannes
[04:29:14] <HannesTschofenig> For both?
[04:29:24] <Barbara> Thanks Hannes, Me either.
[04:29:41] <richard.barnes> Right: hum in favor of a SIP extension/profile that allows a terminal to subscribe
[04:29:50] <richard.barnes> Second hum: Direct vs Indirect
[04:29:50] <martin.dawson> I gather it's a vote for a SIP extension to support subscription via a reference? Yes?
[04:29:57] <anewton> Hums in favor of doing both types of subscriptions: with a URI (direct) and with LIS identifier (indirect)
[04:30:05] --- sschroedl has left
[04:30:28] <richard.barnes> Winterbottom: Do you think it would be possible to get that URI from HELD or RELO?
[04:30:38] <richard.barnes> Henning: Yes, that would be the indirect model.
[04:31:16] --- schulzrinne has left
[04:31:38] <martin.dawson> OK - via a reference (indirect) or via an identifier or for yourself (direct)...
[04:32:08] <anewton> an indirect would be getting the subscription from HELD/RELO/DHCP/LLDP
[04:32:09] <richard.barnes> New speaker: Indirect would be used to obtain LbyR, and this mechanism would be an LbyR lookup
[04:32:21] <anewton> That sounded like Otmar Lendl.
[04:32:27] <richard.barnes> Peter: If you do LbyR, are you proposing changing things already in place, like DHCP and LLDP-MED?
[04:32:49] <richard.barnes> Henning: If an indirect method is accepted, we would then ask for a hum as to whether we want to do this in lower layers
[04:33:16] <richard.barnes> We would have to ask through a liaison to do anything at layer 2
[04:33:29] <richard.barnes> Peterson: We could also have pluralism at this level
[04:33:52] <richard.barnes> Hum: In favor of proceeding with an indirect mechanism for having an end system acquire its location
[04:33:57] <Barbara> Hum
[04:33:59] <richard.barnes> All in favor
[04:34:04] <HannesTschofenig> hum
[04:34:23] --- ben has left
[04:34:26] <richard.barnes> Hum: In favor of pursuing an approch with a direct mechanism (i.e. request contains low-layer info)
[04:34:27] <martin.dawson> hum
[04:34:33] <jerome.grenier> hum
[04:34:36] <dominique.asselin> hum
[04:34:37] <hakem.habib> hum
[04:34:38] <gcaron> hum
[04:34:38] <berry> hum
[04:34:38] <Lukisan> hum
[04:34:43] <Fadi> hummmm
[04:34:48] <pdube> hum
[04:34:50] <richard.barnes> ok ,are those late hums for the second proposal?
[04:34:50] <rob.sired> hum
[04:34:51] <rbzdega> hum
[04:34:55] <richard.barnes> The direct proposal?
[04:35:12] <rbzdega> yes
[04:35:14] <rohan> each please identify for or against in your hum
[04:35:26] <rbzdega> for
[04:35:39] <anewton> ASCII? I'm typing UTF8.
[04:35:41] <richard.barnes> 13 "ASCII hums" have been recorded in favor of the direct approach
[04:35:42] <martin.dawson> I assumed hum was for...
[04:35:45] --- jf.leger has joined
[04:36:06] <jf.leger> hummmmmm
[04:36:15] <richard.barnes> But there was no audible hum in the room, so consensus called against
[04:36:16] <jerome.grenier> hum for indirect
[04:36:24] <richard.barnes> Rohan: This was just for subscription, right?
[04:36:28] <richard.barnes> Henning: yes
[04:36:36] <rohan> we already did the indirect hum
[04:36:46] <richard.barnes> Clarificatoin: Indirect is yes, Direct is split?
[04:36:51] <rohan> NO!
[04:36:59] <rohan> we voted to do indirect
[04:37:05] <richard.barnes> Cullen: All these will be taken to the list
[04:37:27] <rohan> whether we do direct or not is an orthogonal question
[04:38:24] <richard.barnes> Henning: second question is whether we should task someone with providing that URL at lower layers
[04:39:17] <richard.barnes> Hum 4: In favor of extending protocols like DHCP to carry a URL for subscription LCP?
[04:39:29] <richard.barnes> (please indicate number in your hum)
[04:39:33] <Barbara> Hum against DHCP extension for carrying url
[04:39:46] <martin.dawson> Hum against - 4
[04:40:01] <richard.barnes> In the room, consensus in favor, with a couple of loud hums against
[04:40:30] <richard.barnes> Hum 5: In favor of provision of URIs through layer 7
[04:40:31] <Barbara> Hum for L7
[04:40:32] <rohan> hum 5 in favor of l7 URI approach
[04:40:40] <richard.barnes> Unanimous in favor
[04:40:45] <martin.dawson> Hum for - 5
[04:40:58] <gcaron> Hum 5
[04:40:59] <richard.barnes> Cullen: One more thing about pluralism: Do we also want an HTTP-based approach?
[04:41:01] <jerome.grenier> hum for 5
[04:41:10] <richard.barnes> Rohan: For fetching the result of a ref or for LCP?
[04:41:11] <dominique.asselin> hum5
[04:41:22] <jf.leger> hum5
[04:41:24] <berry> hum5
[04:41:24] <Lukisan> hum5
[04:41:27] <pdube> hum5
[04:41:27] <hakem.habib> hum5
[04:41:32] <rbzdega> hum5
[04:41:34] <Fadi> hum hum hum hum hum 5
[04:41:42] <rob.sired> hum 5
[04:41:44] <richard.barnes> Hum 6: In favor of an HTTP-based LCP
[04:41:47] <rohan> hum 6: http based LCP
[04:41:49] <martin.dawson> hum for 6
[04:41:52] <Barbara> Hum for 6
[04:41:55] <jerome.grenier> hum 6
[04:42:01] <gcaron> hum 6
[04:42:01] <hakem.habib> hum6
[04:42:03] <dominique.asselin> hum6
[04:42:03] <jf.leger> hum6
[04:42:03] <Fadi> hum 6
[04:42:04] <Lukisan> hum6
[04:42:05] <rbzdega> hum6
[04:42:05] <berry> hun6
[04:42:09] <rob.sired> hum6
[04:42:10] <pdube> hum6
[04:42:14] <richard.barnes> Henning: Want to pick up on Rohan's question:
[04:42:25] <HannesTschofenig> hum
[04:42:55] --- joelja has left
[04:43:04] <richard.barnes> Henning: Should there be at least 2 dereference mechanism for dereferencing URLs?
[04:43:08] <richard.barnes> HTTP and SIP
[04:43:20] --- HannesTschofenig has left
[04:43:32] <richard.barnes> Keith: Process question; we've been working requirements, do we know that these solutions we're humming on meet them?
[04:43:48] --- jiangxingfeng has left
[04:43:55] --- HannesTschofenig has joined
[04:44:16] <richard.barnes> Henning: LbyR draft had requirements that were non-controversial, controversial ones were mostly around security, which is a separate discussion
[04:44:49] <richard.barnes> Keith: Thought we went to some effort to create the requirements document, but that hasn't even been officially looked at by the WG
[04:45:19] <richard.barnes> Rohan: We have LbyR requirements in >=2 documents, and we've spent considerable effort on these, so I feel that this is well-worn territory
[04:45:43] <richard.barnes> Cullen: Agreement that we need a "fetch", but that there are a lot of ways to do it
[04:45:53] <richard.barnes> Requirements didn't drive which protocol you might use for this
[04:46:10] --- Xavier has joined
[04:46:20] <richard.barnes> Henning: If we can prioritize which protocols are candidates, it could help requirements gathering
[04:46:33] <richard.barnes> Keith: Don't think we should be trying to develop the protocol without having the requirements
[04:46:44] --- ben has joined
[04:46:47] <richard.barnes> Cullen: Agree with Keith
[04:46:54] <anewton> I agree with Keith.
[04:47:09] <richard.barnes> Ted Hardie: One piece of confusion is whether one or both is mandatory to implement
[04:47:15] <HannesTschofenig> We have requirements
[04:47:33] --- jiangxingfeng has joined
[04:47:39] <richard.barnes> It's not clear whether what you're saying is that SIP&HTTP would be the "expected" ones, or if they're just the first two to handle
[04:47:40] <anewton> Keith's point was that the hums are attempting to get around any written requirements.
[04:47:48] --- jiangxingfeng has left
[04:47:59] <richard.barnes> Henning: Just to focus requirements
[04:48:24] <richard.barnes> Henning: Not a high-priority item, so if there's lots of process discussion, let's table it.
[04:48:34] <richard.barnes> Brian: Let's hold this humm, I think it will be obvious
[04:48:51] <hardie@jabber.psg.com> I think Brian said "pull this hum"
[04:49:01] <richard.barnes> so noted.
[04:49:12] <otmar> i hear d"hold this hum"
[04:49:25] --- jiangxingfeng has joined
[04:49:27] <otmar> in the sense of jzst do it
[04:49:33] <richard.barnes> Polk: There are many applications of a dereference protocol
[04:49:42] --- axelm has left: Replaced by new connection
[04:49:53] <richard.barnes> Henning: the only document that makes an implementation recommendation is the ECRIT phonebcp
[04:50:35] <richard.barnes> Hum: Is the WG ready and interested in HTTP and SIP dereference mechanisms for LbyR?
[04:50:40] <richard.barnes> Hum 7
[04:50:45] <Barbara> Hum for 7
[04:50:49] <jerome.grenier> hum for 7
[04:50:51] <martin.dawson> hum for 7
[04:50:52] <richard.barnes> Hold hums - clarification
[04:50:52] <dominique.asselin> hum7
[04:50:55] <hakem.habib> hum 7
[04:50:56] <gcaron> hum 7
[04:50:57] <Fadi> hum 7
[04:50:57] <berry> hum7
[04:50:57] <jf.leger> hum7
[04:50:59] <Lukisan> hum7
[04:51:00] <HannesTschofenig> hum for HTTP and SIP
[04:51:00] <rob.sired> hum7
[04:51:01] <pdube> hum7
[04:51:04] <rbzdega> hum7
[04:51:12] <martin.dawson> cease fire :)
[04:51:15] <richard.barnes> Henning: Pursuing requirements and protocol detail for HTTP & SIP based protocols
[04:51:35] <richard.barnes> Re-hummed on same proposition, all in favor
[04:51:56] <jerome.grenier> re-hum for 7
[04:51:58] <dominique.asselin> hum7
[04:51:59] <Barbara> Rehum for 7
[04:51:59] --- jiangxingfeng has left
[04:52:01] <martin.dawson> hum for 7
[04:52:05] <rbzdega> hum 7
[04:52:06] <jf.leger> hum7
[04:52:07] <hakem.habib> hum 7
[04:52:10] <richard.barnes> Henning Schulzrinne talking about L7LCP requirements document.
[04:52:10] <berry> hum7
[04:52:11] <rob.sired> hum7
[04:52:12] <gcaron> hum7
[04:52:13] <Fadi> hum 7
[04:52:43] <richard.barnes> Background: This document captures L7LCP discussion
[04:52:46] <Lukisan> hum7
[04:52:57] --- m.germain has joined
[04:52:57] <richard.barnes> Been through WGLC, got lots of comments
[04:53:23] <m.germain> hum
[04:53:26] <richard.barnes> Document Structure:
[04:53:41] <m.germain> hum 7
[04:53:54] <rob.sired> hum7
[04:53:57] <HannesTschofenig> We don't do a hum right now? right?
[04:54:21] <richard.barnes> Right, hums are done now.
[04:54:22] <anewton> I think there is some sort of lag
[04:54:37] <richard.barnes> Proposal to delete section 6, VPN considerations
[04:54:52] <HannesTschofenig> Please only hum if you know what you hum for and when there is actually a hum needed.
[04:54:56] <richard.barnes> Maybe make a small warning, but it wasn't productive to unravel all the VPN possibilities
[04:55:23] <richard.barnes> Brian Rosen: Object; something more than a short statement is required
[04:55:38] <richard.barnes> Brian: This is a serious issue that you can't dismiss because it's too hard
[04:55:50] <richard.barnes> Henning: If it's more than .5page, then we'll never converge
[04:56:03] <richard.barnes> So lets do it quickly
[04:56:11] <richard.barnes> Polk: Want to agree with Brian
[04:56:13] <anewton> I think breaking my arm is less painful than working on all the possible VPN deployments.
[04:56:56] <HannesTschofenig> I think that the VPN stuff needs to be removed from the document since it has nothing todo with a requirements doc
[04:57:11] <HannesTschofenig> No VPN stuff in the requirements anymore.
[04:57:15] <HannesTschofenig> Talk about it in a solution
[04:57:18] <richard.barnes> Proposal to move discussion of location by reference to draft-barnes-geopriv-something
[04:57:26] <richard.barnes> Agreed by author (me)
[04:57:48] <richard.barnes> sorry, proposal to move LbyR to LbyR doc, security to another doc
[04:57:50] --- jiangxingfeng has joined
[04:58:16] <martin.dawson> requirements docs?
[04:58:27] <richard.barnes> Authors feel that Lis-to-LIS and OBO are sufficiently different from LCP and ill defined that we should simply punt
[04:58:41] <richard.barnes> Winterbottom: Why don't we define them
[04:58:47] <richard.barnes> Henning: This isn't the proper venue
[04:58:57] <anewton> Yes, move the LbyR stuff to the Roger's LbyR draft, move security stuff to a new security draft
[04:59:01] --- jiangxingfeng has left
[04:59:04] <HannesTschofenig> We thought about pushing the LIS-to-LIS and OBO to Rogers' doc
[04:59:06] <richard.barnes> Brian: If you want to move on, let's hum on this
[04:59:47] <richard.barnes> Cullen: Concerned about whether we want to bring this in as a WG item -- needs to deal with privacy and integrity
[05:00:04] <anewton> What is the "this" that Cullen is talking about?
[05:00:07] <HannesTschofenig> Which doc are we talking about?
[05:00:11] <richard.barnes> integrity = "you don't report a completely bogus location"
[05:00:22] <richard.barnes> draft-ietf-geopriv-l7lcp-ps-req
[05:00:30] <HannesTschofenig> It is already a WG item
[05:00:46] <richard.barnes> I think he's talking about LIS2LIS/OBO
[05:00:57] <anewton> Yeah, isn't he talking about something else. Can somebody ask Cullen to restate his concern?
[05:01:36] --- ggarber has joined
[05:01:39] <richard.barnes> Cullen: I am concerned about our ability to make a protocol that meets the LIS2LIS/OBO requirements
[05:01:52] <richard.barnes> Therefore I think we should remove them, and add them back when we understand them better
[05:02:17] <richard.barnes> I'm worried about it falling short in two areas: Privacy, and Integrity (recording the right data)
[05:02:31] <richard.barnes> This approach could end up delivering the wrong information, with no way to detect that that's the case
[05:02:39] --- axelm has joined
[05:02:41] <richard.barnes> It's not that it's not interesting to solve, but it's more of a research problem
[05:02:57] <anewton> Cullen, thanks for the clarification. That helped.
[05:03:05] <richard.barnes> Winterbottom: Provided you can specify use cases, that's probably reasonable
[05:03:27] <richard.barnes> Cullen: Keep in mind, the IETF gets ancy about defining protocols that have very limited use cases
[05:03:39] <martin.dawson> I don't understand why integrity is more challenged for OBO.... I think I'm missing some context...
[05:03:46] <richard.barnes> Henning: From a process perspective, If this is to be useful, we need to move quickly
[05:04:49] <martin.dawson> OBO is primarily needed to support devices that don't speak the LCP... but the LIS can still support integrity in the same way.
[05:04:52] <anewton> I think it was also about privacy.
[05:04:58] <richard.barnes> Otmar: We don't want to do something that's applicable to a small % of scenarios -- that's why we need LIS2LIS
[05:05:07] --- ben has left
[05:05:11] <richard.barnes> If we don't then lots of networks won't be able to do IETF location
[05:05:26] <HannesTschofenig> Who said that?
[05:05:31] <richard.barnes> Otmar
[05:05:33] --- ben has joined
[05:05:41] <HannesTschofenig> I don't believe him
[05:05:43] <richard.barnes> Henning: Didn't say we're not going to do LIS2LIS, just that it's a separate topic
[05:05:53] <anewton> The LIS-to-LIS ought to be separated from LCP.
[05:05:55] <martin.dawson> Isn't privacy taken care of by saying that OBO is only supported with authorization?
[05:06:09] <richard.barnes> Cullen: Understand the benefit, don't want to stop discussion, just think it's at a different stage than L7LCP
[05:06:18] <anewton> And perhaps confidentiality.
[05:06:53] <richard.barnes> Winterbottom: If you don't have OBO, then you're not going to have something deployable
[05:07:11] <HannesTschofenig> I tend to agree
[05:07:17] <richard.barnes> Hum 8: In favor of OBO and LIS2LIS being in the document
[05:07:22] <HannesTschofenig> That's the IMS type of environment
[05:07:36] <Barbara> Hum for including - 8
[05:07:41] <martin.dawson> hum for 8
[05:07:42] <Lukisan> hum8
[05:07:46] <jf.leger> hum8
[05:07:46] <gcaron> hum8
[05:07:47] <hakem.habib> hum 8
[05:07:48] <berry> hum8
[05:07:48] <dominique.asselin> hum8
[05:07:48] <Fadi> hum 8
[05:07:49] <jerome.grenier> hum 8
[05:07:49] <rbzdega> hum8
[05:07:52] <HannesTschofenig> hum
[05:07:53] <rob.sired> hum8
[05:07:58] <pdube> hum8
[05:08:37] <richard.barnes> Rohan: Separate document?
[05:08:47] <richard.barnes> Hum 9: Could not live with this being in a separate document
[05:08:51] <richard.barnes> no hums in the room
[05:08:52] --- jiangxingfeng has joined
[05:08:56] <Barbara> Hum - separate is ok - 9
[05:08:58] <richard.barnes> Winterbottom volunteers to write that document
[05:09:37] <martin.dawson> I'm still not sure if "document" means requirements or specification. Clarification?
[05:09:44] <otmar> reqs
[05:10:03] <richard.barnes> Conclusion is to take OBO requirements to a separate document and move them along separately
[05:10:03] <martin.dawson> thanks
[05:10:20] <anewton> Ask them if that includes the identifiers as well as the requirements?
[05:10:34] <richard.barnes> Henning: Move LbyR requirements to draft-marshall-lbyr-requirements?
[05:10:40] <anewton> Forget it... they seem to have moved on.
[05:10:57] <richard.barnes> Just need to merge reqs, no objection
[05:11:08] <richard.barnes> Henning: Do we need "Operational Considerations"?
[05:11:38] <richard.barnes> Henning: Not sure what we should put here
[05:11:53] <richard.barnes> Cullen: This proposal originated from the OPS AD (Dan Romascanu)
[05:12:12] <richard.barnes> Brian: Don't think that this is something that goes in this requirements document, but should go in a protocol document
[05:12:27] <martin.dawson> or a deployment guide or bcp
[05:12:30] <richard.barnes> Henning: Proposal to note that this should be noted in the doc, but actually done by a protocol
[05:12:48] <richard.barnes> Henning: We'll make the changes quickly and issue another WGLC
[05:12:59] <richard.barnes> James Winterbottom talking about HELD
[05:13:17] --- jiangxingfeng has left
[05:13:37] <richard.barnes> HELD was introduced 2 years ago as of this IETF
[05:13:47] <rohan> happy birthday to HELD
[05:14:08] <richard.barnes> originated from NENA's requirements beyond DHCP
[05:14:25] <richard.barnes> application-layer protocol that's usable with SIP et al
[05:14:31] <richard.barnes> emphasis on the et al
[05:14:36] --- m.germain has left: Replaced by new connection
[05:14:45] --- Xavier has left
[05:14:45] --- m.germain has joined
[05:15:29] <richard.barnes> [Since it's independent of HTTP now, is it just ELD? LD?]
[05:16:12] <richard.barnes> Henning: Please stick to technical topics
[05:16:22] <richard.barnes> Basic HELD: HTTP GET to a URL
[05:16:45] <richard.barnes> LIST discovery via draft-thomson-geopriv-lis-discovery
[05:16:55] <richard.barnes> [erratum: s/LIST/LIS/
[05:17:02] <richard.barnes> existing open-source implementation
[05:17:22] <richard.barnes> HELD identity extension allows for additional identifiers (e.g. GRUU)
[05:17:46] <richard.barnes> Henning: Does this depend on HELD?
[05:18:01] <richard.barnes> James: This is just an XML schema, so it's not critically dependent on HELD
[05:18:16] <richard.barnes> OBO example
[05:19:05] <richard.barnes> If there's not OBO, then you're not going to be able to do this
[05:19:23] <richard.barnes> Rohan: We want to be able to do this, but this might not need to be standardized in the same time frame
[05:19:43] --- jiangxingfeng has joined
[05:20:16] <richard.barnes> Ted Hardie: Understand the desire for re-use, but we should consider using different protocols/profiles for OBO and end-user
[05:20:39] <richard.barnes> Ted: Trust models are very different
[05:20:40] <martin.dawson> OBO is probably needed earlier - since it's main application scenario is to support devices that haven't learnt to talk LCP yet.
[05:21:28] <richard.barnes> James: Don't think that the protocol actually needs to be different
[05:21:32] --- jiangxingfeng has left
[05:21:33] <martin.dawson> What if we posit that OBO means the requestor is treated as if they are the target-device? That would be the meaning of OBO.
[05:21:46] <richard.barnes> Rohan: In terms of priorities, we want to get a home run on the target->LIS problem,
[05:22:02] <richard.barnes> Rohan: Then once that's on its way, we can go back to this stuff
[05:22:21] <richard.barnes> James: But if the network can't do this, then there's nothing for the LCP to talk to
[05:22:49] <martin.dawson> I guess - if the protocol supports client identity extensions then OBO is implicitly supported anyway.
[05:22:49] <richard.barnes> Brian: Support that position, and want to keep the presentation going
[05:22:58] <richard.barnes> Device capabilities: useful in wireless networks
[05:23:24] <richard.barnes> [martin: yeah, i think the semantics in HELD will do for both use cases. maybe a BCP to describe OBO]
[05:24:00] <martin.dawson> yep
[05:24:35] <richard.barnes> Brian: This is not location configuration, this is location determination
[05:24:41] <anewton> Are these capabilities listed in the LCP P&S draft?
[05:24:54] <anewton> Were they offered as requirements?
[05:25:04] <richard.barnes> [Andy: do you want me to take that to the mic?
[05:25:32] <hardie@jabber.psg.com> He's moved on to "lcp requirements compliance"
[05:25:35] <anewton> Well, apparently he has a presentation on LCP requirements. Hopefully he'll talk about it there.
[05:25:39] <richard.barnes> [Protocol: questions that jabber folks want taken to the mike, please prefix with **MIC**]
[05:25:44] <martin.dawson> they were offered as requirements
[05:25:55] <richard.barnes> James now talking about how HELD complies with the L7LCP requirement
[05:26:33] <richard.barnes> Both proposals meet the L7LCP requirements, so we'll just step through this quickly
[05:27:35] <anewton> Hannes: I don't see them in the P&S draft. If they were offered, did the design team feel they were not appropriate?
[05:28:08] --- randy has joined
[05:28:23] <richard.barnes> (Just going through requirements slides.....)
[05:30:26] <richard.barnes> Now talking about LbyR requirements compliance
[05:30:54] <richard.barnes> Henning: Thought we were focusing on LCP. Do you see HELD as an LCP or an LbyR solution?
[05:31:08] <richard.barnes> James: Think it can do both, but we can omit this section for now.
[05:31:19] <anewton> MIC: Are features listed in draft-thomson-geopriv-held-capabilities-01 LCP features? If so, are they to be added to the list of LCP requirements?
[05:31:36] <richard.barnes> Rohan: Really like the base document
[05:32:21] <richard.barnes> James: HELD capabilities describes a framework for doing this
[05:32:43] <richard.barnes> It is tied to LCP in that in some cases, the end device needs to tell the network what it can do
[05:32:51] <richard.barnes> It's not a general requirement, but useful in some cases
[05:33:05] <richard.barnes> [I need to step out for a second, can someone else take over]
[05:33:08] <richard.barnes> [?]
[05:33:18] <richard.barnes> Henning Schulzrinne on RELO
[05:33:46] <richard.barnes> Motivation: Want to find simplest possible solution for end systems to deploy
[05:35:08] <richard.barnes> Discovery: Uses S-NAPTR (should probably be U-NAPTR) or DHCP
[05:35:22] <richard.barnes> Query is an HTTP get with query parameters
[05:36:04] <hardie@jabber.psg.com> As simple as possible apparently involves 15 parameters
[05:36:32] <rohan> (but no simpler ;-)
[05:36:42] <richard.barnes> Identifiers: IP, MAC, CDP, MSAP
[05:37:27] <richard.barnes> Winterbottom: Interested that you suggested SOAP for HELD, but now you're using a mechanism that doesn't do this
[05:37:41] <richard.barnes> Henning: Asked a student to build it, found it too complicated
[05:38:08] <martin.dawson> What's the evidence that "simplicity" is a differentiator? The latest RELO draft just added assertion - so it's most like HELD v0.0 now....
[05:38:12] <richard.barnes> Winterbottom: Now you're pass through a big object in the query string
[05:38:30] <richard.barnes> Response contains LO or URI
[05:38:39] <richard.barnes> HTTP Expires header indicates validity
[05:39:23] <cullenfluffyjennings@jabber.org> on to design decisions
[05:40:03] <cullenfluffyjennings@jabber.org> James - bring up question URI that one renew, and so this is the simulr to HELD context
[05:40:12] <cullenfluffyjennings@jabber.org> On to Requirements slide
[05:40:20] <martin.dawson> MIC: questioning "simplicity". RELO now strongly resembles original HELD specification - before Henning requested it be decoupled from HTTP. With assertion now added, what is the quantification with respect to relative "simplicity"?
[05:40:26] --- Jack3010 has joined
[05:40:38] <anewton> MIC: Are you willing to remove the discovery section from RELO and defer to draft-thomson-geopriv-lis-discovery-00 for LIS discovery?
[05:42:00] <richard.barnes> Henning: hard to compare simplicity across protocols
[05:42:01] <HannesTschofenig> There is nothing wrong with RELO being similar to HELD.
[05:42:11] <richard.barnes> Henning: One metric is the length of the spec
[05:42:34] <richard.barnes> Rohan: Let's outlaw the word "simplicity" for the rest of the day
[05:43:00] <richard.barnes> Henning (to Andy's question): Certainly can use draft-thomson-geopriv
[05:43:09] <richard.barnes> James: Length of spec is a bad metric
[05:43:29] <richard.barnes> Cullen (AD hat): If we decide based on # of pages, then we'll close the WG
[05:43:29] <martin.dawson> Hannes: No - just telling. What I mean is complexity differences are negligible - and it could actually be the other way around.
[05:44:01] <richard.barnes> Done with RELO
[05:44:21] <richard.barnes> Peterson: Couple of questions to put to the room, gradually moving toward consensus calls
[05:44:31] --- Jack3010 has left: Computer went to sleep
[05:44:37] <richard.barnes> First question: We have a pretty significant mandate to do something related to LCP at layer 7
[05:44:51] <richard.barnes> Do people feel that it's important to have one answer?
[05:44:53] <rohan> what hum number will we be on
[05:45:06] <richard.barnes> Note that this WG could adopt one, and another WG could adopt another.
[05:45:33] <richard.barnes> Ted: For things that are relatively similar, we should make a choice
[05:46:03] <richard.barnes> Ted: Having a single answer is an advantage where we have a single substrate protocol
[05:46:29] <richard.barnes> Marc Linsner: In sympathy with Brian, an 802 client is going to have to implement all of them
[05:46:42] <gcaron> Rohan: the next one is 10
[05:47:01] <richard.barnes> Polk: Ditto. Defining similar things that do about the same thing is begging for providers to choose more than one, and forces endpoints to support them all.
[05:47:19] <axelm> i remember "IRIS" vs. "CRISP"....
[05:47:20] <richard.barnes> Peter Blatherwick: As a device manufacturer, beg and plead to have only one.
[05:47:41] <richard.barnes> Peter: Can we know what the minimal part is to implement?
[05:47:41] <hardie@jabber.psg.com> axelm iris vs. ldap in CRISP, you mean?
[05:47:49] <anewton> IRIS vs. CRISP? You mean IRIS vs. FIRS?
[05:48:02] <richard.barnes> Hum 10: If you believe that this WG should produce a single standard HTTP LCP, hum now.
[05:48:08] <Barbara> Hum!!! for only one - 10
[05:48:15] <martin.dawson> hum for 10
[05:48:16] <richard.barnes> Unanimous in favor in the room
[05:48:17] <jerome.grenier> hum for 10
[05:48:18] <gcaron> hum 10
[05:48:20] <dominique.asselin> hum10!!
[05:48:22] <mlepinski> hum for 10
[05:48:23] <rob.sired> hum10
[05:48:27] <m.germain> hum 10
[05:48:27] <Lukisan> hum10
[05:48:30] <pdube> hum 10
[05:48:34] <Fadi> hum10
[05:48:35] <berry> hum10
[05:48:35] <richard.barnes> Hum 11: Is there enough information to decide between the two protocols presented?
[05:48:37] <jf.leger> hum10
[05:48:38] <hakem.habib> hum10
[05:48:50] <martin.dawson> hum for 11
[05:48:54] <Barbara> Hum for 11
[05:48:55] <hakem.habib> hum11
[05:48:56] <jf.leger> hum11
[05:48:58] <gcaron> hum 11
[05:48:59] <dominique.asselin> HUM11
[05:49:00] <Fadi> hum 11
[05:49:01] <berry> hum11
[05:49:03] <rob.sired> hum11
[05:49:04] <mlepinski> hum for 11
[05:49:07] <m.germain> hum 11
[05:49:20] <richard.barnes> Called in favor of both 10 and 11
[05:49:56] <richard.barnes> Rohan: Whichever one we pick, we can modify afterward. So the exact content is fixable
[05:49:58] <mlepinski> Will the next hums be for adopting one of the two protocols as a working group document?
[05:49:59] <HannesTschofenig> hum 10: yes
[05:50:08] <HannesTschofenig> hum 11: no
[05:50:16] <richard.barnes> Ted: Could you call hums on specific draft names, please?
[05:50:38] <rohan> draft-schulzrinne-geopriv-relo-03
[05:50:44] <richard.barnes> [matt: that's where we'll end up at some point today, not sure if that's next up]
[05:51:01] <mlepinski> I think my question was essentially the same as Ted's
[05:51:16] <rohan> draft-winterbottom-http-location-delivery-05
[05:51:42] <martin.dawson> relo or held
[05:51:43] <richard.barnes> Peterson: final call for comment before hums
[05:51:55] <richard.barnes> Hum 12: In favor of going forward with HELD
[05:52:01] <martin.dawson> hum for 12
[05:52:01] <berry> hum12
[05:52:02] <hakem.habib> hum12
[05:52:02] <jf.leger> hum12
[05:52:02] <gcaron> hum 12
[05:52:02] <jerome.grenier> hum 12
[05:52:03] <Fadi> hum12
[05:52:03] <dominique.asselin> hum12
[05:52:05] <richard.barnes> Hum 13: In favor of RELO
[05:52:05] <m.germain> hum 12
[05:52:08] <mlepinski> hum for 12
[05:52:08] <Lukisan> hum12
[05:52:08] <rob.sired> hum12
[05:52:09] <Barbara> hum for 12
[05:52:17] <pdube> hum 12
[05:52:18] <martin.dawson> hum against 13
[05:52:44] <richard.barnes> Hum 14: Is it important to resolve this today?
[05:52:50] <Barbara> Hum!!!!!!!! for 14
[05:52:55] <gcaron> hum 14
[05:52:55] <martin.dawson> hum for 14
[05:52:57] <jf.leger> hum14
[05:52:57] <dominique.asselin> hum14
[05:52:58] <hakem.habib> hum14
[05:52:59] <jerome.grenier> hum 14
[05:53:00] <berry> hum14
[05:53:00] <Fadi> hum 14
[05:53:01] <HannesTschofenig> Hum 14: No
[05:53:02] <m.germain> hum 14
[05:53:02] <rob.sired> hum14
[05:53:03] <Lukisan> hum14
[05:53:18] <pdube> hum 14
[05:53:24] <richard.barnes> Brian: How many who supported HELD would be willing to go forward with RELO, and vice versa?
[05:53:39] <richard.barnes> Henning: A generic possibility is to hash out a compromise
[05:54:02] --- cullenfluffyjennings@jabber.org has left
[05:54:08] <richard.barnes> Tom Taylor: MEGACO was decided by a coin flip
[05:54:32] <ekr> I propose to resolve this by putting people up front and asking them trivia questions.
[05:54:38] <HannesTschofenig> Tom: Which was a failure
[05:54:43] <martin.dawson> MIC: I think RELO has been approaching HELD anyway - but HELD has already integrated some other WG input (separating bearer protocol for example).
[05:54:45] <ekr> First man to get a question wrong loses
[05:56:09] <richard.barnes> 15 in favor of Hum 12
[05:56:19] <richard.barnes> none in favor of Hum 13
[05:56:37] <richard.barnes> 13 in favor of Hum 14
[05:57:00] <richard.barnes> [I was counting, what did Ted just say?]
[05:57:05] <rohan> marc lisner suggested we develop hum cancelling headphones
[05:57:20] <richard.barnes> Keith: Let's focus on what the differentiators are between the two proposals
[05:57:37] <Barbara> Proposal that we agree first on whether we are willing to accept plurality and then to determine plurality.
[05:57:41] <richard.barnes> Peterson: Let's try Ted's suggestion
[05:57:50] <HannesTschofenig> What is it?
[05:58:00] <mlepinski> See Barbara's message
[05:58:14] <mlepinski> Barbara stated Ted's suggestion ...
[05:58:29] <richard.barnes> Believe that the proposal is to hum to agree to a plurality vote
[05:59:13] <richard.barnes> Cullen: Have gotten queries about including Jabber, which will require taking this to the mailing list
[05:59:34] <richard.barnes> Polk: A little bit concerned counting jabber, since two continents are asleep right now
[05:59:53] <richard.barnes> Winterbottom: Just logged in 45 of my own clients to Jabber
[06:00:36] <richard.barnes> Rohan: About the Jabber room: A lot of people are on jabber who have been very vocal in the past that can't be here right now
[06:00:49] <richard.barnes> So jabber is particularly important today
[06:00:53] <richard.barnes> Polk: Purple fingers?
[06:01:20] <richard.barnes> Hum 15: Instead of ordinary constraints on rough consensus, we will accept a plurality vote
[06:01:24] <martin.dawson> I think we have representatives from Americas, Europe, Asia, and Oceania.... so contrinental rep is good.
[06:01:32] <Barbara> Hum for 15
[06:01:42] <mlepinski> Hum for 15
[06:01:42] <richard.barnes> Unanimous in favor of plurality in the room
[06:01:47] <martin.dawson> hum for 15
[06:01:50] <richard.barnes> Counting hands in the room
[06:02:49] <richard.barnes> Q: What about deployment?
[06:03:01] <richard.barnes> Cullen: We're picking a baseline. We'll adapt it as it goes on.
[06:03:07] <richard.barnes> Henning: Both proposals have running code.
[06:03:28] <rohan> hand raising now
[06:03:28] <richard.barnes> Now voting
[06:03:29] <richard.barnes> [Protocol: Please indicate your vote with VOTE:HELD or VOTE:RELO]
[06:03:44] <Barbara> VOTE: HELD
[06:03:44] <martin.dawson> VOTE:HELD
[06:03:45] <gcaron> vote:held
[06:03:45] <jerome.grenier> VOTE:HELD
[06:03:46] <jf.leger> vote held
[06:03:51] <dominique.asselin> VOTE:HELD
[06:03:51] <mlepinski> VOTE:HELD
[06:03:51] <hakem.habib> vote:held
[06:03:52] <rbzdega> VOTE: HELD
[06:03:53] <Fadi> VOTE:HELD
[06:03:54] <rob.sired> vote: held
[06:03:54] <m.germain> vote: held
[06:03:57] <pdube> VOTE:HELD
[06:03:59] <Lukisan> vote:HELD
[06:03:59] <berry> vote held
[06:04:59] <richard.barnes> All votes in?
[06:05:10] <richard.barnes> Closing jabber voting now.
[06:05:35] <anewton> what was the count?
[06:05:52] <anewton> what was the count in the room?
[06:06:08] <richard.barnes> 22 in the room in favor of HELD, 23 for RELO
[06:07:03] <richard.barnes> Rohan: What's the worth of the jabber room?
[06:07:19] <richard.barnes> Rohan: It's more or less even in the room
[06:07:41] <martin.dawson> well I hope my vote is worth one in the room....
[06:07:47] <richard.barnes> Area directors conferring.
[06:08:45] <anewton> I don't think there is a precedent for counting Jabber "votes" or "hums". Jabber is not mentioned in any of the IETF RFCs about how decisions are made.
[06:08:49] <martin.dawson> this is more exciting than the Eurovision song contest
[06:09:10] <richard.barnes> Cullen (AD hat): any way you slice it with the jabber room, it looks like there are more in favor of HELD
[06:09:28] <richard.barnes> Cullen: We agreed that we would go with plurality, and that's how the majority seems to be going
[06:09:38] <richard.barnes> Ted: No clear consensus, but clear plurality
[06:10:41] <richard.barnes> Ted: Remaining to do: Take to the mailing list for confirmation
[06:11:17] <richard.barnes> JDR: Did you ask the question as to how strongly people supported each?
[06:11:37] <richard.barnes> Peterson: Both protocols are very similar, and we're just talking about a basis for going forward.
[06:12:05] --- jiangxingfeng has joined
[06:12:08] <richard.barnes> JDR: That illustrates my point. When two protocols are so similar except for encoding, you might have a 50/50 split
[06:12:14] --- jiangxingfeng has left
[06:12:19] <richard.barnes> Peterson: We executed a process, and we have a result
[06:12:29] <jf.leger> it is more than plurality 15 people in the jabber room voted for held
[06:12:36] <richard.barnes> Marc Linsner: To be fair, this wasn't on the agenda. There may be people who didn't attend
[06:12:40] --- jiangxingfeng has joined
[06:12:45] <richard.barnes> Peterson: Those people will be on the mailing list
[06:13:25] <richard.barnes> Brian: Accept the decision. Would like a hum that the WG item will only have LCP, not OBO.
[06:13:47] <richard.barnes> Peterson: We've very generally agreed to take HELD as a basis going forward. Request is reasonable, but not right now.
[06:14:29] <richard.barnes> Henning: I would feel more comfortable if there were a consensus that there would be a design team including others than the current list of authors to manage the adopted document
[06:14:54] <richard.barnes> Henning: This would help people feel more comfortable with the process with that
[06:14:59] <anewton> MIC: Since asking for hums seems to be the order of the day, I would like Brian's question asked.
[06:15:14] <jf.leger> we were askedto vote on going forward with held, the question was clear and so was the answer
[06:15:28] <richard.barnes> [andy: Brian's in the mic line, I've passed your comment on to him]
[06:15:48] <richard.barnes> We can put new authors in charge of the documents
[06:16:02] <HannesTschofenig> Who proposed that?
[06:16:09] <richard.barnes> Brian: Oppose Henning's suggestion. Just want to get this done. Let the authors do their job.
[06:16:23] --- jiangxingfeng has left
[06:16:24] <rohan> andy: please clarify what you want asked at the mic
[06:16:24] <anewton> I think Jon said the authors could be changed, not that it would happen.
[06:16:29] <richard.barnes> [Hannes: don't remember, conversation between Jon, James, and Henning]
[06:17:12] <anewton> It was Brian's questions about accepting the non-LCP parts of HELD.
[06:17:32] <martin.dawson> excluding OBO from WG item consideration.
[06:17:51] <anewton> Yes.
[06:18:30] <anewton> Otmar's comment is to the point, the identities draft contains LCP identifiers.
[06:18:34] <richard.barnes> Alexander Mayrhofer on geo: URI
[06:18:35] <anewton> And other identifiers.
[06:19:01] --- rohan has left
[06:19:35] <richard.barnes> Motivation: Lots of things are using location now, trying to avoid proliferation of location formats
[06:20:51] <richard.barnes> Want an unambiguous, protocol independent way to represent location
[06:22:39] <richard.barnes> Requirements: Just identify location, as simple ase possible, distinguishable as location
[06:22:57] <richard.barnes> James: Is the URI associated with a resource?
[06:22:57] --- incarose has joined
[06:23:10] <richard.barnes> Alexander: No, just the location
[06:23:25] --- mayumimunakata has joined
[06:23:52] <richard.barnes> Brian: You said you're not interested in representations, then you defined representation
[06:24:11] <richard.barnes> Brian: We have a representation (PIDF-LO), why are you defining a new one?
[06:24:14] <gcaron> Richard: What is the status on the exclusion of obo from LCP?
[06:24:24] <richard.barnes> Alex.: It's tied to XML, not "jottable"
[06:24:32] <richard.barnes> Brian: Then write down that requirement
[06:24:33] <anewton> Jon refused to ask the question.
[06:24:43] <martin.dawson> Guy: I think it was tabled and the room has moved on...
[06:24:49] <richard.barnes> [guy: there was no resolution on that; jon declined to put it to the room]
[06:25:14] <richard.barnes> Format: geo:[lat],[long],[alt]?[query]
[06:25:48] --- xmlscott has left
[06:26:08] <richard.barnes> Use cases: Hyperlink, Header field, business cards, newspapers, bar codes, etc.......
[06:26:24] <richard.barnes> Ted: This is different from what you said before, and what's in the draft
[06:26:45] <richard.barnes> Ted: You're actually defining a pointer to a location; what do I get back when I reference it?
[06:27:03] <richard.barnes> Ted: So you said that it's just a short form encoding of location
[06:27:12] <richard.barnes> Ted: But now you say to use it as a hyperlink.
[06:27:27] --- rohan has joined
[06:27:30] <richard.barnes> Ted: You're trying to do different things
[06:27:38] <richard.barnes> (1) Short encoding of location
[06:27:50] <richard.barnes> (2) Go get a resource of the following type from this location
[06:28:13] <richard.barnes> Jon: 4-minute warning
[06:28:43] <richard.barnes> Henning: Share Ted's concern that we have a URN scheme here (i.e., not URI), AND something you can resolve
[06:29:40] --- jiangxingfeng has joined
[06:29:56] --- ShoichiSakane has left
[06:30:11] <richard.barnes> Alex.: URI scheme adds semantics to raw numbers
[06:30:23] <richard.barnes> Ekr: This is the worst representation I can possibly think of?
[06:30:34] <richard.barnes> [I can't keep up with Ekr.]
[06:30:45] <richard.barnes> Decimal representation is bad.
[06:30:50] <richard.barnes> There's not FEC/checksum
[06:31:02] <richard.barnes> Commit to what this if for
[06:31:30] --- ben has left
[06:31:37] <rohan> jon volunteered to act as an ekr decompression gateway!
[06:31:43] --- hardie@jabber.psg.com has left
[06:31:44] <richard.barnes> ... and we're done!
[06:31:47] <HannesTschofenig> What does mean?
[06:31:58] <martin.dawson> Good job Richard - thank you.
[06:32:07] --- jfischl has left
[06:32:14] <anewton> EKR talks really, really fast.
[06:32:18] <gcaron> Yes. Job well done Richard
[06:32:19] --- berry has left
[06:32:23] --- axelm has left
[06:32:23] <richard.barnes> thanks, guy
[06:32:24] <anewton> Thanks Richad.
[06:32:30] <richard.barnes> just glad we got some work done
[06:32:40] --- jiangxingfeng has left: Replaced by new connection
[06:32:41] --- Barbara has left
[06:32:43] --- Lukisan has left
[06:32:44] --- anewton has left
[06:32:48] --- mlepinski has left
[06:32:50] --- rbzdega has left
[06:32:58] --- rob.sired has left
[06:33:02] --- ysuzuki has left
[06:33:04] --- m.germain has left: Logged out
[06:33:36] --- pdube has left
[06:33:39] --- jerome.grenier has left
[06:33:56] --- mayumimunakata has left
[06:34:07] --- jf.leger has left
[06:34:09] <Fadi> thank you
[06:34:20] --- Fadi has left
[06:35:12] --- dominique.asselin has left
[06:35:19] --- randy has left
[06:35:23] --- isudo has left
[06:36:05] --- rohan has left
[06:37:13] --- gcaron has left
[06:38:48] --- incarose has left: Replaced by new connection
[06:38:48] --- m_ersue has joined
[06:39:29] --- m_ersue has left
[06:42:22] --- ggarber has left: Replaced by new connection
[06:44:37] --- gcaron has joined
[06:44:37] --- HannesTschofenig has left
[06:44:47] --- gcaron has left
[06:50:03] --- otmar has left
[06:51:01] --- richard.barnes has left
[06:53:19] --- kafka-j31415927 has left
[07:35:32] --- ekr has left
[07:49:58] --- isudo has joined
[08:02:17] --- isudo has left
[08:31:46] --- hakem.habib has left: Logged out
[11:06:53] --- jiangxingfeng has joined
[11:20:00] --- jiangxingfeng has left
[19:26:29] --- martin.dawson has left