IETF81 – Quebec City, Quebec Canada

ECRIT Minutes - summarized by R. Marshall, and based on raw notes from John Elwell (john.elwell@siemens-enterprise.com) and Ram Mahon R (rmohanr@cisco.com), that are appended below.

ECRIT Meeting time: 13:00 – 15:00, Monday - 25/07/2011

----------------------------------------------------------------

Approved agenda (as posted)

10 min * Agenda Bashing, Draft Status Update (Marc Linsner,

Richard Barnes, Roger Marshall)

10 min * Similar Location (Roger Marshall/Brian Rosen)

http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-01

Intention: Discuss changes & proposal for wg item

10 min * Data Only (Brian Rosen/Hannes Tschofenig)

http://tools.ietf.org/id/draft-ietf-ecrit-data-only-ea-02

Intention: Discuss issues and differences

10 min * Additional Data related to an Emergency Call (Brian Rosen/Hannes Tschofenig)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data-01

Intention: Discuss open issues

20 min. * Trustworthy Location Information (Hannes Tschofenig/Bernard Aboba)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location-02

Intention: Discuss issues and differences

20 min. * Extensions to the Emergency Services Architecture for dealing with

Unauthenticated and Unauthorized Devices (Hannes)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access-03

Intention: Discuss issues and differences

20 min. * (SIP) Media Feature Tag PSAP Callback (Christer Holmberg/Brian Rosen)

http://datatracker.ietf.org/doc/draft-holmberg-ecrit-callback-00

Intention: Discuss issues, merging & proposal for wg item

20 min. * Questions?

--/

--/ Summarized minutes:

--/

Start time: 13:04

Stop time: 15:00

10 min * Agenda Bashing, Draft Status Update (Chairs)

Status of phonebcp & framework drafts: Brian is still awaiting response to his questions. Update can happen this week if no objections to his proposals.

Status of lost-sync draft: new draft version -11 reflects discussions Hannes had in Prague over WGLC issues, and feels that the document is now about ready to go. Hannes mentioned two open source implementations.

Status of Rough loc: the draft is about ready to go.

Status of Emergency Services Workshop: Brief report that ESW8 took place in Budapest, this last April, from Richard and Hannes.

Status of NENA i3 Standard: Richard mentioned that NENA 08-003 (i3) specification has been published by NENA.org.

Status from IEEE 802.23 - the “Final” Report, Geoff Thompson related that the 802.23 work group is going to be officially closed down in September, and PAR cancelled (due to lack of participation). Question asked (Richard Barnes) about any way to keep it alive. Only if the IETF sent a letter to delay the closing could the 802.23 group be hibernated, eventually expiring – if no further activity, according to Geoff.

Clarification requested from Randall Gellens on whether Geographic or network NAT(?). 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 Barnes commented that 3 more documents expired.

Action: Please refresh soon as possible

next/

http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-01, Roger Marshall

Brian liked the example slide but had a slight unease about the particular example used.

Action: The example will be cleaned up.

James Winterbottom: commented that this doesn't work due to external policy decisions (NENA) that determines what is valid vs. invalid overall. If one of the elements is wrong... It was clarified that this example is only for the valid case.

Request: need to have very clear definition of what is valid or invalid.

Action: Brian, Roger to take offline, asked to provide some input.

Roger requested to make this a WG item. Brian supported it, saying that open items were not technical issues.

Marc had some concerns about backward compatibility (he said it sounded like this draft was still confused), and needed clarification in the draft. Brian said there are no such issues, that the mechanism is sound.

It was agreed that a call for adoption on list would happen in a couple of weeks.

next/

draft-ietf-ecrit-data-only-ea-02 Brian Rosen presented.

Brian: explains changes made to new version and clarfies what problem CAP in the draft addresses, explains CAP model

Hannes Tschofenig: Not sure if all the fields of CAP are useful as the use-cases are mostly around machines (non human initiated)

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. Asks would it better to have other encoding JSON(?)

