Re: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013

[Christer Holmberg <[e-mail]>]

Hi,

A minor correction to bullet 2): Hannes will fix the nits to draft-ietf-ecrit-psap-callback.

Regards,

Christer

________________________________________
From: [e-mail] [[e-mail]] on behalf of Roger Marshall [[e-mail]]
Sent: Saturday, 23 March 2013 12:45 AM
To: [e-mail]
Subject: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013

Minutes w/summary, ECRIT WG Meeting, IETF86 Orlando, 03/13/2013, 13:00-15:00

If you have any additions or modifications to these minutes, please let
Roger & Marc know via email.  These minutes will be updated to the IETF86
meeting materials page.

Thank you goes to Jean Mahoney for note-taking, and, thanks also to Robert
Sparks for serving as RAI AD these past years.

Chairs:
Roger Marshall, [e-mail]<mailto:[e-mail]>
Marc Linsner, [e-mail]<mailto:[e-mail]>

Summary

1. Revisions shown to former milestone dates will be posted to the list, then
submitted, based on comments received in the working group meeting. It was
agreed that the current date for rough-location should be pushed out a year.

2. Christer agreed to fix the nits to draft-ietf-ecrit-psap-callback-08, then
chairs will submit to IESG for processing.

3. Richard provided status on the rough-location, stating that it's progress
is dependent on a liaison response for direction.

4. Brian agreed to additional-data next action discussing new block or URI on
the wg email list.

5. For data-only draft, when a CAP message is by reference or value, Brian
agreed to rework the draft to make it like the additional-data draft, using
a Call-Info header with a URL that can be a cid.

6. Ecall draft, it was proposed that document be made separate drafts, so
that service URNs just need expert review.  Brian would be agreeable subject
to wg consensus (tested on the list).

7. The discussion around trustworthy-location was that some parts needed to
be lifted out and put into other drafts, then ask for an intense review once
Bernard submits version -05.

8. Draft rph-reg-policy suggests changes that avoid adding a new top level
requires standard track, but would make it by expert review. Adam Roach
stated that the RPH Registry Management Policy draft be raised in sipcore.

9. For draft-holmberg-ecrit-country-emg-urn, the proposal to handle
this with expert review was proffered, and the wg chairs asked for a show of
interest in this work? <12 hands up>, with <no opposition>, which showed a
decent amount of interest.



Actual drafts discussed:

Additional Data related to an Emergency Call
draft-ietf-ecrit-additional-data

Data-Only Emergency Alerts using the SIP
draft-ietf-ecrit-data-only-ea

Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall

Trustworthy Location Information
draft-ietf-ecrit-trustworthy-location

RPH Registry Management Policy to IETF Review
draft-rosen-rph-reg-policy-00.txt/

URN For Country Specific Emergency Services
draft-holmberg-ecrit-country-emg-urn/



-----------------------------------------------------------------------
Agenda Bashing, Draft Status Update (10 min)
Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-5.pptx
Presenters: Marc Linsner, Roger Marshall

Note taker: Jean Mahoney
Jabber scribe: Hannes Tschofenig
Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-03-13.html

The ECRIT working group presented the outgoing RAI area director Robert Sparks a bottle of tequila as a token of their appreciation.

On behalf of the GEOPRIV working group, which didn't meet, Richard Barnes presented Robert with geographically-specific chocolates and a chocolate bar with privacy rules and which, according to its label, may cause an emergency if consumed.

ACTION: Robert Sparks to report on how he gets the tequila home.

Note well presented.

The agenda has been modified - the presentation "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (15 min)" was canceled.

Document status presented:

draft-ietf-ecrit-psap-callback-08* would be good to correct nits first, then send to IESG

Milestones presented:

Have been updated but not submitted.

Hannes Tschofenig - what's the status of the Imprecise Location draft?

Richard Barnes - Liaison to see if pending NC direction.

Hannes - the March milestones need to be updated. I also requested a WGLC on [?], maybe in July.

ACTION: provide feedback on the mailing list before the update is submitted.

-----------------------------------------------------------------------
Additional Data related to an Emergency Call  (10 min)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-1.pptx
Presenter: Brian Rosen
Intention: Discuss if ready for WGLC

Sllide 3 - Open Items:

Brian - We need some text on when it is appropriate to use either a new block or URI and type with registry in device block when handling device-specific data.

The answer has to do with the following issues:
- things that are widely applicable and large structure - need separate  block with more IETF review
- URI - first come first served

What kind of review should it get?

It's allowable to send a block by value but not a device block with url, you can't send that by value. What about A huge thing sent by value? - I worry about that. It should be covered in the considerations section.

Any reactions?

Randall Gellens - There can be side effects from sending large data by value, but for device, you can only send by value.

