Subject: [Ecrit] Rough notes

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jul 2011 21:02:22 +0200

10 min * Agenda Bashing, Draft Status Update (Chairs)
Concerning issues holding up approval of phone bcp and framework, Brian is still awaiting response to his questions. Update can happen this week if no objections to his proposals.

Concerning status of lost-sync - 11 reflects discussions Hannes had in Prag on WGLC issues, and he feels document is now about ready to go. Mentioned two open source implementations.

Rough loc is about ready to go.

Brief report of ESW8 in Budapest, April, from Richard and Hannes.

Richard mentioned that NENA i3 spec is released.

Extra item: Demise of 802.23, Geoff Thompson
Final report - not enough people participating or contributing, so documents will be archived and the group will be killed off in September. Draft may have value as pointer to work needing to be done in 802.1 to fill gaps.

Randall asked for clarification. Response from Geoff was that you would get a network topology and which node in that topology has location. Correlating network topology with physical topology.

Richard asked question ???? Missed this and response.

10 min. * Similar Location (Roger Marshall)
Brian liked the example slide but had a slight unease about the particular example
????: If one of the elements is wrong, but pointed out that this example is only for the valid case.
????: so need to have very clear definition of what is valid or invalid. He was asked to provide some input.

Roger wanted to make this a WG item. Brian supported it, saying that open items were not technical issues. Marc had some concerns about backward compatibility. Brian said there are no such issues.

Will be a call for adoption on list in a couple of weeks.

10 min * Data Only (Brian Rosen/Hannes Tschofenig) Brian presented.
Hannes: Not sure on CAP question. Brian says he should come up with a counter example where it doesn't work.
Hannes: CAP is using XML in a very verbose way. Brian says we are using CAP because it is the generally accepted mechanism for this type of thing. If you want to change, don't make a new type of CAP.

????: Distinction between non-human-associated and non-human-initiated. CAP is OK if no human interaction, but a heart-rate monitor might later on have voice as well, so might want to establish a session.

Authors asked to summarise the issues and put to the list.

10 min * Additional Data (Brian Rosen) 
Looking for feedback on whether his breaking up into blocks and other received comments have been handled correctly.

????: Should avoid losing data on call forwarding. Brian said original PSAP would pass it along. Brian wants to know if there is any data missing from his list.

James Winterbottom: Concerned about privacy issues, things in INVITE message body being seen by entities en route. Brian - security section should warn against sending private information.

Martin: Draft says all the right things but a little confusing in language. Need to spend more time on language before final review. Martin will send specific comments.

20 min. * Trustworthy Location Information (Bernard Aboba/Hannes Tschofenig) 
Bernard's presentation:

Discussion on whether Geolocation API requirements lead it not to reveal source of location. Fact remains it doesn't give the source.
Roger: If you include uncertainty, also need to include confidence.
Brian: Should send what you know. Don't send what you don't know for certain.
Bernard will propose resolution based on feedback received.

Hannes's presentation:
Martin Thompson: Different identities might not be meaningful to all entities.
Bernard: Is a link between accountability and trustworthy location, but only partial. Need signed location.
Geoff: Location isn't the problem, people are the problem, and location spoofing is the problem. So have method of fixing it in terms of people.
Brian: Strongly object to fact that document has no conclusion. NENA didn't understand what it was asking for. Location signing is helpful but insufficient. Saying that you can't solve enough problems by location signing does not mean it is not helpful. Hannes says it is fair to say in what cases things work and in what cases they don't work.

Richards: Trade-off is between access and security. Can't say can't do location signing just because there are entities that don't sign location.

Martin: Some of the solutions we are looking at are very abstract - need something more concrete. Hannes: this is because there is so much outside the traditional things we deal with.
Martin: Would help to work through specific cases. Gave example of not knowing it is emergency call when asking for location.

Brian: No silver bullet, no perfect solution, so have to deploy multiple imperfect solutions.

20 min. * Unauthenticated and Unauthorized Devices (Hannes Tschofenig)
On issue 1:
Richard: As host, I can make the necessary holes for LIS and LOST access, but have to open up SIP, perhaps to limited service providers. Document should say what you need to open up.
Geoff: We considered this problem in 802.23, and concluded it was a bad idea to provide access to an arbitrary SIP service provider, so should have a single one or a limited number.
Martin: SIP has the means to override default ports, and so on. How about ISP obtaining from LOST server the legitimate places an INVITE request can go to, so can ensure INVITE only goes to PSAP.
Richard not sure this would help.

Richard: Another aspect is that there are other ways an ISP can make things more predictable ????

James: ????

On the document in general:
Brian: This is way ahead of where we need specification - no regulation yet. Just document what the issues are, but don't provide solutions.

Bernard: Thought issues 2 and 3 were already resolved.

20 min. * PSAP Callback (Christer Holmberg/Hannes Tschofenig) Christer presented.
Brian: Isn't requirement 2 already met if you meet requirement 1.
Martin Dolly: Need an emergency indicator such that for a duration in time you can let calls through if they have that indicator, and that can also be used for turning off features such as call forwarding.
Brian: Have not answered my question. But may be a requirement for device to recognise emergency callbacks.
Martin: Callback indicator could also be used to block other calls for a period of time.
????: Agrees with Martin.
Randall: Requirement 1 is really two requirements: the same device, and second that call reaches that device.
Andrew Allen: 1 deals with issue of multiple devices, and 2 is to do with not being transferred elsewhere or going through additional features before getting there.
Geoff: 2 is just a detail of 1, and there are a lot more details to be added.
Brian: Separating addressing from permission might be useful.
Brian: What actually happens today is that you attempt a callback and it may or may not work. PSAPs have not asked for anything better.
Christer: ????
Martin Dolly: doesn't exist in circuit switched world because can't be done, but want to do better in the IP world.
Brian: But we have not been asked to do this.
Christer: 3GPP is asking for it.
???? from Canada: Do have a requirement for holding a 911 call and preventing hang-up, so no need for callback, just ringback (connection is held up).
Randall: The Canadian idea can only work in a legacy wireline environment.
Brian: There are those who disagree with that point of view.
Brian: More text is needed to fulfil something in PhoneBCP?

Hannes: Need to look at scenarios.

No conclusion.

20 min. * Questions?