IETF80 – Prague, CZ
ECRIT Meeting Notes summarized by R. Marshall
Note: Geoff Thompson’s and Shida Schubert’s raw
meeting minutes are appended.
Meeting time: 13:00 – 15:00, Tuesday, 29/03/2010
----------------------------------------------------------------
Agenda as posted
10
min * Agenda Bashing, Draft Status Update (Marc Linsner,
Richard
Barnes, Roger Marshall)
10
min * Similar Location (Roger Marshall)
http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt
Intention:
Discuss possibility for wg item
10
min * Additional Data related to an Emergency Call (Brian/Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Intention:
Discuss open issues
30 min. * Public Safety Answering Point (PSAP) Callbacks
(Hannes/Milan?)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/
Intention:
Discuss issues/differences
30
min. * Trustworthy Location Information (Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/
Intention:
Discuss issues/differences
30
min. * Extensions to the Emergency Services Architecture for dealing with
Unauthenticated
and Unauthorized Devices (Dirk)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/
Intention:
Discuss issues and differences
Agenda as Presented:
* Similar Location (Roger Marshall)
http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt
Intention: Discuss possibility for wg item
* Additional Data related to an Emergency Call (Brian/Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Intention: Discuss open issues
* Public Safety Answering Point (PSAP) Callbacks (Hannes) @ 1:53
http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/
Intention: Discuss issues/differences
* Trustworthy Location Information (Aboba)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/
Intention: Discuss issues/differences
* Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices (Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/
Intention: Discuss issues and differences
--/
--/ Summarized notes:
--/
Action items based on the discussion and presentations:
-1- Hannes will take a look at the location-hiding draft and
confirm whether the references listed are normative or
informative.
-2- The rough-loc draft will be revised after which the
author (Richard Barnes) believes it's ready for WGLC.
-3- The data-only-ea draft will have 2 reviewers assigned
to generate a report before a WGLC is initiated. WGLC
is expected sometime soon.
-4- Per the lost-synch draft, the chair will make sure that
the draft gets the required review by the XML Directorates.
-5- For the emergency-RPH draft, James Polk will resend an
e-mail request to Robert Sparks.
-6- The AD asked the WG to review the phone-bcp draft version
that has been recently revised, and to do this ASAP in
order to provide comments as necessary.
-7- For the similar-location draft, the fact that its
location(s) returned is(are) not necessarily ones that are
recommended for use. This needs to be noted clearly in the
draft.
-8- For the Unauthenticated Emergency Call draft, it was noted
that the warning in the draft is written from the PSAP point
of view and so, there should also be a stated warning from
the deploying network's point of view.
General highlights around other drafts presented:
The additional-data draft, presented by Brian, fostered some good discussion around its applicability, the mechanisms for how this data is defined, how it is to be conveyed (i.e., via PIDF-LO, a separate MIME attachment, etc.
The discussion around the PSAP callback draft, presented by Hannes, talked about the challenges of providing either token-based (problematic w/IMS) or shared state gateways (too many), or common key material. Some of the difficulties surrounding roaming and requirements for home networks – in light of GRUUs (or ES-specific GRUUs) were talked about. Agreed to continue discussion on the list.
Also announced the upcoming ESW8 in Budapest, Hungary.
--/
--/Raw notes of Shida Schubert as follows:
--/
ECRIT minutes
=========================================
2011.03.29 13:00-15:00
Document Status - Recent RFCs , IESG Processing
** CLEAR ACTION ITEMS FROM THE MEETING **
1. Hannes will look at the loc-hiding and confirm whether
the fererences listed are normative or informational.
2. rough-loc will be revised and author believes it's ready
for WGLC.
3. data-only-ea: 2 reviwers will be assigned and reported
before WGLC is initiated. WGLC sometime soon.
4. Lost-synch : Chair will make sure drafts gets the
review by the XML Directorates.
5. Emergency-RPH : James will send the e-mail once again
to Robert.
6. AD asked the WG to review the phone-bcp that has been
recently revised ASAP and provide comments if necessary.
7. similar-location:
The fact that it location(s) returned is(are) not
recommendation needs to be noted clearly in the draft.
8. Unauthenticated Emergency Call
The warning in the draft is written from the PSAP point
of view and there should be warning from the deploying
network's point of view.
////////////////
10 min * Agenda Bashing, Draft Status Update (Marc Linsner,
Richard Barnes, Roger Marshall)
1. Location-Hiding
> Why is there normative reference to location
conveyance in the loc-hiding? (Hannes)
> Hannes will look at the drafts and confirm whether
the fererences listed are normative or informational.
2. Phonebcp
> changed text on the codec selection.
> Believe that all the comments are resolved. (Brian)
3. Rough-location
> Believe it's ready for WGLC (Richard)
4. Data-only-ea draft will go through WGLC very soon. (Chair)
> Will find two reviewers and be sent to the ML.
5. Local-emergency-rph-namespace draft
> Waiting AD's action since IETF78.
> It wasn't in the queue, AD(Robert) will pick it up.
6. Lost-sync
> Haven't got review from the XML Directorate.
> Chair will make sure this gets done.
///////////////
10 min * Similar Location (Roger Marshall)
http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt
Intention: Discuss possibility for wg item
What do we do when in big city and many locations are returned.
- Just return all four (Brian)
Think it looks good, may be good to limit the number
of returns. (Martin)
If there are too many variations, there are too many
possibilities. (Martin)
How do you figure out the quality of the returned value?. (?)
LoST is used in a non-human driven scenario, this is
not useful for non-human interventing scenario.(Randall)
What's the behavior difference when the similar locations
are received? (Randall)
Mainly geared towards human (Marshall)
This only comes back when you request validation. The action
needs to be made so the request can be sent which will resolve
the issue that was found upon validation. (Marshall)
May be we should add a way to say whether you want similar
location returned or not. (Marshall)
Just ignore it if it doesn't make sense in the local context. (Marshall)
If only one is returned then there should be an indication
to recommend or not recommend the use of the recommendation. (Cullen)
This suggestion is only a guess, so you don't want the machine
to wrongly use, recommendation is no good. (Brian)
The fact that it is merely a recommendation needs to be
noted strongly on the draft so the implementors won't simply
use the recommendation without a second thought. (Cullen)
Agreed (Many)
////////////////
10 min * Additional Data related to an Emergency Call (Brian/Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Intention: Discuss open issues
Data itself
> Will provide container to carry data (telematic data etc.)
Actions
> Need more reviews
There are 2 categories of data, 1. that service
provider knows, and 2. that device only knows.
Vehicle telematics/Sensor data should be transmitted
directly. (?)
For telematics etc., the scheme can be composed so
it can just send it in the message. You want to be
able to do both.(Randall)
Use Info message and get a data in the response (Dale).
It relates to routing, the information needs to be
sent prior to the call. Needs to be able to do both. (Brian)
How does data-only and this works together?(Hannes)
The diff is data-ony may be all that is available,
and additional data + data-only may be available
when there is a call.(Brian)
Some debates about the identiry.
Let's take it offline. (Brian)
The contreversial topic in NENA is what data to
require (Brian)
Seems like you can solve it with registry if
needs to be extensible. (Richard)
There was an idea of including all of this in PIDF. (Brian)
IETF doesn't have the expertise in the emergency, data
structure should be designed somewhere like NENA (Richard)
NENA is NA centric but wants general mechanism, that's
why we are doing it in the IETF.(Brian)
Needs to make sure information is not modified along the
signlaring path. (?)
The rule is intermediary can add but can't change/delete what's
already there. (Brian)
What do you mean by saying you want to use it for routing?(Keith)
It's internal to PSAP.(Brian)
In particular in NENA, it's the server inside the ESInet that
decides how to route the call and use this information.(Brian)
Inserting it in the call-info is probably not the right place
to put it. (keith)
What will change in the draft?(Hannes)
Will consider text about use of MIME etc..(Brian)
////////////////
30 min. * Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/
Intention: Discuss issues/differences
Token based solution doesn't work and this was discussed in the ML.(Christer)
There were no conclusion. (Hannes)
In case of roaming (in IMS) the token needs to be delivered all the way to
the home NW. (Christer)
The problem with the PSTN is that gateway doesn't see it when the
call goes out as token aren't shared and not always the same gateway
are involved in the call. (Keith)
Can be solved if proxies can share the token among proxies. (Martin)
The only way to view the token is to always use the same signaling path. (Cullen)
Only two solutions, use of PKI and the use of correlation information and
whatever is aware needs to implement the correleation. (Cullen)
Don't need to store the token if there are common keying material. (Martin)
There is no way to grasp how many gateways there will be, (Ted)
Shared state between the gateway is not a solution. (Ted)
Because this information will not be carried by the
PSTN there won't be information available for the GW. (Christer)
There are two cases where call-back is important. 1. When service
gets interrupted, 2. When the call back is much after the
initial emergency call. (Christer)
In former case you use contact. (Brian)
If it's an emergency call usually uses GRUU or some
form of contact in which case the callback should go
back to the roaming user. (Brian)
Even if you have GRUU, it would still get routed
back to the home-NW. (Keith)
We can devise Emergency GRUU.(Andrew)
Cullen explained the idea of Emergency GRUU
which still doesn't solve the PSTN interworking cases,
but it will work for the roaming/local case.
Cullen also mentioned the potential of abuse with
this emergency GRUU as one may be able to hand out
emregency GRUU to friends so friends can all to
bypass the billing (Cullen)
Call wouldn't go through if there is no credit. (I am
assuming that it will be billed). (Hannes)
Continue the discussion on the list. (Chair)
////////////////
30 min. * Trustworthy Location Information (Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/
Intention: Discuss issues/differences
With regards to issue 4:
Conclusion, include as much information as possible
about the location. If there is no information about the
location, still pass it on. (Bernard)
Problem is with the location API that uses the location.
Which location to use? (Bernard)
Different source of location information, with different
reliability and it's up to the user of location API that should
choose the location but usually don't. (Martin)
Don't want to depend on the intermediary for reliability
decision. (Brian)
Tell me what you know, don't change or take it out,
add if needed and if needs to make decsion for routing etc.,
make a decision on what it thinks is more reliable.(Brian)
Give enough information so decision can be made when
multiple location information. (Martin/Bernard)
////////////////
30 min. * Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices (Dirk)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/
Intention: Discuss issues and differences
{Missed the discussion}
ZBP is at the VoIP provider right? (Martin)
Yes, will fix the diagram. (Hannes)
WGLC after the updated version.
Needs operator review. (Bernard)
What kind of people? (Richard)
Kind of people that provides unauthenticated access.(ISP)
There is a warning in the front of the document. (Hannes)
The warning is from the PSAP point of view and there
should be warning from the deploying network's point of
view.
--/
--/Raw notes of Geoff Thompson as follows:
--/
10 min * Agenda Bashing, Draft Status Update (Marc Linsner,
Richard Barnes, Roger Marshall)
10 min * Similar Location (Roger Marshall)
http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt
Intention: Discuss possibility for wg item
10 min * Additional Data related to an Emergency Call (Brian/Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Intention: Discuss open issues
30 min. * Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/
Intention: Discuss issues/differences
30 min. * Trustworthy Location Information (Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/
Intention: Discuss issues/differences
30 min. * Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices (Dirk)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/
Intention: Discuss issues and differences
=====================================================
Called to order at 1:03 PM by Marc Linser
Roger And Richard at front table
Blue sheets passed
* Agenda Bashing, Draft Status Update (Marc Linsner, Richard Barnes,
Roger Marshall)
Hannes instead of Dirk presenting last item (Dirk has changed jobs)
Re: Doc status
Re: Location hiding, Hannes isn't sure of missing refs item. Hannes took AI
Re: PhoneBCP, Brian has spun a new version, didn't catch what the
differences were (codec?). Brian thinks it can thru to the ISG. Check
the diff
Re: Richard Waiting for WG Last Call
Active WG drafts
Not going to talk about data-only (01). authors think it is ready for
WG Last Call
2 w/ ecrit in title have expired
Polk has changed name of one of them and it is now an individual
lost-sync Review didn't get done.
Chairs take AI to nag
RE: ESW#8 Announce it.
* Similar Location (Roger Marshall)
http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt
Intention: Discuss possibility for wg item
Not (yet) a WG item
See his slides (ecrit-0)
New draft submission (00)
Addresses the lack of a feature in LoST to return "similar" location
"Address not found, did you mean?"
Some questions/discussion, James, Brian, Martin... regarding # of
possible "useful" responses and how you deal with that.
To be used when you put in a location and ask for validation.
Roger will take the suggestions and spin the draft.
* Additional Data related to an Emergency Call (Brian/Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Intention: Discuss open issues
Brian: See slides
There is additional data in the system that can be useful to PSAPS
Standardize a format to pass it to PSAPs
Data itself
list of data possibilities
Little list discussion, trying to stimulate
No 3rd party data insertion
Who provides data is included.
Need more review and input.
Already done as a standard object in NENA. Want Intl.
Randall Galens: 2 kinds of data a) Server knows, b) only device knows
Thinks b) needs a different mechanism.
MIME ext in a separate message?
Brian: Various flavors of this (On-Star example)
Hannes: ?? Brian: Lets take off-line
Martin: Has NENA converged on their reqts? Brian: Yes.
Richard: Does this doc have any provision for agility in terms of content.
Brian: General XML issues
Richard: Perhaps a registry. Brian: Please send text.
Brian: Want to put same data element in the PIDF
Keith Drage: Wants end client control of whether data goes in.
Brian: Sure.
Requests for text for who should put data in and security considerations
Be clear about difference between content id and content indirection.
* Public Safety Answering Point (PSAP) Callbacks (Hannes) @ 1:53
http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/
Intention: Discuss issues/differences
Hannes (See slides)
At #79 suggested sol'ns. Alts came up at mtg.
Token approach. seemed to be simpler, lightweight
Problem was: Token based approach doesn't fulfill IMS...
There may be a way to fix this but this is still an open issue.
Discussion on list faded.
Discussion: You have to store the token at a place n the system that
knows what it means.
Litany of problems when going in and out of PSTN.
"Shared state between gateways is not a viable solution"
Hannes: It will not be easily solved. what do we do?
Brian: Two opposed things (1) We don't have anything in the system
and no one misses it
Soon case and later case. Soon uses contact, Later uses ??
Keith: Should do more exploration this week.
Marc: Put it out on the list for more discussion
* Trustworthy Location Information (Aboba)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/
Intention: Discuss issues/differences
What was fixed in (01)
References still need to be fixed
Fixed threat model discussion.
#4 Untrusted Location and Provider intent
Not all LCP are appropriate for ES.
(IETF San Fran, Stockholm example cited)
Notes Rosen proposal as helpful.
Bernard is going to summarize into text and spin it.
Would like people to read draft. we need all of the input we can get.
Brian: I don't think I want intermediaries making reliability decisions.
Fraught w/ peril
Just label
There was discussion on putting more than one. That was not fun.
(finish at 2:34)
* Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices (Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/
Intention: Discuss issues and differences
Version (01) See slides (nice flowchart from IETF #77)
(There is an error in the diagram. Top yes/no reversed)
Richard: It shouldn't say BCP. Prob should say use ECRIT Direct.
Martin: Thinks this will be necessary.
(To keep the set of service provided bounded)
Hannes wants to go to WGLC after he updates it.
Bernard thinks it is important to have some operator review (access
providers, ISPs, VSPs)
Geoff: Warning should be expanded to include perils to to network
fraud and traffic as well as unwanted calls to PSAPs.
AD says look at Phone BCP today !
Adjourn at 3:50 PM
/end