[18:25:57] --- tomkri has joined
[18:26:15] --- tomkri has left
[18:43:36] --- richard.stastny@jabber.org has joined
[18:44:05] --- richard.stastny@jabber.org has left
[18:44:23] --- richard.stastny@jabber.org has joined
[18:46:09] --- tomkri has joined
[18:46:24] --- mlepinski has joined
[18:47:00] <mlepinski> Marc: Agenda
[18:48:08] <mlepinski> Brian Rosen : Bashing Agenda
[18:48:39] <mlepinski> Reverse Framework and BCP
[18:48:57] <mlepinski> Ted Hardie: Claims to only need 10 minutes
[18:49:19] --- isudo has joined
[18:49:40] <mlepinski> James Polk: SoS namespace will go under framework discussion
[18:49:54] <mlepinski> Marc: Document Status Slide
[18:50:01] --- klensin has joined
[18:51:06] <mlepinski> Next Slide: IESG Discuss for Threats document
[18:52:06] --- uli.m has joined
[18:52:57] --- richard.barnes has joined
[18:53:29] <richard.barnes> Security threats in IESG discussion
[18:54:11] <richard.barnes> (Winterbottom) Seems a lot like location dependability issues, should this be in GEOPRIV?
[18:54:26] --- bnsmith has joined
[18:54:26] <richard.barnes> (Hannes) We're addressing GEOPRIV security separately in that group
[18:55:41] <richard.barnes> Service URN in IESG discussion
[18:56:07] <richard.barnes> (Peterson) Probably want to distinguish between blocking and non-blocking comments
[18:56:50] <richard.barnes> New proposed milestone list
[18:58:30] <richard.barnes> 3rd SDO Coordination workshop 30 Oct - 1 Nov in Brussels
[18:58:41] <richard.barnes> ATIS Liaison still in progress
[18:59:41] <richard.barnes> [moving to Ted/LoST...]
[19:00:16] <richard.barnes> lost is in -06 now
[19:00:41] <richard.barnes> -06 is in ECRIT SVN, but not IETF ID repos
[19:01:18] --- Barbara Stark has joined
[19:01:48] <richard.barnes> error codes: if http succeeds get 200, LoST-specific error code
[19:03:39] <richard.barnes> no contention against adding circles, ellipses, arc bands
[19:03:47] <richard.barnes> oh, no:
[19:04:10] <richard.barnes> (B. Rosen) is this the same as the shapes profile?
[19:04:29] <richard.barnes> (Hannes) trying to avoid conversion among geometries
[19:05:09] <richard.barnes> (Winterbottom) pdif-lo profile introduces prism, ellipsoid in addition
[19:05:19] <richard.barnes> can just handle these in 2d by projection
[19:05:42] <richard.barnes> would like to get shapes from profile and just throw them into lost
[19:07:24] <richard.barnes> going to submit -06 to drafts dir asap
[19:08:16] <richard.barnes> [moving to Brian/framework/phonebcp...]
[19:09:14] <richard.barnes> no update to phonebcp due to day job spike
[19:09:22] <richard.barnes> resolved comments in framework
[19:09:59] <richard.barnes> prof schulzrinne marked up the framework, scanned, sent to brian
[19:10:17] <richard.barnes> small updates to correspond to LoST updates
[19:10:31] <richard.barnes> Still a couple of open issues
[19:10:59] <richard.barnes> ... essentially the same as ECRIT's open issues
[19:11:37] <richard.barnes> (Hannes) don't think we really need everything in here. this is the base.
[19:11:57] <richard.barnes> e.g. can leave out location hiding and location integrity, which are longer way off
[19:12:20] <richard.barnes> unauthenticated network access could also be an issue
[19:12:46] <richard.barnes> (Brian) document is out there, do we want to make it an RFC with all those questions unanswered?
[19:13:21] <richard.barnes> framework and phonebcp will be the last two docs out of the group
[19:13:39] <richard.barnes> (Hannes) Some of these things might take a long time
[19:14:31] --- Leslie has joined
[19:14:35] --- klensin has left
[19:14:59] <richard.barnes> (Brian) do you want a whole RFC on location hiding?
[19:15:08] <richard.barnes> (Hannes) Sure, why not?
[19:15:12] --- klensin has joined
[19:15:59] <richard.barnes> (Brian) I had thought this would be a long-term document, but we can do it differently if you want
[19:16:10] <richard.barnes> (J. Polk) Agree that we should put off some issues to later docs
[19:16:43] <richard.barnes> (Blatherwick) Revving the framework is inevitable. Don't like it, but inevitable
[19:17:22] --- tetsu1 has joined
[19:18:57] <richard.barnes> (Hannes) Is everyone ok that the current framework has the endpoint getting its own location?
[19:19:21] <richard.barnes> (Winterbottom) I can see several scenarios, most probably related to location hiding
[19:19:49] <richard.barnes> e.g., in centralized office configs, an office pbx might make location requests to a LIS/LCS on behalf of the endpoint
[19:20:04] <richard.barnes> don't think current doc should prohibit this
[19:20:41] <richard.barnes> (Hannes) endpoint needs to know what to do, though
[19:21:18] <richard.barnes> (Brian) ... reading from framework ...
[19:21:34] <richard.barnes> (Winterbottom) Don't see any issue based on the text, Hannes' diagram doesn't correspond to the doc
[19:22:22] <richard.barnes> (JDR) This is about something completely different -- this says proxy can redirect to a URN, not that it can add a location and route
[19:22:42] <richard.barnes> (Hannes) need to make it clear what the architecture would look like
[19:22:57] <richard.barnes> (Brian) I meant the text to include that case
[19:23:05] <richard.barnes> No update to phonebcp
[19:23:25] --- nan_626 has joined
[19:23:32] <richard.barnes> Reorganization has been suggested - endpoint BCP and proxy BCP and access network BCP
[19:24:39] <richard.barnes> brian doesn't like this because people can lose context as they hop between docs
[19:24:52] <richard.barnes> compromise: reprise requirements, marked by who they apply to
[19:26:10] <richard.barnes> (Hannes) that's fine. want a way to reference
[19:26:14] <richard.barnes> (Brian) can do
[19:27:11] <richard.barnes> (Spencer) glad to see someone thinking about usability. would this be an informative appendix? what if it's a normative appendix that contradicts?
[19:27:30] <richard.barnes> (Spencer) Might be good enough to do it inline in the document
[19:28:18] <richard.barnes> The "Additional Data" issue
[19:28:54] <richard.barnes> There is a defined Call-Info header that carries pointers to XML documents
[19:29:08] --- nan_626 has left
[19:29:54] <mlepinski> Do we need to standardize (or reference) the data structure
[19:30:36] <mlepinski> [Jonathan] Unless you define the data structure, you will not get any interoperability
[19:31:28] <mlepinski> [Winterbottom] Are their security/privacy issues?
[19:32:27] <mlepinski> If this passes through a proxy before getting to the VSP, the privacy implications are bad
[19:32:49] <mlepinski> [Brian Rosen] Probably better to put this into a different document
[19:33:20] <mlepinski> [Hannes] Discuss this on the list.
[19:33:31] <mlepinski> [Hannes] Emergency Marking Issue
[19:34:46] <mlepinski> [Brian] I thought we decided on Jonathan's UA Loose Routing
[19:35:16] <mlepinski> [Jonathan] THis is an open issue. UA Loose Routing may be killed in SIP working group
[19:36:57] <Barbara Stark> I will
[19:37:13] <mlepinski> [Hannes] Need reviewers for PhoneBCP and Framework
[19:37:15] <Barbara Stark> I will review framework
[19:37:16] <richard.barnes> (so noted, barbara, thanks)
[19:37:29] <richard.barnes> [taking back over... thanks, Matt!]
[19:37:31] <Barbara Stark> And phonebcp when Brian publishes again.
[19:37:46] <richard.barnes> Now James Polk talking about resource priority header
[19:37:52] --- nm has joined
[19:37:59] <richard.barnes> draft-polk-ecrit-local-emergency-rph-namespace-01
[19:38:23] <richard.barnes> missed the deadline by 2hours
[19:38:35] <richard.barnes> Namespace for resource priority header
[19:38:54] <richard.barnes> NENA wants it, coders like it because it's easy
[19:40:12] <richard.barnes> idea is to use it within ESInet, but not excluding usage before then in the signaling path
[19:40:38] <richard.barnes> (B. Rosen) It'll get rewritten at the boundary of the ESInet, if it's present
[19:41:29] <richard.barnes> (S. Norreys) Don't understand, thought the RPH was to get it to the ESRP
[19:41:48] <richard.barnes> Could envision priority utilization within ESInet
[19:42:17] <richard.barnes> (J. Winterbottom) If you don't have the disaster example in the doc, put it in
[19:43:03] <richard.barnes> What value does it have coming from the UA?
[19:43:43] <richard.barnes> (S. Goldman) Having the RPH E2E is a good architecture. Should allow for it, even if the UE doesn't opt to insert it.
[19:44:32] <richard.barnes> (J. Gunn) Packetcable specifically says that it wants a new namespace for RPH too
[19:44:54] <richard.barnes> (T. Hardie) Have they already defined one? (A: don't know)
[19:45:18] <richard.barnes> (J-F. Mule) There's not active work in cablelabs to do any standards work
[19:46:09] <richard.barnes> (Hannes) Who has read this doc?
[19:46:30] <richard.barnes> ~25% of room?
[19:48:42] <mlepinski> [Richard] What about Fraudulently claiming something is an emergency call.
[19:50:00] <mlepinski> [Brian Rosen] Emergency calls shouldn't fail.
[19:50:20] <mlepinski> [Rosen] If there is a conflict, you don't get priority, but the call still goes through
[19:50:52] <mlepinski> [Keith Derge] Priority vs Pre-emption
[19:51:01] <mlepinski> [James] Priority not Pre-emption
[19:52:06] <richard.barnes> (J. Winterbottom) If this doesn't indicate that it's an emergency call, then if you don't include a sos URN, then it's reasonable to drop it
[19:53:23] <richard.barnes> (Hannes) Previously had the idea that service URN would identify emergency call, this is not true given SIP this morning?
[19:53:54] <richard.barnes> (JDR) the idea was that having the URN in the the R-URI would be a clear signal, then get flagged post-routing
[19:55:05] <richard.barnes> will continue to discuss in SIP
[19:55:46] <richard.barnes> [moving to location hiding discussion ... ]
[19:56:44] --- richard.stastny@jabber.org has left: Replaced by new connection
[19:58:01] --- richard.stastny@jabber.org has joined
[19:58:10] <richard.barnes> Some ISPs don't want to give away location away for free, some regulations forbid giving it away without consent
[19:58:35] <richard.barnes> (Linsner) Where in the docs does it say that the location is free?
[19:59:00] <richard.barnes> (JDR) assumption is that since the endpoint gets location, they either get it free or they pay for it
[19:59:21] <richard.barnes> in any case you're giving it the endpoint to do what it wants with
[19:59:39] <richard.barnes> (Hannes) So we're trying to make things work when the endpoint doesn't have (precise) location
[20:00:15] <richard.barnes> NB: Two types of location (1) for dispatch, and (2) for routing. This only concerns (2)
[20:01:20] <richard.barnes> (Polk) How does endpoint get precise location for dispatch?
[20:01:36] <richard.barnes> (Hannes) if endpoint has location, then it's not an issue. but we think this won't always be true
[20:02:22] <richard.barnes> (Polk) Some networks don't use TCP! Providers can choose not to implement specs, let the market decide
[20:04:39] <richard.barnes> (S. Kent) You're allowing for the network to give out references, but charging for use, right (Hannes: Yes, absolutely)
[20:04:59] <richard.barnes> (S. Kent) You don't need precise location for routing, but aren't there edge cases where that's not true?
[20:05:49] <richard.barnes> ... so whoever fuzzes the location has to have knowledge of the PSAP map? (A: Yes.)
[20:06:29] <richard.barnes> (J. Winterbottom) Agree that there are different precision requirements, but don't necessarily think that reduced precision is the solution
[20:06:50] <richard.barnes> (JDR) Also strongly in support of this work. Was worried that we'd make something that nobody would implement
[20:07:59] <richard.barnes> (Rosen) Second JDR. Rather we didn't have to, but seems necessary based on conversations with carriers AND regulators
[20:09:14] <richard.barnes> (Hardie) I disagree with JDR and Brian. Need to preserve end-user control, or things will fail for different reasons.
[20:09:38] <richard.barnes> If you put this in the standard, it MUST be optional
[20:10:19] <richard.barnes> This work CANNOT blow up the existing architecture
[20:10:48] <richard.barnes> Need to make it clear that this is an EXTENSION to the original architecture to accomodate those who won't implement the original
[20:11:19] <richard.barnes> (Linsner) If you make this too difficult on the user, then they'll find another way to get their location
[20:12:04] <richard.barnes> (Rosen) Noone has proposed breaking the GEOPRIV architecture. This is just an alternative.
[20:12:41] <richard.barnes> (Marhsall) cutting the line after J. Polk
[20:13:21] <richard.barnes> (JDR) agree with Ted. Proposed mechanism is intriguing -- it's giving you your location in "PSAP format"
[20:14:27] <richard.barnes> (Polk) One of the fundamentals of GEOPRIV was not to give misinformation, just lower precision. Need to make sure that any "fuzzing" doesn't betray that
[20:14:58] <richard.barnes> (Polk) Want this to be a separate set of RFCs
[20:15:14] --- nm has left
[20:15:59] <richard.barnes> (Hannes) Just want to see if this is a direction that the WG wants to look into
[20:16:30] <richard.barnes> (Hannes) Question to the group: Should this group work on location hiding?
[20:16:40] <richard.barnes> hands from the jabber room in favor?
[20:16:44] <richard.barnes> against?
[20:16:45] <Barbara Stark> yes
[20:16:53] <Barbara Stark> in favor of working
[20:17:47] <richard.barnes> No hands opposed in the room, moderate number in favor. Lot of abstentions
[20:18:17] <richard.barnes> [next speaker: 802.11u on unauthenticated network access]
[20:19:01] <richard.barnes> Two use cases in 11u
[20:19:19] <richard.barnes> (1) dedicated SSID for emergency services only
[20:20:23] <richard.barnes> (Hannes) What does "unauthenticated access" mean?
[20:20:47] <richard.barnes> (Speaker -- name?) We mean endpoints connecting without credentials to make emergency calls
[20:21:09] <richard.barnes> GAS - way to decide which network to use for your emergency call
[20:21:37] <richard.barnes> No encryption -- no protection from link-layer attacks
[20:21:53] <richard.barnes> use case (2) public credentials
[20:22:41] --- uli.m has left
[20:22:53] <richard.barnes> use 11i security
[20:23:26] <richard.barnes> concept: endpoint uses GAS to request credentials from AP
[20:23:48] <richard.barnes> AP provides credentials, endpoint uses them to associate with AP
[20:24:02] <richard.barnes> (Norreys) How does this solve the problem of link-layer attacks?
[20:24:10] <richard.barnes> Depends on the nature of the attack.
[20:24:16] <richard.barnes> Doesn't restrict calls.
[20:24:28] <richard.barnes> Does derive an endpoint-unique key
[20:24:53] <richard.barnes> (Hannes) That was the reason a liaison was sent to the EMU working group
[20:25:16] <richard.barnes> Correct. This is an ugly workaround to make a username/password mechanism work
[20:27:05] <richard.barnes> (Hannes) Some people might wonder how this relates to us. Here's the short description:
[20:27:26] <richard.barnes> In the current interaction, we assume that the user-VSP interaction doesn't need to be specified. Could be SIP, could be Skype, etc.....
[20:27:50] <richard.barnes> In this case, you don't have a VSP since you don't have credentials (if you lost ALL your credentials)
[20:28:19] <richard.barnes> If you have a VSP, but no access, the access net wants to make sure you only make emergency calls
[20:28:29] <richard.barnes> so the net needs to understand one or more VoIP signaling protocols
[20:29:05] <richard.barnes> Perhaps need to specify how one determines that a call is an emergency call.
[20:29:31] <richard.barnes> (Linsner) did you consider how you might do feedback? (A: No, out of 802.11 scope)
[20:30:02] <richard.barnes> (Winterbottom) Suppose I want to use Hannes AP, then can't get an IP from the DHCP
[20:30:11] <richard.barnes> Not an 802.11 problem, that would be a problem for this WG
[20:30:23] <richard.barnes> (Winterbottom) You've got to give EVERYBODY an IP address
[20:30:42] <richard.barnes> (JDR) This little problem, which everyone says is out of their scope, is the 1000000-pound gorillla
[20:30:52] <richard.barnes> [or, i guess, the elephant]
[20:31:04] <richard.barnes> at a system level, someone needs to figure out how this works
[20:31:13] <richard.barnes> (Linsner) Do we have a requirement?
[20:31:32] <richard.barnes> (Hannes) We've started other work without specific regulatory requirements
[20:31:48] <richard.barnes> The IEEE does the same, to account for the delay that it takes to make standards
[20:32:12] <richard.barnes> (Winterbottom) Large amount of this requirement comes from analogy to cellular space
[20:32:57] <richard.barnes> A lot of countries already turn off that functionality, or are considering it, since they never get valid calls that way
[20:34:08] <richard.barnes> (JDR) This is the Internet. There will be lots more cases where you don't usually have connectivity. Bigger issue is service to community -- it's good to have this capability!
[20:34:59] <richard.barnes> (Winterbottom) To clarify, most regulators I deal with are making the simile to cellular
[20:35:32] <richard.barnes> (Lennox) Is there a way for the endpoint to know that the network will actually route to emergency services, instead of a "dial 1 for murder"
[20:36:06] <richard.barnes> (JDR) None of these guys are providing LoST servers, etc.
[20:37:12] <richard.barnes> (Rosen) Sometimes, ideas that seem like a good idea just aren't. E.g. "big red 9-1-1 button" led to lots of accidental calls
[20:37:50] <richard.barnes> (Rosen) This will cause more problems than it solves
[20:39:01] <richard.barnes> (speaker -- name?) There are multiple levels of authentication. There could still be authentication at a higher layer.
[20:39:14] <richard.barnes> (Winterbottom) Operators are screaming "Don't do this."
[20:39:48] <richard.barnes> (Rosen) We do want to support when you don't have a carrier, but still want some level of identification.
[20:40:17] <richard.barnes> Basic rule is that if you can make another call, you can make an emergency call, if not, not
[20:40:38] --- tomkri has left: Logged out
[20:40:53] --- klensin has left
[20:41:00] <richard.barnes> (speaker -- name?) Question in response: There are some cell operators who have expressed interest in using .11 where it's hard to get cell signal. What about this case?
[20:41:26] --- mlepinski has left: Disconnected
[20:42:07] <richard.barnes> (JDR) This is the kind of issue I'm talking about. This is a lot different from cellular. You're not guaranteed access when the physical medium allows it, just because you have a provider.
[20:42:22] --- Leslie has left
[20:42:22] <richard.barnes> (Linsner) When my cell phone says "no service" I don't make a 9-1-1 call.
[20:42:53] <richard.barnes> (Rosen) The notion that you should be able to dial 9-1-1 when you can't otherwise make a call is the problem
[20:43:09] <richard.barnes> (JDR) That's because the assumption is that then you're some nasty SIM-less attacker
[20:44:46] <richard.barnes> (Hannes) It's a valid area of investigation. IEEE, WiMAX are doing it, we should also investigate how our architecture would work. Regardless of whether regulators would require this in some jurisdictions.
[20:45:05] <richard.barnes> (Gunn) It's up to the provider whether it says "no service" or "9-1-1 only"
[20:46:23] <richard.barnes> (Norreys) Between a rock and a hard place. There will be regulators who require it (Germany still requires SIM-less calls). Unfortunately, the PSAPs deal with MILLIONS of fraudulent calls from the black market.
[20:47:27] <richard.barnes> Show of hands to investigate: many in favor, 2 against
[20:48:03] <richard.barnes> (adjourned -- seeya!)
[20:48:16] --- Barbara Stark has left
[20:48:43] --- richard.barnes has left
[20:48:46] --- tetsu1 has left
[20:49:34] --- isudo has left
[22:20:53] --- isudo has joined
[22:54:52] --- richard.stastny@jabber.org has left
[23:47:03] --- isudo has left