[Ecrit] IETF75 ECRIT Meeting Notes, July 29, 2009

["Roger Marshall" <[e-mail]>]

Here are the ECRIT meeting notes that I received and have posted in the
Meeting Materials.  Thanks go to Spencer!

Please reply to the list with any corrections, etc.

Roger Marshall 

***

ECRIT Meeting Notes - IETF75, Stockholm
date/time: Wed July 29/ 0900-1130
taken by: Spencer Dawkins


1.1.1            Status Update
Hannes is attending virtually this time.

Keith - still have outstanding comments on -framework and -phonebcp. 

This was discussed on June 3rd teleconference, Keith was going to review
these documents, but  the comments haven't been addressed. No solution
has been offered by anyone. Chairs discussed  with ADs and can sort this
out during IESG evaluation. Cullen said concerns about advancing  the
document don't have to be solved.

Ted - if there's consensus in the working group that the problem needs
to be solved, and it  isn't solved, that's not good. If the working
group doesn't think the problem needs to be  solved, that's a different
state, but the chairs haven't asked the working group if the  problem
needs to be solved.

Keith - absence of consensus about the proposed text doesn't mean that
we addressed the  concern.

James Polk - proposed text was shot down.

Ted - do you think we've had a consensus call on whether there's a
problem here?

Marc - could have been asked better, but we thought that it was asked.
Will add a topic at the  end of the session about this.

Brian Rosen - actually seeing planned deployments for next year. Need to
get these documents  finished in time to be used.

Marc - EENA is going to line up with NENA, since NENA is ahead. Marc and
Hannes are both on  the EENA calls as well.

1.1.2            Specifying Holes in LoST Service Boundaries 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01
.txt

    Cullen raised some concerns about the additional feature that this
document requires.  

   He suggested that an alternative would not require support of
interior polygons, or holes.

   Confirmation whether WG is OK with the current direction or whether
changes are necessary.

Alex - thinks the alternative proposal to create borders is plain wrong.

Cullen - fine with this conclusion - asking if it's been discussed. We
have running code, but  have we discussed it? Is there a technical
reason why we're making the decision?

GIS systems work with holes - the alternative (to use borders) requires
GIS systems to change.

Anyone against the current text? No one speaking against it here.

1.1.3            Geocoding and Reverse-geocoding Using
Location-to-Service Translation  
http://www.ietf.org/internet-drafts/draft-polk-ecrit-lost-geocoding-00.t
xt

   Introduction and discussion around this idea.

Geocoding is turning coordinates into civic location. 

This is being done in ECRIT because all LOST work will happen in ECRIT -
Dublin decision.

Why not do this in HELD? Think LOST will be in almost all endpoints that
are intelligent  enough to use this function, not true of HELD.

Will have an update in August, fully populated. Know I need to add URNs.

Martin - not sure LOST is the right way to query this information.

LOST, HELD, or HTTP POST are the alternatives. Think LOST makes the most
sense.

Richard Barnes - LOST is for discovery, not for geocoding itself.

Brian - NENA thinking web service was more appropriate (even on the same
box) - needs a  different interface. Should be RESTish.

Alex - Should separate discovery from the service itself.

Ted - think reusing LOST is reasonable, but agree that LOST model is to
return a pointer to  somewhere else (even if the pointer points to the
same box).

How do we find the geocoding servers? 

Martin Thompson - would not be opposed to doing a LOST step as part of
the solution.

Richard - LOST is fine for discovery, not for geocoding itself. 

Merge this with geopriv geocoding document (which also does half the
problem)? Richard doesn't  think this is necessary. 

Andy - there are better questions to ask - how many times do clients
want to ask? What latency  is required? How many rounds of transactions
do you want to go through, to get the answer?  What's best for the
client?

Hannes thinks proposal makes sense, doesn't care about the number of
documents. Looking at  number of round trips depends on the type of
service - emergency VS non-emergency, for  example.

Other transformations? Standardized forms of address as an example.

Form of URN? If we're doing discovery, probably only need one URN form.

1.1.4            Using Imprecise Location for Emergency Context
Resolution 
http://tools.ietf.org/id/draft-barnes-ecrit-rough-loc

   What is necessary to finish this work? 