Hannes - You don't want to be restrictive on the process of adding new blocks. You can shoot yourself in the foot.

Brian - It's expert review - not RFC.

Hannes - that's not that restrictive.

Martin Thomson - it's not a restrictive space.

Brian - Right. We think we're done. Get it out before the intermediary [?] (interim? but Marc indicated later in the meeting that there wasn't an interim).

Marc - Anyone willing to review it? <no response> We'll take it to the list.

ACTION: Discuss when it is appropriate to use either a new block or URI and type with registry in device block when handling device-specific data on the mailing list.

-----------------------------------------------------------------------
Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (10 min)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/
Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-2.pptx
Presenter: Brian Rosen
Intention: Discuss latest changes

Slides presented.

James Polk - On slide 3, do you mean any SIP request? Including CANCEL?

Brian - it's not a request, it's a transaction. CANCEL is a bad example. Certainly UPDATE.

Bernard Aboba - you could include a URL. Fetch an updated version if you wanted to.

Brian - sure. Now I need to define a mime type or a new header. Now it's a just a [...]

Martin - I was going to suggest using Call-Info. Where to get the sub and the authorization?  Send a message saying I'm here [...]. I think it's a fine idea.

Brian - I should put the mechanism with the original INVITE. It will be easy. I can define […] In the Call-Info, for further info, subscribe here - URL and call info.

Randall - what about the mechanism in additional-data […]

Brian - I'm going to reuse that.

Roger - Summarize what Randall said.

Brian - Send a CAP message by reference or value. Like the additional-data draft - A Call-Info header with a URL that can be a CID. I will rework the draft to that.

Randall - you just need a definition of the MIME type and […]

Brian - make the CAP message a block of additional data. Great idea.

-----------------------------------------------------------------------
Internet Protocol-based In-Vehicle Emergency Call (20 min)
http://datatracker.ietf.org/doc/draft-rosen-ecrit-ecall/
Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-6.ppt
Presenter: Hannes Tschofenig
Intention: Discuss whether candidate for WG adoption

Slides presented.

Marc, as indvidual - How does this draft contrast with the data-only draft?

Hannes - It complements data-only. There are some additional structures. The eCall spec talks about 2 data elements - a minimal set (covered in the example on slide 4). The other is more extensive and lines up with additional-data and data-only. The data-only plays a role when there's no media.

Brian - additional-data provides a mechanism for carrying sensor-related data. We have extensions for carrying data. data-only provides CAP - alert related - which says, "you need to pay attention because". I don't know how this adds. We have a place to put the data and a place to put the alert. What isn't covered?

Hannes - This defines 2 service URNs for eCall. It provides description of how it relates to eCall. How to use this work for their purpose.

Randall - With every situation for eCall, the voice channel is the paramount importance.

Hannes - The draft doesn't reference the data-only draft because I had the same impression. eCall doesn't spec how to [?].

Henning - In the United States, there are researchers that collect data that include deceleration, airbags inflated, tension on seatbelt. Doesn't seem to fit into a CAP model.

Hannes - it fits into Additional Data.

Henning Schulzrinne  - we should talk with those folks. How to make it fit in. They are using VOIP for emergency calls. 2nd - there's a blurring between true emergency calls - sending an ambulance for instance - and when you want to do more prevention. Reporting that the ABS/stability systems go on - can indicate black ice. Or fog lights go on - fog - the information could go to highway patrol. Possibly a different service URN. It's safety related. They can get warnings out. Need to send salt out. Act as data fusion center. Can be automated. This is stretching the 911 model. Can think about this.

Hannes - We can describe that in doc as use cases. And double check with additional-data to see if we have schemas in place. But it's a different level of detail.

Henning Schulzrinne - try to get people to think ahead.

Randall, to Henning - have those people get in touch with authors, review, sign up on mail list. You raise the safety related issues. There's overlap for reuse. The use cases should be in a new doc. I want this doc to be emergency calling.

ACTION: Henning to contact the US researchers he mentioned to ask them to review the document and to sign up for the ECRIT mailing list.

Brian - I'm an author but I haven't been involved in the last 2 versions. First point - the doc needs to be clearer on its intended purposes. It doesn't explain why you are defining new URNs. It's because they are routed differently. Second point - why is it standards track? Because it’s defining service URNs. Otherwise it's an informational document.

Keith Drage - eCall is an emergency call. We have different architectures for delivering calls. Don't want non-emergency sent to the PSAP.

Randall - that's why it should be in its own document. RFC - say URNs need expert review, not standards track.

Hannes - Is there interest in the working group?

Brian - I would like to speak in favor as an author. It's a reference to use IETF mechanisms to do what they want to do. It's valuable.

Marc - Then I heard Henning say we need to add others.

