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.txt 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-access 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.txt http://www.ietf.org/internet-drafts/draft-hellstrom-textpreview-06.txt http://www.ietf.org/internet-drafts/draft-hellstrom-text-turntaking-02.txt 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…