Brian: we are using CAP because it is the generally accepted mechanism for this type of thing. Another option is to use call-info header. If you want to change, don't make a new type of CAP.

Brian: Example provided of a heart-rate monitor.

Randall Gellens: asked to clarify terms Non-human initiated vs. non-human-interactive. If Non-human-interactive, then CAP is OK, but a heart-rate monitor might later on have voice as well, so might want to establish a session.

Hannes, Richard: call to end the mic line

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

next/

draft-ietf-ecrit-additional-data-01 Brian Rosen presented

Looking for feedback on whether his breaking up into blocks and other received comments have been handled correctly.

3 proposal mechanisms:

1. URI points to XML structure,

2. CID points to body part, and

3. new provided-by pointer within the PIDF-LO

Requesting comments to see if prior comments are covered, all the data, got the syntax right?

Sohal: stated the challenge is when we do call forward we lose data. Make sure we don’t lose data while 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: stated that security section should warn against sending private information.

Martin: Draft says all the right things but a little confusing in language. It’s not written very well - lots of details missing. Not sure if you intend to use MIME types or Call-Info.

Brian: clarifies MIME types and asks for specific comments in mail list about language

Brian: look for your review/comments on the list

Richard: pretty quick to expect this? After that, we'll ask for reviews on the list.

next/

(Part_A)

draft-ietf-ecrit-trustworthy-location-02 Bernard Aboba

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.

Bernard: agreed.

Brian: Should send what you know even if you don't know everything about it. Don't send what you don't know for certain. List things that might be sent.

Example W3C Location API - list of things shown. What is returned in the API? Show list of what is defined.

W3C requirements - last one seems wrong or needs better translation

Action: Way forward - put some text to the document, get some discussion going around accuracy.

Bernard will propose resolution based on feedback received.

(Part_B)

draft-ietf-ecrit-trustworthy-location-02 Hannes Tschofenig’s presentation

Discussion: False/fraudulant calls, an example, in the US, "swatting", an attribution problem - points to draft - Identity & Location, types of Identity

Martin Thomson: almost doing this a dis-service by making it almost seem trivialized

Martin Thompson: Different identities might not be meaningful to all entities.

Bernard Aboba: There is a link between accountability and trustworthy location, but only partial. Need signed location. NENA took the position of making the location trustworthy by signing it.

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. Recommendations.

Richard: This document really talks about the trade-offs of security, or lack of. Can't say can't do location signing just because there are entities that don't sign location. The valuable outcome of this document is to brief the reader, if you allow these things, then this is the problem that will result.

Martin: Some of the solutions we are looking at are very abstract - need something more concrete, we could get further.

Hannes: I think it will always be wishy-washy because of all the things outside the IETF work. It is going to be this way as there are a lot of technical things that need to be clarified before the solution becomes clearer.

Martin: Would help to work through specific cases. Gave example of not knowing it is emergency call when asking for location.

Martin: A third, competing characteristic is "privacy" to security & identity.

Brian: No silver bullet, no perfect solution, so have to deploy multiple imperfect solutions - we have to employ all known mechanisms.

next/

draft-ietf-ecrit-unauthenticated-access-03 Hannes Tschofenig

Marc: had started WGLC last month.

Several comments on the list - need wg input before spinning a new version.

Issue 1:

Conclusion - no solution yet

Issue 2:

Brian: says the draft should document the issues and no solutions to these (as it depends on lot of factors, e.g., regulations)

Richard: As a 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…

On the document in general:

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

Bernard: Thought issues 2 and 3 were already resolved.

next/

draft-holmberg-ecrit-callback-00 Christer Holmberg

Christer: want to focus on requirements and not on solution in the slides

Brian: Isn't requirement 2 already met if you meet requirement 1.

Martin Dolly: Need an emergency indicator such that for a duration over 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: You have not answered my question. But may be a requirement for device to recognize 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.

