[20:31:35] --- mankin has joined
[20:32:03] --- richard.barnes has joined
[20:38:51] --- lemmakin has joined
[20:39:44] --- richard.barnes has left
[20:40:17] --- hardie@jabber.qualcomm.com has joined
[20:40:41] --- axelm has joined
[20:41:16] --- ysuzuki has joined
[20:41:56] --- richard.barnes has joined
[20:42:31] * axelm has changed the subject to: IETF 67 geopriv meeting
[20:45:30] <axelm> meeting starts.
[20:46:06] <hardie@jabber.qualcomm.com> Howdy, Monitor Allison!
[20:46:08] --- cullenfluffyjennings@gmail.com has joined
[20:46:49] --- nan_626 has joined
[20:46:57] <axelm> agenda bashing.
[20:47:17] --- miki has joined
[20:47:19] --- pk has joined
[20:48:09] <axelm> agenda accepted.
[20:48:36] --- randy has joined
[20:48:44] <axelm> note well being read by Andrew.
[20:49:17] <axelm> rohan attemps to stop him :-)
[20:49:28] <axelm> document status
[20:49:29] <hardie@jabber.qualcomm.com> rohan does not succeed, and takes 5p damage
[20:49:30] <axelm> -----------------------------
[20:50:22] <axelm> geopriv-civil will be an RFC soon..
[20:51:07] <axelm> there are issues with the option number in DHCP.
[20:51:56] <axelm> "geo-shapes" is going to the OGC
[20:52:15] <hardie@jabber.qualcomm.com> (the option number assigned by IANA was unique; the RFC Editor reflected the wrong one, though, and it did not get caught--as a result, the RFC needs to be re-issued to reflect the correct number)
[20:52:30] <mankin> Unbelievable!
[20:53:00] <axelm> output from that OGC work will go into pidf-lo draft, and will be used by us.
[20:53:18] <axelm> OGC will have a draft version in December.
[20:53:54] <axelm> revised-civic-lo needs a final revision to match henning's RFC.
[20:54:34] <axelm> hannes tschofenig talks about geopriv-policy.
[20:54:52] <axelm> --------------------------------------
[20:55:14] <axelm> slide about suggested draft updates.
[20:56:11] <axelm> hannes promises an update next week.
[20:56:36] --- rwatro has joined
[20:57:14] <axelm> chairs are working on milestone & charter update - will go to list.
[20:57:20] <axelm> no comments on this generally.
[20:57:56] <axelm> Layer 7 LCP
[20:57:58] <axelm> ------------------
[20:58:10] <axelm> presentation about updates between -02 and -03
[20:58:26] <axelm> purpose: collect reqs and scenarios.
[20:58:40] <axelm> 2nd purpose: capture discussions about l7 lcp.
[20:59:01] <axelm> ToC was extended - changes:
[20:59:19] <axelm> 1) restructured discover mechanisms
[20:59:49] <axelm> 2) VPN considerations, location-by-reference and loc subscriptions.
[21:00:20] <axelm> 3 of 4) prevent faking location based on DoS
[21:00:34] <axelm> requirements: editorial changes
[21:00:47] <axelm> 4) sec. cons. rewritten based on threat classification
[21:01:16] <axelm> next steps: design team work finished. Is something missing in the doc?
[21:01:36] <axelm> should pretty much capture discussions...
[21:01:52] <axelm> turn it into WG item, and then WGLC soon?
[21:01:54] <axelm> comments?
[21:02:12] <axelm> Brian Rosen: supports adding as WG item.
[21:02:49] <axelm> Brian: closing is the right thing now.
[21:03:31] <axelm> Humming about WG adoption.
[21:03:35] <axelm> Adopted.
[21:03:49] <axelm> next doc.
[21:04:13] <axelm> geopriv-locationreg
[21:04:17] <axelm> ------------------------------
[21:04:21] <axelm> s/reg/ref/
[21:04:32] <axelm> very early draft put together over dinner ...
[21:04:47] <mankin> Axel, WG - we can't adopt new work - we can ask for consideration of adoption when we recharer
[21:04:59] <mankin> s/recharer/recharter
[21:05:03] <axelm> ok, sorry.
[21:05:31] <mankin> Something for Randy to point out if it was not said to the room
[21:05:37] <axelm> Goals: UA to obtain location by ref of value
[21:05:59] <axelm> recipient should be able to "claim" LO
[21:06:23] <axelm> authorization by "pawn ticket"
[21:06:45] <axelm> unified locbyv locbyr mechanism.
[21:07:08] <axelm> Scenario slide.
[21:07:41] <hardie@jabber.qualcomm.com> the draft doesn't cite the Lemonade BURL work (which is also "pawn ticket") auth. Do folks who were at the dinner know whether it was considered and rejected as not meeting the needs?
[21:08:10] <axelm> another slide "AOR based" scenario.
[21:08:16] <randy> I pointed that draft out on the geopriv list some time back, but likely that was forgotten.
[21:08:46] <axelm> another scenario, this time by-value.
[21:08:56] <axelm> Event parameters slide.
[21:09:09] --- pk has left: Computer went to sleep
[21:09:30] <axelm> IP address, MAC address, "msap" = base64 encoded MAC service access point.
[21:09:42] <axelm> CDP could be added as well
[21:09:58] <hardie@jabber.qualcomm.com> It
[21:10:00] <axelm> those tokens would be used as identifier.
[21:10:09] <hardie@jabber.qualcomm.com> is now RFC 4467 (URLAUTH)
[21:10:39] <axelm> rohan: sent comments to list earlier today.
[21:11:40] <axelm> henning: discussed allowing a time specification.
[21:12:01] <axelm> would not change fundamental.
[21:12:54] <axelm> rohan's 2nd problem: should not bake into presence.
[21:13:46] <axelm> henning: would work with any event package.
[21:14:29] --- pk has joined
[21:15:42] <axelm> rohan has security considerations about the "pawn". Henning will elaborate on that - is one of the open issues.
[21:17:14] <axelm> ted hardie: there is more work about "pawn". was that just because you don't know?
[21:17:24] <axelm> henning is not aware of that work.
[21:18:52] <axelm> ted hardie: suggest to seperate the first SUBSCRIBE in the first scenario from the other transaction.
[21:19:12] <axelm> ted & henning will talk offline.
[21:19:38] --- hardie@jabber.qualcomm.com has left
[21:20:01] <axelm> james winterbottom: aquisition mechanism tied to sip - might be useful outside sip as well...
[21:21:06] --- hardie@jabber.qualcomm.com has joined
[21:21:34] <axelm> james winterbottom: no mechanism to indicate kind of "location determination", eg. for use in mobile networks, where multiple mechanisms might be available.
[21:21:54] <hardie@jabber.qualcomm.com> And since I did not say it at the mic: repent and sin no more! The willingness to deal entirely with LIS and not location objects really risks the whole framework.
[21:22:28] <axelm> andrew: that is a req that we did not consider...
[21:22:47] <richard.barnes> question: does the draft specify that the reference that's returned is a sip: URI?
[21:23:42] --- raj has joined
[21:24:02] <hardie@jabber.qualcomm.com> well it does say it returns a rpru, which is "by including location information encoded as a PIDF-LO [10]. We refer to this SIP URL as a randomized presence retrieval URL, or an RPRU for short.
[21:24:05] <axelm> comment about that some PIDF-LO fields don't make any sense in this scenario.
[21:25:23] <axelm> HELD - location aquisition solution
[21:25:26] <axelm> -----------------------------------------
[21:25:37] <axelm> james winterbottom speaking
[21:26:07] <axelm> based on real-world reqs.
[21:26:33] <axelm> provides application layer loc aquisition not tied to sip only.
[21:26:57] <axelm> demonstrations to residentail broadband.
[21:27:06] --- raj has left
[21:27:23] <axelm> currnently HTTP binding supported.
[21:27:47] <axelm> Basic operation: HTTP GET, identification via client IP.
[21:27:56] <axelm> location provided as PIDF-LO
[21:28:13] <axelm> LIS discovery via Provisioning or DHCP.
[21:28:24] <axelm> or reverse DNS or UNATPR
[21:29:17] <axelm> differentiators:
[21:29:30] <axelm> supports requesting location in form usable by application
[21:29:52] <axelm> supports response time indicator, to choose determination technique
[21:30:06] <axelm> support target identity extensions.
[21:30:12] <axelm> (eg. for DSL)
[21:30:28] <axelm> supports target to LIS loc capability exchanges.
[21:30:40] <axelm> (for target base measurements)
[21:30:58] <axelm> context and references support
[21:31:22] <axelm> URI types to access target location can be SIP or HTTP
[21:31:45] <axelm> HELD identity extensions example slide.
[21:33:12] <axelm> Device capabilities
[21:33:27] <axelm> device can assist in location determination.
[21:33:40] <axelm> (timing/signal measurements eg.)
[21:33:53] <axelm> types of HELD device capabilites exchange.
[21:35:09] <axelm> device to LIS capabilities exchange.
[21:36:46] <axelm> open source HELD client posted to sourceforge
[21:37:43] <axelm> Brian: design team failed to complete the reqs - because that stuff is all not in the reqs..
[21:38:03] <axelm> Brian: any of those additional things could be added to _any_ protocol.
[21:38:21] <axelm> Brian: those are mechanisms, not protocol items.
[21:38:50] <axelm> James: why not pick a protocol that is there and works?
[21:39:38] <axelm> Henning: what has changed since last time?
[21:39:59] --- richard.barnes has left
[21:40:10] <axelm> James: this protocol supports all reqs - so ?
[21:41:02] <axelm> rohan: we have reqs - both support the reqs - could say all that has been mentioned about hennings doc as well..
[21:41:29] <axelm> cullen: we know IETF processes - do we work towards consensus?
[21:41:43] <axelm> andy: there are converging ideas as well...
[21:42:30] --- Antoin has joined
[21:42:39] <axelm> andy: progress may be slow and painful, but we do progress.
[21:43:55] <axelm> schnitzlein:has the impression that a lot of reqs were proposed to support a solution..
[21:44:41] <axelm> keith: are we looking for one protocol solution?
[21:46:51] <axelm> Brian: interopability is key thing. work harder to achieve agreement on _one_ l7 lcp.
[21:47:19] <axelm> Hannes: IEEE also works on similar protocols...
[21:48:03] <axelm> Ted hardie: IETF has good experience in evaluating protocols against reqs.
[21:48:19] <axelm> Ted Hardie: reqs do mention that "there can only be one".
[21:49:37] <hardie@jabber.qualcomm.com> I believe I said " I do not see "there can be only one" in the reqs"
[21:49:41] <axelm> Brian: isolating "mechanism" from "protocol" would help
[21:49:44] <axelm> sorry.
[21:49:56] <hardie@jabber.qualcomm.com> not at all; thanks for the scribing you're doing.
[21:50:31] --- hardie@jabber.qualcomm.com has left: Disconnected.
[21:51:18] <axelm> dynamic feature extension to pidf-lo
[21:51:20] <axelm> --------------------------------------------
[21:52:13] <axelm> reqs and use cases.
[21:52:20] <mankin> Axel, I just want to say, I too think you're doing a great job of scribing
[21:52:29] <axelm> indicate temporal features
[21:52:38] <axelm> track location of moving objects.
[21:52:49] <axelm> eg. safety personnel.
[21:52:58] <axelm> extends 4114
[21:53:14] <axelm> based on GML dynamicFeatures
[21:53:22] <axelm> XML example shown.
[21:53:42] <axelm> includes "speed" / "compasspoint" elements.
[21:54:11] <axelm> may contain multiple moving elements.
[21:54:39] <axelm> could also use other GML features... but..
[21:55:23] <axelm> rohan: again an issue for "do we have reqs for this"?
[21:55:30] <axelm> rohan: may be premature.
[21:56:13] <axelm> hannes: extnesion of 4 fields in pidf-lo , same like radius / filters stuff.
[21:56:40] <axelm> rohan: l7 should have higher priority than this.
[21:57:49] <axelm> next steps: adopt as WG, close issues, revise text...
[21:58:17] <axelm> Binary to Decimal conversion for LCI
[21:58:19] <axelm> -----------------------------------------
[21:59:24] <axelm> describes nature of data def. in RFC3825 - includes examples of conversion binary<->decimal.
[21:59:55] <axelm> issue with the resolution parameter (significant digits)
[22:00:01] <axelm> addressed in this draft.
[22:00:29] --- hardie@jabber.psg.com has joined
[22:01:34] <axelm> comments: resolution of significant bits != geo-coordinate measurements
[22:01:42] <axelm> (fixed length calls for this)
[22:02:06] <axelm> however, this doc does not _change_ 3825.
[22:02:32] <axelm> appendix A of pidf-lo profile gets it wrong..
[22:02:52] <axelm> James winterbottom: It _does_ change the way 3825 is interpreted...
[22:04:15] --- Antoin has left
[22:04:53] <axelm> James: needs to be a standards track, because updates ...
[22:05:14] <axelm> ??: no, attempts to clarify appendix A only.
[22:05:58] --- otmar has joined
[22:06:01] <axelm> schnitzlein: we are just attempting to clarify the misinterpretation..
[22:06:50] <axelm> Ted: did anyone implement it wrong? if not, we just to need to get the information out...
[22:07:35] <axelm> Ted: if there's a real risk that implementations will be wrong, then do it.
[22:08:18] <axelm> Hannes: would see something like the GML clarifications, which were pretty confusing in the first point.
[22:09:12] <axelm> hannes: think it's a good first step, but more structuring needs to be done.
[22:09:42] <axelm> James: disagree with OGC?
[22:09:55] <axelm> Schnitzlein: 39 and 39.00000 is something completely different...
[22:11:17] <axelm> andy: we should care about interopability, so if that clarifies, we should move it forward.
[22:13:09] <axelm> cullen: why not make a doc which resolves that interop problems?
[22:13:25] <axelm> andy: add text why people are misinterpreting that?
[22:14:54] <axelm> discussion revolves around "if it's broken, fix it. but is it broken?"
[22:15:38] <axelm> no disagreement on "the right thing" - just about the expression of it...
[22:16:01] <hardie@jabber.psg.com> speaking for myself: if there was enough worry that misinterpretation would result in broken interoperability that a clarification is needed, I think tying it to the document it is clarifying is good
[22:16:54] <axelm> brian: we should fix the text of appendix A, and replace it.
[22:17:41] <axelm> schnitzlein: it's just a misinterpretation of the doc...
[22:18:49] <axelm> hum: who thinks this should be added to our milestones...
[22:19:15] <axelm> (and hence become WG item). some hummers are confused.
[22:19:24] <axelm> new Q: this to be a WG item?
[22:19:35] <axelm> Hum indicates that this should be a WG item.
[22:20:22] <axelm> next presentation - James Polk.
[22:20:50] <axelm> Geopriv location error registry
[22:20:52] <axelm> ------------------------------------
[22:21:53] <axelm> more granular errors needed.
[22:22:12] <axelm> like "civic requested", "geo received".
[22:22:33] <axelm> draft creates IANA registry for such location errors.
[22:23:20] <axelm> eg. request with location, some error with that, "424 Bad Location Information" returned. but currently no means to convey additional info.
[22:23:34] <axelm> "Location Error Indication" adds this.
[22:23:55] <axelm> currently, 11 + 7 error codes defined.
[22:24:22] <axelm> based on lost -01
[22:24:46] <axelm> a few suggestions received.
[22:25:31] <axelm> error codes gone in lost -02
[22:25:47] <axelm> so, could either have each using protocol define it's own numbers,
[22:25:58] <axelm> or have an "informational" which just lists error types.
[22:26:44] <axelm> going to present in SIP on friday - can that be resolved till then?
[22:27:16] <axelm> Henning: generally, have tried to define error conditions in the protocol which uses them...
[22:27:56] <axelm> SIP error codes came from HTTP, however, eg. most SIP errors did not become HTTP errors...
[22:28:34] <axelm> henning: probably not so much common between protocols that they could use a "centralized" definition.
[22:30:17] <axelm> hannes: when we copied from HTTP we found out that some are not applicable, some need to be added... so...
[22:31:20] --- nm has joined
[22:31:21] <axelm> keith: stepping back: what are we trying to solve?
[22:32:15] <axelm> keith: the problem is eg. the mapping from LOST to SIP errors... need the SIP proxy to understand the semantics of error codes?
[22:32:35] <axelm> or - do we loose information here, and just return a general error..
[22:33:04] <axelm> so, the basic idea was easier interworking..
[22:34:04] <axelm> randy: integrity of location info when pushing between protocols is good - for error codes makes sense as well..
[22:34:21] <axelm> but maybe a small XML error snippet would work as well.
[22:34:36] <axelm> wouldn't be tied to a specific proto.
[22:37:16] <axelm> henning: need a decision whether we want to move all those errors back and forth, or if we can live with "lossy" errors.
[22:37:44] <axelm> Hannes: there might be privacy related concerns as well.
[22:37:53] <axelm> Is probably more than just error codes..
[22:39:43] <axelm> henning: 3 options:
[22:39:49] <axelm> 1) binary success/fail
[22:39:58] <axelm> 2) translate error codes between protocols
[22:40:18] <axelm> 3) generic "content" errors eg. in some XML interpreted by UAC.
[22:41:04] <axelm> 3) would require to define a namespace, and have an BCP which describes those elements (application/lost-error+xml) ...
[22:42:02] <axelm> James: hmm.. any UAC would then need to support those error conditions (eg. "got geo, civic requested" needs to be answered by the UAC with the other option)
[22:42:07] --- pk has left
[22:46:18] <axelm> W3C workshop on Privacy
[22:46:20] <axelm> ---------------------------------
[22:46:25] <axelm> Hannes speaking.
[22:47:04] <axelm> contributed an overview paper on geopriv architecture.
[22:47:21] <axelm> feedbakc received:
[22:47:37] <axelm> #1: Intended recipient not explicit.
[22:48:46] <axelm> #2: sticky policies only for location.info
[22:49:10] <axelm> other information could be sensitive also, so why only location info?
[22:50:15] <mankin> who spoke just now?
[22:50:33] <hardie@jabber.psg.com> Jon
[22:50:43] <axelm> #3: policy push vs. policy pull
[22:51:15] <randy> I said the "sticky rules" versus "core rules" was a semantic as well as terminology issue:
[22:51:45] --- lemmakin has left
[22:51:50] <randy> "Core" meaning absolute minimum rules, while "sticky" might imply any rules you want carried along.
[22:51:56] <axelm> W3C pointed to P3P...
[22:53:26] <axelm> next steps - last slide
[22:53:35] <axelm> how to process feedback?
[22:53:43] <axelm> Establish close relation to W3C?
[22:53:53] <mankin> I didn't say I'd do more with W3C but would go have a talk with Danny Weitzner
[22:53:59] <axelm> participate in upcoming Policy interest framework group.
[22:54:45] <axelm> andy: #2 is probably not relevant to geopriv...
[22:55:46] --- nm has left
[22:56:04] <axelm> meeting concludes.
[22:56:08] --- randy has left: Logged out
[22:56:10] --- axelm has left
[22:56:14] --- rwatro has left
[22:56:25] <mankin> but if we want to do topic specific liaising to a w3c WG we have to get that blessed by IAB
[22:56:30] --- ysuzuki has left
[22:57:16] --- hardie@jabber.psg.com has left
[22:57:39] --- miki has left
[22:59:43] --- cullenfluffyjennings@gmail.com has left
[23:06:05] --- nan_626 has left: Disconnected.
[23:09:33] --- mankin has left
[23:22:55] --- otmar has left