[Ecrit] IETF87 Berlin: ECRIT Minutes for 07/29 meeting

[Roger Marshall <[e-mail]>]

Minutes for ECRIT WG Meeting, IETF87 Berlin, meeting date 7/29/2013, 13:00-15:00

If you have any additions or modifications to these minutes, please let
Roger & Marc know via email.  These minutes, along with more detailed notes are pasted below, and are also posted to the IETF87
meeting materials page.

A big thank you goes out to both Jean Mahoney and Randall Gellens for their excellent note-taking.  Thanks also to Shida Shubert for being the Jabber scribe.

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

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

The following contains summarized minutes, followed by more detailed notes.

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

ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin





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

10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall)



Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-9.pptx



Note takers: Jean Mahoney and Randall Gellens



Jabber scribe: Shida Shubert

Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-07-29.html



Chairs presented.





ACTION: Go forward with the draft-ietf-ecrit-country-emg-urn document.



Keith Drage commented that the current milestones have little relationship

to the current charter of the group; suggests rechartering if the group

continues to work on such drafts, or else such drafts should go to DISPATCH



ACTION: Hannes to send milestone updates to the mailing list.

 - draft-ietf-ecrit-trustworthy-location

- draft-ietf-ecrit-unauthenticated-access

- draft-ietf-ecrit-country-emg-urn



ACTION: Chairs to review the charter.





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

20 min * Additional Data related to an Emergency Call (Brian)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss latest changes and if ready for WGLC

slides: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-3.pptx



Brian presented.



There was a discussion about reviewing the document, and adding the IANA registration table to the draft.



ACTION: Brian to discuss IANA registration table on sipcore list.



ACTION: Randall Gellens to add text that the Call-Info header can be a sid.



ACTION: Randall Gellens to fix editorial issues in the draft.



ACTION: WGLC and reviewer reviews of draft-ietf-ecrit-additional-data to be started in parallel.



ACTION: Christer Holmberg and Barbara Stark to review draft-ietf-ecrit-additional-data.



ACTION: Chairs to coordinate reviews from NENA and EENA.







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

10 min * (Brian) Updating Additional Data related to an Emergency Call using Subscribe/Notify (Brian)

http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-7.pptx



Brian presented.



Draft proposes using subscribe/notify to allow updated sensor data to be sent



Uses extension mechanism from Additional-Data to allow subscribe address for updates to be sent as an additional-data block (as per the additional-data draft)



Objection raised to this being done in ECRIT, saying this is a general problem for which there are general solutions



Suggestion to conceptualize not as an extension to additional-data but rather data-only (sensor data sent as CAP in MESSAGE where there is no session), as this narrows the scope and focuses the problem



Discussion followed about using INFO as an alternative solution to using SUBSCRIBE/NOTIFY.



ACTION: Brian to update the draft on how to solve the problem of devices that can't set up a server to receive a SUBSCRIBE.



ACTION: Chairs to determine if a more general RAI solution should be applied.



ACTION: Brian to start the additional-data discussion on the list so that a problem statement can be defined, and a charter item created.





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

15 min. * Trustworthy Location Information (Bernard)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss impact of recent rewrite

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-4.ppt



Bernard Aboba presented.



Added discussions of place shifting, location shifting, time shifting, etc., from previous Martin Thomson drafts



Added discussion of location theft (attacker uses target's location as his/her own)



Room had no feedback on the draft or presentation.



ACTION: Go forward with draft-ietf-ecrit-trustworthy-location pending any final WGLC comments.





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

15 min * eCall - background, current status, and requirements discussion linked to current ETSI work (Ban Al-Bakri)

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-1.ppt



Ban Al-Bakri presented eCall information on behalf of ETSI (i.e., what they want from IETF)



There was a discussion about whether it would be a use case for additional data, if gateways would be used, the requirements surrounding ASN.1, planning for future migration, making any IETF work on it more global.



Some questions from audience regarding requirements Ban mentioned for PSAP to request actions by the IVS and how this fits into Brian's update proposal.



Comments from audience on ASN.1 encoding and why can't XML be used



Comment made regarding ASN.1 and XML being temporary and a means is needed to upgrade later



Comment made to separate the issues of mechanism and encoding



Suggestion made to have IETF define two ways of transporting the same data: ASN.1 for eCall and XML for anyone else



Comment and suggestion that this can be done but needs to be carefully done so as not to appear as though the IETF is messing in eCall



ACTION: Continue eCall discussion on the list.







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

15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes)

