[[These meeting minutes capture the notes of two persons, Andy Newton and Shida Schubert]]




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


Emergency Context Resolution with Internet Technologies WG

TUESDAY, July 29, 2008
1520-1720 Afternoon Session II
Convention 3 RAI ecrit

Note taker: Shida Schubert

== HIGHLIGHT of DISCUSSION==

Issue surrounding CPH. 
Discussion:
Regarding call-back be a replacement of CPH, it's a NO.
- CPH disable caller from making another call. It bricks the phone.

Concerns about the following requirements were expressed.
PD-5 : 
- It's dangerous because phone with multiple line can be bricked and 
may prevent user from making another emergency call via another provider 
when call was interrupted due to some external error (network problem etc.)
- Overload caused by massive emergency on the network may disconnect 
the already established call to the PSAP, causing the phone to brick without 
any hope for re-establishing the call.
- In some architecture it's impossible to retain the connection.

PD-6 
- The requirement was perceived as if it may invade the privacy of the caller 
(spy capability). 
- It was explained that the media path just needs to be retained so when user 
does pick up the phone, audio is available. 
- It was recommended to add PD-8 stating that the requirement is not to send media,
while its in premature disconnect state.

- PD-1 may be a concern >> The probability of DoS is differnt in VoIP.

- The need for making the requirements more reasonable in VoIP was expressed.
- Usage of modern UI rather than network oriented solution was proposed as a 
more effective/reasonable approach.

Documentation/Process debate
- Many expressed concern for delaying the documents simply to accommodate 
the requirements. As an alternative it was suggested to cut out the portion 
on CPH from phone-bcp and document it in a separate draft.

Conclusion: 
- Requirements need to be bi-directional. 
- Needs ML discussion on way forward.


Rechartering Discussion
Lengthy discussion on what group of documents should be on the new charter. 
3 groups were
- Emergency related LoST extension/maintenance
- non Emergency LoST usage
- Authority to Citizen Emergency

> No Conclusion. 

AD expressed that Authority to Citizen should be a separate effort. Even 
if it was to be picked up by ECRIT, BoF like meeting should take place to 
reshape the charter of ECRIT.

In general a lot of interests in pursuing Authority to Citizen work although, 
many seem to believe holding a BoF first is a reasonable way forward. 
- Steve will try to gather people to plan a BoF for the next IETF.

Chair took a poll on which items have interests from the WG to get a feel 
of what revised charter should look like. 
- See below for the detail of the poll (raise of hands).


== DETAIL NOTE ==

Topic: Status & Agenda bashing (including RFC in progress) - Chairs