Henning - I don't want to hold up anything for something speculative. Ensure that the doc is self-contained for all pieces for telematics for emergency calling. I don't know if it's been considered by eCall. Separately - we need to talk about the other component - a separate schema and URI.

Hannes - I reference Additional Data. It would be good [?]. There's a limit on the data they send for eCall.

Marc - what do we think?

Randall - we might want a separate doc so that service URNs just need expert review.

Brian - do IETF consensus for it. I’d be happy to do that doc.

Marc, as chair - how many people read the draft and are interested?

<some folks raised hands>

Marc - We will take it to the list.

ACTION: Discuss adopting the draft as a working group item on the mailing list.

Randall - [?]

Brian - I request a call for a hum to downgrade the registry.

Keith - we're going to talk about this later.

Brian - I can wait.


-----------------------------------------------------------------------
Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (15 min)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/
Presenter: Hannes Tschofenig
Intention: Discuss latest changes

CANCELED.


-----------------------------------------------------------------------
Trustworthy Location Information (15 min)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/
Presenter: Bernard Aboba
Intention: Discuss latest changes

Slide 3 - Issue 4: Untrusted Location and Provider Intent.

Martin Thomson - I worry when people look at how location info was received to determine if it’s trustworthy. The real info used to determine if it’s good is: when it was the info generated? What's the uncertainty? What’s the location? There are other things used to determine trust. The latter half of the paragraph is important.

Bernard - If it came from a LIS, ok. But if it came from some weird place, what do I say in the pdif-lo? I want to tell the PSAP enough info to make a judgment.

Brian - It's on the right track. The basic info is: how you measured it, how accurate it is, what the location is.

Bernard - if not authoritative and measured a year ago.

Brian - the timestamp of the measurement and the timestamp of when it was sent [?]

Henning - It's difficult to know if the accuracy was determined in a global way. For instance, GPS has this sort of accuracy. Or for that specific measurement. Wifi gives you this. In certain cases, it's more or less accurate. But you tell me about the particular measurement. Primary and secondary - aggregators - have munged up data magically, adding trust info. The smartphone vendors do this, and don't say how they do it. Just knowing source - like the company and if they do a good job of preventing spoofing - it gives you a sense.

Bernard - We're not capturing that. we'll expand section 4.

Martin - every location provided provides uncertainty on it. There are some cells where locations are within 10 meters. With GPS, you can determine uncertainty and can report that. You need to make it explicit that you report the measurement's uncertainty, not the technology's. The location info is not technology specific - there's a lot of combination of data.

Bernard - good point. "wifi location" term is meaningless.

Henning - it's not a technology - saying which vendor which provided it is shorthand for what data is blended. FCC no longer makes some of these distinctions.


Slide 4 - Issue 9: Definition of Trustworthy

Russ Housley - I worry that the term "Secure" is more vague than "trustworthy". You are trying to say with authentication, integrity or both. But not confidentiality.

Bernard - We're not talking about privacy here.

Russ - Define the security services - authentication, integrity or both.

Henning - our model is different than a traditional security system. Our model is more statistical, a risk assessment model. As a PSAP, I care about the following: out of a million locations, how many are wrong? How many are maliciously modified? How many of these issues can I detect reasonably? If you can detect it. Except for large scale man-in-the-middle attacks, this is generally determined one by one. This is risk assessment. If your adversary can compromise GPS satellites - then your data can't be trustworthy.

Bernard - How about the end - "securely obtained from a trusted source"?

Richard - It needs to say what we are and aren't doing. Would like to guarantee the position of the call.

Henning - There are levels of trust - origin assertion that you verified. If you were to ask a PSAP director to define trustworthy, he would care about correctness, not that there's an adversary. A wifi access point has been moved to a new Starbuck's branch, for instance. That's far removed from the trustworthy computing model. They are concerned more with incompetence than malice.

Richard - Say in doc that we're reducing the problem from the security problem to the positioning problem.

Henning - it's a framing informational doc. Need to start at a high goal - what is trustworthy. I need to have confidence in data in provided, that someone is responsible for improving the data (the locations of people calling from a certain mall always show that they're over there), and that mucking with data is difficult. PSAPs conflate all of those. The solutions are different.

Martin - it's hard work. The biggest part is managing where the location info comes from and patching it when it changes. It's complicated and expensive.

Slide 6 - Issue 8 Solutions

Martin - I've commented on section 3.2 on the list. What a list provider would do, but not what we want to do in this situation. You're talking about authorization from the LIS end of things.

Bernard - We have an operational concern - how does the PSAP do this? But circumstance [?] location hiding.

Martin - Move it to a doc on location hiding, it doesn't belong here.

Bernard - is it worth talking about access control at all?

Martin - no, it can be cut.