http://tools.ietf.org/id/draft-rosen-ecrit-ecall/

Intention: Discussion of draft & WG adoption question

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-2.pdf



Randall Gellens presented.



Comments made about the current charter language that says the group does not work on items that are specific to a regulatory environment, and hence the group could adopt the ACN bits but not the ecall parts



There was a discussion about splitting the document into eCall and ACN drafts. An eCall specific draft is currently not covered in the charter.



ACTION: Chairs to work with the ADs on rechartering to do specific eCall work.





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

10 min * Uniform Resource Name (URN) extension for automatic and manual Emergency Services (Roland)

draft-jesske-ecrit-ecall-urn-extension-01

Intention: Discussion of changes to draft

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-0.pptx



Roland presented on the ecall URN extension for subservices.



Proposes to add police/fire/ambulance/etc., into the ecall service URN



It was pointed out this out as a two dimensional problem and that this presents a combinatorial nightmare.



Suggested that other mechanisms (such as Caller-Preferences) to pass this information but not in the URN.



There was a discussion about how these extensions are not scalable and how they were conflating concepts of "What?" (sos emergency call) with the "How" (eCall, police, fire, ambulance).



Comment made that even automatic and manual should not be in the URN either



No actions.





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

10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (Brian)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

Intention: Discuss recent updates to draft

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-5.pptx



Brian presented.



Data-only call that does not create a session (carries sensor data as CAP message)



Draft changed how CAP message is sent: now as a block of additional-data (and hence can be passed by value or reference)



No discussion other than the timing of the review.



ACTION: Chairs to move draft-ietf-ecrit-data-only-ea to WGLC simultaneously with draft-ietf-ecrit-additional-data.







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

10 min * Service Coverage Scope for Service URN (Brian)

http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/

Intention: Discuss new draft



Brian presented.



Presentation around service coverage scope (geographic scope), so-called "A1", "A2", etc. level of geoprif PIDF-LO, to distinguish from neighborhood watch up to borough, to city or town, to county or parish, to state or region, to entire country



Discussion covered how these scopes weren't really geographical, and some of the taxonomy issues.



Objection heard that this approach conflates geographic division with type of service (see detailed notes)



Vigorous debate on how services are divided up today, between a "pure" architecture and pragmatics.

Comment made that IMS needs something besides a number in the request URI.

More debate, especially from Henning and Ted versus Brian (see detailed notes)



ACTION: discuss draft-mongrain-ecrit-service-coverage-scope-urn on the mailing list.





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

10 min * A LoST extension to support return of complete and similar location info (Brian)

http://tools.ietf.org/id/draft-marshall-ecrit-similar-location

Intention: Discussion of changes to draft

slides:



Brian presented.



Defines an extension to LoST so that location information can be included in a LoST response to a FindService query



Uses are: provide missing fields if location information in request is valid but not complete ("The crrect representation is") -- used when provisioning



Additionally, so it can provide alternatives when location in request is not valid (a "Did you mean?")



Very few people in the room had read the draft.



ACTION: working group to read draft-marshall-ecrit-similar-location and comment on the list.









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

5 min * Open Discussion



No questions



[EOM]







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

///////////////////////////////////////////////////////////////////////////

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

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

Detailed meeting notes as follows, by A. Jean Mahoney

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



ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin



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