Document has been through a couple of revisions around civic addresses,
but think it's  through?

Martin - think there's still a hole around civic addresses and service
boundaries. Maybe it's  not your problem, but there's a problem that
needs to be addressed. 

Brian - don't assume that there's only one way to interpret the data.
Want to be cautious  about how prescriptive we are.

Martin - document discusses general requirements of location independent
of type of location.

1.1.5            Location-to-Service Translation Protocol (LoST)
Extension:  ServiceListBoundary 
http://tools.ietf.org/id/draft-wolf-ecrit-lost-servicelistboundary

   Status of the work and remaining open issues.

listServicesByLocation provides a service list, but the area where that
service list is valid  isn't known. Proposing ServiceListBoundary to
provide this information.

Ted - we've had this discussion three times in the past and reached the
opposite conclusion -  need comprehensive knowledge of what services are
offered everywhere, and that's  computationally painful. You don't
re-query unless you need a new service or some period of  time has
passed. Do you think the service list will churn?

Need to get Henning and Karl-Heinz in a room - proxies at both ends in
THIS room.

Ted - if you're the service provider for Austria, and you're in Vienna
which is flat, you  STILL find out about mountain rescue in the country,
rather than trying to figure out whether  you need to be told about
mountain rescue.

Don't think the issues we're discussing here have been resolved, but
don't think they need to  be resolved before we accept the document as a
working group item.

1.1.6            Extensions to the Emergency Services Architecture for
dealing with  Unauthenticated and Unauthorized Devices 
http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces
s

   What are the open issues with the draft? Are there decisions we can
make with the group in  the room? 

Three classifications of "unauthenticated/unauthorized" - no access
provider, no VoIP  provider, zero-balance with VoIP provider.

Brian Rosen - not "VoIP provider", but "service provider".

Hannes - Brian's suggestion is fine.

 "No access provider" is the hardest classification to deal with. WiMAX
draft was aligned for  this, but has now changed.

1.1.7            Premature Disconnect Indication
http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts

   Discussion got stuck. Attempt to refresh it. 

Disconnect by user isn't always wrong, and user needs to be in control
(don't brick the  phone). 

We have years of experience with this feature. 

Abandoned call (user disconnects before call is answered by a human
call-taker) is a separate  issue.

Randy - Debate is about whether this is UI or signaling? Actually three
cases (signaling at  call setup, signaling at call setup and at
disconnect time).

Draft has gone through several revisions, and has now expired. Draft
wasn't acceptable to "do  it on the UI" crowd, who demanded more
rewrites and promised alternative text, which hasn't  happened. "Signal
PSAP controlled disconnect" crowd needs solutions.

Ted - do we agree that this is a problem that has to be solved? Don't
think we've decided  that.

Randy - think we got wedged because we were only considering two of the
three cases (and still  allowed serious failure cases). 

Ted - we're going back to a circuit-switched model that we're not using
today, we're going  back to a wireline model that we're not even using
in cellular.

Brian - typically the IETF doesn't do user interactions (although there
are discussions in  some documents, so starting there should be OK in
the IETF).

Not opposed to compromise, but don't want to keep trying text changes
without some direction,  and we need to decide something quickly or the
people who need the solution will forum-shop.

James Polk - problem is that the requirement starts at disconnect time.

Brian - no, that's when the user experience starts, but it doesn't have
to be entirely  reactive.

Ted - you keep coming back and hoping for "yes", but if this had been
put forward as a BOF,  you would be done (asked twice and been told "no"
twice). This isn't going to satisfy Canadian  PSAP requirements. This is
coming from a time that has passed, and it's not going to be in the
code path for half the devices that are out there.

Brian - does IETF think that something needs to be done? That was my
hope for today.

Ted - network can't meet these requirements. If requirements change and
this is advisory, the  answer could change, but not with the current
requirements.

Brian - we can come up with an acceptable compromise.

Ted - what I need is that user has to agree to the function, and the
user can turn the  function off (actually, the user's DEVICE has to
agree to the function, but). 

Cullen - is the working group willing to work on this?

Keith - is this about early disconnect AND abandoned call?