Brian - I'm not sure I agree on this. I care about the solution. Sending it by reference to some server, and we know who we're talking about. The choice of credentials becomes a problem. The PSAP can't maintain credentials for everything. Then the PSAP has to provide credentials to you. Can't ignore this.

Bernard - if using TLS [?]

Brian - It needs text on where credentials come from. Section 3.3 (proxy added location) needs more work. If the access network … and doesn't trust … and it adds a proxy. The proxy adds location. Because it's more trustworthy, I don't need the other. The intermediary doesn't have the trust. Could expand the text.

Bernard - Please provide text.

Martin - Add the text and the PSAP credentials to the rough-loc draft. It's confusing in this doc.

Slide 10 - Next steps

Bernard - Would like an intense review to get into -06

Marc - when you submit -05, we'll ask for reviewers.


-----------------------------------------------------------------------
Resource Priority Header (RPH) Registry Management Policy
to IETF Review (5 min)
http://datatracker.ietf.org/doc/draft-rosen-rph-reg-policy-00.txt/
Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-3.pptx
Presenter: Brian Rosen
Intention: Discussion

Brian - This is IESG approved, but 4412 requires standards track to define a new RPH namespace. I wrote this draft to downgrade the IANA policy to make it consensus rather than standards track.

Adam Roach - Please comment on sipcore list.

Marc, as chair - quickly.

Brian - sos only requires expert review. Adding a new top level requires standard track, this is a proposal to change that. Adding [?] expert review, Hannes' doc can be informational. There are no changes to the registry policy.

Richard - please summarize [?]

Marc - I'll have to find it. Let Christer go on with his presentation.




-----------------------------------------------------------------------
URN For Country Specific Emergency Services (20 min)
http://datatracker.ietf.org/doc/draft-holmberg-ecrit-country-emg-urn/
Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-0.ppt
Presenter: Christer Holmberg
Intention: New draft presentation


Slide 4 - alternative 1

Brian - we've recreated X- or P headers.

Christer - We've been told to do this on the list.


Slide 6 - alternative 3

Keith - I don't think this solves the problem of "we may never have to move it". You have one country that wants it. Or three countries that want it, but they don't exist. For example, road side assistance. You may need to cover 2 or more values. The first person in says - I have service offered by the police. The second one - same service, same semantics, but not offered by police. You are still going to have this problem.

Brian - I don't know how to engineer around it. We want review, not first-come-first-served. I support this proposal. Will there be a document that does just this?

Christer - it updates 5031.

BIran - want to downgrade in the same doc.

Henning - There is not a demonstrated need at the moment.

Brian - I don't want this to be held up because it's only defining service URN.

Henning - Don't want to argue about regional. For example, lower 48, not offered in Alaska. Only reason to do sub-services - don't get lower level. Still have a problem with an organizational hierarchy that changes over time - think of the Department of Homeland Security. Advice to experts to consider - is it inherently a police function? Not enforcement of law. Could add that advice. It may not be a big enough problem to create another label. There's no way to go up, no generic emergency service on top of it.

Christer - to clarify - there may be a reason why due to hierarchy but the semantics are the same and should also allow to register.

Henning - that outcome is undesirable and should be avoidable.

Brian - send text

Henning - we don't want to imply [?] The notion of one country is somewhat meaningless.

Christer - and send xml version of 3631[?]

Andrew Allen - who can apply? You have to check that they are a relevant authority.

Christer - it's good to have guidance, but we can't say who can and can't apply.

Brian - good idea, send text. The experts can consider who's asking.

Keith - I sent to the list 2-3 weeks ago. In regard who is asked to reply. the top level. If you don't apply if you can't offer. If you need to move subtypes. For example sos.police.xyz and the police go away. The admin wants the URNs, not the deployers, they are not involved in IETF. That's why we need expert review.

Richard - moving subtypes from one super-type to the other is not a big deal, just define the new one. I don't think "who's asking" is a problem. Check out the wikipedia article on what emergency services are. We can just go ahead and register these.

Brian - this document doesn't do - adding sub-sub-service. There are different hierarchies of policy. Do you want a separate doc?

Christer - I think we need a separate decision.

Brian - I'm raising the issue. People recognize that this is a problem. State and local policy need different URNs.  It doesn't have to be this doc.  I recommend that it is in this doc.

Keith - To do that - just write a letter to IANA.

Brian - only add sub-services after sos. I have an already registered service. sos.police -> sos.police.nnn If IANA doesn't have a problem.

Keith - we want the same policy to apply to sub-sub-types.

Marc, as chair - your coauthor sent request to IANA.

Christer - I was informed just before the meeting. That isn't really about this document.

Marc - we'll handle this with expert review. How many people interested in this work? <12 hands up>

Marc - Any opposition? <none>


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.