10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall)



Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-9.pptx



Note takers: Jean Mahoney and Randall Gellens



Jabber scribe: Shida Schubert

Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-07-29.html



The agenda was bashed on the mailing list and updated.



Slide 4 - Document Status



draft-ietf-ecrit-country-emg-urn-00



Marc Linsner - The WGLC completed today, are there any comments?



No comments from the room.



Marc - How to progress the doc? It won't be presented at this meeting. Any comments?



Brian Rosen - Everyone agreed that the prior version was what they wanted to see. There was substantial list discussion that converged. The author reflected working group consensus in the prior draft.

draft-ietf-ecrit-trustworthy-location-07 - WGLC completed today



Slide 5 - Milestones



Marc - Need to revise the June 2013 for "Trustworthy Location Information draft"



Richard Barnes - The rough-loc draft expired. The AD should talk with the chairs after this meeting. ACTION



Hannes Tschofenig - draft-ietf-ecrit-unauthenticated-access has been sent to IESG



Roger - We will note it as done on the milestones.



Hannes - draft-ietf-ecrit-country-emg-urn should be moved up from December 2013.



Marc - We can move that up.



ACTION:   Hannes to send milestone updates to the mailing list.



Keith Drage - The active working group documents don't match the core charter. Will you recharter?



Marc - you're right about the docs.



Keith - Non-charter docs should go to dispatch.



Marc - We'll review the charter.



ACTION:   Chairs to review the charter.





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

20 min * Additional Data related to an Emergency Call (Brian)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss latest changes and if ready for WGLC

slides: http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-3.pptx



Brian presented the slides, which provided a quick overview of how additional data works, a covered changes to the doc.



Brian - The authors think this is done. No list contention. Just need to do some editorial work.



Randall Gellens - The Call-Info header can be a sid. I can add text after WGLC.



Roger Marshall - I don't think the doc has had a good review for a while. Should request reviews from NENA and EENA since they rely on this doc.  We need two good reviews from the working group.



Marc - has anyone read it?



Brian - Barbara?



Barbara Stark - yes, I'll review it.



Hannes - Christer?



Christer Holmberg - I'm ok to do it.



ACTION:    Christer Holmberg and Barbara Stark to review draft-ietf-ecrit-additional-data.

           Chairs to coordinate reviews from NENA and EENA.



Randall - The reviews should be in parallel with WGLC.



Marc - We need new spin on draft.



Randall - I can do that.



ACTION:   Randall to fix editorial issues, and release the document. When the draft is available, start WGLC and reviewer reviews in parallel.



Keith - Did this document raise the IANA registration table to ... ?



Brian - Yes



Keith - Was there a discussion in sipcore?



Brian - Assuming that there was, but I will raise the issue on sipcore list



ACTION:   Brian to discuss IANA registration table on sipcore list.



Keith - It shouldn't take place ad-hoc.



Brian - The document doesn't create a purpose table. I will raise the issue. It won't be added to the document until we get agreement.





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

10 min * (Brian) Updating Additional Data related to an Emergency Call using Subscribe/Notify (Brian)

http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-7.pptx



Brian presented.



Brian - The PSAP has to control rate of updates. Defines new URI. Send the subscription to. The event package is XML multi-part MIME, there is no new definition here. Just a new block of data. If you send by reference,  can get it. No new mechanism.



There has been a fair amount of discussion. There are other working group participants that want info-block, but then the PSAP couldn't control the rate. The main advantage of this solution is that you get the filter mechanism.



I would like to adopt this document as a working group item.



Marc - Who's read this document?



Room - 5 or so hands



Christer - I would like to adopt the draft. However, a user behind a NAT has to register. However they don't get the credentials, it won't work. That's the main issue. If you use INFO, then it's in the dialog, don't have that problem. If you use SUBSCRIBE, there are issues with reaching the PSAP. In dialog,  it would go to PSAP. This should be discussed.