Drafts
draft-ietf-ecrit-lost-10 (RFC Editor's queue)
draft-ietf-ecrit-mapping-arch-03 (IESG Evaluation :: AD Followup)
draft-ietf-ecrit-dhc-lost-discovery-03.txt (RFC Editor's queue)

Slide used: http://www3.ietf.org/proceedings/08jul/slides/ecrit-1.ppt

Presented by: Chairs

Presentation:
- Marc explained the agenda. 
- There is another Emergency SDO
- Vienna, Austria on October 21-23, 2008.


Topic: Status update/open issues with Framework and Phone BCP – Brian

Drafts:
draft-ietf-ecrit-framework-06
draft-ietf-ecrit-phonebcp-05

Presented by: Brian Rosen

Slide used: http://www3.ietf.org/proceedings/08jul/slides/ecrit-0.ppt

Presentation for Framework:
- WGLC completed.
- Some comments overlooked need to be reflected.
- Framework has no issues but issues in phonebcp may 
affect the framework.


Presentation/Discussion for Phone-BCP:
- Phone-BCP
- WGLC completed.

Open issue was raised surrounding UA 
unable to send BYE in the draft.

There are 2 problems
Premature Disconnect and Abandoned Call

Problem 1: Premature Disconnect
- Caller hangs up before call-taker wants to terminate the call.

Explained Current Implementaiton of CPH(Called Party Hold): 
>> Refer to Slide 8

Baseline Requirement is for PSAP to rapidly re-establish 
the connection to the user. 

In jurisdiction where there is no CPH and PSAP calls back the originator, 
is CPH and call-back perceived different?(Ted)

Yes it's different. Real problem is you can get Voicemail.. Instead of the originator.
Originator can also make a call, with CPH, originator can't make another call. (Brian)

Call-back is not a replacement of CPH.

There is nothing that can be done when the device is mechanically disconnected. (Henning)

Current text on the Phone BCP is not adequate. (Brian)
There is a negotiation mechanism necessary and that's a requirement. (Ted)

Requirements:
>> refer to Slide 9
PD-5
1. Problem when phone has multiple line presence, risk is 
if user is subscribed to multiple providers and phone is disabled to make 
a call because it's bricked by CPH even though the call failed due to 
external cause such as network trouble, user can't attempt to make another 
emergency call although it has a capability to do so. (Henning)

>> Needs ML discussion.

2. May be a concern if there is a massive emergency and there are overload 
happening.. (Problem with the network). (Andrew)
- There is a deployment experience around this. (Brian)
- Don't have experience of doing this in network. (Ted)
- We can still learn from what they have done. (Brian)


PD-6 
- Sounds like it's asking spy capability (listening in even when the phone is hanged up).
- No requirement is saying there needs to be an active media path available for 
when user picks up the phone.(brian)
- This is very difficult to resolve on the IP network (NAT binding etc.) (ted)

- Will feel comfortable if we can add PD-8 to add text to not send media,
while its in premature disconnect state. (Henning)

Suggestion: Add another requirement which explicitly prevents any media to 
go through the media path retained when CPH is enabled.

- PD-1 may be a concern >> The probability of DoS is differnt in VoIP.(Ted)
>> Causing many CPH so resources on PSAP is non-existent to make 
any out-going call impossible.

- PD-5/PD-7 are almost impossible in Wireless > resource preservation/release . (Hannu). 

- BYE control from the protocol is not good enough, especially with cellular, 
out of boundry problem etc will not prevent.. 

- We need a cognitive VoIP requirements. Needs to be 2 ways. (Henning)

- Agree, need to make the text to make the requirements more reasonable in VoIP. (Henning)

- Some solution in the area of using modern UI rather than network oriented solution 
may be much better/far more effective. (Henning)

- Concern because there is no way to know what the calling device is, the reason of 
the disconnect can't be known (Run out of battery, broken wire etc.).

- Why are we adding another 14months to phone-bcp/frameworks. 

Problem 2: Abandoned Call
>> Refer to slide 11:
- Caller hangs up before the call-taker picks up the phone.

- Until call-taker picks up the phone. It's not a CPH.(Marc)
- Requirements is that PSAP wants to control abandoned call. (Brian)

- How do they define abandoned call? (Ted) 
> They take a log. (Brian)

Requirements
>> Refer to slide 12: 
- UI can resolve this.. Don't think network needs to be involved. (Ted)

Documentation/Process debate
How can we finish BCP/Framework (Hannes)?
- They don't want to lose the capabilities.(Brian)
- Can't even agree on the requirements right now. (Henning)
- There are two approach discussed and both has its consequences, 
but two proposals are in polar opposite and it will not be a trivial effort 
to come to any consensus. It will hinder the progress of these 
documents. (Henning)

- Propose to separate the document.. (Hannes)

- There is a new protocol requirements necessary because of negotiation.(Ted)

- Propose to define a new draft, which will update the phone-bcp. Remove the 
text form the phone-bcp.(Ted)

Conclusion: Continue the discussion on the list.


Topic: Mapping Architecture
Draft: draft-ietf-ecrit-mapping-arch-03 (IESG Evaluation :: AD Followup)
Presented by: Henning
Slide: http://www3.ietf.org/proceedings/08jul/slides/ecrit-2.ppt

Presentation: 
Described the status of the document.
- Quickly went over the slide explaining the changes and 
action to be taken on each of the comments received. 
- No issues.
NO DISCUSSION.

Topic: LoST Synch
Draft: draft-ietf-ecrit-lost-sync-00 (new wg draft)
Presented by: Henning 
Slide: http://www3.ietf.org/proceedings/08jul/slides/ecrit-4.ppt

Presentation: 
Described the status of the document.
NO DISCUSSION.

Topic: Requirements for Location Hiding
Draft: draft-ietf-ecrit-location-hiding-requirements-00 (new)
Presented by: Henning
Slide: http://www3.ietf.org/proceedings/08jul/slides/ecrit-3.ppt

Presenation: 
Described the issues by going over the slide.
NO DISCUSSION. 

Topic: Rechartering discussion - What do folks want todo next? 

Draft: 
draft-polk-ecrit-local-emergency-rph-namespace-03 (updated)
draft-barnes-ecrit-rough-loc-00 (unchanged)
draft-schulzrinne-ecrit-unauthenticated-access-03 
draft-norreys-ecrit-authority2individuals-requirements-01 (updated)
draft-forte-ecrit-lost-extensions-00 (new indiv)
draft-forte-ecrit-service-classification-00 (new indiv)
draft-robins-ecrit-sub-services-00 (new)
draft-rosen-ecrit-ecall-01 (new)
draft-sun-ecrit-shelter-service-00 (new)
draft-sun-ecrit-unsafe-areas-00 (new)
draft-tschofenig-ecrit-trustworthy-location-00 (new)
draft-wolf-ecrit-lost-servicelistboundary-00 (new)

Presented by: Marc
Slide: http://www3.ietf.org/proceedings/08jul/slides/ecrit-1.ppt
Presentation: 
[Slide 6-17]
Marc explained the gist of each draft.

[Slide 18]
Presented the potential charter item group.

For authority to citizen we need a framework to come up with 
requirements, need a signle direction with what we mean by 
authority to citizen. (Steve)

Don't think non-Emergency Services are in scope of this WG. (James)

To handle this outside of ECRIT, will mean either to handle it 
at general RAI or spin off a new WG and we all know the effort to 
spin off a WG.(Henning)

Need to think about what's going to be in the charter..(Jon)
It's good to pick a manageable chunk of work to be effective, suggests 
to work on the black sheep(Authority-Citizen) separately(Jon) 

If you decide to handle Authority-To-Citizen in ECRIT, recommend 
to hold some BoF like meeting. (Jon)

Don't want to see ECRIT to handle every items at one time. (Jon)

Auth-Citizen needs independent effort.(ted)

Support the BoF (ted,brian and others)

Unless starting a BoF will pull in new people, pointless 
to separate the group.(Henning)

If same sort of people are the only ones at the BoF,
don't see the benefit of separating the work. (Henning)

From administrative perspective, BoF like process needs to 
take place. (Jon)

Can be done in ECRIT session, but will advertise what 
the new charter is going to look like. (Jon)

Chair poling the group for what people want to see in the new charter.
> Favour for 1 and 3 
> Not in favour 

Discussion on how the hum should be taken.

> Taking out non-E service
8 in favor, 1 opposed.
> Taking out Authority-Citizen Services

AD opposed to how the hum was taken, wants to see 
what is most important right NOW!

Some expressed there is no reason WG can't work on some 
of the less important item when there is a time left.

There is no reason to prevent shipping draft that's 
ready.(Henning)

Chair proposes to hold a BoF like meeting at the next 
ECRIT. 

Chair started to poll the group for each of the items 
if WG is willing to spend the effort(Potential WG item). 

rph-namespace
5 in favor
1 against

rough-loc
9 in favor
2 against

unauthenticated-access
Not sure where it's going to be used. (Ted)

There is an effort arising to look at this problem. (Brian)
It will be based on the jurisdiction. But it may be 
a bit too pre-mature.
Emphasis was made that it is not about anonymous call. (Henning)

Will need to discuss.

authority2individuals
Steve will try to gather people to hold a BoF for the next IETF.

lost-extensions
12 in favor
2 against

service-classification
Should not be considered for WG item but deserve an expert review.


sub-services
0 in favor
3 against

ecall
Need to discuss more.
Need feedback from 

shelter-services
5 in favor
against

Debate about why taking the poll, many drafts are too premature. 
Chair expressed it's needed to grasp what the charter should look like.

undsgr-area
2 in favor
3 against

trustworthy-location
not enough readers.

It's more geopriv topic than ECRIT. 
It doesn't seem to belong elsewhere.(Henning)

Probably belongs to geopriv (Richard)

servie-boundary
not enough readers. 


- EOF -

Regards
Shida 






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





Minutes ECRIT Working Group, IETF 72.
Scribe Andy Newton
Chairs: Marc L., Hannes T.
Secretary: Roger M.

1. Note Well.

2. Agenda Bashing
- Specifying holes not to be discussed.
- Lots o crap on drafts regarding rechartering.

3. 5th SDO Emergency Services Coordination Workshop
October 21-13, Vienna

4. Document Status.
LoST, DHC Discovery in editor's queue

5. ECRIT Framework - Brian Rosen
(Slide deck not uploaded due to network connectivity issues)
Changes Since last rev.
No open issues with this specifically, but other issues affect this doc.

6. Phone BCP - Brian R
WGLC Complete
One open issue: Calling UA should not send BYE.
Need requirements first before deciding on course of implementation.
Doc is available on this issue.
Requirment is to rapidly reestablish connection to user.
Call Party Hold is the mechanism used in some jurisdictions.

Steve Norris: Requirement is to attempt to reestablish call.
Brian: Everything within reason

Ted Hardy: Clarification about the PSAP being the party not willing to release the call.
Brian: Yes.
Ted: Were not required, does the PSAP calling the party back serve the same NENA function.
Brian: Does not serve same function because of time.  And you can get voicemail. And user can start another call.
Ted: Where this was given up, it was replaced with nothing?
Brian: yes.

Henning: Difference between POTS mechanical switch and more advanced digital systems.
Brian: You are talking about implementaiton, not requirments
Henning: PSAP could still have microphone engaged.
Brian: They aren't asking for spy capabilities.
Henning: What happens on both sides when BYE is sent to PSAP.
Brian: That is implementation, not requirements.

Ted: This is a behavior that may need negotiation.
Brian: Yes.

Stu Goldman: This capablity disappeared with SS7, but that calling number which gave PSAP ability to reestablish.
Marc: That happened with E911, not SS7.
Brian: PSAPs don't consider that to be true.

Brian - going over NENA requirements in slides

Ted: Call not established?
Brian: Different.

Brian - continues with NENA requirements from slides

Henning: Advanced phones have multi line pressence.  PD5 says that none should be able to place a call.
Brian:  Probably true.
Henning: Could cause problems with failures not being able to talke to PSAPs.

Martin: Jabber room wants to know about slides.
Brain: yes, we know.  network problems

Brian - going back to PD7 requirement

Steve: PD5 is concerning.  You have disconnected and this can cause more problems,
Brain: requires list discussion

Ted: PD6?  You told Henning not spy capability.  But all media flows seems to say that.
Brian: That is not what it is suppose to do.
Ted: What about NAT bindins.
Brian: You are into solutions.
Ted: The network as deployed now makes it difficult to not leak info.
Brain: We can have requirements on the phone that might solve this.

Henning: More comfortable about PD8 must not send unintentional signals.
Brian: sure

Andrew Allen: Concern with PD5.  Mass emergency situation, where getting disconnected to PSAP due to overload, if you cannot call anybody else, then this causes problems.
Brian: We can deployment experience with this issue, we don't have to talk about theoritcal situations of overload.

Henning: Something about shooting himself with a large calibre weapon.

Ted: You don't have pracitcal experience because everything so far has been circumspect with VoIP.  circuit switch vs. voip is not the same thing.
Brian: But we can ask about their experiences.

Hannes: PD6 Not transmit audio any more?
Brian: you are talking about solutions, not requirements

Ted: PD2 - thinking about congestive load on the network.  thinking about PSAP DoS attack.  The BYE state may never reach the PSAP, so how does that affect this.
Brian: That is a legitmate concern.  But this is not all or nothing.
Ted: But circuit switch with DoS is different for VoIP.  This could result in that they don't reach anybody, not just the PSAP.

Andrew A.: In VoIP it is very easy to accept the new incoming stream from teh PSAP.
Brain: Solution again, not requirement.
microphone scuffle on the underlying requirements

Hannu: Even if we don't like thise requirements, we will see this stuff from various places and different nations. Valid concern about premature disconnection, we should keep in mind that cellular the user can always say bye but removing the battery.  Then, combining PD5 & PD7 lead to a dangerous situation in cell environments.

Henning: In some circumstances, there may not be any need for solutions.  We are forcing mechanisms which can be placed on the user interfaces.
Brian:  Feature negotiaiton.
Henning: Better to consider doing this all on the user interfaces.
Brian:  But these are two endpoints.
Henning: I'm talking about protocols.

Keith: Which resource are we protecting.  Handset, user, PSAP?

Steve: PSAP could cut in to streams and determine information just from listening and determine that way.

James P.: We don't know the type of endpoint the caller is calling from.  We will never be able to solve this, because of the multiple environments.  This will just delay these 2 documents for 18 months.
Brain: I don't think it is that bad.

Brain- goes on with slides on abandoned call

Ted: Does this happen today?  How do they know about an abandoned call?
Brian: it gets logged.

Brian - goes back to slides on abandoned call requirements

Marc: When is a called abandoned, SIP wise?
Brian: This wording could be improved, because VoIP changes this a bit.

Keith: Resource reservation with AC1, continue it?
Brian: yes.

Ted: Underlying requirement is that the emergency system determine that the use really intended to abandon the call.  Could al be done on the UI?

Hannes: Stops the discussion, and asks would should we do about these requirements?  Would like to finissh our documents today.  How do we do that?
Brian: People want to do this today.
Henning: The notion that these documents will be correct is hard to believe, and we will revise them.
Brian:  Not trying to lose capabilities to do this now, since it is already deployed.
Hannes: But implementation experience later on will help.
Brian: But we know now this will be lost functionality.
Henning: We cannot agree on requirements done in short amount of time.  Unless you want to delay by 6 months, we need to find another way forward.
Hannes: Remove MUST NOT send BYE, and then we can deal with this like unauthenticated emergency calls.
Brian: But you are taking a feature away.
James P: Not taking a feature away, because vendors can add above and beyond.
Brian: But what about interoperability.
Brian: We are in a new world and therefore we should not deploy this feature is not a good reason.
Brian: This is straightforward, and I think we could do this.
Hannes: Would phone-bcp reference this stuff.
Brian: yes.
Hannes: I don't get the impression that this would work.
Ted: There is new protocol negotiation mechanism, which is not soemthing we have done in the past.  What about wording to have PSAP will always send the BYE, and the phones know to rely on the PSAP.
Brian: Undeployable.
Ted: You can deploy what you have either.  You can do what I just said, though.
Ted: Move to a new document, have new doc point to phone bcp.
Hannes: Sending proposal to the list.

7. ECIRT Mapping Architecture - Henning

Zipping through slides.

Coverage regions... catching up with LoST.
Experimental doc issue, beyond my pay grade.

8. LoST Sync. - Henning

Update and status

9. Location Hiding Requirements - Henning

Zippng throught slides

Todo: no impact on automated call testing - requirement needed.
Need security requirement.

10.  Rechartering discussion - Marc

Henning: Discussing using emergency services to make free calls. Some point about a minor distinction he just made.

Marc continues

Steve: re Authority to Citizen, people talking apples to oranges... we need a framework before going on with requirements.  need single direction.

Keith: Agree.

James P.: Agree with Keith. But it should live here until a new WG is spun up.
James P:. Extensions for non-Emergency should not be in the WG.
Henning: The IETF is to get stuff done, not find way not to get stuff done.  So, is it bad work or just should be done somewhere but not here?  Spinning up new WG is difficult.
James P: But the problem is large.
Jon: Different community for non-emegency.
Jon: We should let LoST be chewed on the community, and the see what they say.
Henning: Some of things James doesn't want to do we have demos of.
James P: I was concerned about the work load of the working group.

Hannes: More discussion on recharting....
Ted: Authority 2 Citizen needs to be big focus.
Hannes:  Recharter the WG on this vs BoF?
Ted: Yes, refocus WG.
Brian:  This is important work, needs IETF to do it.  Don't care if it is done in ECRIT or new group.
Henning: arguing for doing things in this wg.
Henning: BoFs are for new sets of people.  If it is the same set of people as ECRIT, what is the purpose.
Hannes:  From the adhoc meeting, it was the same people.
Steve: Need BoF because of architectural implications.
Steve: Useful to get experience of current early warning systems.
Jon: Need BoF because IETF requires process.

Hannes:  Who would be in favor of LoST extensions, and emergency service extensions?
Martin: Two in favor on jabber.
Hannes: Strong in favor, no objections.

Hannes: LoST extensions for non-emergency services, raise hand?
Ted: Two logical ways to split this.  A2C goes to extensions, and non-emergency goes somewhere esle.  Or the other way.
Ted: What about all 3 in this WG, vs these one by one being split out.
Henning: A2C emergency is a misnomer, since it is usually used for school closing.
Steve:  This is why we need a framework doc.
Hannes:  Non-emergency services lost work?
Hannes: 8 in favor, one opposed.
Hannes: In favor A2C emergency even if it contains components for non-emergency, either in this group or separate wg.  First in this wg?
Hannes: one in favor.
Jon: Ask which is most important to work on first.
Brain:  Asking questions about homes for drafts, is not important.  Asking to prioritize is a good question.
James:  #1 priority is emergency extensions, next A2C.
Keith: Separate what GEOPRIV and ECRIT are doing.
Henning: Let's do the low priority when we have time.

Marc: chairs will propose charter changes... A2C sounds big enough to have a BoF... we will see. But wg should go through docs.

Marc: Bring in rph namespace draft?
Marc: 5 for it, one against.

Marc: Bfring in ECRIT rought location?
Marc: 9 in favor, 2 against

Marc: Bring in ecrit unauthenticated?
Ted: this domain is shrinking constantly, do we need to do this?
Henning: do another rev, and then we can look at this again.
Hannes: good idea
Brian: Somebody needs to have it, think about global

Marc: Steve will put a BoF together for A2C.
Steve: A bit early for wg acceptance.

Marc: Bring in ecrit-lost-extensions?
Marc: 12 in favor, 2 against.

Henning: See ecrit-service-classification is more exploratory.  Would rather get feedback on it before having wg looking at this.
Ted: yes.

Hannes: robins-ecrit-subservices?  Bring it in?
Hannes: 0 in favor, 3 against

Hannes: rosen-ecrit-ecall?  Only a handful have read it.
Steve: eCall is a name for EU.  It would good to get the IP network.  Support work, even though I haven't read it.
Brian:  Need to document the problem that already exists.

Hannes:  Bring in sun-ecrit-shelter-service
Martin: isn't it premature to discuss these as they have not been discussed on the list
Henning: in favor of comment

Hannes: ecrit-unsafe-areas?
Hannes: 2 in favor, 3 against

Marc: ecrit-trustworthy-location?  Very small number who have read the docment.
Henning: This is a more GEOPRIV document
Hannes:  But nothing gets done in GEOPRIV.
Henning: This belongs in GEOPRIV

Hannes: lost-serviceboundary?  With only four readers, not enough.

EOM