Marc - trying to figure out if we care at all, then let design team
fight this out. Might be  able to get some movement in SOME direction.

Ted - please ask the rest of the group!

Randy - only for premature disconnect?

Brian - separate the two, only premature disconnect. Are we working on
this at all? Think  about abandoned call if we make any progress at all.

Alex - concerned that we are sneaking legal requirements into the device
using protocol  mechanisms. 

Bernard - we're having problem statement discussions now. Need to do
that first before we work  on protocol mechanisms.

Keith - want to do problem statement in an author draft, then adopt as
WG item.

Brian read text from the current draft that talks about the problem -
could reword, but there  is text today.

Ted - UI-only feature doesn't give you reconnect. Once they send a BYE,
network state is torn  down and we're not talking about reconnect at
all.

Brian - could reconnect, or could prevent disconnect - user experience
is the same.

Ted - no, it's not.

Brian - if you close a phone, the only reasonable thing to do is an
alert. 

Ted - when you open a phone, you can tell the difference.

Randy - we keep reaching an impasse because requirements sincerely TRY
to avoid solutions, but  current text assumes a solution. If a small
design team can't come up with problem statement  text, can't do a
solution, either.

Keith - not prepared to work on this today. Hoped author draft
discussion would move this  forward.

1.1.8            Trustworthy Location Information 
http://tools.ietf.org/id/draft-tschofenig-ecrit-trustworthy-location-02.
txt

   What is in the updated version? Does the group want the work? 

   Discussion about the direction of the work. Where is the right place?
GEOPRIV/ECRIT?

"Prank" emergency calls becoming substantial and serious problem
(including SWAT team  dispatches).

Most pranks spoof both identity and location. These are independent
issues. Location could be  trusted (Germany) or unknown by PSAP
(Ausrria).

Marc - in US, carriers still last six digits of ESN into phone number so
they have a chance of  tracing the caller.

Martin - cellular handles unauthenticated calls to some extent. On the
border of proprietary,  but they handle the calls (generate IMEI, etc).

Additional VoIP issues - authentication at multiple layers, anonymous
access devices, and lack  of link between link identity and SIP
identity.

Draft focuses on malicious end host.

NENA i2 has requirements for "trustworthy location". 

LLDP-MED endpoint can make an "end run" around return routability. 

If you know what you're doing, you can generate GPS readings that spoof
your location.

Potential solutions put forward thus far all have holes.

Are VPC and ERDB operators prepared to operate as CAs?

Once you've built the bunker, what are the conditions for signing certs?


How do PSAPs manage these ACLs and LbyR credentials?

Marc - PSAP is still going to accept a call from unauthenticated caller
and will always  believe the caller about the caller's location.

Bernard - lots of expensive infrastructure here, it's complex through
the roof. 

Brian - we can do this, we're going to this, the next generation will
have this and be "secure  enough". 

Bernard - if you have a rocket and a pig, I believe you when you say
you're launching the pig  to the moon. My question is "why?"

Brian - installing this infrastructure, could extend to issue certs to a
LIS.

Martin - number of comments, but this presentation is a critique of i2 -
what is the purpose  of the presentation?

Bernard - to understand the meaning of "trustworthy location".  Can cut
and paste LbyRs into  anything and they still work.

What's an alternative definition of "trustworthy location" -
auditability after the fact, or  determining "prank calls" with an
acceptable rate of false positives?

1.1.9            Continued PHONEBCP discussion
Is PHONEBCP ready for publication? No one had anything to say.

Keith - comments also applied to FRAMEWORK, they both cover the world.

The rest of the people thought this was only PHONEBCP.

Taking a hum - ready for publication? 70-30 for/against in the room,
going to the list...

Cullen - nothing will happen to the document until chairs call consensus
on the list question.

1.1.10       Real-time text activities relevant for ECRIT 
http://www.ietf.org/internet-drafts/draft-hellstrom-text-conference-01.t
xt

http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt

http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.t
xt

   Status update regarding real-time text activities.

Has anybody read the drafts? Not yet... 

Robert - this is a DISPATCH conversation - it's what DISPATCH is for.

Marc asking that people read the drafts and think about emergency
services...

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.