[12:02:03] --- LOGGING STARTED
[14:50:06] --- bhstark has joined
[15:16:25] --- bhstark has left
[17:19:58] --- bhstark has joined
[17:45:10] --- ⎇ has joined
[17:45:54] <⎇> Barbara, are you local to the meeting?
[17:46:17] <bhstark> no
[17:46:29] <⎇> Can you hear the audio?
[17:46:33] <bhstark> yes
[17:46:38] <⎇> They just did "test test test"
[17:46:39] <⎇> Great.
[17:46:46] <bhstark> heard it
[17:47:53] <⎇> Now doing status; nothing not in adio
[17:47:56] <⎇> (er, audio)
[17:48:19] --- anewton has joined
[17:48:54] <⎇> pointer to issue tracker @ www.tschofenig.com; pointer on the list
[17:49:31] <⎇> now on rechartering slide
[17:49:43] <⎇> accepted, but web not yet updated to reflect
[17:49:48] <⎇> Same as proposed on the list.
[17:50:56] <⎇> Slide on the joint ad hoc meeting this last sunday
[17:51:10] <⎇> http://www.ietf-ecrit.org/3GPP-IETF-2006/
[17:51:56] <⎇> fiddling with the projector again
[17:52:09] <⎇> fixed
[17:52:14] <⎇> (hgs to the rescue)
[17:52:42] --- cullenfluffyjennings@gmail.com has joined
[17:52:44] <⎇> SDO coordination meeting for emergency services. date--september/october 2006
[17:53:05] <⎇> asked a variety of organization for interest
[17:53:38] <⎇> Slide on why this is being discussed; feedback, synchronization, and information-sharing
[17:54:02] <⎇> not yet sure about organization, though it will likely be hosted at Columbia
[17:54:44] <⎇> now discussing implementation activities
[17:54:52] <⎇> They are setting up a webpage, and will send a pointer to the list.
[17:55:00] <⎇> End of slides
[17:55:20] <⎇> James Polk at the mic on service urn issue he raised
[17:55:57] <⎇> He believes the service urn doc solution for finding a lost uri, but that it is incomplete
[17:57:18] <⎇> hgs notes that the service urn resolution stuff has been there for a long time, and that it has passed wg last called, and these aren't helpful
[17:57:32] <⎇> James likes the urn namespace part.
[17:57:47] --- cullenfluffyjennings@gmail.com has left
[17:57:53] <⎇> He dislikes the resolution aspects, and he would like it removed.
[17:57:59] --- ysuzuki has joined
[17:58:39] <⎇> there is a proposal for one, not the only, method
[17:59:38] <⎇> James repeats he doesn't think the draft should handlethis.
[17:59:41] --- cullenfluffyjennings@gmail.com has joined
[18:01:11] <⎇> HGS repeats that this is not meant to rule out other discovery mechanisms
[18:01:16] <⎇> James has alternates
[18:02:01] <⎇> Hannes notes that we have a full agenda, and that this conversation doesn't seem to be terminating, so we'll take it off line.
[18:02:11] <⎇> Goes back to the agenda.
[18:02:16] <cullenfluffyjennings@gmail.com> Agreed to get together after meeting and try and sort out this disagreement over the scope of the document
[18:02:49] <⎇> I am booked after the meeting, but James is way off base in his objection--urn resolution mechanisms are fine in urn docs, and it's a wacky view that they aren't
[18:03:06] <anewton> I agree.
[18:03:22] <⎇> LoST doc presented by henning; this preso doesn't incorporate jdr's issues.
[18:03:28] <⎇> Open issues presented
[18:03:57] <⎇> 15 open issues listed; http://www.ietf-ecrit.org:8080/Lost/
[18:04:15] <⎇> s/Lost/lost/
[18:04:28] <⎇> reviewing the proposed resolutions.
[18:05:13] <⎇> For #2, two cases--two representations of same address; hybrid location
[18:05:56] <⎇> rough consensus that case one has a danger of synch problems
[18:06:03] <⎇> ordering which one to use a problem, etc.
[18:06:08] <⎇> more interest in case two
[18:06:43] <⎇> But hgs has concerns about how likely this is.
[18:06:52] <⎇> suggested resolution: do not support for now
[18:07:23] <⎇> Keith asks if it is a geopriv problem, rather than ecrit
[18:07:50] <⎇> Andy says: if we are talking about composite locations in general, that's geopriv, but ecrit can profile this further for its use.
[18:08:37] <⎇> focus in these discussion has been on call takers, not on use by a LoST server for resolution to a psap
[18:09:13] <⎇> So using RFC 3825, to receive a geo with a floor cannot be used directly in a lost query?
[18:09:34] <⎇> go for a hum. Case one? who agrees that we should not support that.
[18:09:44] <⎇> No one eager to support that.
[18:10:57] <anewton> hannes: only relevant if psap boundaries are different on floor boundaries
[18:11:39] <anewton> ted: that is corner case. if you put it off now, we can support it later.
[18:12:01] <anewton> ted: must remember that this is psap resolution, not what is sent to the call taker
[18:12:46] <⎇> back to the list
[18:12:50] <⎇> humms are close
[18:12:50] <anewton> hum taken... no consensus either way
[18:13:04] <⎇> Now list all service functionality issue
[18:13:22] <⎇> resolution: return the child elements of a service URN for the area
[18:13:41] <⎇> (proposed resolution)
[18:14:48] <⎇> Martin asks if the assumption is that we're talking to the right LoST server for the area; you have to include location with the request for services.
[18:14:52] <⎇> Group agrees.
[18:15:02] <⎇> Otherwise resolution appears non-controversial
[18:15:22] <⎇> If there is no mapping for a specific query, should the result be returned for a generic query?
[18:16:12] <⎇> 4 choices are presented
[18:17:56] <⎇> Andy believe two and three are semantically error conditions but avoid re-querying.
[18:18:40] <⎇> Steve is worried about the list coming back to a panicky user
[18:19:10] <⎇> speaker says use one--get them to an emergency responder as soon as possible.
[18:19:32] <⎇> agrees--two does what one does, just returns the "real" service urn as well.
[18:20:10] <⎇> Keith asks if this for all services, or just sos services.
[18:20:50] <⎇> option 3 is always available as a server choice, so it could be applied for non-emergency services
[18:20:58] <⎇> jdr has the same issue.
[18:22:15] <anewton> keith: put a discussion of these into the doc?
[18:22:59] <anewton> ted: asking for child when there are only children does not work with the next hop up algorithm
[18:23:51] <anewton> henning: moving with option 2 if there is nobody really unhappy by this
[18:23:51] <⎇> moved to psap boundary hint issue
[18:23:59] <⎇> Alway return? ask explicitly?
[18:24:15] <⎇> rough consensus appears to be always return it?
[18:24:31] <⎇> /aside this could be one where the default for emergency doesn't make sense for pizza
[18:25:29] <⎇> jdr wants to do a "don't include a hint", so that when size is an issue (at emergency call time)
[18:25:54] <⎇> andy is suggesting an option, at least for now. hgs agrees
[18:26:42] <⎇> "authority", replaced by via
[18:27:14] --- martin.thomson has joined
[18:27:26] <⎇> annotation to the URL? e.g., indicate if the target URI would like the location as well.
[18:27:51] <⎇> current proposal: don't specify it now, but allow for this extensibility
[18:28:07] <⎇> dial strings: numbers, dial-string format, or as kpml?
[18:29:52] <⎇> henning is concerned about kpml in non-sos services; he's leaning for either numbers or dial-strings
[18:31:34] <⎇> jdr: believes you want more than just numbers. For all service, can we be sure that there is nothing but numbers?
[18:32:01] <⎇> rosen prefers dial-strings, okay with numbers proposal, but kpml is problematic
[18:32:26] <⎇> Cullen argues against kpml. don't revive it here.
[18:35:16] <⎇> rough consensus on taking kpml; default to first, until use cases on the list show need for dial-string draft format
[18:35:48] <⎇> LoST response with PSAP preference?
[18:36:12] <⎇> HGS thinks yet another layer of indirection here is of minimal value--omit at this point.
[18:36:30] --- lebb has joined
[18:36:51] <⎇> #10--Can we add an additional query attribute? Qualify the query, without mucking up the service urn.
[18:37:23] <⎇> resolution: not now, leave in extensibility hook, then revisit as advisory.
[18:37:57] <⎇> For referral: no cross-protocol refer, agreed that within LoST URL or host/port should be possible
[18:38:55] <anewton> kieth: is gen load balancing issue or a referral?
[18:39:05] <anewton> henning: the latter
[18:40:18] <anewton> ted: do a uri, not host/port.
[18:42:28] <⎇> Going through open issues from the Sunday meeting: other types of location information, other discovery of services, and how to encode civic regions.
[18:42:42] <⎇> Matching subset of civic object
[18:45:00] <⎇> jdr raises security question
[18:45:11] <⎇> jdr likes mutual tls auth
[18:47:47] <⎇> andy thinks mutual tls auth will not deploy, and it must be possible for a client to use with mutual tls auth
[18:47:55] <⎇> Brian goes into framework document
[18:48:12] <⎇> for andy above, use *without* mutual tls auth
[18:48:50] <⎇> framework should be standalone at a highlevel; will need to refer to others for details.
[18:49:02] <⎇> framework will be informative and phonebcp bcp
[18:50:14] <⎇> following the slides closely
[18:50:21] <⎇> open issues: including contact and aor
[18:50:33] <⎇> (first is immediate callback, the second is aor)
[18:50:48] <⎇> aor is for "followup"
[18:50:59] --- a.hawrylyshen has joined
[18:57:18] --- cullenfluffyjennings@gmail.com has left
[18:58:41] <⎇> for associted uris, protocol mechanism utility comes with privacy issues that are serious; they may or may not be possible in all jurisdictions
[19:00:19] <⎇> test call flow was discussed
[19:00:37] <⎇> Just said this document will try to document things that were considered and rejected
[19:01:45] <bhstark> I read it!
[19:01:58] <⎇> i'll reflect
[19:02:58] <⎇> discussion of the relationship to phonebcp
[19:03:16] <⎇> Hannes asks for hum on adoption as wg item.
[19:03:19] <⎇> adopted
[19:03:34] <⎇> Now on phonebcp.
[19:04:36] <⎇> couple issues not resolved: dhcp and l7 are listed; patty mccalmont says there should be no explicit list.
[19:06:54] <⎇> Brian Rosen responds that we should have to have a list, with a principle that all must be in the phone and the network should support one.
[19:06:58] --- a.hawrylyshen has left
[19:07:33] <⎇> Dan notes that is hard to have a must list for every environment; there may be a table.
[19:07:56] <⎇> Brian argues that we have to have a mandatory list
[19:08:31] <⎇> How to reach interoperability
[19:08:36] <⎇> is a real issue here
[19:13:38] <⎇> group talks about how the list is structured, whether self-config counts, and then goes into lldp-7
[19:17:08] <⎇> The rev to every phone aspect here is very troubling. The "rev to every network" would be getting screams, and I'm suprised that the "rev to every phone" is getting this mild a reaction.
[19:23:28] --- ⎇ has left
[19:44:28] --- ysuzuki has left
[19:56:04] --- martin.thomson has left
[19:57:29] --- anewton has left
[19:59:30] --- bhstark has left