IETF77 – Anaheim ECRIT Meeting Minutes Day: Monday Date: 3/22/2010 Time: 9:00AM-11:30AM Note-takers: Paul Kyzivat; Byron Smith Compiler: Roger Marshall Some editorial comments from the note-taker are represented in "[ ]". Roger opened the meeting at 9 AM for the note-well and bluesheets. A memento (coffee!) was presented to Cullen Jennings for his good RAI AD service. * Agenda Bashing, Marc – No changes since last version distributed. Leadership of ECRIT announcement: Hannes Tschofenig (outgoing for new responsibilities), Marc Linsner remaining, and Richard Barnes as incoming co-chair of the working group. Marc mentioned that none of the chartered milestone items were going to be discussed in today's meeting. Report on Ad-hoc Interim meeting on Feb 11 on PSAP callback. Marc stated that there is planned 20 minutes to discuss chartering at end of today’s meeting. * Introduction to IEEE ESSG (Emergency Service Study Group) Geoff Thompson - ESSG Co-chair Geoff Thompson brought a report from the IEEE 802 Emergency Service Subgroup. IEEE is creating new 802.23 WG on March 25, more narrow than 802.21, looking at Citizen to Authority only. It does include callback. Arnoud Vanwijk raised an issue - was troubled that real time text or teletext was not mentioned. Hannes' response – asked presenter for clarification as to whether this new wg was concentrating on voice only to the exclusion of multimedia? Geoff replied that no there was no intent to exclude multimedia. Reference to VoIP really was intened to mean multimedia. IEEE Wants to respect work of ECRIT, desires to liaison with ecrit on location for 802 L1/L2. Shared their planned meeting schedule. No documents yet, drafts of documents to be made available to ECRIT on liaison basis. Drafts will be available to mailing list participants. Details in the slides. Significant discussion: James Polk commented he has heard rumors that 802 wants to do some things at L1/l2 because they have issues with things that ietf has done at L3. James Winterbottom commented that location work should be in geopriv, not ecrit. He expressed desire for a ubiquitous solution, not one dependent on 802. Geoff responded that they are focusing on emergency services uses of location. (But ecrit is depending on generic location.) Cullen Jennings stated that IAB must decide about liaison, but it probably will probably agree. But where it gets handled will be determined by them. * Unauthenticated Emergency Services (Dirk Kroeselberg) http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access Presentation on draft relating to emergency services for devices lacking authentication and authorization. Lack of ISP authentication, lack of VSP/ASP authentication. Already agreed to as a WG item, yet it is not yet a wg item, since it requires rechartering of the WG. Henning Schulzrinne complained that no progress is being made – that bringing these up serves no purpose. Wants to switch to technology discussion. How to “open” network for emergency use without creating huge security holes. He had numerous issues with the doc as it exists. He asserted that this may not have a technical solution, but may be better solved as a legal problem – with legal consequences to abuse rather than technical prevention of abuse. Bernard: Document does not reflect knowledge what is really out there in real access networks. Henning: Problem is unbounded, a flood of traffic may cause re-routing, for example, no reasonable way to do this. Dirk: Hard problem, no easy solution. Marc: Can you expect all access networks to support? Dirk: no impact – handled at another layer. Henning: We need to understand why this problem is hard, and what are the trade-offs? What are the (probable) consequences. Document challenges, may be all we can do. Geoff Thompson: What could be done as part of the solution of what can be done at layer 1 – layer 2 with IEEE, who may have tools. Hannes: Must use the tools we already have, we can’t leave to jurisdictions. Bernard: Keep in mind potential backward compatibility issues. Existing RFC 5216 contradicts this draft. Caution, the draft could create something that will never be used, zero deployment. Chair encourages discussion to be continued offline. Concerns were raised about "Decorated NAI" that could probably not be supported. (missing some context around this). Request to continue the discussion by email. * Transformations ID (James Polk) http://tools.ietf.org/id/draft-polk-ecrit-lost-transformations-urn A service urn for transformations. E.G., urn:services:transformations (Example: Geo – civil transformations). Reviews of previous version of this draft resulted in request to generalize it - hence the general "transformations-urn" approach. Option proposed to merge with draft-george-geopriv-address-translation. If LoST server understands URN, can respond with conversion. Open issues: native HTTP or HELD, or both. Henning Schulzrinne expressed that (geo) transformation tend to regional, e.g. geocoding in France would not be provided by a US service, etc. This is backwards – before specifying URNs, is there a set of services (with common properties) that we agree upon, then we can specify transformational services. Work from what we want to accomplish then work toward mechanisms. Brian Rosen agreed and wanted to take it to geopriv. James stated he was asked to generalize to arbitrary transformations, (that are not related to location), which are out of scope for geopriv. Argument back – arbitrary transformations is too big, but need to decide exactly the scope. James thinks this is regionally based transformations, LoST is what deals with regions, and therefore, it is handled by ecrit. James Winterbottom: What about pizza? There was request to continue the discussion offline. * ECRIT Direct (James Winterbottom) http://tools.ietf.org/id/draft-winterbottom-ecrit-direct This draft proposes a special registration service for emergency calls, to support callback. Supports those who have no VSP. Asserts that PSAPS only accept requests from sources they trust. This may be from known ISPs and/or known VSPs. ISPs are the new LECs. What layers effectively subject to national regulation? Devices -> Access Networks -> Internet –> vsp -> Emergency Calls centers. (VSP mitigates regulatory boundaries?) Calling for a “slim” emergency client attached to various applications, e.g., Internet games. Security: 1) VSP validates request originates within PSAP jurisdiction, and 2) ISP ensures call originating from within PSAP jurisdiction. Proposes (Trusted) relationships between ISPs and PSAPs. Bottom line – “PSAP only accepts requests from source that it trusts.” Marc: Isn’t this contrary the initial concepts at the beginning of ecrit? Henning: Our role is not write/lobby for regulations – our job is to provide alternatives fairly argued and illuminating technical issues. Don’t let similarity to traditional systems guide policy. We must illuminate options by identifying options and implications for politicians and regulatory authorities. Brian: NENA doesn’t want the VSP to be bypassed - ECRIT should promote that. NENA wants to allow access from VSP, and will allow calls from anywhere. Calls will be accepted from anywhere… James W: Got only *one* communication from NENA. Brian: stated he didn't find this kind of registration of any value. Geoff Thompson: Agreed about PSAP trust. Believes “bottom line” will be true in a world of political realities. Roger M: Lends support to Brian’s NENA comments, wants to retain VSP in the call setup, and points out NENA's motto as, “calls from any device, anytime, and from anywhere.” James W: wants to hear how this works for devices that don't have explicit calling capability, such as game machines. [I noted no outcome or next steps.] * Additional Data (Brian Rosen) http://tools.ietf.org/id/draft-rosen-ecrit-additional-data Intention: Initial document version. Presentation of the history and the origin of the work. Goal is to determine interest. Examples of this data are: SP contact, subscriber data, sensor data, what kind of service, what kind of device. James W: Entities that hold some of the information of interest may not be in the originating Brian: NENA wants IETF to expand this internationally. Byron: Is the NENA protocol based on NIEM? (US: National Information Exchange Model). (?): answer is no. This sort of information is open ended. Martin Thomson: Is this much like presence data? Henning: Closely related to presence specifications. Henning wanted to ensure that the mechanism will allow expanding the data included without requiring chartering a WG – needs to be easy to add - separated namespace for internationalization. Intent to issue another version – will look into presence relationship. * Completing the Request Location (Brian Rosen) http://tools.ietf.org/id/draft-rosen-ecrit-completed-location-00.txt [Above is document name in agenda and online. The presentation showed the name draft-rosen-ecrit-completed-data, which apparently doesn't exist. I presume these refer to the same document.] Intention: Discussion of whether the group should work on this document. The document is making a normative change to RFC 5222. LoST needs enough fields to uniquely identify a specific address. Extends LoST by adding elements/attributes to existing elements, via a New RELAX NG schema. James W requested that if the schema is being changed, please add extension points so that future enhancements won't require schema changes. Hannes: (sarcastic remarks..) Richard B: Does this include transformations? Ans(?): No Martin Thomson: Does this include alternatives, or does error message contain alternatives? Ans: No, not yet, may end up being a different mechanism. Stephen McCann: At what point is credit card information requested? Henning: Not mandatory, “extra” feature, not USPS zip code lookup protocol, tweak language. Henning also wants something added to the draft explaining what is intended to be used for, and not used for. Brian asked to have that captured in the notes. * Data Only Emergency Calls (Brian Rosen) http://tools.ietf.org/id/draft-rosen-ecrit-data-only-ea This is about sending an emergency "call" when there is no media. Use CAP format, OASIS standardized, in SIP MESSAGE method. Uses all the same mechanisms for routing. This is “non-human initiated,” e.g. sensor, no SDP / RTP. CAP has no standardized message transport or routing, so we propose to use SIP. Could be an “aggregator” between sensor and PSAP. Stephen McCann: why not use HTTP. Ans: Reason is there is no routing mechanism for HTTP, whereas there is for SIP. Richard Barnes asked why anything needs to be standardized - just send MESSAGE. Brian: there is need at least for a MIME type. Geoff: Some 802.11 networks cannot handle voice. Is there a different class of service? A: no, looks just like any other “call.” Keith D: Already defined data format for PSTN, the (EU) eCall that has a defined format. Brian: It's not CAP. CAP is the recognized format for this kind of messaging. * Emergency Text Messaging using SIP MESSAGE (Henning) http://tools.ietf.org/id/draft-kim-ecrit-text-00.txt Intention: Discussion about what the group should do in this area. Problem: How to use page-mode messaging for emergency via the SIP MESSAGE method? (Session-less IM / SMS. Successive messages could go to different call-takers, even different PSAPs. Implication is that a complete "interaction" may include multiple message exchanges, yet there is no session. Risk that these don't get to same place. Proposes some architecture for this, including specifics for SMS. Proposed solution is to create “softstate” in ESRP so successive messages go to same call-taker. Related issue for SMS: How to do location delivery, no p-ANI, no good way to resolve location. Keith D: Isn’t this 3GPP issue? What value does IETF contribute? 3GPP is working on gateways 3GPP. Keith wants issues with SMS deferred to 3GPP. Also, wants session mode IM, not page mode used. Ans(?): two options: either find a way to make page mode work, or do nothing. Ben Campbell: Said this seems to build a session for MESSAGE for a special use – thinks if we are going to do it, then do it in a more general way. (We have previously forbidden INVITE dialogs being established for use with MESSAGE.) James W: Why not have client (outside ERSP) do it? Brian: 90% of the issues are SIP protocol conversion. Supports document, must be done, must address location. * Service URN Update and Service Classification (Henning) http://tools.ietf.org/id/draft-forte-ecrit-service-classification http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy Goal to classify non-emergency services. Make it easy to do – don't require standards action for every one – just expert review. Non-emergency uses of location based services, N11 services, (e.g., pizza!) etc. Attempt to classify non-emergency services, 80% coverage, not comprehensive, but beats no coverage at all. Propose a more “open” registration policy, update RFC5031, “expert review” of top levels of classification. Alex Mayrhofer: reuse the classifications used for street map software, automated importation mechanisms, car services, etc. Ans(?): send pointer to list. Example of issue: “Petrol” versus “gas” stations. James W expressed disbelief this sort of classification is possible to do, hence impossible to define expert reviewers. Henning would be satisfied with an 80% solution, which he thought would be feasible. Cullen thought it is possible but people in this group aren't the ones to do it – wants to find an existing list to use. Cullen: This group isn’t librarians; we won’t do a good job. Looking for how we can pick a good piece of work and “steal” it. Any list is better than no list, but we should be able to find a good one. Whatever we put in we cannot take out. Find a good “authority” quickly. (Yellow pages may be organized to require multiple listing, driving revenue!) Much discussion. * Milestones/Charter – request to ADs for permission to take on new work. Cullen said new work was being limited until phonebcp was done. Now it is, so ADs are more receptive to new work. We are now in a position to move forward. Robert Sparks: ECRIT is at a natural point for a re-chartering effort, and requested input of priorities for what work to take on, and why. Cullen doesn't want to replicate the kind of group SIPPING was. Chairs, Robert, and othere on list will discuss where to go next. Henning – big decision: have a LoST protocol to deal with, and lots of issues about location services, either in geopriv or somewhere. If geopriv isn’t the right place, then we need to make a new place. James Polk – asked about RPH-namespace – that is not chartered but many think it is essential. [Ed.] Room query determined there were at least three implementing it. More discussion, not conclusive. Adjourned 11:27 AM * Describing Boundaries for Civic Addresses (Martin Thomson) http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-00.txt [Ed., This was dropped from the agenda, due to lack of time, w/agreement from presenter.]