Brian - For handling devices that can't set up a server to receive a SUBSCRIBE. The next version of the draft will say that they should use a server outside of that. It's the presence problem, and can be solved the same way - use an outside server. The problem with INFO - you have to create filters - copy all of the filters RFC - and reproduce it for INFO.



ACTION: Brian to update the draft on how to solve the problem of devices that can't set up a server to receive a SUBSCRIBE.



Christer - You need it for info package anyway.



Brian - I would have to quadruple the draft and copy everything from the Filters RFC.



Brian - The most common occurrence of this is data-only. There is no session. In the eCall case, there is the call and data so there's a dialog.



Christer - You could establish a session. Updating data.



Brian - The PSAP needs to control that. The PSAP would create the session. The people along the line don't want updates. Only the responder does, but  they aren't in the call path. The want updates after call is over.



Keith - Why is this emergency call specific? Only because the PSAP wants to use it. ecrit should not solve the problem - transmit data once call is in progress. There's a more general solution here.



Brian - You are saying that we need a generic RAI solution for updating data in a SIP message.



Keith - Not necessarily. There are RAI solutions already there. It shouldn't be ecrit in terms of making decision.



Brian - Make chairs make that decision.



ACTION: Chairs to determine if a more general RAI solution should be applied.



Randall - If it's data only, it narrows the scope and fits better with the solution. It's a solution for sending data when you don't have sessions.



Richard - Isn't this solved by additional-data itself - put it in the URI?



Brian - You don't want to just poll since you don't know when data changes.



Richard - Subscribe to a SIP URI.



Brian - That's what I said. It's a block of additional data. It's a URI, you can subscribe to it.



Hannes - We had a discussion about data-only being sent around without session. It was conflated with this draft on the list by Ivo.



Brian - When you look at discussion, the subject references data-only, not additional-data. There's 7 blocks of data, only 2 would have updates.



Christer - The use case was data only. There is no session.



Brian - INFO won't solve that problem since there's no session.



Christer - You can establish the session.



Brian, Hannes - No! We don't want to open a session.



Brian - there's an alternative that folks want to see. Need to define a problem statement, get a charter item, and get drafts that fit.



ACTION: Brian to start the additional-data discussion on the list so that a problem statement can be defined, and a charter item created.



Randall - Why is not in the data-only draft?



Brian - It was suggested that it be split out.





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

15 min. * Trustworthy Location Information (Bernard)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss impact of recent rewrite

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-4.ppt



Bernard Aboba presented.



Bernard - There was an issue raised in WGLC, which ended today. Issue 15 - the definitions could be revised, made simpler. Any feedback?



Room had no feedback.



Marc - Sounds like we're ready to go forward pending end of WGLC.



Brian - I have a few more hours to get my comments in.



ACTION: Go forward with draft-ietf-ecrit-trustworthy-location pending any final WGLC comments.





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

15 min * eCall - background, current status, and requirements discussion linked to current ETSI work (Ban Al-Bakri)

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-1.ppt



Ban Al-Bakri presented.



Questions:



Christer - This is a use case with the session and additional data.



Ban - The PSAP can request additional data.



Christer - INFO would then be the appropriate mechanism. Maybe the solution should be split into session based and non-session based.



Brian - Reasons for update that survive the call



Ban - The PSAP can request update to the MSD. Once the voice call is released, there may be a call back maybe.



Brian - Can the MSD call back? The PSAP is not interested in updates unless there's an error. But the responders want the data. If you have updates, the responders want them.



Ban - the EU requirement is that the PSAP should keep on the call until responders are on the scene.



Randall - eCall requirements are different that requirements for updates for sensor data - the sensor knows that there are updates, not the PSAP.



Hannes - I don't care about specific encoding - text or JSON. We can ship data around.



Hadriel Kaplan - Both you guys need to go up a level and describe how the responder gets the data. If they get it from the PSAP, then the SUBSCRIBE goes to that.