Martin Dolly: [This] doesn't exist in circuit switched world because [it] can't be done, but [we] want to do better in the IP world.

Brian: But we have not been asked to do this.

Christer: 3GPP is asking for it.

Guy Caron: We 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 fulfill something in PhoneBCP?

Hannes: Need to look at scenarios.

No conclusion.

/end of summary.

--/

--/ Raw Notes by John Elwell:

--/

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.

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?

--/

--/ Raw Notes by Ram Mohan R:

--/

Notes for ECRIT:

Speaker - Marshall Roger

Brian rosen says: proposed modifications for all documents, no responses received, need to hunt teams ( includes framework and location drafts)

H. Tschofenig - Document(draft-ietf-ecrit-lost-sync-11) sent for review long time back

Richard Barnes - 3 more documents expired. Please refresh soon as possible

title : (IEEE802_23_final_rpt_to_IETF)

-------------------------------------------

Presenter - Geff Thompson

Geff: mentions status of the IEEE802.23

Rand - is it a Geographic NAT or network NAT mentioned in draft ?

Geff - it is a network topology

Presenter - Marshall

(draft http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-01)

-------------------------------------------------------------------------------------

Marshall: explains how quality feedback mechanism works.

Brian: clarifies its just a look up and no algorithm

?? - need to have clear definition of what is valid with in the fields

Brian, Marshall - take it offline

Marshall- requests to make it WG item, says needs justifiable reason why it cannot be made WG item

Brian - clarifies mechanisms are well defined and no open items in those.

Mark - what about back ward compatiblity, need clarificaton in draft

Brian - no issues w.r.t backward compatibility

Presenter - Brian

(http://tools.ietf.org/id/draft-ietf-ecrit-data-only-ea-02)

------------------------------------------------------------------------

Brian - explains changes made to new version and clarfies what problem CAP in the draft addresses, explains CAP model

Hannes Tschofenig - Not sure if all the fields of CAP are useful as the use-cases are mostly around machines (non human initiated)

Brian - clarfies the values of CAP fields takes care of all cases, requests for counter examples

Hannes Tschofenig - CAP uses heavvy XML. would it better to have other encoding JSON ?

Brian - we use CAP as it is generally accepted for this kind of standard, other option is to use call-info header

Presenter - Brian

(http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data-01)

------------------------------------------------------------------------------------

Brian - asks for more review before starting WGLC

Sohal - challenge is when we do call forward we lose data. Make sure we don’t lose data while forwarding

Brian - clarifies it is designed to take care of all data and takes care of all cases and asks for any thing missing.

Martin thompson - language needs more clarity in the draft, not sure if you intend to use MIME types or call info

Brian - clarifies MIME types and asks for specific comments in mailer about language

Chairs - asks for review comments to be posted to mailer

Presenter - Bernard Aboba

(http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location-02)

----------------------------------------------------------------------------------------

Roger marshall - include conference usecases with out which it is absurd.

Bernard - agreed

Bernard - propose a resolution based on feedback

Presenter - Hannes Tschofenig

Brian - strongly objects that this document does not have any conclusion. NINA is partially responsible for asking this document

Hannes Tschofenig - ??

Martin Thompson - lot of solutions we are looking at are abstract. We need concrete solutions

Hannes Tschofenig - It is going to be this way as there is a lot of technical things that needs to be clarified before the solution becomes clearer.

Martin Thompson -

Brian - there are no silver bullets. So multiple imperfect solutions can be put together to solve the problem

Presenter - Hannes Tschofenig

Draft - http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access-03

-----------------------------------------------------------------------------------------------------

Explains Issue:1

Conclusion - no solution yet

Issue #2:

Brian - says the draft should document the issues and no solutions to these (as it depends on lot of factors like regulations e.t.c)

PSASP call back

(draft-holmberg-ecrit-callback-00)

-------------------------------------------

Christer - wants to focus on requirements and not on solution in this slides

/end