Brian - The PSAP doesn't want to be in the path.



Hadriel - ASN.1 is a legal requirement?



Ban - Yes.



Hadriel - If the EC wants to support a SIP-based service, they should just point to RFCs.



Randall - The more IETF gets into business of telling EC how to do eCall, the less progress we make. We can tell them how SIP can solve it.



Hadriel - If you can't specify to the PSAPs, then we need a gateway.



ban - Should be transferred as a package. Need minimum impact on the network. Don't want extra network elements.



Hadriel - But if you are working with existing infrastructure.



Hannes - In US, the BES (?) data looks different than eCall data.



Hadriel - Why is this specific to eCall? We should design globally.



Randall - Even if it's encoded in XML, it doesn't ensure that the vendor's implementation (like OnStar) would be clear. Can work towards commonality, but can't just jump there.



Henning - The solution should be long-lived - 20 year old cars break down. As you migrate with car model years. PSAP software is provided by a small number of vendors. Need mechanism in place where gradual migration is possible. Have you thought about that?



Ban - We have discussed this.  Too much work right now.



Henning - In SIP we've tried to separate format. It's handled with a negotiation or a label, versioning scheme. You don't want to throw out the whole thing if the format changes.



Keith - We will continue this discussion on the list. Be clear about transfer syntax or the encoding. Need to be specific.



ACTION: Continue eCall discussion on the list.



Brian - We'll define block of additional data as chunk of ASN.1, could we not also have XML with the same data? Multipart alternative.



Randall - Can use MIME type for ASN.1 and then can wrap it later to upgrade.



Brian - For data structures that have already been defined, put them in a MIME block. Could and should define an XML block as an alternative. Allow someone else to use the same idea, not in EU law.



Ban - 3gPP should specify which block to use.



Randall - Say how to do eCall the way it is now. And then how to do it more generally.



Brian - Exactly.



Roger - Is there a draft to describe this?



Ban - The EC is funding this work. Please sign the attendance sheet - so it can get in kind funding.



Keith - Have you checked with secretariat on this process? You should use the blue sheets.



Ban - It's ok, I've checked with the secretariat.



Marc - If you don't want to sign, just pass it on.









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

15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes)

http://tools.ietf.org/id/draft-rosen-ecrit-ecall/

Intention: Discussion of draft & WG adoption question

Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-2.pdf



Randall Gellens presented.



ACN - Automatic crash notifications



Brian - The current draft is informational. If we split it, the eCall draft would be normative. Would define block of additional data with MSD.



Ban - I support this, but the info draft will be ...



Brian - will be ACN.



Marc - Split the docs?



Hannes - Randy's comment - We trying to make doc generic so it works everywhere. Routing functionality, SIP setup is generic, but for specific vendors, they don't care.



Keith - ACN is not an emergency call?



Randall - It is.



Keith - How does this fit in the charter?



Randall - these are all emergency calls.



Ted Hardie - I agree with Keith. If you split into ACN and eCall, eCall is specific regulatory environment, which the charter forbids work in. You have to recharter to adopt eCall. You could adopt the ACN bits now.



Marc - chairs will work with ADs on recharters.



ACTION: Chairs to work with the ADs on rechartering to do specific eCall work.





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

10 min * Uniform Resource Name (URN) extension for automatic and manual Emergency Services (Roland)

draft-jesske-ecrit-ecall-urn-extension-01

Intention: Discussion of changes to draft



Presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-0.pptx



Roland presented.



There's eCall for police, eCall for fire.



Ban - 3gpp has the requirement. However, haven't seen the requirement on car manufacturers to provide this info. Needs to be regulated across Europe. There are liability issues here. When you have multiple categories, you can't fork the voice call to all the categories. You need to route to the PSAP that supports eCall, and they find appropriate services. Defining multiple categories is in the network, and is also regulated.



Roland - I have received similar comments. There are PSAPs that can support eCall and others not.



Henning Schulzrinne - There are two dimensions here - who gets the call? Police, Fire; Automatic, Manual. You have combinatorial explosion problems. Anytime you add a service (health monitoring (fallen can't get up), you have to update this. We use this as a key in LoST, but we route on location, on language capabilities. this leads to a non-scalable solution, and you have to have fallbacks, etc. If we need a coarse-grain routing, we have mechanisms that do that without the explosion.



Roland - We have an existing implementation, description in 3GPP. Drawback currently. Don't want to redo anything at the IT level. If you only have eCall implemented.



Henning - You are assuming a hierarchy, the more dimensions you have, the harder to determine a hierarchy. OnStar gets police, ambulance, and then routes. If you add poison control, it would go to OnStar and they would deal with it. You need a responder hierarchy. We can change protocols. If it's not in LoST, add it. You make complicated tradeoffs. For eCall, you don't route differently for automatic and manual.



Keith - IMS sticks URN in the URI and doesn't use LoST. There are scenarios where neither of these work. My car needs to work in any country it goes to. Work in countries that don't support eCall, or support the first hierarchy of police, fire.



Ted Hardie - A URN service sos is a "what?". You are conflating a "how?" Manual and Automatic are also "hows?". Need to do in 2 urn namespaces to get "how" away from "what".



Hadriel - I'm agreeing with Ted and Keith. eCall shouldn't be in Brian's draft.



Ban - Auto and Manual indicate the target. Could be different PSAPs.



Ted - It's not a different "what". sos.fire - who I want the response from. If automatic gives me a different responder, then it's different. If it's just a different PSAP, then it's not.



Henning - There are all kinds of things to route on. Fire department - the truck and the equipment, the people - are the same. In terms of trustworthiness.... The PSAPs use all sorts of differentiators. It's a gray zone. A URN is not the only thing to use. Not the details on agency, whether it was mediated by alarm company, not valuable in a URN. You can only have 1 hierarchy. Appropriate default responses.



Ban - Need to keep mind in automatic, it's part of the flag.



Henning - You need to look at the routing behaviors that you want, then what are your tools to make the info available to the required parties. And where is it available, where could it be added. If you look at PSTN - call types - pay phone, prison. Labeled them ...





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

10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (Brian)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/

Intention: Discuss recent updates to draft

presentation:

http://www.ietf.org/proceedings/87/slides/slides-87-ecrit-5.pptx





Brian presented.



Brian - Other than the discussion of using a block of additional data, I think the doc is settled and is ready to go. No one has raised objections.



Marc - Move to WGLC next week.



Brian - You have to do WGLC simultaneously with additional-data.



ACTION: Chairs to move draft-ietf-ecrit-data-only-ea to WGLC simultaneously with draft-ietf-ecrit-additional-data.







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

10 min * Service Coverage Scope for Service URN (Brian)

http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/

Intention: Discuss new draft



Brian presented.



Henning - What about transit police, or campus police, secret service, etc?



Brian - They have geographic boundaries.



Randall - But roads can be confusing - you think it's a public road, but actually you need park police.



Ted - If it's based on location.



Brian - What if you are sitting in one of these buildings, but want the state police.



Ted - You are conflating geographic dominion with different services. Fire service - halon versus water. It's a "what". Police provide different services - put that in a "what" rather than "where". Describe the "what" in the URN - for instance, drug-enforcement.



Brian - Interesting idea, but that isn't the way services are organized, there is no taxonomy, I couldn't come up with a way to build a device. RIght now people use phone numbers.



Ted - it's in people's brains.



Brian - I don't know how to deal with the taxonomy issues.



Ted - But this is muddying the service URN because there is muddiness in the background.



Brian - there are different numbers for different services.



Ted - Some human will have to pick a department.



Brian - There's no solution.



Ted - If they need to call a specific phone number, they pick up the phone. You know the difference between the park service and the police.



Keith - The draft goes into irrelevant geographic details. Say you want the police force that handles kidnapping versus theft.



Brian - If we could just start over.



Keith - It's too late. But in each country has distinguished between them.



Marc - This discussion is cutting into your next presentation, brian.



Keith - Want to use something in the request URI, not the dialed number.



Henning - Geography doesn't work. It's not clear to a citizen. There's comingling. If someone calls 911, and if I forward their call to the metro police. There is no reason for the cities have the same organizations - it's database identifiers.



Brian - This is an external problem. Start with a service phone number, map to service URN, get a URI to route the call. The current drafts don't solve this.



Henning - Is it solvable?



Brian - You want a service number for kidnapping.



Hadriel - You call 911



Brian - This issue isn't applicable for US.



Hadriel - We don't need to convert to URN. Dial Emergency on your phone, and it works. If you need to call DEA - then you can look that up and call. It's not a real emergency.



Marc - Take to the list.



ACTION: discuss raft-mongrain-ecrit-service-coverage-scope-urn on the mailing list.





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

10 min * A LoST extension to support return of complete and similar location info (Brian)

http://tools.ietf.org/id/draft-marshall-ecrit-similar-location

Intention: Discussion of changes to draft

slides:



Brian presented.



Is there sufficient interest here? The NENA guys are interested.



Marc - How many people have read?



2 or so



Brian - please read and comment on list.



ACTION: working group to read draft-marshall-ecrit-similar-location and comment on the list.



Randall - Is this the same proposal that came up in geopriv?



Brian - This is a LoST thing. Not geopriv.



Barbara - I read this draft, and my colleague has asked me to support it. I thought it looked good.









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

5 min * Open Discussion



No questions



[EOM]





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

///////////////////////////////////////////////////////////////////////////

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

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

Detailed meeting notes as follows, by Randall Gellens

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



Here are my notes from the ecrit session:



*           Updated milestones

*           Keith Drage comments that the current milestones have little relationship to the current charter of the group; suggests rechartering if the group continues to work on such drafts, or else such drafts should go to DISPATCH



*           Brian Rosen presents on status of additional-data draft

*           Editorial revisions from Randy were lost in recent update from Hannes

*           Randy will update document this week; WGLC will start next week

*           Christer and Barbara agree to do reviews



*           Brian Rosen presented on sub-not draft

*           Draft proposes using subscribe/notify to allow updated sensor data to be sent

*           Uses extension mechanism from Additional-Data to allow subscribe address for updates to be sent as an additional-data block (as per the additional-data draft)

*           Allows PSAP (or other recipient) to control rate

*           Brian asks for WG adoption

*           Christer says he has an issue: data updates don't go in session, could be a problem with credentials and access (separate credentials needed to successfully subscribe, server may not be accessible to arbitrary clients).  Brian says in that case the device uploads the update to an externally-accessible server and sends an address on that server

*           Christer prefers to send updates in INFO in the session, but Brian objects because there is no mechanism now for PSAPs (or other recipient) to set filter/throttle to control rate of updates, and also because in the data-only case there is no session, and also because the party interested in updates may not be the PSAP itself but rather a responder (who isn't in the call path)

*           Keith Drage objects to this being done in ECRIT, saying this is a general problem for which there are general solutions

*           Randy suggests that this should be conceptualized not as an extension to additional-data but rather data-only (sensor data sent as CAP in MESSAGE where there is no session), as this narrows the scope and focuses the problem

*           Much further discussion



*           Bernard presents on trustworthy-location

*           Added discussions of place shifting, location shifting, time shifting, etc., from previous Martin Thomson drafts

*           Added discussion of location theft (attacker uses target's location as his/her own)

*           Document passed WGLC



*           Ban presented on eCall on behalf of ETSI (what it is, what they want from IETF)

*           Some questions from audience regarding requirements Ban mentioned for PSAP to request actions by the IVS and how this fits into Brian's update proposal.

*           Randy says that the requirements that Brian is solving (where sensor knows it has updates) and in eCall (where PSAP knows what it wants) are different and we should not get into details now

*           Comments from audience on ASN.1 encoding and why can't XML be used

*           Henning has comments regarding ASN.1 and XML being temporary and a means is needed to upgrade later

*           Keith Drage says we need to separate the issues of mechanism and encoding

*           Brian suggests that the IETF define two ways of transporting the same data: ASN.1 for eCall and XML for anyone else

*           Randy suggests that this can be done but needs to be carefully done so as not to appear as though the IETF is messing in eCall



*           Randy presented on the ecall draft

*           Keith asks how any of this is in charter

*           Ted Hardie points to charter language that says the group does not work on items that are specific to a regulatory environment, and hence the group could adopt the ACN bits but not the ecall parts

*           Chairs will take this under advisement and consider rechartering



*           Roland (D-T) presented on the ecall URN extension for subservices

*           Proposes to add police/fire/ambulance/etc. into the ecall URN (as proposed in the eCall draft), either before or after the 'ecall' portion

*           Ban asks about the concept before the draft; says there is a 3GPP requirement and Stage 3 text providing for subservices but that this doesn't apply to cars, and further any such facility (e.g., cars reporting that they are on fire) needs to be standardized.  Ban also points out that this would be a problem for the MNO to route the call -- currently eCall calls are routed to an eCall-capable PSAP; how would an eCall with a subservice be routed?

*           Henning says that there are two dimensions to the problem: call routing (ecalls are routed to ecall-capable PSAP and it's not likely that there will be dedicated PSAPs for eCalls from vehicles on fire, vehicles with poisoning victims, etc.) and that this presents a combinatorial nightmare.  Henning suggests using other mechanisms (such as Caller-Preferences) to pass this information but not in the URN.

*           Keith Drage says this needs to work in countries that don't support eCall, and in countries that don't support police/fire/ambulance/etc. as the top level.

*           Ted Hardie says don't conflate the what (sos emergency call) with the how (eCall, police, fire, ambulance)

*           Hadrien says even automatic and manual should not be in the URN either

*           Ted says routing to a different place is a different "how" and not a different "what" and so manual vs automatic shouldn't be in the URN but 'police', 'fire', etc. are different "what"s.

*           Henning echoes Ted's point that the URN is supposed to indicate who you expect to show up (police, fire, etc.)

*           Henning proposes using a different mechanism for conveying this information (and discusses the old PSTN concept of call types such as pay phone, prison, etc.)

*           Comment to use feature-tag



*           Brian presents on data-only draft

*           Data-only call that does not create a session (carries sensor data as CAP message)

*           Draft changed how CAP message is sent: now as a block of additional-data (and hence can be passed by value or reference)



*           draft-mongrain-ecrit-service-coverage-scope-urn-00

*           Brian discusses service coverage scope (geographic scope), so-called "A" level of geoprif PIDF-LO, to distinguish from neighborhood watch up to borough, to city or town, to county or parish, to state or region, to entire country

*           Ted objects that this is conflating geographic division with type of service; if different police forces provide the same type of response, it doesn't belong in the "what" difference

*           Brian says that's not how services are organized today, where different numbers are used

*           Brian and Ted argue about architectural purity versus pragmatics

*           Keith says we do need something in the Request-URI so IMS can use it, just not the dialed number

*           Brian says this comes down to: we start with a service number that a user dials, which is mapped to a service URN, which is used to route to a responder

*           More debate, especially from Henning and Ted versus Brian



*           Brian presents on similar-location

*           Defines an extension to LoST so that location information can be included in a LoST response to a FindService query

*           Uses: provide missing fields if location information in request is valid but not complete ("The crrect representation is") -- used when provisioning

*           also provide alternatives when location in request is not valid (a "Did you mean?")



--

Randall Gellens







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.